Has anyone successfully used a texture of size larger than 64MB on a GeForce4?
With NV_texture_rectangle I am able to go beyond 64MB, but not with normal textures. The actual width/height/depth doesn’t matter, its the total size that seems to be the limit.
If I recall correctly, even NV_texture_rectangle is limitted by GL_MAX_TEXTURE_SIZE. And note that a 4096x4096x32-bits == 64MB. Given that your card only has likely has 128MB of RAM, you could never allocate more than one of these.
In any case, the drivers may limit you to 64MB of texture memory, reserving the rest for Windows swap-space (so that Windows doesn’t need to trash your textures when you alt-tab) and the frame/z-buffers/VAR memory.
Moshe,
My work also involves absurdly large sets of image data being used as textures under OpenGL. We came to the conclusion that we couldn’t simply rely on being able to generate a single texture and upload it - rather, we developed a class which, given a set of images and their spatial relationships to each other, generates usefully-sized (i.e., closest fit power of two) textures from the set as a whole. We store these tiles out to disk, forgetting about the original source image, and then only load tiles that are visible. These tiles become textures and are later released when no longer visible. It also builds the mipmap levels as seperate files - loading the textures at run time is pretty expensive to begin with and run-time mip map level buiding, even using SGIS_Generate_MipMaps just took too long. Also, some of our older cards would bog down when we bound a large texture object, even if we were only displaying, say, it’s 10th mipmap level.
To our joy, we now have an image set tens of gigabytes in size that (after a one-time over-weeekend import session) runs quite nicely on our new portable (A Dell Inspiron 8200 with the 64MB GeForce4-To-Go). It still runs faster on the GeForce4 Ti4600 of course, but this is the first time we’ve had a portable that runs our full-up app without some tinkering of the data.
The moral is, the speed of todays cards plus the speed of the AGP bus means your app can use ludicrous amounts of texture data, but you’ve still got to control how much you send up at any given time. Until you can add memory to video cards like you can a motherboard (4GB VRAM anyone?) we can’t resonably expect not to have to get involved with texture management.
On the other hand, a similar project failed miserably a couple years ago because the cards simply couldn’t handle having all of their texture data being constantly swapped out, since their 4 MB buffers were too small for the GPU side to hold all of the data for a single frame except at, like, 4 bits per pixel with the depth buffer turned off. Then they got a decent framerate, as long as they didn’t change their viewpoint… 
Anybody else out there using the new large memory, high speed cards simply for their ability to handle being fed large amounts of texture data?
-Chris Bond
Originally posted by Korval:
In any case, the drivers may limit you to 64MB of texture memory, reserving the rest for Windows swap-space (so that Windows doesn’t need to trash your textures when you alt-tab) and the frame/z-buffers/VAR memory.
First, I made an error in my original posting. Normal (power-of-2) single texture cannot go above 32MB (not 64MB as I wrote)
Doesn’t look like all that memory is reserved.
Frame + z-buffer is much less than 128-32=96MB
What’s more, I can take up much more than 32MB of textures (without paging), if I use several textures and not just one big texture. For example, I can do 120MB with 120 1MB 512x512x4 textures