¿por qué son costosas las llamadas al sorteo?

Question

suponiendo que los datos de textura, vértice y sombreado ya están en la tarjeta gráfica, no es necesario que envíe demasiados datos a la tarjeta. hay unos pocos bytes para identificar los datos, y presumiblemente una matriz de 4x4, y algunos otros parámetros surtidos.

¿de dónde vienen todos los gastos generales? ¿las operaciones requieren un apretón de manos de algún tipo con el gpu?

¿por qué el envío de una sola malla que contiene un grupo de pequeños modelos, calculados en la CPU, a menudo más rápido que el envío de la identificación de vértices y las matrices de transformación? (la segunda opción parece que debe haber menos datos enviados, a menos que los modelos sean más pequeños que una matriz 4x4)

Answer 1

En primer lugar, supongo que con "llamar llamadas", te refieres al comando que le dice a la GPU que represente un cierto conjunto de vértices como triángulos con cierto estado (shaders, blend state, etc.).

Las llamadas al sorteo no son necesariamente costosas. En las versiones anteriores de Direct3D, muchas llamadas requerían un cambio de contexto, que era costoso, pero esto no es cierto en las versiones más recientes.

La razón principal para hacer menos llamadas al sistema es que el hardware de gráficos puede transformar y representar triángulos mucho más rápido de lo que puede enviarlos. Si envía pocos triángulos con cada llamada, la CPU lo obligará por completo y la GPU estará prácticamente inactiva. La CPU no podrá alimentar la GPU lo suficientemente rápido.

Hacer una llamada de un solo sorteo con dos triángulos es barato, pero si envía muy pocos datos con cada llamada, no tendrá suficiente tiempo de CPU para enviar tanta geometría a la GPU como podría haberlo hecho.

Hay algunos costos reales al realizar llamadas, requiere configurar un montón de estado (qué conjunto de vértices usar, qué sombreado usar y demás) y los cambios de estado tienen un costo tanto en el hardware (actualizando un grupo de registros) y en el lado del conductor (validando y traduciendo sus llamadas que establecen el estado).

Pero las llamadas al costo de sorteo principal solo se aplican si cada llamada envía muy pocos datos, ya que esto provocará que esté vinculado a la CPU y le impida utilizar el hardware por completo.

Al igual que dijo Josh, las llamadas al sorteo también pueden hacer que el búfer de comando se vacíe, pero en mi experiencia eso suele ocurrir cuando llamas a SwapBuffers, no cuando envías geometría. Por lo general, los controladores de video intentan almacenar tanto como puedan (con algunos fotogramas a veces) para extraer todo el paralelismo posible de la GPU.

Debería leer la presentación de nVidia Batch Batch Batch!, es bastante antigua pero cubre exactamente este tema.

Answer 2

Las API de gráficos como Direct3D traducen sus llamadas de nivel API en comandos independientes del dispositivo y los ponen en cola en un búfer. Enjuagar ese buffer, para realizar el trabajo real, es costoso, tanto porque implica que ahora se está realizando el trabajo real, y porque puede incurrir en un cambio de usuario a modo kernel en el chip (y viceversa), que no es eso barato.

Hasta que se vacíe el búfer, la GPU puede realizar algunos trabajos de preparación en paralelo con la CPU, siempre que la CPU no realice una solicitud de bloqueo (como asignar datos a la CPU). Pero la GPU no preparará -y no puede- todo hasta que realmente necesite dibujar. El hecho de que algunos datos de vértices o texturas estén en la tarjeta no significa que estén arreglados apropiadamente todavía, y pueden no ser arreglables hasta que los diseños de vértices estén establecidos o los sombreadores estén vinculados, etcétera. La mayor parte del trabajo real ocurre durante el comando de vaciado y extracción de llamadas.

DirectX SDK tiene un section on accurately profiling D3D performance que, aunque no está directamente relacionado con su pregunta, puede proporcionar algunos consejos sobre lo que es y no es caro y (en algunos casos) por qué.

Más relevante es this blog post (y los mensajes de seguimiento here y here), que ofrecen una buena visión general del proceso lógico de bajo nivel de funcionamiento de la GPU.

Pero, en esencia (para tratar de responder a sus preguntas directamente), la razón de las llamadas son caras, no es que no necesariamente una gran cantidad de datos a transferir, sino que hay una gran cantidad de trabajos más allá de simplemente enviando datos a través del bus que se difieren hasta que se vacía el búfer de comando.

Answer 3

Respuesta corta: el controlador almacena una parte o la totalidad del trabajo real hasta que llame al sorteo. Esto se mostrará como una cantidad relativamente predecible de tiempo invertido en la llamada al sorteo, dependiendo de cuánto ha cambiado el estado.

Esto se hace por varias razones:

• para evitar hacer el trabajo innecesario: Si (innecesariamente) configura el mismo estado varias veces antes de dibujarlo puede evitar hacer el trabajo caro cada vez que esto ocurre. Esto realmente se convierte en una ocurrencia bastante común en una gran base de código, digamos un motor de juego de producción.
• sea capaz de conciliar lo que internamente son estados interdependientes en lugar de procesarlos inmediatamente con información incompleta

respuesta (s) alternativo:

• el buffer del controlador utiliza para almacenar comandos de representación se completa y la aplicación está efectivamente esperando a que la GPU procese parte del trabajo anterior. Esto generalmente se mostrará como bloqueos de tiempo extremadamente grandes en una llamada al azar dentro de un marco.
• Se ha alcanzado el número de fotogramas que el controlador puede almacenar en búfer y la aplicación está esperando a que la GPU procese uno de ellos. Esto típicamente se mostrará como un gran bloque de tiempo en la primera llamada de dibujo dentro de un cuadro, o en Presente al final del cuadro anterior.