Video Memory

I

Infinisearch

New member
In the DirectX CapsViewer included with the DirectX8.1 SDK under:
DirectDrawDevices/~DisplayDevice~/Memory/
The program reports video, local, non-local, and texture memory. Does anybody know by what method the program gets this information? The closest I got was the GetAvailableTextureMem() method of the IDirect3DDevice interface. The D3DCAPS8 structure doesn't seem to possess the information either.

* In another forum it was suggested that it might be done through a DX7 interface, before i start installing and reading the dx7 SDK does anyone know if it can be done through 8.1.

Any help would be greatly appreciated.
 
I don't have any answer, but I have a question ... :)
Why do you need this information? An application shouldn't make any assumptions based on the size of the video memory, it should really be transparent.
 
Humus said:
I don't have any answer, but I have a question ... :)
Why do you need this information? An application shouldn't make any assumptions based on the size of the video memory, it should really be transparent.
Click to expand...

this might be off topic...but have you been active in the amiga scene like...say 10 years ago ? I knew someone from lulea/sweden once back in those days :)
 
"Why do you need this information? An application shouldn't make any assumptions based on the size of the video memory, it should really be transparent."

The reason I need the information is I would like to make an LOD renderer. Actual video and AGP memory is two variables i would like to take into account. I look at it like cache memory, it is transparent but if you take it into account you can get a big performance gain.
 
But say bitboys finally releases their magical chip with loads of onboard eDram memory, say 64MB, which acts more or less like a cache, but only need little ram, say for instance 16MB. If your application then looks up this information and assumes this card wont be be able to handle 32MB of textures efficiently, then it has made a bad assumption. Some professional cards supports virtual texturing, which means it can often texture from AGP without taking the serious performance hit normal consumer card get, so the assumption will fail here too. Bad assuptions made by developers are a major bug and problem generator. Instead the best thing to do is just leave it as a user option.
 
Wow, a thread with both Amiga and BitBoy comments. Who would have thought... I still have my Amiga 500, gave away my C64 though.

Its going to be more of a guideline than anything else. I rather allocate only 2MB of D3D resources that will use AGP memory instead of 20MB.

"Some professional cards supports virtual texturing, which means it can often texture from AGP without taking the serious performance hit normal consumer card get, so the assumption will fail here too."

Virtual Texturing if I remember right is a texture management scheme. I think it was the permedia line of chips that first implemented that feature. I really don't remember much about the feature beyond that but while it may decrease the performance hit, any memory access of the "GPU" to system memory should be avoided in my mind. Besides system memory being slower than the video card memory in terms of bandwidth, its also has a much higher latency do to contention between the CPU and PCI access.
Beyond that if my code is memory bandwidth intensive, profiling the code with peformance counters will not tell me that AGP texturing is sucking up bandwidth. So I would prefer to isolate the systems as much as possible. The isolation should for that same reason lead to more predictable performance. This predictability is the basis of the LOD engine, because FPS and/or the time to render a frame will be the feedback portion of the engine.
Besides with all the trouble people have with VIA chipsets... getting AGP4X, fast writes, AGP texturing to work properly, I'd rather not depend on it that much.
 
Another reason why you should avoid assumptions like these is that there's no garantuee that for instance a 1MB texture will take up 1MB texture memory once uploaded. It may be 1.5MB, it may be 0.5MB, since there may be other info stored with it and there may be some lossless texture compression on the chip.
 
You must log in or register to reply here.
Back
Top