Android OpenGL ES: auto-corrección env-> self y NvRmChannelSubmit fallaron
Dos preguntas a continuación.
Tenemos una aplicación de gráficos OpenGL ES 2 que funcionó bien durante algunos años en Windows, Linux, MacOS, iPhones, iPads y teléfonos Android. En los últimos meses hemos comenzado a recibir comentarios de los usuarios de algunos de los dispositivos Android (como Toshiba Thrive, HTC One X, Nexus 7 o Asus Transformer, API 15 y 17) con respecto a los problemas con negro o parpadeo de la pantalla, o raramente, una aplicación choque. Nuestra aplicación está orientada a API 9 y superior, y está escrita en NDK usando NativeActivity, basada directamente en ejemplos y demostraciones de nvidia android, ha sido probada exhaustivamente en todas las plataformas, sin pérdidas de memoria, sin accesos de memoria inválidos, rara vez llama a algunos pequeños java código.
- Procesamiento de texto Android OpenGL ES 2.0
- EglCreateWindowSurface falla con java.lang.IllegalArgumentException
- Point sprite desaparece en el borde de la pantalla en mi Galaxy S4 (no en el Nexus 7)
- Google Maps Android API V2 no muestra mapas en Emulator
- Implementación de problemas GLSurfaceView.Renderer
En cuanto a LogCat, nos dimos cuenta de dos tipos de mensajes de error en estos dispositivos:
(1) JNI ERROR: env->self != thread-self (0x11734c0 vs. 0xd6d360); auto-correcting
JNI ERROR: env->self != thread-self (0x11734c0 vs. 0xd6d360); auto-correcting
(2) NvRmChannelSubmit failed (err = 196623, SyncPointValue = 0)
seguido por GL_OUT_OF_MEMORY
Respecto a (1), sabemos de los hilos frente a los problemas de JNI, y esperamos saber cómo solucionarlo. He leído esta información y mi pregunta aquí es: ¿la "corrección automática" significa que tenemos que preocuparnos por algún ERROR, o es sólo una advertencia que significa que el código se comportará mal EN EL FUTURO, pero ahora funciona perfectamente (Corregido!) Y esto no está relacionado con la cuestión (2)? La razón que estoy pidiendo es que a veces también vemos las líneas siguientes:
E/libEGL: call to OpenGL ES API with no current context (logged once per thread) E/NvEGLUtil: Failure: eglSwapBuffers, error = 0x0000300d (swap:422)
Que miran seriamente. Hemos probado nuestra aplicación en un emulador API 17 con JNIcheck habilitado – no se informan problemas, y la aplicación funciona bien.
Ahora, con respecto al mensaje (2), he encontrado algunos foros (por ejemplo aquí , aquí y también esto ) donde la gente reportó este mensaje, y las razones no están claras. Parece que el problema de firmware o controlador, o fugas de memoria GPU o fragmentación de la memoria … Muchos juegos se ven afectados por el parpadeo de la pantalla, y la gente está tratando de reiniciar / reiniciar el dispositivo, limpiar caché, actualización, etc, pero parece persistir . Este problema se refiere a bastantes dispositivos populares. A pesar del código de error GL_OUT_OF_MEMORY
, "no hay suficiente memoria" no está justificada, ya que la aplicación que usamos para las pruebas utiliza texturas pequeñas de 32×32 en lugar de texturas de 512×512 que se usan en la versión regular (y estas texturas más grandes funcionan perfectamente en dispositivos antiguos). ¿Alguien tiene alguna experiencia en cómo arreglar esto, y es este fijable en nuestro lado en absoluto? ¿Se trata de un fallo firmware / firmware / OS oficialmente confirmado? Estoy buscando una razón conocida y una verdadera solución a este problema, no una solución de prueba y error que accidentalmente ayudaría sin saber por qué .
¡Gracias!
- Cómo forzar el modo de paisaje con NDK utilizando códigos C ++ puros
- Android OpenGL ES 2.0 sólo está limitado a 16 texturas en la memoria?
- ¿Cómo utilizo un sombreado en las líneas de color dibujadas con GL_LINES y OpenGL ES 2.0
- Android 6.0 Nexus 6 Crash en el controlador Adreno 420
- ¿Por qué mi programa de shader openGL para puntos tiene anillos de artefactos?
- GLSurfaceView onDrawFrame comportamiento de borrado
- Dibuja una imagen 2D con OpenGL ES 2.0
- Uso de FBO para grabar la pantalla en Android
- Google Analytics Android no funciona
- No se puede crear mediaplayer al reproducir sonido usando uri desde RingtoneManager.getDefaultUri (RingtoneManager.TYPE_ALARM) en android