Por qué no se pueden llamar las funciones de OpenGL ES desde otro hilo

Question

Estoy experimentando con la escritura de un motor de juegos pequeños para Android con OpenGL ES. Creé un Game Thread que actualiza los objetos del juego y el GLThread dibuja la escena. Leí que necesita cargar las texturas en el método de GLSurfaceView en SurfaceFreated. Estoy siguiendo eso, pero con algún propósito de depuración intenté cargar texturas de mi hilo de juego en lugar del hilo GLT. No recibí ningún error y la textura no aparecía en la pantalla. Pasé todo el día tratando de resolver el problema y finalmente leí el siguiente here

"Solo asegúrese de usar OpenGL únicamente en el hilo principal". Muy importante. No puede invocar su Motor de juego (que puede estar en otro hilo) una función de carga de textura que no está sincronizada con el hilo gl. Establezca una bandera para señalar su hilo gl para cargar una nueva textura (por ejemplo, puede colocar una función en OnDrawFrame (GL gl) que comprueba si debe haber una nueva textura cargada.

Voy a modificar mi código para que las texturas se carguen desde el subproceso GL. Simplemente no pude entender por qué es así? ¿Por qué las funciones OpenGL no funcionan desde otro subproceso?

Sé cómo crear subprocesos, pero no sé qué El extracto anterior menciona: "No puedes invocar tu Game Engine (que puede estar en otro hilo) una función de carga de textura que no está sincronizada con el hilo gl." Así que supongo que mi Game Thread podría no estar sincronizado. con el hilo GL. ¿Es posible crear otro hilo que esté sincronizado con el hilo GL? para que las funciones GL puedan ser llamadas desde allí? ¿Qué debo aprender al enhebrar para comprender estos conceptos?

Answer 1

El comentario de quixoto es el más cercano, creo. La razón tradicional por la que los contextos OpenGL son específicos de subprocesos en casi todas las plataformas es que OpenGL depende en gran medida de los estados y no tiene semántica para realizar una serie de cambios atómicos. Así, por ejemplo, la operación de dibujo sobre un hilo podría ser:

glVertexPointer(... supply vertex positions ...) 
glTexCoordPointer(... provide texture positions ...) 
/* and supply a few other pointers, maybe bind a texture */ 

glDrawArrays(... draw some geometry ...) 

Así que la última llamada proporciona resultados fiables sólo en el contexto de las llamadas anteriores. Si permite que ese bit de código se pause después de, por ejemplo, glVertexPointer, otro hilo que salta y hace la misma secuencia para dibujar su geometría y luego este código procede, dibujará con una geometría incorrecta, posiblemente incluso causando -of-bounds accede a la memoria si algunas de las matrices reemplazadas son más pequeñas que las originales.

Android suministra EGL, que admite el concepto común de un grupo compartido OpenGL (aunque implícitamente, proporciona un contexto existente con el que desea un nuevo contexto en un grupo común mediante el tercer argumento al eglCreateContext). Si dos contextos están en un grupo compartido, cada uno de ellos tiene un estado independiente y es seguro llamar desde un único subproceso, pero los objetos con nombre como texturas o los objetos del búfer de vértice están disponibles para cada uno de ellos. Por lo tanto, al usar grupos de compartir puede realizar acciones de OpenGL en múltiples hilos simultáneamente para poder combinar los resultados en un solo hilo.

Por lo tanto, no es un problema atar un contexto a un solo hilo. Planear el problema en OpenGL también sería una incógnita porque parte de la razón por la que los contextos de OpenGL se crean, administran y eliminan de una manera específica del sistema operativo es que algunos sistemas operativos necesitan manejar esto de maneras radicalmente diferentes a otras o pueden ofrecer mejores soluciones al exponer sus propias soluciones únicas.