|
Determining Free Video Memory Question submitted by (18 September 2001)  |
Return to The Archives |
 |
 |
|
|
I'm working on a little 2D shoot-em up for Windows using OpenGL for
rendering and DirectX for sound and input. During initialization, I'm using
a texture proxy to check if my texture formats are supported. In debug mode
I'm also polling the amounts of free/used/total physical and virtual memory
during the game, using GlobalMemoryStatus(). But I'd like to poll the amount of free/used/total video memory as well. By searching the MSDN library I found how to do it in DirectDraw, but that isn't doing me any good in my OpenGL game. ;) So basically I'm asking: Is there a any way to figure out how much free/used/total video ram there is, while not using DirectDraw or Direct3D? |
||
 |
 |
 |
|
|
|
My first question is: Why do you care how much video RAM is available? I'll
assume that your reason is so that you can determine how many textures you
can store on the card. The reason it's difficult (and sometimes impossible) to determine the amount of video memory is very similar to the reasons why OpenGL won't let you lock the frame buffer and access it directly. Let's take this to an entertaining extreme. Aliens have landed on Earth. What they like most about our planet is our video games. You see, their race lacks the creative juices for creating games. Their technology is a few billion times greater than ours, so it's extremely distressing to them to see the horrible graphics in our games. They decide to open a company creating video cards. Matrox, ATI & nVidia all went out of business the next day. Their technology bears absolutely no resemblance to ours. For example, they store all their textures in a single byte because they've got some fantastic dynamic compression algorithms (and as any good alien knows, you gotta switch to a math system of base PI to get to the REAL compression schemes.) Their frame buffer requires zero bytes, because their video display technology isn't based on displaying the contents of memory. Instead, they use a single mathematical formula. As you render portions of the scene, they simply change a few of the parameters to this formula. No scan conversion, no worries of texture accuracy, no z-buffer lookus, etc. Later, when the display hardware generates our cheezy ("Earth based technology") analog video signal, the hardware solves the display formula over time, and out pops a video image on our monitors. So, do you really care how much video RAM is available? :) I realize this is very extreme, but this does have some foundation in today's world. For example, a card may find it best to store textures in memory on 256-byte boundaries. If a texture ends on a 128-byte boundary, then 128 bytes are wasted. But the performance benefit to that particular hardware platform is well worth the occasional waste. You add this up over a few thousand textures, and you might find that you thought you had room for 8 more, but don't. Also, some card may decide to store their mipmaps on separate memory busses for faster access. So now you have a number of "memory banks" to work with. Will one value for available RAM suffice? Probably not. What about distributed rendering through multiple devices? I'm no expert on hardware, but I wouldn't be suprised if the cards on the market today employ stuff that would impede our ability to manage video memory directly. I've also seen a number of video cards report incorrect memory values on DX7. I don't know if this was a bug in DX7, a bug in the driver, or if the driver simply didn't know -- it wouldn't suprise me. Even today, we have a number of algorithms that will not know their outcome. A BSP is a good example. You can't query a BSP for the number of available nodes -- it all depends on the scene as to how the tree will be built. So I wouldn't be suprised if video cards (or their drivers) are already utilizing algorithms with this same property. This kind of thing is a small price to pay for the performance you can get from a 3D card. Response provided by Paul Nettle |
||
|
|
|
This article was originally an entry in flipCode's Ask Midnight, a Question and Answer column with Paul Nettle that's no longer active. |