Open christian-rauch opened 5 years ago
If you haven't noticed, I'm trying to get through my Issue backlog with some free time I have right now :)
Again, 3 years too late, but this isn't a simple topic! glReadPixels is a pretty horrible API because it blocks (and we know multithreading in OpenGL is rough). It has to block because it needs to guarantee the lifetime of the memory it's copying into, and you need to know when it's ready.
I'd recommend reading http://www.songho.ca/opengl/gl_pbo.html about pixel buffer objects and causes of GPU stalls. You can also upload / download from PBO's asynchronously (e.g. https://www.seas.upenn.edu/~pcozzi/OpenGLInsights/OpenGLInsights-AsynchronousBufferTransfers.pdf) so that you can overlap IO etc (again, you need to be careful to avoid stalls by being careful about things that will cause the execution queue to stall).
I am reading from the colour and the depth buffer using OpenGL's
glReadPixels
function and try to achieve a high rendering and reading throughput.Question: How do I need to use
glReadPixels
to achieve the fastest reading time for colour and depth buffers?example code:
The following modified HelloPangolin example (code+cmake: HelloPangolin.zip) reads the buffer directly to a opencv matrix/image, measures the time of this operation, and writes the image to disk:
buffer reading time:
I get different reading times for the colour and depth buffer on different machines, which makes me wonder what reading times I can expect. E.g.
I read somewhere that the buffer type and the reading type (
GL_FLOAT
) need to match to prevent type casts. But when usingGL_UNSIGNED_INT_24_8
(24bit depth, 8bit stencil) in place ofGL_FLOAT
I getGL_INVALID_OPERATION
(0x0502).1ms for reading the colour buffer (w x h x 3 x 8bit) seams reasonable to me. Since the depth buffer is supposed to be of the same size (w x h x 24bit), I would expect similar reading times there.
How do I need to setup Pangolin or
glReadPixels
to achieve the fastest buffer reading time?