OpenGL preguntas de rendimiento de bajo nivel

Question

Este tema, como con cualquier problema de optimización, recibe mucho, pero no pude encontrar lo que (creo) quiero.

Una gran cantidad de tutoriales, e incluso las preguntas más importantes tienen consejos similares; generalmente cubre:

• cara Uso GL sacrificio (la función de OpenGL, no la lógica escena)
• Enviar sólo 1 matriz a la GPU (combinación projectionModelView), por lo que disminuye los cálculos MVP desde por vértice a una vez por modelo (como debería ser).
• Use vértices intercalados
• Minimizar el mayor número posible GL llama, lote, si procede

Y, posiblemente, unos pocos/muchos otros. Estoy (por razones de curiosidad) renderizando 28 millones de triángulos en mi aplicación usando varios buffers de vértices. He probado todas las técnicas anteriores (a mi leal saber y entender) y casi no he tenido cambios en el rendimiento.

Si bien recibo alrededor de 40FPS en mi implementación, lo que de ninguna manera es problemático, ¿todavía tengo curiosidad por saber dónde se utilizan estos "consejos" de optimización?

Mi CPU está al ralentí alrededor del 20-50% durante el procesamiento, por lo tanto, I asumo Tengo una GPU destinada a aumentar el rendimiento.

Nota: Estoy buscando en gDEBugger en el momento

Cruz publicada en Game Development

Answer 1

El punto 1 es obvia, como es ahorra tasa de relleno. En caso de que las primitivas de la parte posterior de un objeto se procesen primero, esto omitirá esas caras. Sin embargo, las GPU modernas toleran el sobregiro bastante bien. Una vez (GeForce8800 GTX) medí hasta 20% de sobregiro antes de que se alcanzara un rendimiento significativo. Pero es mejor guardar esta reserva para cosas como la eliminación de oclusiones, la representación de geometría combinada y similares.

El punto 2 es, así, inútil. Las matrices nunca se han calculado en la GPU, bueno, si no se cuenta SGI Onyx. Las matrices siempre fueron solo un tipo de parámetro global de representación calculado en la CPU, luego se incluyeron en los registros globales de la GPU, que ahora se llaman uniformes, por lo que unirlos tiene muy poco beneficio. En el sombreado, solo se ahorra una multiplicación de matriz vectorial adicional (se reduce a 4 instrucciones MAD), a expensas de una menor flexibilidad algorítmica.

El punto 3 es todo acerca de la eficiencia de caché. Los datos que pertenecen juntos deben caber en una línea de caché.

El punto 4 trata de evitar que los cambios de estado dañen las memorias caché. Pero depende en gran medida de a qué GL llaman. Cambiar los uniformes es barato. Cambiar una textura es costoso. La razón es que un uniforme se encuentra en un registro, no en una memoria almacenada en caché. Cambiar un sombreador es costoso, ya que diferentes sombreadores exhiben un comportamiento de tiempo de ejecución diferente, lo que arruina la ejecución de la ejecución de la tubería, altera la memoria (y por lo tanto) los patrones de acceso a la memoria caché, etc.

Pero todas son micro optimizaciones (algunas de ellas con un gran impacto). Sin embargo, recomiendo mirar en grandes optimizaciones de impacto, como implementar un pase Z temprano; utilizando la consulta de oclusión en la primera Z para una discriminación rápida de lotes de geometría completa.Una gran optimización de impacto, que básicamente consiste en resumir muchas micro optimizaciones de punto 4, es ordenar los lotes por costosos estados GL. Así que agrupe todo con shaders comunes, dentro de esos grupos clasifique por textura, etc. Esta agrupación de estado solo afectará los pases de representación visibles. En las primeras Z solo estás probando los resultados en el buffer Z por lo que solo hay transformación de geometría y los sombreadores de fragmentos simplemente pasarán el valor Z.

Answer 2

Esto depende mucho de qué hardware en particular esté ejecutando y cuáles son los escenarios de uso. Las sugerencias de rendimiento de OpenGL tienen sentido para el caso general: la biblioteca es, después de todo, una abstracción de muchas implementaciones de controladores diferentes. Los fabricantes de controladores pueden optimizar de la forma que prefieran bajo el capó, por lo que pueden eliminar cambios de estado redundantes u otras optimizaciones sin su conocimiento. En otro dispositivo, es posible que no. Lo mejor es apegarse a las mejores prácticas para tener una mejor oportunidad de buen rendimiento en una amplia gama de dispositivos.

Answer 3

1. Sí
2. no tiene sentido ya que el conductor puede combinar estas matrices para usted (se sabe que son uniformes, por lo que no va a cambiar durante la llamada empate).
3. Sí
4. sólo si está obligado

CPU La primera cosa que hay que saber es dónde está exactamente su cuello de botella. GPU no es una respuesta, porque es un sistema complejo. El problema real podría estar entre ellos:

• procesamiento Shader (vértice/fragmento/geometría)
• tasa de relleno
• Draw llama al número
• GPU < -> VMEM (que es donde el intercalado y texturas más pequeñas ayuda)
• bus de sistema (streaming algunos datos de cada cuadro?)

Es necesario llevar a cabo una serie de pruebas para ver los pro blem. Por ejemplo, dibuje todo en un FBO más grande para ver si se trata de un problema de tasa de llenado (o aumente la cantidad de MSAA). O dibuja todo dos veces para verificar los problemas de sobrecarga de llamadas de sorteo.

Answer 4

Solo para agregar mis 2 centavos a las respuestas de @kvark y @datenwolf, me gustaría decir que, si bien los puntos que menciona son consejos básicos de rendimiento de la GPU, una optimización más involucrada depende en gran medida de la aplicación.

En su caso de prueba de geometría pesada, ya está lanzando 28 millones de triángulos * 40 FPS = 1120 millones de triángulos por segundo - esto ya es bastante: la mayoría (no todos, especialmente Fermi) GPU tienen una configuración de triángulo rendimiento de 1 triángulo por ciclo de reloj de GPU. Lo que significa que una GPU que se ejecuta a 800 MHz, por ejemplo, no puede procesar más de 800 millones de triángulos por segundo; esto sin siquiera dibujar un solo píxel. NVidia Fermi puede procesar 4 triángulos por ciclo de reloj.

Si está llegando a este límite (no menciona su plataforma de hardware), no hay mucho que pueda hacer en el nivel OpenGL/GPU. Todo lo que puede hacer es enviar menos geometría, mediante una eliminación más eficiente (trunco ​​u oclusión), o mediante un esquema LOD.

Otra cosa es que los triángulos diminutos lastiman el fillrate ya que los rasterizadores hacen el procesamiento paralelo en bloques cuadrados de píxeles; ver http://www.geeks3d.com/20101201/amd-graphics-blog-tessellation-for-all/.