Question about 3d texture on GF4

OpenGL OpenGL: Advanced Coding
1

My GF4Ti4600 is failing to display a 512x512x128 RGBA8 (128 Mb) texture. It just comes out black and opaque. Smaller sizes such as 512x512x64 work fine. 512x512x128 luminance textures also work.

GL_MAX_3D_TEXTURE_SIZE_EXT is reported to be 512, and no OpenGL errors are spit out.

Is it failing because there is not enough video memory left over after framebuffers and whatnot to contain the whole texture? Is there an error I should be looking for to catch this case? For instance, what if I had enough display lists/VBO or whatever on the card such that a smaller volume doesn’t fit? It would be nice to have the application notify the user instead of simply failing to draw anything.

Thanks,
Zeno

2

Yes, you are running out of memory.

You should use proxy textures to verify that your texture will fit into video memory. Here’s how to check if your texture will fit:

  1. call glTexImage3D with a target parameter of GL_PROXY_TEXTURE_3D and pass in NULL as the pointer to the texels array. All other parameters to this call should be the same as your usual glTexImage3D call.
  2. Call glGetTexLevelParameter*() with a target parameter of GL_PROXY_TEXTURE_3D to query the width, height, depth, etc… of the texture and if the values returned are 0, your texture couldn’t fit into memory.
3

Remember though, that the proxy query does not answer the question if the texture specified will be resident or not.

4

Your 3D texture must completely into the local graphics card memory, because 3D textures allow you to render arbitrary slices throw the volume.

However, the size of a volume doesn’t have to be limited to the maximum size of graphics card memory. In volume graphics there is the well known technique of bricking: http://www.sgi.com/software/opengl/advanced97/notes/node190.html http://www.vislab.usyd.edu.au/users/manuals/vis/volumizer/doc/sgi_html/ch04.html#id5199091

Note, that bricks have to overlap by one voxel (texel) to fix interpolation.

5

jra101- I tried the proxy texture thing. What’s weird is that it accepts the large proxy texture and returns the dimensions I gave it even though the texture itself doesn’t fit in RAM and doesn’t show up on the display. Is this a bug?

Klaus - What you say makes sense - that the whole texture has to fit in video memory. I just wanted to ask to be sure that I wasn’t missing some other problem. Thanks for the links on Bricking . Do you know if texture borders work on 3D textures and if so on what hardware? That’d make the 1 pixel overlap a lot easier and more memory efficient.

– Zeno

6

Zeno - sorry, i never tried texture borders, so i have no idea if they work. They should … :wink:

In OpenQVis (http://openqvis.sourceforge.net/) we don’t use texture borders for bricking. We just duplicate border voxels and adjust texture coordinates.

7

Ya, looks like proxy textures aren’t doing the right thing in our driver in this situation. I’ll file a bug on this.