Getting the total video card memory

Started by
6 comments, last by AlexEiffel 21 years, 8 months ago
Hello. Does anyone know a way to get the total video memory in D3D? I tried GetAvailableTextureMem, but it was telling me I had 88080384 megs of available texture memory. The only way I see that as possible is if it is counting my hard drives'' memory as well. Any suggestions?
Advertisement
Alex Eiffel eh? Your parents big Pixies fans?
Heh, actually, I''m the Pixies fan. Though I tend to use Mr. Grieves instead of AlecEiffel now.
Get Up Kids have done a pretty neat cover of Alec Eiffel if you''re interested.

Reguarding your question, try looking up D3DCAPS in psdk, bound to be tied up in there somewhere.
Yeah, that was on the tribute album I believe. David Bowie just did a cover of Cactus on his new album, I''d like to say I like it (since it''s David Bowie and such) but I still can''t make up my mind about it.

I''ve looked all through the caps structures, but there is nothing I can find in there. The GetAvailableTextureMem was the closest I found, but like I mentioned, it''s telling me 88080384 megs of available texture memory... not quite believeable on a 4 year old computer, hehe.
I found this little example of using the GetAvailableVidMem() function in the Dx7 sdk. I haven't tried it yet.
WARNING: it seems it's a difference when using hardware surfaces (DDSCAPS_VIDEOMEMORY) and software (DDSCAPS_SYSTEMMEMORY)

// For this example, the lpDD variable is a valid
// pointer to an IDirectDraw interface.

  LPDIRECTDRAW7 lpDD;DDSCAPS2      ddsCaps2; DWORD         dwTotal; DWORD         dwFree;HRESULT       hr;  hr = lpDD->QueryInterface(IID_IDirectDraw7, &lpDD); if (FAILED(hr))    return hr;  // Initialize the structure.ZeroMemory(&ddsCaps2, sizeof(ddsCaps2)); ddsCaps2.dwCaps = DDSCAPS_TEXTURE; hr = lpDD->GetAvailableVidMem(&ddsCaps2, &dwTotal, &dwFree); if (FAILED(hr))    return hr;  


[edited by - filisoft on August 3, 2002 12:17:34 AM]
Have FUN,FeeL E!
Thanks for the help filisoft, I have actually tried your method as well, and though it is a lot closer to my actual hardware, it''s still off a bit. It reports 29 total megs on a 32 meg card. I think that it only counts memory not reserved by the system or something. Any other ideas on how to get it to actually report 32?
simply put very few drivers will report the correct amount. 29 meg is a more useful number anyway. it tells you whats avaiible excluding resources that are never availible (ie primary buffer, and other misc stuff, possibly backbuffer as well).

there is no way. look at the d3dcaps viewer with the sdk. does it show the number you seek? in any case, blame driver writers for not returning the right info.

quote:
GetAvailableTextureMem Remarks
The returned value is rounded to the nearest MB. This is done to reflect the fact that video memory estimates are never precise due to alignment and other issues that affect consumption by certain resources. Applications can use this value to make gross estimates of memory availability to make large-scale resource decisions such as how many levels of a mipmap to attempt to allocate, but applications cannot use this value to make small-scale decisions such as if there is enough memory left to allocate another resource


quote:
If the surface has the DDSCAPS_VIDEOMEMORY flag set, this method will return different amounts of video memory depending on whether or not the surface can be used as a 3-D texture. If the surface can be used for 3-D textures, the GetAvailableVidMem method will return the sum of the local video memory and the non-local video memory on AGP systems.

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).


some quotes from the docs for extended info.

This topic is closed to new replies.

Advertisement