¿Se puede precalentar un sombreador en un hilo de fondo con su propio contexto?

Question

Estoy desarrollando un gran juego que transmite datos de nivel (incluidos sombreadores) a medida que avanzas por el mundo del juego. No quiero tener enganches en mi velocidad de fotogramas cuando los sombreadores se compilan/vinculan o la primera vez que se usan.

Tengo mi shader de compilación y vinculación trabajando en un hilo separado con su propio contexto open-gl. Pero no he podido lograr que el precalentamiento de los sombreadores funcione en el subproceso separado (para que no se produzca ningún impacto en el rendimiento cuando se usa por primera vez el sombreador).

El precalentamiento realmente no se menciona en ningún lugar en los documentos iOS o OpenGL. Sin embargo, se menciona en OpenGL ES Analyzer (uno de los instrumentos disponibles cuando se realiza un perfil desde xcode). En esta herramienta recibo una advertencia de "Shader Compiled Outside of Prewarming Phase" cada vez que se renderiza algo con un shader que no se ha utilizado para renderizar algo antes. El "Detalle ampliado" dice esto:

"OpenGL ES Analyzer detectó una compilación de sombreado que no forma parte de una fase de precalentamiento inicial. La compilación de sombreado puede ser una operación lenta. Para evitarlos, precaliente todos los sombreadores utilizados para la representación. Para ello, realice un pase de precalentamiento cuando la aplicación se inicie y ejecute una llamada de dibujo con cada uno de los programas de sombreado que se utilizarán, utilizando cualquier configuración de estado gl. El programa de sombreado se usará junto con Estados como combinación, máscara de color, lógica ops, multisamping, formatos de textura y estado de punto primitivo pueden afectar la compilación de sombreadores ".

El término "compilación" es un poco confuso aquí. Los sombreadores de vértices y fragmentos ya se han compilado y el programa se ha vinculado. Pero la primera vez que se renderiza algo con un determinado estado OpenGL, hace un poco más de trabajo en el sombreador para optimizarlo para ese estado, supongo.

Tengo un código para precalentar los sombreadores formando un triángulo de tamaño cero antes de su primer uso.

Si compilo, enlace y precalentamos los sombreadores en el hilo principal con el mismo contexto Open GLL que el renderizado normal, entonces funciona. Sin embargo, si lo hago en el hilo de fondo con su contexto Open GL separado, no funciona (aún recibe la advertencia del Analizador en el primer uso).

Entonces ... podría ser que precalentar un sombreador en un contexto separado no tenga ningún efecto en otros contextos. O podría ser que no tengo el mismo estado configurado en el contexto separado. Existe un gran potencial de Open GL state que podría necesitar ser configurado. Estoy usando un buffer de representación fuera de pantalla en el hilo de fondo para que pueda considerarse parte del estado.

¿Alguien ha tenido éxito al obtener precalentamiento trabajando en un hilo de fondo?

Answer 1

Para ser honesto con usted, era bastante ignorante sobre este tema hasta ayer, aunque he estado trabajando en la optimización de mi motor por un tiempo. Entonces, antes que nada, gracias por el consejo :).

He estudiado desde entonces el tema del calentamiento del sombreador y no he encontrado mucho alrededor.

he encontrado una mención de la documentación oficial de AMD en un documento titulado "Programación ATI OpenGL y optimización Guía":

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&ved=0CEoQFjAF&url=http%3A%2F%2Fdeveloper.amd.com%2Fmedia%2Fgpu_assets%2FATI_OpenGL_Programming_and_Optimization_Guide.pdf&ei=3HIeT_-jKYbf8AOx3o3BDg&usg=AFQjCNFProzLiXf5Aqqs4jZ2jOb4x0pssg&sig2=6YV7SVA97EFglXv_SX5weg

Este es un extracto de las cuales se refiere al calentamiento de los shaders:

Cita:

Mientras que el R500 soporta de forma nativa de control de flujo en la unidad de fragmento de sombreado, el R300 y R400 asics no. El controlador de flujo estático para R300 y R400 es emulado por el controlador compilando condicionales no usados ​​y bucles de desenrollado basados ​​en las constantes establecidas. Aunque la familia asics R500 admite de forma nativa el control de flujo, el controlador aún intentará compilar las condiciones de flujo estático que permiten reorganizar las instrucciones del sombreador para una mejor programación de instrucciones. El controlador también intentará almacenar en caché el sombreador compilado para una condición de flujo estático específico establecida en anticipación para su reutilización. Entonces, cuando escribe un programa de fragmento que usa control de flujo estático, se recomienda "calentar" el caché de sombreado representando un triángulo ficticio en el primer cuadro que usa las permutaciones condicionales estáticas comunes relevantes para la vida del sombreador.

La mejor explicación que he encontrado alrededor es la siguiente:

http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part-1/

Cita:

Por cierto, esta es también la razón por la que en general se ven un retraso de la primera vez que utilice un nuevo sombreador o recurso; Gran parte del trabajo de creación/compilación es diferido por el controlador y solo se ejecuta cuando es realmente necesario (¡no creería la cantidad de basura sin usar que crean algunas aplicaciones!). Los programadores de gráficos conocen el otro lado de la historia: si quieres asegurarte de que algo realmente se crea (en lugar de tener solo memoria reservada), debes emitir una llamada simulada que la use para "calentarla". Feo y molesto, pero este ha sido el caso desde que comencé a usar el hardware 3D en 1999, lo que significa que para entonces ya es un hecho real, así que acostúmbrate. :)

En esta presentación, se menciona cómo cryteck engined lo realizó en el motor de lejanía, aunque está relacionado principalmente con DirectX.

http://www.powershow.com/view/11f2b1-MzUxN/Far_Cry_and_DirectX_flash_ppt_presentation

espero que estos enlaces ayudan de alguna manera.