• Locked Locked
  • Replies 9 replies
  • Subscribers 136 subscribers
  • Views 5792 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

EGL Pixbuffer is slow

Ahmed Tolba
Note: This was originally posted on 25th February 2013 at http://forums.arm.com

Hi All,

I'm having a 1k*1k*rgb texture that is rendered using shader and I want to copy the pixels to buffer so that I use Opencv with it. I tried glreadpixels and its very slow, I tried Pixbuffer of Egl, it has the same perforamance its very slow 7FPS. I'm using Mali400 on Exynos4412

Here is the code
  Please view it in pastebin, there is a problem with code posting here

http://pastebin.com/TwrtF0EG
Parents
  • Note: This was originally posted on 5th March 2013 at http://forums.arm.com

    Hi Ahmed,

    The slowdowns you are experiencing are to be expected with your usage unfortunately, as you are "breaking" the pipeline model that Mali GPU's implement. As a deferred renderer, frames are ideally not submitted to the GPU until a call to eglSwapBuffers is made. Therefore in a normal use case such as a game, the CPU will be working on frame N, whilst the GPU is processing frame N-1. In your use case, you are attempting to synchronously read back pixels from frame N to the CPU side, which implies that the frame up to that point must be submitted to the GPU, be processed, and then be read back. The CPU therefore has to wait for the GPU, and after which time the GPU has a huge pipeline bubble whilst it waits for more work from the CPU. It's easy to see why this is sub-optimal on deferred renderers.

    ReadPixels is a synchronous call as you want to read back the state of rendering for the frame you are currently working on (and that normally wouldn't have been submitted yet). CopyTexImage isn't necessarily synchronous, but in your case as you're copying to a Pbuffer that is accessible from the CPU side it is. I'm asking around for an asynchronous method that would work for your use-case, but my advice for now is that synchronous calls of any kind are bad for deferred renderers, and come with a slowdown. This is described in the "mali gpu application optimization guide" available from Mali Developer Guides, which is well worth a read.

    Hope this helps,
    Chris
Reply
  • Note: This was originally posted on 5th March 2013 at http://forums.arm.com

    Hi Ahmed,

    The slowdowns you are experiencing are to be expected with your usage unfortunately, as you are "breaking" the pipeline model that Mali GPU's implement. As a deferred renderer, frames are ideally not submitted to the GPU until a call to eglSwapBuffers is made. Therefore in a normal use case such as a game, the CPU will be working on frame N, whilst the GPU is processing frame N-1. In your use case, you are attempting to synchronously read back pixels from frame N to the CPU side, which implies that the frame up to that point must be submitted to the GPU, be processed, and then be read back. The CPU therefore has to wait for the GPU, and after which time the GPU has a huge pipeline bubble whilst it waits for more work from the CPU. It's easy to see why this is sub-optimal on deferred renderers.

    ReadPixels is a synchronous call as you want to read back the state of rendering for the frame you are currently working on (and that normally wouldn't have been submitted yet). CopyTexImage isn't necessarily synchronous, but in your case as you're copying to a Pbuffer that is accessible from the CPU side it is. I'm asking around for an asynchronous method that would work for your use-case, but my advice for now is that synchronous calls of any kind are bad for deferred renderers, and come with a slowdown. This is described in the "mali gpu application optimization guide" available from Mali Developer Guides, which is well worth a read.

    Hope this helps,
    Chris
Children
No data