Representación pura del software OpenGL

8

Para entrenar un algoritmo de aprendizaje automático, necesitamos renderizar algo de geometría en OpenGL sin ningún soporte de renderizado de hardware (sin tarjeta gráfica). Así que estábamos pensando en renderizar en software puro, y ya hemos analizado Mesa. Parece que es capaz de renderizar en software puro, pero hasta ahora, solo obtenemos OpenGL 2.x, mientras que necesitamos OpenGL 3.3.

¿Alguien sabe si eso es posible? Y si es así, ¿cómo? Parece que nos encontramos con escollos todo el tiempo.

(Antecedentes, por qué queremos hacer eso: para entrenar el algoritmo de aprendizaje, necesitamos realizar muchas ejecuciones de nuestro software en un clúster de PC, lo que no permite la representación en hardware).

Cualquier sugerencia, idea y puntero serán apreciados.

software-rendering Gabriel
fuente
Mesa ni siquiera admite OpenGL 3.3 acelerado por hardware en algunos sistemas (como mi computadora portátil).
Coronel Treinta y dos
gamedev.stackexchange.com/questions/17571/…
Ciro Santilli 冠状 病毒 审查 六四 事件 法轮功

Respuestas:

6

Estoy confundido con tus requerimientos. ¿Está ejecutando el código en una PC o un sistema integrado? Si está ejecutando algo que se parece remotamente a una PC, "cualquier soporte de representación de hardware" básicamente no es cierto. Como mínimo, tiene algunas cosas integradas de Intel. Todavía tengo que ver un sistema sin cabeza que físicamente no tenía un chip de video.

En un sistema sin cabeza que puede renderizar sin una ventana, cómo hacer esto con GLX puede ver detalles en WindowGL OpenGL . En cualquier caso, incluso el hardware más malo será más eficiente que un procesador de software.

Si realmente está en apuros y absolutamente no tiene hardware gráfico, puede usar algo como VirtualGL .

Pero si está sintetizando imágenes en software usando OpenGL es algo al revés. OpenGL está diseñado en torno a las severas restricciones del hardware gráfico. El resultado es que existen importantes restricciones de compilación que pueden ignorarse voluntariamente al renderizar en software. Además, el algoritmo ráster no es muy eficiente cuando se utiliza el hardware actual. Un trazado de rayos de primer orden puede ser más eficiente y paralizar fácilmente múltiples núcleos. Tal vez puedas mirar algo como PovRay .

rioki
fuente
1
Incluso hoy en día se fabrican algunos chips de video Intel de mala calidad, que solo admiten OpenGL 1.4 + ensamblaje de fragmentos ARB + ​​ensamblaje de vértices implementado por software ARB. Estos no serán más eficientes que el procesador de software para cualquier aplicación que requiera OpenGL 3.
Ruslan
Muchas gracias. Sí, es como una PC. Primero, una PC simple en un clúster de PC, en la que iniciamos sesión a través de ssh. Más tarde, serán nodos de PC en un sistema HPC. El problema es: no importa lo que hagamos, siempre solo obtenemos OpenGL 2.1. Nuestra aplicación se basa en Qt, pero en la versión sin ventanas, todo el código Qt está inactivo, excepto el que crea el contexto OpenGL. Y sí, configuramos DISPLAY en: 0.0 en la máquina remota.
Gabriel
Pero, de nuevo, OpenGL 2.1 no es tan malo. Lo usé ampliamente con resultados bastante buenos.
rioki
3

Parece que solo OpenGL 2.x es totalmente compatible con el renderizador de software de Mesa.

Sin embargo, esta respuesta sugiere que la mayor parte de la funcionalidad de OpenGL 3.x es compatible a través de extensiones. Por lo tanto, es posible que desee probarlo.

kolrabi
fuente