PBO as textures

I just got the Superbible 4th edition, and they talk about using PBO for textures. I can do one and it works fine, but not sure what I am doing wrong when I try to use many different textures…

By this I mean if I was using glBindTexture() and bound 10 different texture objects to render. I am assuming you still need to call glActiveTexture() on each unit you want to use and then call glBindBuffer()? and no need for glBindTexture or glGenTexture either? I didn’t use them with the one buffer I have working. Also when shutting down many buffers, do you only call NULL on that buffer type once for e.g. 10 buffers bound?


I think you’re misunderstanding what they’re talking about when they say “use PBO for textures”. There’s two viable possibilities.

The first is the recent extension, " Texture Buffer Object . That is, a 1D texture of significantly larger size than a regular 1D texture, who’s data is stored directly in a buffer object. But unless you’re using G80 or R600 hardware, this is not what they’re talking about.

The other thing is the intended purpose of PBOs: asynchronous data transfer. You don’t use PBOs as though they were texture objects. You simply use them to transfer texture data to the implementation.

Basically, when you do a glTextureSubImage, the implementation must copy every bit of data out of your pointer before returning control back to you. It can then asynchronously transfer data upstream. For a large texture (2048x2048: 4MB even with S3TC), this extra copy time can be fairly onerous.

By first putting the image data in a buffer object, you allow the driver to not copy the data itself. You just hand it the buffer object, and go do something else while it feeds on the data.

Note that this does not mean that the buffer object is the storage for the texture, or that the texture and the buffer are in any way linked. You should not do this every frame for static images; it’s primary purpose is to speed the upload for dynamic image data.

You sure you don’t mean P-Buffers instead of PBO’s?
(or possibly FBO instead of PBO?)

the poor PBO extension seems to be the most misunderstood one out there… at least, for something so simple :frowning:

gives it a cookie

Korval, thanks for clarifying this for me. I was under the assumption that you could use them as a buffer object vs. a texture object and would give some kind of speed increase.

So, I can use the PBO to stream the data from the HD to the GFx VRAM and bypass the system’s RAM. So once in there I still need to glGenTexture() and glBindTexture and then do a glTexSubCopy? to setup a texture object?


Once you’ve got the data in a GL_PIXEL_PACK_BUFFER_EXT, you can bind that, and then call glTexSubImage2d() with the pointer argument being BUFFER_OFFSET(0), with

#define BUFFER_OFFSET(i) ((char*)NULL + (i))

Essentially, the only thing PBO helps with in this use-case is that texture download is asynchronous on the CPU side. Everything else is the same, except that while a buffer is bound, glTexSubImage looks there instead of in system RAM.

So no, you aren’t bypassing system RAM; you’re just avoiding a few milliseconds of CPU blocking during download.

The other use-case for PBOs is during readback, and you get a similar advantage there.