Since OpenGL doesnot have a way to find out how many RAM is free in the video card I thought the only way is to use DirectX. DirectX has a useful command the GetAvailableVidMem which returns the Total and Free video ram.I used this command in my older DirectDraw games and it worked just fine then.
If I start a DirectDraw proccess that every 3sec writes to a file the result of this command, and then I start my Opengl program shouldn’t it work? Have anyone tried it or something like it?
Is there a good reason why you need this kind of info?
What you’re suggesting sounds horrendous. And I’d be very suprised if it works.
There is really no need to know how much Video RAM you have. Some cards dont even store textures in Video RAM.
Nutty
There is really no need to know how much Video RAM you have.
I wouldn’t go so far as to say that there is no need to know the ammount of VRAM is avaliable. It would be nice to have a general idea (16MB, 32MB, 128MB) at the beginning of a program so that you may estimate how large are the textures you are willing to use. But, as far as trying to look at the output of some function like GetAvailableVidMem() and making some decision (like you have 4.7MB free, so you feel that a 4MB texture should fit) is not necessarily going to be successful in OpenGL.
Some cards dont even store textures in Video RAM.
I don’t know of any modern, consumer-level graphics card that does not use video memory.
[This message has been edited by Korval (edited 02-18-2002).]
If you want a quick estimate, just check the board type in the vendor string or something… and make a quick lookup table. Something like.
[“GF2”][32MB]
[“GF3”][64MB]
[“GF4TI”][128MB]
Althugh there are gf2’s with 64 meg n stuff… but most have 32. I still believe you should always make it user definable also. So they can increase or decrease texture detail to their taste.
Nutty
Maybe the free VRAM is not useful during the execution of the program. But the total ram is very useful. You can use some texture size presets. For example for 16mb cards you cound use small textures, for 32mb medium, and for 64+ the maximum resolution.
For example if you use a sky box with 6 big textures it matters a lot if these are 512x512 or 256x256 in a 16mb card 
.After all, vram should also be used for display lists and compiled vertex arrays not just textures.
Well you can just have a terrain detail option.Low,med,high if a user with a 16mb card sets it to high performance will suck but it won’t be your fault and hopefully he will be able to ‘guess’ the problem.Why automate everything?Remeber automation maybe easier for some users but it gives you less control and is more bug-prone.(e.g. I might have a 16mb card but still want to see how it is with better textures.Why shouldn’t I be able to do that?).Keep it simple and efficient.(btw isn’t this what happens in quake3?There you go.)
So you want to know the total amount of memory available, and if the user has select 4x AA in the display panel, will you then have 32MB free memory, or hole lot less because of the AA?
If you are running on a 3DLabs card with it’s virtual texture memory, which can through clever caching appear as if it had a hole lot more texture memory than it physically has. Should you then limit 32MB 3DLabs users to predef. 32MB textures rather than the 256MB that the virtual texturing allows?
So the card can do this really, reaally fast texture upload and thus doesn’t really need to have alot of texturememory free. And this really, reaally fast texture upload is only available through some complicated procedures. Wouldn’t it just be easier to let the driver handle it then?
The Intel I740 had no texture memory. Though it’s obsolete, that technology might come back. So why do you want to limit yourself to what you only know right now. Instead of placing the responsibility on OpenGL. And have you application adapt.
Also, you should rather give the user the option to select themself.
Isn’t DX also starting to move away from telling how much memory that’s available?
Btw. some OpenGL drivers used(they might still do) to use DX underneath, this will mostly likely break your idea of checking every x seconds.
And you shouldn’t make presumptions on where the graphics adapter will place the different data. It might not allways be obvious to us why it might place Vertex data in AGP memory instead of vidmem when ther’s clearly enough space for it to be there. And we shouldn’t worry about that.
Maybe it’s an idea, to load all textures form their smallest mipmap level to the most detailed. First the samallest then the next detail step and do on. If the card lacks of memory you’ll have all textures in with the maximum degree of resolution.
Of course you’ll have to set your mipmap ranges new and performance will be terrible, but I think, that you want to load all textures at the beginning of your level.