Textures + PBOs - a few questions

[BrianDFS]

I come from a long history of DX coding, with bits of OGL here and there. I'm resurrecting a large chunk of older GL code and have a few quick questions regarding filling textures via PBOs.

1. If I have a texture that's intended to be static draw, i.e. I want to create it, fill it once with data off the disk, and then use it for repeat rendering, is it necessary to retain a PBO for that texture? Or can I create a PBO, map it, write to it, unmap it, call glTextSubImage2D (to have it source the pixels from said PBO), and then discard the PBO?

2. Furthermore, assuming I fill a texture one mip at a time, the PBO really only needs to as large as the largest mip?

Am I out in left field here? What's the general practice when it comes to PBOs and textures? Is there generally a one-to-one correspondence, i.e. one PBO for every one texture regardless of the intended usage of the texture, or can it be done the way I've described (for static textures only)?

Essentially, does creating a PBO set aside memory in addition to glTexImage2D? Or is the PBO just a conduit for accessing the memory allocated by glTexImage2D?

Thanks.

[Alfonse Reinheart]

PBOs have no direct relationship to textures. The only relationship they have is when you call glTexImage*, and that only lasts as long as it takes OpenGL to pull the image data from the PBO into the texture's memory.

The purpose of a PBO is to gain greater asynchronous texture transfer performance. If you use client memory to transfer data, then the driver must make a copy of the pixel data before transferring it asynchronously to the GPU. If it is in a PBO, then the glTexImage* call is very fast.

Well, unless you change that PBO before the asynchronous operation is complete.

STATIC_DRAW is almost never appropriate for pixel transfers. Remember: STATIC means that once you define this buffer object, you will never change its data again. Since you probably intend to use the same buffer object to upload multiple textures, this is almost never what you want to do.

STREAM is more likely what you want. You will write to it once, and then upload it once. Then write to it once again, then upload it once again (to a different texture).

[BrianDFS]

So for static textures there's really no point in using PBOs just to fill the textures once and be done with them. Safe assumption?

But how about dynamic textures? I understand that PBOs allow for asynchronous read/write functionality for textures. I'm still curious about the following two questions though:

1. Does creating a PBO set aside memory in addition to glTexImage2D? Or is the PBO just a conduit for accessing the memory allocated by glTexImage2D?

2. Is there generally a one-to-one correspondence, i.e. one PBO for every one texture regardless of the intended usage of the texture?

[Alfonse Reinheart]

I answered both of these questions:


PBOs have no direct relationship to textures. The only relationship they have is when you call glTexImage*, and that only lasts as long as it takes OpenGL to pull the image data from the PBO into the texture's memory.

The purpose of a PBO is to gain greater asynchronous texture transfer performance. If you use client memory to transfer data, then the driver must make a copy of the pixel data before transferring it asynchronously to the GPU. If it is in a PBO, then the glTexImage* call is very fast.

So no, they do not set aside memory for textures. All they do is allow you to use glTexImage and glGetTexImage calls without incurring synchronization overhead.