Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

DarkSlayer

How to find out how much video memory is free?

This topic is 5732 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''m doing a DirectDraw 7 tilebased game. With win32 api. ...and suddenly it popped into my head: "How much video memory does the video card have, and how much is free?" Why do I bother at all...I mean...a tile game doesn’t necessarily waste that much space does it? If you have a resolution of 1600 x 1200 with 32bit colour, that would use 7,3MB of the memory. A front buffer, a back buffer, and a buffer where you keep your different tiles….. it should be difficult finding a silly graphics card that could not run this silly game……. But I have 128MB on my overpriced video card ( I got it cheap though ), and if I want to make a buffer in video memory that could take advantage of the free memory, how would I then measure total memory and free memory? With my game I could take a 150x150 map, with 32x32pxl tiles, 32bits images, and store it in video memory….that would use almost 90MB of the memory…… I could also see other games taking advantage of free video memory as well. So how do I do it? There is a function in directx which is IDirectDraw7::GetAvailableVidMem. But it looks like it returns video memory + system memory reserved for the video card, so that wasn’t entirely easy. So how does the pro’s doing it? Creating huge surfaces and see which one of them returns a “out of memory” and not? Can’t say that would be all that smart thing to do….. how could I then create a game and let it take advantage of graphics card with 256MB or 512MB of video memory? Another question on the side here, if I create a ton of surfaces in video memory to the brink of no free memory available , and someone then use alt+tab or whatever, how can I be sure that tings stay “correctly” when my program receives “the focus” again? Bring out your dead! Bring out your dead! [clang] Bring out your dead! [clang] Bring out your dead! [clang] Bring out your dead! [clang] Bring out your dead! -= Monty Pyton: Holy Grail =- Bring out your dead! Bring out your dead! [clang] Bring out your dead! [clang] Bring out your dead! [clang] Bring out your dead! [clang] Bring out your dead! -= Monty Pyton: Holy Grail =-

Share this post


Link to post
Share on other sites
Advertisement
quote:
Original post by DarkSlayer
Another question on the side here, if I create a ton of surfaces in video memory to the brink of no free memory available , and someone then use alt+tab or whatever, how can I be sure that tings stay “correctly” when my program receives “the focus” again?


they never do. you need to reload all your surfaces if a device is lost.

Share this post


Link to post
Share on other sites
1)
quote:
If you have a resolution of 1600 x 1200 with 32bit colour, that would use 7,3MB of the memory


That''s an incorrect assumption. It *might* use *roughly* 7-8Mb. The hardware has all kinds of special needs for any surfaces and often includes extra memory for padding areas, alignment etc - for example one chip may require the width of ALL surfaces to be say an integer multiple of 64pixels (i.e. 64,128,256 etc), so if you create a 16x16 sprite, in video memory (private to the driver) it might end up taking 64x16 worth of memory. Other chips may compress surfaces in various ways (e.g. [hypothetically] using RLE on 8 bit surfaces) meaning they take much less than you thik. etc etc etc.

The padding areas are also the reason why you have to account for pitch when locking (i.e. so you can skip any non-visible part of the surface) and part of the reason why you have to lock in the first place (i.e. the driver may convert from its internal swizzled/compressed internal format to a linear format in a temporary system memory buffer).

Because most people make that mistake, looking at the documentation for GetAvailableVidMem() you''ll see:
quote:
This method provides only a snapshot of the current display-memory state. The amount of free display memory is subject to change as surfaces are created and released. Therefore, you should use the free memory value only as an approximation. In addition, a particular display adapter card might make no distinction between two different memory types. For example, the adapter might use the same portion of display memory to store z-buffers and textures. So, allocating one type of surface (for example, a z-buffer) can affect the amount of display memory available for another type of surface (textures). Therefore, it is best to first allocate an application''s fixed resources (such as front and back buffers and z-buffers) before determining how much memory is available for dynamic use (such as texture mapping).


On more recent versions of the video memory retrieval functions the value returned is deliberately rounded because so many people wrongly assume a 2Mb video card means 2Mb of surfaces can be created.



2)
quote:
So how does the pro’s doing it?

Plan different versions of all your surfaces and frame buffer sizes. e.g. for Pac-Man:Adventures in Time (which had to work on 2Mb cards) we had about 3 main internal configurations:

a: GetAvailableVidMem returns 3.5Mb or less
b: GetAvailableVidMem returns 7.5Mb or less
c: GetAvailableVidMem returns over 7.5Mb

The texture sizes were scaled and the choice of modes limited depending on what we knew would *ROUGHLY* fit.

However, I can''t stress enough how important it is to take that as an extremely rough guess amount and do the same when estimating what you''ll be able to fit in memory.

You should still make your code handle "out of memory" errors as gracefully as possible, because they CAN still happen.
Some drivers unfortunately return bogus values for the total video memory, some return more than can actually be created. Many others return the amount free *AFTER* the memory used for the desktop has been taken into account - in a fullscreen exclusive app, that memory is also available for your surfaces but won''t look like it. This came up for us during compatibility testing of Pac-Man:AIT, we got startup failures on some laptops with 2Mb of VRAM - when I investigated the problem I found those chips reporting something like 1.2Mb of VRAM.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
Thanks for answearing.

I didn''t had too big hopes on the GetAvailableVidMem() function, and I know it is just roughly. But on my computer it returns a value which is at least 64MB wrong, so it is completly useless.

But I found your points on the pitch a great tip, I knew they could be silly, but when you have 128MB onboard the card, it''s no big deal you think, so thanks for making the point. It would be a bit silly making a 2D game returning "out of video memory" when you have 128MB hehe.

I''ll be back with more tricky questions....but first I have to deal with security issues on my computer after it became hacked resently.....silly freekin naughty kiddies.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!