Forums - OpenGL readback performance on 330

2 posts / 0 new
Last post
OpenGL readback performance on 330
rjfrank
Join Date: 22 Oct 15
Posts: 1
Posted: Tue, 2015-10-27 14:56

We are working on an application that requires us to be able to read back the color buffer from our OpenGL context on a 330 GPU so that the pixels can be transmitted elsewhere.  At present, we are using an onscreen context with 8888 RGBA encoding and the performance is sub-optimal (single digit fps).  Question: for optimal readback performance, what paths/factors should we be considering on this GPU?  Are there specific  pixel formats (dropping to 16bit would be acceptable here), bitdepths/layouts that might be faster?  How about using render to buffer or texture and an offscreen context (with glReadPixels(), glGetBufferSubData()  or glGetTexImage())?  Finally, we have some flexibility as to the image size as well.  Are there specific sizes that are known to be faster/slower?  Any help in narrowing down the options (or correcting our expectations) would be helpful.

Thanks!

rjf.

  • Up0
  • Down0
carrado.grant@g...
Join Date: 20 Sep 12
Posts: 38
Posted: Thu, 2016-01-07 17:21

If you are doing read back using glReadPixels by itself I would suggest STOPPING immediately. As to why anyone still chooses this route is beyond me as there is a myriad of documentation explain why this is very inefficient and will kill performance. With that said, the Adreno 330 does support pixel buffer object and those can be used for asynchronous readback ( this will make sense when you understand why using glReadPixel by itself is not a good idea ). If the pixel data is to be used host side ( on the CPU ), then this will probably be your best bet, however you may incur some latency in your application. If the pixel data is just being transferred around on the GPU, then you can render to a texture attached to a framebuffer object and passed that around. Hopefully, that points you in the right direction.

  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.