Rendering OpenGL ES in user space memory

Question

I need to implement off-screen texture rendering on an ARM device with PowerVR SGX hardware.

Everything is done (using pixel buffers and the OpenGL ES 2.0 API). The only problem that has not been resolved is the very slow glReadPixels function.

I am not an expert in OpenGL ES, so I ask the community: is it possible to convert textures directly into user space? Or maybe there is some way to get the hardware address of the texture memory area? Some other methods (EGL extensions)?

I don't need a one-stop solution that just works for PowerVR hardware.

Update: A little more information about the "slow glReadPixels function". Copy 512x512 RGB texture data to processor memory:

• glReadPixels(0, 0, WIDTH, HEIGHT, GL_RGBA, GL_UNSIGNED_BYTE, &arr) takes 210 ms,
• glReadPixels(0, 0, WIDTH, HEIGHT, GL_BGRA, GL_UNSIGNED_BYTE, &arr) takes 24 ms ( GL_BGRA not standard for glReadPixels, it is a PoverVR extension),
• memcpy(&arr, &arr2, WIDTH * HEIGHT * 4) takes 5 ms

In the case of large textures, the differences are also greater.

Answer 1

solvable.

Method for forced rendering of OpenVR equipment in distributed memory: http://processors.wiki.ti.com/index.php/Render_to_Texture_with_OpenGL_ES#Pixmaps

An example of how to use it: https://gforge.ti.com/gf/project/gleslayer/

After all this, I can get the displayed image faster than 5 ms.

Answer 2

When you call opengl functions, you execute the queues in the render queue. These commands are executed by an asynchronous GPU. When you call glReadPixels, the processor must wait for gpu to complete in order to render it. Thus, the call may wait for the completion of the rally. On most hardware (at least the ones I'm working on) the memory is shared by the processor and gpu, so the read pixel should not be so slow if rendering is done.

If you can wait for the result or delay it until the next frame, you may no longer see this delay

Answer 3

Frame buffer objects are what you are looking for. They are supported by OpenGL ES and PowerVr-SGX.

EDIT: Keep in mind that the GPU / CPU hardware is incredibly optimized for moving data in one direction from the processor side to the GPU side. The return path from the GPU to the processor is often much slower (its simply not a priority for using hardware resources). So, no matter what technique you use (for example, FBO / getTexImage), you will work against this limit.