Out of VRAM freeze

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is ON
[img] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Out of VRAM freeze

Re: Out of VRAM freeze

by dpJudas » Wed Oct 09, 2019 2:17 am

@De-Mo-oN: Video memory is a shared resource. Even if you explicitly check how much video memory is available you still run into the possibility that another application used a significant portion of it. The upper limit on the memory heaps in Vulkan is simply to prevent each individual application from using an excessive amount, and to provide hints how much memory is available in total. It is still expected that the vulkan display driver handles any required paging to system memory if the video memory ends up over committed. At least that was my impression when I read the spec (although if someone has seen a section in the spec that states otherwise please provide a link).

As for how other games do it - well obviously they limit how much video memory they allocate. But you need to understand this thing is really about two separate things: proper error handling for out of memory conditions, and better resource management in GZDoom. This thread is about the former, not the latter. So "use less memory, duh" is not really the core of the discussion.

Re: Out of VRAM freeze

by Graf Zahl » Wed Oct 09, 2019 12:13 am

Any allocator should return null if it cannot allocate the requested storage. This one does not, it just misbehaves. This needs to be fixed on NVidia's side.
The exit handling has nothing to do with it, that was done because some parts of code cannot be shut down from an exit handler, because the order of execution of them is problematic when DLLs are involved. And the DLLs for the sound backend had problems on some systems. Another reason was that the entire startup procedure could not be cleanly controlled because there was no good way to partially shut it down.

Re: Out of VRAM freeze

by Rachael » Tue Oct 08, 2019 10:20 pm

I doubt it, especially if it's the driver causing issues. As far as I know, driver issues are something that the kernel has to handle, rather than the application. The driver may be able to forward the error to the application, but then we have this chicken-and-egg problem where we are right back where we started here in the first place.

Re: Out of VRAM freeze

by Major Cooke » Tue Oct 08, 2019 7:31 pm

...
Moving on.
With Graf's overhaul of the exit handling, perhaps now it'll throw the error instead of freezing. I'll give it a try soon, see if this has improved any at the very least. I know it most likely still won't help but it's still worth a shot.

Re: Out of VRAM freeze

by Rachael » Tue Oct 08, 2019 6:20 pm

De-M-oN - just stop while you're ahead, please...

This is very pedantic and insulting.

Re: Out of VRAM freeze

by De-M-oN » Tue Oct 08, 2019 6:13 pm

But how do other modern games handle it? Do they have a handler like OpenGL has, that it copies the too much VRAM over to System RAM, while the vulkan library in GZDoom currently doesnt?
So even if the nvidia driver sends too much vram, couldnt the too much data just be copied further to system ram then?

Re: Out of VRAM freeze

by dpJudas » Tue Oct 08, 2019 6:03 pm

The issue is a little bit more complex than simply out of memory. The nvidia driver provides the application with some memory heaps and then cannot handle if they are fully used as adverticed.

_mental_ posted earlier test results showing that Intel works correctly where it produces an out of memory error. And Marisa showed that the Nvidia driver advertices larger heaps than there's video memory. The issue could very well be a Nvidia driver bug.

Re: Out of VRAM freeze

by De-M-oN » Tue Oct 08, 2019 5:48 pm

I wish I could ;)
_
Wasnt meant as offense. I was just a bit surprised that you didnt use overlay tools first which would've saved you so much time finding the issue :)

I cant write code though. Would be nice if you can somehow fix it :wub:

Re: Out of VRAM freeze

by dpJudas » Tue Oct 08, 2019 5:40 pm

Hey since you're so smart, can't you file a pull request with the fix? Surely it shouldn't be a problem.

Re: Out of VRAM freeze

by De-M-oN » Tue Oct 08, 2019 5:08 pm

You really needed long time to figure out that "out of vram" is the issue :P

I figured it out directly and without all these debugging tools.
Just have MSI Afterburner Overlay running and you can see how the game freezes as soon as it reaches the maximum VRAM you have.

It either freezes completely or the game collapses down to below 5 fps.

With OpenGL it works fine.

My card is a RTX 2080 Ti.

Re: Lockups occasionally occurring when rendering new things

by Major Cooke » Sat Aug 31, 2019 12:55 pm

Same results there too. Last frame frozen in place.

Re: Lockups occasionally occurring when rendering new things

by _mental_ » Sat Aug 31, 2019 12:52 pm

Yes, I didn’t describe what I meant by default settings. Options you changes are OK, but could you please check with IWAD only, with and without map loaded?

Re: Lockups occasionally occurring when rendering new things

by Major Cooke » Sat Aug 31, 2019 11:57 am

Tested with my regular config file and default. It always happens on my NVidia card with vulkan enabled.

But just so you know, If you test with default settings, vulkan is disabled by default. On top of that, laptops use the default choice between graphics card providers - my intel in this case.

So after generating a brand new config, setting Vulkan back to On and setting the graphics card to Nvidia, this is what it looks like -a shrunken screen with the 'ghost' image frozen in on it. But you can see at the top it says "Fatal Error", caused by me entering the error_fatal command.

Re: Lockups occasionally occurring when rendering new things

by _mental_ » Sat Aug 31, 2019 12:20 am

Is this with default settings? I cannot test on NVIDIA graphics hardware, but on AMD fatal errors work fine for me.

Re: Lockups occasionally occurring when rendering new things

by Major Cooke » Wed Aug 28, 2019 3:21 pm

It didn't help, it seems. But at the same time, I think I found a clue.

If you attempt to do error_fatal in console, instead of showing the box like it's supposed to, it keeps the window from the game and simply shrinks it down. You get nothing out of it otherwise. No dialogue box with the logs or anything.

Top