¿por qué las llamadas de sorteo son caras?


Asumiendo que los datos de textura, vértice y sombreado ya están en la tarjeta gráfica, no necesita enviar muchos datos a la tarjeta. hay unos pocos bytes para identificar los datos, y presumiblemente una matriz 4x4, y algunos otros parámetros variados.

Entonces, ¿de dónde viene toda la sobrecarga? ¿las operaciones requieren un apretón de manos de algún tipo con la gpu?

¿ Por qué enviar una sola malla que contiene un montón de modelos pequeños, calculados en la CPU, a menudo más rápido que enviar el vértice id y matrices de transformación? (la segunda opción parece que debería haber menos datos enviados, a menos que los modelos sean más pequeños que una matriz 4x4)

Author: notallama, 2011-01-31

3 answers

En primer lugar, asumo que con "dibujar llamadas", te refieres al comando que le dice a la GPU que renderice un cierto conjunto de vértices como triángulos con un cierto estado (sombreadores, estado de mezcla, etc.).

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

La razón principal para hacer menos llamadas de dibujo es que el hardware de gráficos puede transformar y renderizar triángulos mucho más rápido de lo que puedes enviarlos. Si envía algunos triángulos con cada llamada, estará completamente vinculado por la CPU y la GPU estará en su mayoría inactiva. La CPU no podrá alimentar la GPU lo suficientemente rápido.

Hacer una sola llamada de 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 tener.

Hay algunos costos reales con hacer llamadas de sorteo, requiere configurar un grupo de estados (qué conjunto de vértices usar, qué sombreador usar, etc.) y los cambios de estado tienen un costo tanto en el lado del hardware (actualizar un grupo de registros) como en el lado del controlador (validar y traducir las llamadas que establecen el estado).

Pero el costo principal de las llamadas de sorteo solo se aplica si cada llamada envía muy pocos datos, ya que esto hará que esté vinculado a la CPU y le impedirá utilizar el hardware completamente.

Como dijo Josh, las llamadas de sorteo pueden también causa que el búfer de comandos se vacíe, pero en mi experiencia, eso generalmente sucede cuando llamas a SwapBuffers, no cuando envías geometría. Los controladores de video generalmente intentan almacenar tanto como pueden salirse con la suya (¡varios fotogramas a veces!) para exprimir tanto paralelismo de la GPU como sea posible.

Usted debe leer la presentación de nVidia Lote Lote Lote!, es bastante viejo pero cubre exactamente este tema.

 50
Author: Joakim Hårsman,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-11-03 12:54:14

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

Hasta que el búfer se vacía, la GPU es capaz de hacer algún trabajo de preparación en paralelo con la CPU, siempre y cuando la CPU no realice una solicitud de bloqueo (como la asignación de datos a la CPU). Pero la GPU no prepare y no puede prepare preparar 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 dispuestos apropiadamente todavía, y puede que no se puedan arreglar hasta que se establezcan diseños de vértices o se encuadren sombreadores, etc. La mayor parte del trabajo real ocurre durante el comando flush y draw call.

El SDK de DirectX tiene una sección sobre perfilar con precisión D3D rendimiento que, si bien no está directamente relacionado con su pregunta, puede proporcionar algunos consejos sobre qué es y no es costoso y (en algunos casos) por qué.

Más relevante es esta entrada de blog (y las publicaciones de seguimiento aquí y aquí), que proporcionan una buena visión general del proceso operativo lógico y de bajo nivel de la GPU.

Pero, esencialmente (para tratar de responder directamente a sus preguntas), la razón por la que las llamadas son caras no es que necesariamente una gran cantidad de datos para transferir, sino que hay un gran cuerpo de trabajo más allá de solo enviar datos a través del bus que se pospone hasta que el búfer de comandos se vacía.

 11
Author: Josh,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-01-31 18:04:37

Respuesta corta: El conductor almacena en búfer parte o todo el trabajo real hasta que llame a draw. Esto se mostrará como una cantidad de tiempo relativamente predecible en la llamada de sorteo, dependiendo de cuánto estado haya cambiado.

Esto se hace por algunas razones:

  • para evitar hacer trabajo innecesario: Si (innecesariamente) establece el mismo estado varias veces antes de dibujar, puede evitar hacer trabajo costoso cada vez que esto ocurra. Esto en realidad se convierte en una ocurrencia bastante común en un código base grande, digamos un motor de producción.
  • para poder conciliar lo que internamente son estados interdependientes en lugar de procesarlos inmediatamente con información incompleta

Respuestas alternativas:

  • El búfer que usa el controlador para almacenar comandos de renderizado está lleno y la aplicación está esperando a que la GPU procese parte del trabajo anterior. Esto generalmente se mostrará como bloques de tiempo extremadamente grandes en una llamada de sorteo aleatorio dentro de un marco.
  • Se ha alcanzado el número de fotogramas que el controlador tiene permitido almacenar en búfer y la aplicación está esperando en la GPU para procesar uno de ellos. Esto normalmente se mostrará como una gran parte de bloqueo de tiempo en la primera llamada de sorteo dentro de un marco, o en el Presente al final del marco anterior.
 2
Author: Zoner,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-06-20 22:28:19