• Locked Locked
  • Replies 9 replies
  • Subscribers 136 subscribers
  • Views 5786 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,

    It may be possible to render to a pixmap in one thread, and have another thread wait on an EGL Fence for the render OP to complete, at which time it can grab the data and pass it along to the CV processing. By reading back from pixmaps you are not causing a flush, and by waiting on the fence on another thread you are not blocking your render thread. This removes the synchronous read back and means you should increase your throughput and FPS. Details on the fence mechanism can be found here: http://www.khronos.org/registry/gles/extensions/OES/EGL_KHR_fence_sync.txt. The most optimal implementation should ideally implement a ringbuffer of pixmaps so that you do not have the continuous overhead of creating and destroying pixmaps every frame, which is a general producer-consumer optimization.

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

    Hi Ahmed,

    It may be possible to render to a pixmap in one thread, and have another thread wait on an EGL Fence for the render OP to complete, at which time it can grab the data and pass it along to the CV processing. By reading back from pixmaps you are not causing a flush, and by waiting on the fence on another thread you are not blocking your render thread. This removes the synchronous read back and means you should increase your throughput and FPS. Details on the fence mechanism can be found here: http://www.khronos.org/registry/gles/extensions/OES/EGL_KHR_fence_sync.txt. The most optimal implementation should ideally implement a ringbuffer of pixmaps so that you do not have the continuous overhead of creating and destroying pixmaps every frame, which is a general producer-consumer optimization.

    Hope this helps,
    Chris
Children
No data