PDA

View Full Version : Performance: reading rendertarget each frame



john_connor
01-04-2017, 03:05 PM
Hi, i've read this wiki site:
https://www.khronos.org/opengl/wiki/Pixel_Buffer_Object#Downloads


Downloads: ... if you are going to read from the render target every frame, you may want to consider having two render targets and switching between them. Obviously, with resolutions being as large as they are these days, this will take up a lot of memory. It's something of a memory vs. performance tradeoff.

memory isnt an issue for me
i want to make the download operation as efficient as possible, so i'm considering to use an additional rendertarget (a "double-buffered" rendertarget)

my current framebuffer:
2 color attachments, 1 is a rgba color texture, 1 is a 32bit integer texture to store unique "ID" values of all rendered objects
each frame:
-- clear all attachments
-- render into both attachments simultaneously (MRT)
-- read the integer texture (basically 1 pixel at cursor position)
-- glBlitFramebuffer(...) to copy the rgba texture into the windows framebuffer


question: how should i do that ???

assuming my attachments are:
GL_COLOR_ATTACHMENT0 rgba texture
GL_COLOR_ATTACHMENT1 1st integer texture
GL_COLOR_ATTACHMENT2 2nd integer texture

should i call each frame:

GLenum buffers[] = {
GL_COLOR_ATTACHMENT0, // rgba
GL_COLOR_ATTACHMENT1, // 1st integer texture
};
glDrawbuffers(2, buffers);
glReadBuffer(GL_COLOR_ATTACHMENT2);

... and every next frame:

GLenum buffers[] = {
GL_COLOR_ATTACHMENT0, // rgba
GL_COLOR_ATTACHMENT2, // 2st integer texture
};
glDrawbuffers(2, buffers);
glReadBuffer(GL_COLOR_ATTACHMENT1);

or is there a better solution ? perhaps using a second FBO ?
or can i make somehow use of GL_READ_FRAMEBUFFER and GL_DRAW_FRAMEBUFFER ?


thanks for any suggestions !!

Silence
01-06-2017, 05:00 AM
From your quote I would use a single FBO and 2 render targets. Having 2 FBOs will imply to bind one of them for each rendering frame, and bind the other for reading back in the same frame, and do the opposite the next frame. This might be unnoticeable for some tests, but this has a cost for sure. With a single FBO you just have to bind once.

Just my two cents.