¿Existe un límite en la cantidad de contextos de representación de OpenGL que puede crear simultáneamente?

Question

Mi aplicación .Net Winforms crea tres contextos de representación OpenGL en mi ventana principal, y luego le permite al usuario mostrar otras ventanas donde cada ventana tiene dos contextos de representación más (usando un divisor). En torno al contexto de representación 26, las cosas comienzan a ir MUY lentas. En lugar de tomar unos pocos milisegundos para renderizar un cuadro, el nuevo contexto de renderización tarda entre 5 y 10 segundos. Todavía funciona, ¡REALMENTE LENTO! Y OpenGL NO devuelve ningún error (glGetError).

Las otras ventanas funcionan bien. Solo los nuevos contextos de representación después de un cierto número disminuyen. Si cierro esas ventanas, todo está bien, hasta que vuelva a abrir suficientes ventanas para pasar el límite. Cada contexto de representación tiene su propio hilo y cada uno usa un sombreador simple. La ralentización parece ocurrir cuando cargo una textura. Pero el tamaño de la textura no tiene ningún efecto en la cantidad de contextos que puedo crear, ni tampoco el tamaño de la ventana de OpenGL.

Estoy usando tarjetas nVidia y veo esto en diferentes GPU con diferentes cantidades de memoria y diferentes versiones de controladores. ¿Cual es el trato? ¿Hay algún límite en la cantidad de contextos de representación que puede crear una aplicación?

¿Alguien más tiene una aplicación con MUCHOS contextos de representación ejecutándose al mismo tiempo?

Answer 1

La mejor opción es que no hay una respuesta real a esta pregunta. Probablemente dependa de alguna limitación interna del controlador, hardware incluso del sistema operativo. Algo que quizás quieras comprobar es la cantidad de unidades de textura disponibles usando glGet(GL_MAX_TEXTURE_UNITS), pero eso puede ser indicativo o no.

Una solución común para evitar esto es crear múltiples ventanas gráficas dentro de un solo contexto en lugar de múltiples contextos en una sola ventana. No debería ser demasiado difícil unir los dos contextos que comparten una ventana con un único contexto con dos ventanas gráficas y algún tipo de widget UI para que sirva como divisor. Las ventanas múltiples son una historia diferente y es posible que desee considerar una reconsideración completa del diseño de su interfaz de usuario si existe una necesidad real de 26 ventanas OpenGL separadas.
Ahora me resulta difícil pensar en un caso de uso de interfaz de usuario real que requiera 26 ventanas OpenGL diferentes que funcionen simultáneamente. tal vez otra opción sea crear un conjunto de contextos de 5-10 y reutilizarlos solo en las ventanas (¿fichas?) que actualmente están visibles para el usuario. No lo intenté, pero debería ser posible crear un contexto dentro de una ventana simple que no contenga nada más y luego mover esa ventana desde la ventana principal a la ventana principal a la ventana de nivel superior en la que se necesite.

EDIT -
Bueno, en realidad no es tan difícil pensar en uno. La última versión de Chrome (9.x.x), compatible con WebGL, puede querer abrir muchas pestañas cada una con un contexto WebGL ... Me pregunto si manejarán esto de alguna manera. Acabo de probarlo y me quedé sin memoria después de 13 pestañas ... En realidad, sería un buen control para usted ver si algo está haciendo mal o si Chrome y Firefox (4.0.x-beta) tienen el mismo problema

Answer 2

Dada la naturaleza diversa de los controladores OpenGL, su mejor opción es probablemente verificar el comportamiento de los principales controladores (AMD/Intel/NVIDIA/MS Software Render) y en el primer arranque ejecutar una prueba. P.ej. Si puede ver que NVIDIA siempre se ralentiza como lo vio, simplemente ejecute un ciclo rápido hasta que vea dónde está el límite en esa máquina (o más bien, en la tarjeta). No es muy divertido, pero creo que es bastante difícil impulsar los límites de otra manera.

En otras palabras, la "mejor apuesta" es como se contestó anteriormente, no se puede saber de antemano.

Answer 3

Como dijo correctamente Nathan Kidd, el límite es específico de la implementación, y todo lo que puede hacer es realizar algunas pruebas en hardware común.

Estaba aburrido en la reunión del departamento de hoy, así que traté de juntar un poco de código que crea contextos OpenGL y trata algunos renderizados. Intenté renderizar con y sin texturas, con y sin contexto de OpenGL compatible.

Resultó que el límite es bastante alto para las tarjetas GeForce (quizás incluso sin límite). Para Quadro de escritorio, había un límite de 128 contextos que podían volver a pintar correctamente, el programa podía crear 128 contextos más sin errores, pero las ventanas contenían basura.

Fue aún más interesante en ATi Radeon 6950, allí el rediseño se detuvo en la ventana # 105 y no se pudo crear el contexto de representación # 200.

Si quieres probarlo, el programa se puede encontrar aquí: Max OpenGL Contexts test (hay código fuente completo + win32 binarios).

Ese es el resultado. Un consejo: evite utilizar contextos múltiples siempre que sea posible. Se pueden entender múltiples contextos en aplicaciones que se ejecutan en múltiples monitores, pero las aplicaciones en un solo monitor deben recurrir a un único contexto. El cambio de contexto es lento. Y eso no es todo. Las aplicaciones donde las ventanas OpenGL están superpuestas por otra ventana requieren regiones de recorte de hardware. Hay una región de recorte de hardware en GeForce, ocho o más en Quadro (las aplicaciones de CAD a menudo usan ventanas y menús que se superponen a la ventana de OpenGL, en contraste con los juegos). En caso de que se necesiten más regiones, la representación recae en el software, así que de nuevo, tener muchas ventanas OpenGL (contextos) no es una muy buena idea.

Answer 4

Si tiene tantos problemas para configurar OpenGL en una moda over-the-top multi-threaded, también podría beneficiarse de ello y considerar cambiar a Vulkan. Vea, por diseño, que la arquitectura OpenGL canaliza todas las operaciones de dibujo separadas por contexto/subprocesos difíciles de obtener en un solo subproceso de controlador que luego redistribuye todas estas llamadas a través de subprocesos de hardware virtual que se asignan a cada contexto. El controlador es, en esencia, un gran cuello de botella porque no está enhebrado, a pesar de que haya un poco de glewmx. Simplemente no está diseñado para manejar esto bien.

Dicho esto, tengo curiosidad por si utilizó una versión anterior de Glew, o si hace todo el manejo de la extensión de alguna otra manera, ya que las últimas glew libs ya no son compatibles con mx. Una razón más para cambiar.