Asynchronous texture streaming using a PBO

Hi,

I have a question regarding PBOs in a CPU -> GPU transfer scenario.

When a PBO is bound, I understand glTexImage2D() returns immediately. What happens with regards to OpenGL rendering while the texture data is being transfered?

What happens if, say, I have a fragment shader attempting to do texture reads on the texture being transfered? Will the values be unpredictable? Or will the texture fragment lookup wait/stall until the texture transfer has completed?

Thanks,
Fred

No, it is not unpredicatble. While TexImage in fact returns immediately, the forthcoming rendering commands will actually be executed on the GPU after the image transfer happened.

When you usually issue a draw call that is not executed immediately either. Commands on the server side are always executed in the order you requested so even though TexImage will return immediately on the client side, on the server side it will be executed before any subsequent commands.

Thanks for your reply. This makes sense.

I have another related question, this time regarding the usage of 1 or 2 PBOs for texture streaming.

I have found this page:
http://www.songho.ca/opengl/gl_pbo.html#unpack

There is one thing I am not very clear about: why are 2 PBOs necessary to maximize efficiency?

It seems to me that being able to discard PBO buffer data (*) is sufficient to maximize performance, and it only requires 1 PBO.
Isn’t it?

I.e.:

// Bind PBO
glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, pbo);

Label1:

// (*) Request new buffer data (third parameter = NULL)
// This call will return immediately. The GPU will complete any transfer in progress with the previous buffer data
glBufferDataARB(GL_PIXEL_UNPACK_BUFFER_ARB, DATA_SIZE, NULL, GL_STREAM_DRAW_ARB);

// Load up new pixels into the same pbo, but into its new buffer data (requested above), not the previous one
glMapBuffer
updatePixels
glUnmapBuffer

// Issue asynchronous transfer to texture
glTexImage2D(…, 0);

goto Label1;

What do you think?

Thanks,
Fred

This version is okay. It should be as efficient as two PBOs as you anyway discard the previous buffer and ask for new storage.

In such cases actually the driver will retain the previously allocated storage until the transfer is completed so actually in this case also at least two PBOs are present just the application does not have to worry about it.

You are probably right :
http://www.opengl.org/discussion_boards/…true#Post276595

Yes.
I am a bit surprised the web page I mentionned above explicitly manages 2 different PBOs, but also still uses the trick here to discard the previous buffer.

Thanks for your feedback.