7

In iOS 5, OpenGL ES Texture caches were introduced to provide a direct way from the camera video data to OpenGL without the need of copying the buffers. There was a brief introduction to texture caches in session 414 - Advances in OpenGL ES for iOS 5 of WWDC 2011.

I found an interesting article which abuses this concept further in the end and circumvents a call to glReadPixels by simply locking the texture, and then accessing the buffer directly.

glReadPixels is really slow due to the tile-based renderer which is used in iPad 2 (even when you use only 1x1 textures). However, the described method seems to process faster than glReadPixels.

Is the proposed method in the article even valid and can it be used to boost applications which rely on glReadPixels?

Since OpenGL processes graphics data in parallel to the CPU, how should the CVPixelBufferLockBaseAddress call know when the rendering is done without talking to OpenGL?

Charles
  • 50,943
  • 13
  • 104
  • 142
Etan
  • 17,014
  • 17
  • 89
  • 148

1 Answers1

4

I describe a means of doing this in this answer, based on your above-linked article and Apple's ChromaKey sample from WWDC 2011. Given that Apple used this in one of their samples, and that I've not heard anything countering this from their OpenGL ES engineers, I believe this to be a valid use of the texture caches. It works on every iOS 5.x-compatible device that I've tried, and works in iOS 5.0 and 5.1 just as well. It's much, much faster than glReadPixels().

As far as when to lock the pixel buffer base address, you should be able to use glFlush() or the like to block until all data has been rendered to your FBO texture. This seems to work for the 30 FPS 1080p movie encoding I've done from texture-backed FBOs.

Community
  • 1
  • 1
Brad Larson
  • 170,088
  • 45
  • 397
  • 571