PBO - Texture Memory extension idea


I’ve got an idea on using texture objects with Buffer objects. It should be possible to obtain the buffer memory of an texture object, like:

unsigned int my_buffer;
unsigned int my_texobj;

glGetTextureBufferObject(&my_buffer, my_texobj);

Then you can access the texture data with buffer objects. I think that this wouln’t get into problems because a texture object is quite the same as a buffer object.
There are some things which have to be taken care of, like a glTexImage/glCopyTexImage/… call. This call have to change the buffer size value of the buffer object.

What do you think about that?

Excellent suggestion. This would provide way to access texture data using PBO. What about mipmaps?
Maybe to extend function to:
glGetTextureBufferObject(&my_buffer, my_texobj, mip_level);

One more issue… If I call ptr = glMapBuffer(…) I shoud get address of texture data. What about texture data storage? I doubt it’s a stored row-by-row? Incorret changing of this data may crash driver? What about compressed textures too?


I haven’t read the PBO extension recently, but supporting mapping could be a very serious problem. Textures are frequently not stored in a linear fashion; they are often stored in a hardware-friendly “swizzle” pattern. PBO normally is used to transfer image data; this does not mean that swizzling is ignored. Any required swizzling will happen during the transfer.

The thing is, mapping is usually assumed to be giving the user access to the memory of the object. Granted, it doesn’t have to be, but if it isn’t, then each map operation will cause a download of the data, along with a de-swizzling, memory allocation, memory deallocation, and a re-upload of the data after user modification (not necessarily in that order). This is not a fast operation. At least with VBO’s, if you map them, they can simply leave them in main memory; textures have to be in video memory to be of use.

It’s just not a good idea to start fetching/setting texture data using PBO.