Some of you noticed this extension in our recent drivers. Here is the spec.
http://developer.download.nvidia.com/opengl/specs/GL_NVX_gpu_memory_info.txt
As you can see this is a NVX extension (NV eXperimental). Meaning we might change it in the future. Any feedback much appreciated!
Barthold
(with my NVIDIA hat on)
Thank you!
Interesting… I always wonder why we didn’t had such extension.
Great!
Have you consider to make it a query object so that it doesn’t stall the rendering pipeline? For frame by frame stats along the time.
I’m not sure if this could make it even more useful… emmm maybe.
FWIW, there has been such an extension for a while: ATI_meminfo.
It’s fairly similar and shouldn’t be hard to abstract the two. If we can get enough feedback about both vendor extensions, perhaps that could contribute to a vendor-agnostic version.
Unfortunately I have to report a problem with NVX_gpu_memory_info extension. 
Calls before the first memory allocation works correctly (with both GL 2.1 and 3.3), but after that the readings are unpredictable. This is a dump form my application:
// Before first allocation (just after context creation)
Dedicated mem: 524288[kb]
Total available mem: 524288[kb]
Current available mem: 470100[kb]
Eviction count: 328
Evicted mem: 589520[kb]
---------------------------
// After application has loaded all data, up and running
Dedicated mem: 0[kb]
Total available mem: 1691160124[kb]
Current available mem: 0[kb]
Eviction count: 1691686003
Evicted mem: 28271216[kb]
---------------------------
This is another example with less data loaded
// Before first allocation (just after context creation)
Dedicated mem: 524288[kb]
Total available mem: 524288[kb]
Current available mem: 470100[kb]
Eviction count: 328
Evicted mem: 589520[kb]
---------------------------
// After application has loaded all data, up and running
Dedicated mem: 3539058[kb]
Total available mem: 3277212[kb]
Current available mem: 0[kb]
Eviction count: 3276800
Evicted mem: 1999443921[kb]
Obviously meaningless, or I don’t know how to use this extension. The drivers are 197.15, and the test was carried out on Vista 32bit.
The function I have used is very simple:
CString GLRenderer::GetMemInfo()
{
int dedVideoMem,totalAvailableMem, curAvailableMem, evictionCount, evictedMem;
glGetIntegerv(0x9047, &dedVideoMem);
glGetIntegerv(0x9048, &totalAvailableMem);
glGetIntegerv(0x9049, &curAvailableMem);
glGetIntegerv(0x904A, &evictionCount);
glGetIntegerv(0x904B, &evictedMem);
CString strMem;
strMem.Format(_T("Dedicated mem: %d[kb]
Total available mem: %d[kb]
Current available mem: %d[kb]
Eviction count: %d
Evicted mem: %d[kb]"),
dedVideoMem,totalAvailableMem, curAvailableMem, evictionCount, evictedMem);
CADebugger::SaveString(strMem,_T("MemDump.txt"));
return strMem;
}
I’m sorry!
The previous post was a false alarm.
NVX_gpu_memory_info works perfectly. The problem appeared because GL context was not active when the function was called. The invoking method should look like this:
CString GLRenderer::GetMemInfo(CWnd* pWnd)
{
CDC* pDC = pWnd->GetDC();
ActivateGL(pDC);
int dedVideoMem=0,totalAvailableMem=0, curAvailableMem=0, evictionCount=0, evictedMem=0;
glGetIntegerv(0x9047, &dedVideoMem);
glGetIntegerv(0x9048, &totalAvailableMem);
glGetIntegerv(0x9049, &curAvailableMem);
glGetIntegerv(0x904A, &evictionCount);
glGetIntegerv(0x904B, &evictedMem);
CString strMem;
strMem.Format(_T("Dedicated mem: %d[kb]
Total available mem: %d[kb]
Current available mem: %d[kb]
Eviction count: %d
Evicted mem: %d[kb]"),
dedVideoMem,totalAvailableMem, curAvailableMem, evictionCount, evictedMem);
CADebugger::SaveString(strMem,_T("MemDump.txt"));
DeactivateGL();
pWnd->ReleaseDC(pDC);
return strMem;
}
Excellent extension!! We’ve been second-guessing this info for many years now, and it’s great to get the real numbers that account for not only textures, but FBOs/renderbuffers, VBOs, TBOs, display lists, etc. Thanks, NVidia!
I am very interested in hearing more details on how you use this extension, what is good about it and what you are missing.
Thanks!
Barthold
(with my NVIDIA hat on)
I’ll give you some needs it meets for us and some question/issues encountered so far.
The biggest needs it satisfies (so far) are telling us:
[ol][li] how much memory is installed on the GPU,[] how much memory your system framebuffer (and off-screen framebuffers/renderbuffers are eating), [] whether the database folks have overcommitted graphics memory, and by how much (not sure this is 100% working right, or maybe I’m misinterpreting what the extension is providing)[/ol]#1 is of course very useful to list with GPU memory usage statistics so you can see how your various GPU memory consumers rank as a percentage of the total. No more need to manually sift Xorg.0.log when faced with a box someone else picked the hardware for. While this can be queried via the NV-CONTROL X extension and OpenCL, it’s good to have a pure OpenGL way to get this.[/li]
#2 is the big one. Before this has been complete guesswork based on reading the spec and guessing how much the actual framebuffer implementation follows theory (does it have 4 aux buffers regardless, does it have an accumulation buffer regardless, how much space does CSAA consume anyway and is it really close to MSAA as stated, does MSAA/SSAA usage follow theory or if not what does it consume, how much space (if any) does the GPU tie up in padding for “non-nice” framebuffer resolutions, etc. It’s very helpful to be able to put a much tighter bound on this when planning GPU memory allocation for a database pre-development so we can reserve the correct amount of space “off the top” and tell the DB modelers they just can’t have it for textures and other resources. We could guess texture usage pretty well based on internal format (barring padding/alignment), but framebuffers was much less definite. It has been nice to see that memory isn’t being wasted out there for aux and accumulation normally.
And as for #3, this one is the one I think we’re given stats for but I’m not 100% sure the values I"m getting back from NVX_gpu_memory_info always make sense (or that I’m reading them right). What’s provided is the amount of GPU memory left available and the amount evicted (presumably for objects/textures bumped to make space for other objects/textures the GPU needs on the GPU but which aren’t on there yet). Sometimes this evicted number makes sense with the theoretical amount of texture we have on the card (yes, we prerender with the textures to force them onto the card), but sometimes it doesn’t – sometimes short by hundreds of MB. So I’m not sure if the error is in our interpreting the results of the extension, or its in the extension values returned. Don’t even have a test program for that, but when I do I’ll send it in.
Anyway, our “guesses” are a lot less guesswork now, thanks to this extension, which allows us to make better usage of the memory on our NVidia GPUs. Thanks again for adding this!
I’m trying to find out why the driver sporadically fails at various places stating it ran out of memory.
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=288755#Post288755
While this might not be the intended use of this extension I hope these numbers somehow help in finding what kind of memory is getting short and what part of our program causes this. So may be debugging driver bugs can be a use case, too.
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.