   Amount of free and used GPU memory?
  Hi guys!Is there a simple and easy way to access the free and total gpu memory? I need to monitor both values (possibly per frame), using opengl and windows xp.Any ideas?Thx in advance!   
  There's generally no reliable way to get this information accurately. You may try vendor-specific GL extensions (what type of card do you have), but even that is generally just a guideline.Why do you need this?   ;  First I need to load a huge amount of textures into the gpu memory, and I want to do some resizing based on the total gpu memory size. (it varies greatly per workstation)   ;Quote:Original post by sirpaleeFirst I need to load a huge amount of textures into the gpu memory, and I want to do some resizing based on the total gpu memory size. (it varies greatly per workstation)There is no portable/reliable way to do this, although various vendors and Operating Systems offer ways to ask for a rough estimate.Games generally expose a setting to the user to adjust this. I take it that is not an option here?   ;Quote:Original post by swiftcoderThere is no portable/reliable way to do this, although various vendors and Operating Systems offer ways to ask for a rough estimate.I could use openCL to get the size of the global memory, but that still doesn't solve my free memory problem. (the whole engine is running in the maya viewport, so there are already a lot of resources in the video memory).Quote:Original post by swiftcoderGames generally expose a setting to the user to adjust this. I take it that is not an option here?Nope, most of the users are artist, not technical staff.   ;Quote:Original post by sirpaleeQuote:Original post by swiftcoderGames generally expose a setting to the user to adjust this. I take it that is not an option here?Nope, most of the users are artist, not technical staff.But it still is the only realistic option you have. Changing resources based on 'available' VRAM queries is completely unreliable. Keep in mind that VRAM availability is volatile. You're not the only graphics-using process on the system. Other processes, and the OS itself will constantly allocate and free VRAM, independently of your application and at any time while your app is running. It could very well be that when the user starts your application 1GB of VRAM is available, but a couple of minutes later it's only 100 MB. You have no way to predict this. And that's especially true on an OS that virtualizes VRAM, like Vista or W7. These OS can allocate or free tons of VRAM at completely random moments, a process that is out of your control. And that's not even considering things like VRAM fragmentation or shared memory architectures.   ;  Vista/W7 also adds the complexity that VRAM is "virtual". So even though only 1GB of physical memory may be present on the hardware, it will still let you "allocate" much more than that, swapping it in and out of system memory as required.One way you could do is by "auto-tuning". That is, if you notice performance is dropping, switch to lower-sized textures. When the application starts up, start off with the smallest texture size and slowly ramp up until you notice a drop in framerate (or whatever).   ;Quote:Original post by CodekaOne way you could do is by "auto-tuning". That is, if you notice performance is dropping, switch to lower-sized textures. When the application starts up, start off with the smallest texture size and slowly ramp up until you notice a drop in framerate (or whatever).Doing this can confuse the virtual memory management in Vista or 7 (probably driver dependent). WDDM can adaptively cache compositor surfaces depending on current VRAM usage. It's not always possible to reliably trial'n'error the memory limit, as that limit will fluctuate due to the internal effects of your iterative tests.The best you could do is probably a coarse fallback system. Start with a user selected detail level: high, medium, low. Even artists should be able to deal with that ;) Then, if you notice extremely bad framerates over a longer timeframe (you have to give the graphics driver a chance to dynamically evict OS caches), then you can start reducing the detail level. After reducing a level, wait for the driver to adapt its caching strategy before falling further.;Quote:Original post by Yann LThe best you could do is probably a coarse fallback system. Start with a user selected detail level: high, medium, low. Even artists should be able to deal with that ;) Then, if you notice extremely bad framerates over a longer timeframe (you have to give the graphics driver a chance to dynamically evict OS caches), then you can start reducing the detail level. After reducing a level, wait for the driver to adapt its caching strategy before falling further.It's not like a traditional game engine, I'm only rendering on demand, so I only have per frame render time, not a classical fps value (however that shouldn't be a problem...), but the scenes are rather complex, so I don't even have an optimal render time (it varies from 0.05 sec even to 2-3 secs, a huge amount of lights, high quality soft shadows etc...).;  What's the problem? You are thinking that if VRAM runs out, then there will be problems when in fact there would not be any. The drivers use RAM as an extension and have been doing so since during the days of PCI video cards.Things get reuploaded to VRAM when needed.The difference between 1995 and today is that PCIExpress is ultra fast so there is even less reason to worry. I have even played games on high settings when I'm suppose to have 512MB but in fact I had 256MB. No problems.   