Handling over 4gb textures (BigTiff) OpenGL

Question

I am working on some HD imaging software and although very large textures are not currently planned for this version I wanted to do some future proofing.

If i was dealing with very large textures (e.g. 1095630 x 939495), could I use standard combination of compressed textures and mip mapping or are these textures going to be far to large to store in texture memory?

My assumption is they would be too big and I would have to do a psudeo manual mip map on the CPU. I.e grab the very large data, create a sensible compressed version for the full zoom out and then as the user zooms in, send sub sections of the large texture to the GPU?

The idea of doing said compression on the CPU would be awfully slow, so my plan is to tile the data and send it it chunks to the GPU for compression. In which case, how do I find out, preferably dynamically, the maximum texture size the GPU can handle?

I am new to the TIFF format but from the looks of it, its already stored as tiles, is this correct? I hope to play a bit with the libtiff but I haven't found many examples of its use (my google skills fail me today, apologies). https://stackoverflow.com/questions/ask

Existing Examples I am hoping to get some pointers from these two:

• BioView3D (open source ftw)
• BigTiffViewer

In summary:

• How do i find out the maximum texture size the GPU can handle (preferably 3D texture size...)
• Whats the best way to break up the large texture format and compress it to what the GPU can handle
• Whats the best way to facilitate the zooming?
• Pointers on using libTiff?

Answer 1

It depends on the hardware you're targeting.

If your goal is widespread support over a large range of GPU generations, then in-situ updating of texture (mipmap) levels like you suggest is the way to go. Older GPU generations have a limit on the maximum texture resolution that can process. Usually something around 4096 to 8192 in either dimension. Normally you'd have a set of tile textures (each tile being some 1024×1024 or so), with enough tiles allocated to cover the whole screen plus some margin.

If your target are the later generation GPUs then you can make use of something called "Megatextures" by John Carmack: Using a bindless, sparseless texture. This is not core OpenGL functionality though, but exposed by the extensions GL_ARB_sparse_texture and GL_ARB_bindless_texture. Instead of having a set of texture tiles, you have one large "virtual" texture, into which you can stream the required tiles on demand.

On GPUs supporting this you also won't run into limits set by the amount of dedicated GPU RAM. OpenGL never had a concept of "available video memory", and textures could always be swapped in and out on demand. With the support for sparse textures, today GPUs can offload gigabytes of texture data in system memory and fetch it from there into their GPU RAM when needed (essentially the system memory turns into a L4 cache for the texture data).

Answer 2

OpenGL does have a limit on the maximum size of a conventional texture. This limit is implementation specific and can easily be queried with glGetInteger():

GLint maxGPUTextureSize;
glGetIntegerv(GL_MAX_TEXTURE_SIZE, &maxGPUTextureSize);

As per the documentation:

The value gives a rough estimate of the largest texture that the GL can handle. The value must be at least 1024.

That being the max squared size in pixels of a texture. I.e.: 1024x1024.

Now, as was suggested by @datenwolf, your problem seems quite suitable for the "Virtual Texturing" AKA "Megatexture" technique. Do a search for those terms and you will find a lot of work and papers on the subject. I think this GDC presentation by Sean Barret was one of the first open works on the subject, very worth the look. Also, the GPU Pro 1 book has two articles about the technique.