   How do I find out the ratio of used/available graphics card memory?
  My application processes point cloud data. It might have well over a billion points (attributed) for a single project. Right now, all of the points are loaded onto the graphics card. The problem is: this application is used by many different systems with very different hardware in them. Some machines might have multiple gigabytes available on their graphics card, and some might have a few hundred megabytes.I am currently trying to design a level-of-detail component, so that the point clouds will become decimated when the graphics card is becoming overloaded (actually before the card is overloaded preferably). I would be able to do this much more efficiently if I were able to find out exactly how much memory is available on the graphics card, as well as the capacity of the graphics card. This must be done programmatically to avoid fictitious user input. It is not known what brand of graphics card the system will have. If anyone has come across this problem before, I would greatly appreciate a solution. Thanks!    
  What OS/API/language are you using?You generally can't find out reliably how much memory is used, since the API will handle swapping buffers etc. if necessary, but you can easily find the total amount of video memory. On Windows there's an example of different ways to do this in the DirectX SDK, in Samples\C++\Misc\VideoMemory.   ;  Note that while using the total amount of video memory is useful for tuning a basic "level of detail" parameter and you can use it to compare the basic relative capacity of different cards, you shouldn't really take that value too seriously. i.e you can't really say "this video card has 512MB of memory and I've allocated 500MB of textures, so I've got 12MB free", because the card stores more than just textures in memory (vertex buffers, index buffers, compiled shaders, and so on), textures can be compressed, and can be swapped in and out of video memory behind the application's back anyway.   ;Quote:Original post by Codekathe card stores more than just textures in memory (vertex buffers, index buffers, compiled shaders, and so on), textures can be compressed, and can be swapped in and out of video memory behind the application's back anyway.And other processes (ie. other applications, including the OS itself) can allocate VRAM resources concurrently. This is especially relevant if you are running a compositing desktop manager.   ;  There is the OpenGL extension GL_ATI_meminfo, which gives you information about:total memory free in the poollargest available free block in the pooltotal auxiliary memory freelargest auxiliary free blockfor texture, FBO and render buffer memory.However, from my experiments this does not work on the "latest" driver (modified mobile Catalyst 9.3 supporting a Radeon Mobile X1600): Creating 10 256x256 RGBA textures does not decrase the free texture memory :-?Maybe it works with newer drivers, I did not try...   ;Quote:Original post by EnricoHowever, from my experiments this does not work on the "latest" driver (modified mobile Catalyst 9.3 supporting a Radeon Mobile X1600): Creating 10 256x256 RGBA textures does not decrase the free texture memory :-?Perhaps the driver delays uploading the texture to VRAM until it's actually used. I would say this is another reason that any actual number you get from a "memory free" function is useless - the driver can do all sorts of stuff in the background that you don't know about.   ;Quote:Original post by Erik RufeltWhat OS/API/language are you using?You generally can't find out reliably how much memory is used, since the API will handle swapping buffers etc. if necessary, but you can easily find the total amount of video memory. On Windows there's an example of different ways to do this in the DirectX SDK, in Samples\C++\Misc\VideoMemory.I am running Windows XP, but other users are on Vista and 7 as well. The graphics are rendered via DirectX 9.0c in C# 3.5. I was just curious as to whether DirectX was keeping track of how much memory it was using behind the scenes, and it was accessible or not. It seems to be the verdict of the crowd that it is not that simple.   ;Quote:Original post by CodekaNote that while using the total amount of video memory is useful for tuning a basic "level of detail" parameter and you can use it to compare the basic relative capacity of different cards, you shouldn't really take that value too seriously. i.e you can't really say "this video card has 512MB of memory and I've allocated 500MB of textures, so I've got 12MB free", because the card stores more than just textures in memory (vertex buffers, index buffers, compiled shaders, and so on), textures can be compressed, and can be swapped in and out of video memory behind the application's back anyway.Yes, it wouldn't do me much good to only account for the memory usage of the textures. I was praying for more of a graphics card monitoring API that would know exactly how much was being stored on it at all time, similar to system monitor. I am now realizing that this type of library doesn't exist.   ;Quote:Original post by CodekaQuote:Original post by EnricoHowever, from my experiments this does not work on the "latest" driver (modified mobile Catalyst 9.3 supporting a Radeon Mobile X1600): Creating 10 256x256 RGBA textures does not decrase the free texture memory :-?Perhaps the driver delays uploading the texture to VRAM until it's actually used. I would say this is another reason that any actual number you get from a "memory free" function is useless - the driver can do all sorts of stuff in the background that you don't know about.I have a previous version that waits for an exception to be thrown and uses that to determine that it is trying to render too much at once. Not the most efficient way to go, but seemingly the simplest.I will have to make the level of detail object smart enough to severely throttle the number of vertices it dumps on the graphics card. The closer the camera is to the cloud, the more dense it will be able to render the points as many points will no longer be in view. My main goal with a memory monitor was to ensure that even on lower end machines there wasn't to be any overloading of graphics rendering going on.Maybe I just need an application variable that knows how big the graphics card is and just take a rough estimate at runtime for the LOD ratio.   ;Quote:Original post by bryanvagisMaybe I just need an application variable that knows how big the graphics card is and just take a rough estimate at runtime for the LOD ratio.That would be my suggestion, yeah. Make sure it can be overridden on the command-line, too :)   