I recall someone saying their graphics card at some point ran out of memory and spit out an error. So if I have say 1G of level data (models/textures etc) that need to go on the card, and the card has only 512MB, I know sometimes the cpu/gpu share memory and I could still upload 1G of data to the card (with 512 sitting on the cpu), but what if that doesn't happen? What if there is an error when going past 512MB. What is the best way to load textures on the fly:

Example, I'm up close to a helicopter model that has a 2048 texture. I run away from it for 30 seconds, it will bind the texture but only use the 512 version of the mip-map. As I'm walking away I'm getting closer to a jeep model. Again they are part of this overflow of textures so I'm looking to manage them and only have relevant ones in memory. So do I delete the helicopter texture and re-upload it only to the 512 version. I know you can set the min/max mip-map levels to use, but that doesn't mean it will destroy the 2048 portion if I force the 512 as the maximum level. So thats what I'm wondering, if I would have to re-upload it to the gfx card only up to the 512 level, and then do the same for the jeep (delete and upload up to the 2048 level).

Or are there other options? I'm assuming on most FPS games, they anticipate going into a new part of the map and start to load a couple items per frame and by the time the player gets there, they will hopefully all be loaded.

If you do need to stream textures asynchronously, then look into PBO.

Deleting and re-uploading textures at runtime is only going to kill performance, and - what's more - video memory used by a texture is not necessarily released the instant you call glDeleteTextures. Depending on how your driver implements it's own memory management (which you most definitely do not have control over) it may not be released until some time later, so not only have you killed your performance but now you've gotten absolutely nothing for it.

General solutions are:

• Use compressed textures. Depending on the compression chosen this can get size down to 1/8 of what it was. There is a quality tradeoff but in most cases it's acceptable.
• Use smaller textures. Do you really need a 2048x2048 image for a brick wall?
• Use detail textures. It's old, it's slightly cheesy, but you might yet find that it's suitable for a specific problem case.
• Reuse textures where appropriate. That helicopter? You can bet that all of it's blades look the same, so why store multiple copies of the same image? Break up the helicopter into a "body" model, a "blade" model, etc, then draw the same "blade" model multiple times. Or if you don't want want to break it up, adjust the texcoords for each blade so that they're all referring to the same area of the source image.
• Use tiling (repeated textures).
• Use something like ID's megatexture, which works in a completely different manner (but there's a reason why John Carmack can afford to play with space rockets while the rest of us can't.)

I don't think I will actually fill it up, But I'm just wondering.

Do you really need a 2048x2048 image for a brick wall?
[/quote]
Yes. I will settle at nothing less than 1024 for anything remotely small, and 2048 for everything else. I'm kinda sick of playing games that still have like 512 textures. I ducked behind a crate in FEAR 3 and it was so crappy. For an object that will potentially fill the whole screen to have with such a low res texture I was like F that. I was also thinking that DXT RGB is only 1/4 compression instead of 1/6.

I guess my issue is not an issue though, I just remember someone posted once that they got an error on creating a new texture or something.