Need to know VRAM usage
BlitzMax Forums/BlitzMax Programming/Need to know VRAM usage
| ||
| Does anyone know of a 3rd party app that can report back Video RAM usage, something like how Fraps can display Frames-Per-Second? Perhaps there's an OpenGL command that would do this(?) Thanks in advance. |
| ||
| I once saw a B3D app that showed VRAM use, so perhaps it's possible directly in BMax without too much hassle...? |
| ||
| No. But it is quite easy to do. You can calculate it on each mainloop by simply adding all usages of images you draw and save that to a global variable. (usage is height*width*bitdepth of the graphics context) That must not be the real used amount of VRAM (as other stuff that has been used before might still be present), but it is what is really needed of the VRAM. (the rest could be overwritten by other images that need the VRAM). I should add that the reported size for images is not always the real size of a texture! If you texture was not power of 2, its true size will be the next larger power of two! |
| ||
| Usage isn't *bitdepth of the graphics context. Usage is the widthofscreen*heightofscreen*bitdepthofcontext + widthoftexture*heightoftexture*textureinternalformatbits. In GL there is a thing called a proxy texture which is like saying "see if there is enough video memory to allocate this texture, without really allocating it". It's supposed to report an error by setting internal state to 0 or something if there isn't enough memory. But I've heard it is not reliable on all implementations. (figures) Find some freeware program that writes the amount of free memory to a file or something. |
| ||
| Dreamora: I read about that technique in another post, but given the amount of graphics I am rendering and the differing sizes of all images involved, as well as images that are loaded and unloaded with various menus and dialogue boxes, an accurate sum would be almost impossible to add up. |
| ||
| Why? The stuff that is in VRAM for sure is what you render in the current loop. The rest can be there and can't but in the end it does not mather as it can be overwritten if you draw more textures. But AD pointed out a very important fact: The backbuffer and frontbuffer are part of the VRAM as well. AD: Why shouldn't a texture have 32bit if drawn in 32bit graphics context? (Thought current GPU will handle regular textures in 32bit anyway for performance reasons? as CPU are far better in performing on 32bit than 16 or 8) |
| ||
| Dreamora ... textures can have an internal format. It could be RGBA8 - 8 bits per component, RGBA4 - 4 bits per component, ALPHA - 8-bits per total pixel, etc... it depends on the format you give (talking OpenGL) as to how much memory it uses to store the texture. The texture format does not have to be the same as the backbuffer format. Max2D probably only uses RGBA8, but directly you can choose from a whole range of texture formats with different bit depths. e.g. RGBA5_A1 has 5:5:5 rgb format with 1-bit alpha channel = 16bit data storage, not 32bit. Saves half the memory. I don't know that the `far better at 32-bit` applies to graphics cards. They say in the GL manual that a lower-color-resolution texture should render faster. |
| ||
| I once saw a B3D app that showed VRAM use, so perhaps it's possible directly in BMax without too much hassle...? But B3D/BlitzPlus had a native commands to return this info: TotalVidMem() and AvailVidMem() DirectX has an API function that will return that info for you. From what I've heard, OpenGL doesn't, it's a bit more trial-and-error. Of course, it would be nice to get these two commands in DirectX mode, if nothing else? |
| ||
| Banksizes, pitch and internal texture swizzling might use additonal memory, so it's really impossible to get a true available VRAM report. GL's proxy texture is probably the way to go. DirectX used to have a video memory size somewhere, but that was always inacurrate and sometimes even zero :) |
| ||
| Yepp. The B3D functionality for example is totally broken (or its DX7 that is starting to work worse and worse with real drivers of 2006). I've a 64MB VRAM notebook radeon 9700 ... B3D returns around 300MB of free VRAM on Toms R2T example ... And its not like this system definitely has no 256MB AGP apperture ... :-) (it ships with 512MB RAM by dfault) |
| ||
| I read there are issues with GL ... sometimes it works and sometimes it doesn.t |
| ||
| If you just need to use VRAM USAGE, just count how much you use. Getting vram availability is another matter. |
| ||
| Dreamora: But pretty much all laptops use shared video memory, meaning it comes out of your main RAM... and since windows will consider both physical memory and your swap file (if necesary), it's not impossible for a video card to have more than your physical RAM 'available' to it.... It's going to be unusably dead slow to actually try to use it, but you probably wouldn't get any out-of-memory errors... |
| ||
| My notebook has 64MB dedicated, not shared (I would never waste money for a shared one from intel or a ATI / NV that only has TC / hypermemory ... at least 64 to 128 MB must be dedicated). Only the cheap systems have shared RAM ... especially the newer generations that have PCIe (I'm on a banias based P-M from first generation, still AGPx4 :-) ) This means I at best have some aperture RAM beside that ... but I've never heard that any AGPx4 card has 256MB especially on a 512MB notebook ;-) That strange behavior started somewhen around 1.90 or the like ... before that it worked correctly ... no idea if it was B3D or the updated drivers around that date |
   |