Uso de cachés de texturas OpenGL ES en lugar de glReadPixels para obtener datos de textura

Question

En iOS 5, se introdujeron los cachés de texturas OpenGL ES para proporcionar un camino directo desde los datos de video de la cámara a OpenGL sin la necesidad de copiar los almacenamientos intermedios. Hubo una breve introducción a los cachés de texturas en session 414 - Advances in OpenGL ES for iOS 5 of WWDC 2011.

Encontré un interesante article que abusa de este concepto aún más al final y elude una llamada a glReadPixels simplemente bloqueando la textura, y luego accediendo al búfer directamente.

glReadPixels es muy lento debido al renderizador basado en mosaico que se utiliza en iPad 2 (incluso cuando se usan texturas 1x1). Sin embargo, el método descrito parece procesar más rápido que glReadPixels.

¿El método propuesto en el artículo es válido y se puede utilizar para impulsar las aplicaciones que se basan en glReadPixels?

Dado que OpenGL procesa los datos gráficos en paralelo a la CPU, ¿cómo debe saber la llamada CVPixelBufferLockBaseAddress cuando la representación se realiza sin hablar con OpenGL?

Answer 1

Describo un modo de hacerlo en this answer, basado en su artículo vinculado anteriormente y en la muestra ChromaKey de Apple de WWDC 2011. Dado que Apple usó esto en una de sus muestras, y que no escuché nada contrarrestar esto de sus ingenieros de OpenGL ES, creo que este es un uso válido de los cachés de texturas. Funciona en todos los dispositivos compatibles con iOS 5.x que he probado, y también funciona en iOS 5.0 y 5.1. Es mucho, mucho más rápido que glReadPixels().

En cuanto a cuándo bloquear la dirección base de la memoria intermedia de píxeles, debe poder usar glFlush() o similar para bloquear hasta que todos los datos se hayan procesado en su textura FBO. Esto parece funcionar para la codificación de película de 30 FPS 1080p que hice desde FBO con textura.