I’d like to know more about what causes the Nvidia OpenGL driver to give up an OutOfMemory error. In my situation, my app seems stable, and there’s ample GPU and system memory (RAM) and usage is closer to none than full. What seems to trigger it, is Microsoft has a game-like program that runs inside its WMR Virtual Reality Portal application. We can’t turn this off, and it obviously doesn’t make sense to have a game like app running on our computers at all times. But something about it seems to interact badly with OpenGL contexts that use the WGL_NV_DX_interop2 to create OpenXR sessions, which cause this app to do a flashy transition and yield to the VR app’s “experience”.
It’s during this transition (away and to what Windows calls the “Cliff House”) that this OutOfMemory condition is likely to occur. I can’t find anything in my app that looks like a memory leak, but then again it’s using D3D11 minimally, and I’m new to D3D11 and try to avoid it (hence I’m mainly using OpenGL outside of blitting to the swap-chain with an effects pass.)
I’m using this same methodology without OpenXR for regular monitor based game-play. In that case everything is remarkably stable. I can rebuild and resize the resources all day long and there’s no memory limit hit. But as soon as I do the WMR portal transition a number of times (maybe 1 for large supersampling loads, or 5 to 10 for smaller loads) I run out of memory, suggesting there’s a memory leak. Once in an OpenXR session, I can rebuild/resize resources and the VR set’s display resolution all day long again, without memory limit trouble. But as soon as I switch out of the WMR portal and back it’s likely to not survive, and report the OpenGL context’s memory is all gone.
When I look at Window’s Task Manager it says GPU memory and RAM (again) all stays very low and stable. It doesn’t climb. So why is the Nvidia OpenGL context reporting it’s out of memory? Is there something internal leaking? All of the large surfaces that are changing in my app are on the D3D11 side and reside in VRAM (they’re “FBOs” in OpenGL speak. But are allocated on the D3D11 side. The extension generates an OpenGL “name”, a/k/a a handle.)
I don’t know how the portal app overlaps if at all with my OpenGL context’s memory model. Thank you, I’m just looking for ideas, and letting your group know maybe Windows’s VR home system is interacting badly with your OpenGL extensions designed to share buffers with D3D11.
Hello @mick-p1982 and welcome to the NVIDIA developer forums!
Thank you for the detailed problem description. This looks really inconvenient and detrimental to proper application development, let alone giving this as a product to users.
We haven’t heard of this bad interaction between OGL applications and the WMR app and D3D11 before, so it would be difficult to give you pointers or suggestions on how to address this.
Would you be able to provide a minimal reproduction case, a small app ideally in source, which shows this issue? That would definitely make it easier for engineers to get some insight on the problem, even if I can’t promise when or if someone might be looking at this.
Thanks!
1 Like
Thank you, I should have provided this link I think. I can’t make a “minimal app” for time, but perhaps you can use any profile tools you have on this (KING'S FIELD 25th PROJECT by swordofmoonlight) app since it’s the one that gives problems.
I posted looking for any insight into Nvidia OpenGL internals. My system is RTX 3060 and HP Reverb G2 for the VR set I’m using. And 32GB RAM. Thanks for taking interest. I will add that I think this problem can also apply when entering an OpenXR session depending on how much memory the app is using, since I have more ambitious projects that use this engine that have a hard time just entering the session before memory is exhausted. All this says is it’s not likely limited to leaving the session and reentering. Again, the system RAM and GPU memory aren’t anywhere near exhausted according to the Task Manager readout, but I don’t know if Windows limits OpenGL contexts to a portion of memory or not, still the screen buffers aren’t a whole lot of memory, assuming they exist in the same pools as everything else. (They are hundreds of MBs, but that’s not a lot… I think they may require as much as 1GB for full supersampling depending on what the OpenXR runtime is doing with it–lower estimate is 300MB–but I think the problem is more likely related to interactions with the Cliff House’s resources. Even though I don’t know anything about how game like apps interact. Really Microsoft shouldn’t have elected to force on a full game like program in the background on systems that are already pushing the limits of what today’s systems can do.)
Edited: FWIW the relevant parts of this app are open-source, so I can provide links, but it’s not a “minimal example” but still the D3D11 and OpenXR code is very simple and just like 2 small C++ code files. I can also provide a debug build if so desired. Perhaps in private?
(Looking forward to a follow-up :D)
Let me try with a follow-up.
So far we did not have the time to try a repro using the app you linked to. Also when talking to OGL guys they are not aware of any kind of leaks that would cause this behaviour.
I myself have a Reverb G2, so I might try it out if I find some time for it. But your installation instructions alone are already daunting.
Speaking of OpenGL, there are no “NVIDIA OpenGL internals”. OpenGL is a standard which we implement and which has to pass OpenGL conformance testing. Which means there are NVIDIA driver internals we cannot share, and then there is the open source OpenGL specification which we follow. Of course the underlying implementation differs from vendor to vendor, but those are sadly closed source, so I am not at liberty to give insights to those.
In the meantime, are you familiar with our Developer tools? Nsight Graphics in particular is very useful in analysing app behaviour in terms of GPU/CPU usage and covers OpenGL calls as well. I recommend you have a look at those since I cannot promise how fast someone can look into this from our side.
I am sorry if this is not the follow-up you are looking for, but that is as much as I can do right now.
Thanks!
No problem (no hurry) good to here someone has something on a to-do list!
RE “But your installation instructions alone are already daunting.” Really, just Extract the ZIP should work fine. On a dev machine that has Windows Defender type things disabled it should go off without a hitch. Otherwise there could be antivirus interaction. (Any other instructions are just for optimal operation.)
I will look into Developer Tools. I really hope someone takes a look. You never know, it could expose your driver’s Achilles heel! (I can’t think of an explanation myself.)