c++openglrace-conditionpbo

Race Condition with PBO

I read something about PBO's in OpenGL and I got a question regarding a race condition.

Let's take the following example: I got two PBO's and I want to transfer their pixel data in turns to a texture object. So when I start an asynchronous pixel transfer for one PBO I can immediately do something else with the CPU while the pixel data is transferred in the background. Now I do some pixel manipulation on the second PBO and when it's done I want to transfer the pixels from the second PBO to the texture object. But what if the transfer of the first PBO isn't done yet? It's like in this first example: http://www.songho.ca/opengl/gl_pbo.html

index = (index + 1) % 2;
nextIndex = (index + 1) % 2;

glBindTexture(GL_TEXTURE_2D, textureId);
glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, pboIds[index]);

glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, WIDTH, HEIGHT, GL_BGRA, GL_UNSIGNED_BYTE, 0);

glTextSubImage2D() will return immediately and I can start working on the second PBO while the data of the first PBO is transfered to the GPU. What if glTexSubImage() (the pixel data of the second PBO should now be transfered) is reached before the first transfer has completed? Will it result in CPU stall-cycles?

Solution

  • OpenGL will introduce a synchronization point and make sure, that further asynchronous operations will not effect on any operations scheduled by former calls making use of the modified OpenGL objects.

    What if glTexSubImage() (the pixel data of the second PBO should now be transfered) is reached before the first transfer has completed?

    Nothing unexpected. All calls sceduled after the call to glTexSubImage will make use of the modified data. All calls scheduled before it make use of the unmodified data. The OpenGL specification mandates this.

    Will it result in CPU stall-cycles?

    It may, or may not. OpenGL doesn't specify this.