Reporting this by proxy for somebody else:
Recent versions of GZDoom (stated to be within the last few days' worth of dev builds from DRD Team) were exhibiting bizarre framerate loss on Nvidia Quadro cards, eventually discovered to be happening any time the sky was in view. With some experimentation in the console, we discovered that gl_no_skyclear needs to be set to True in order for framerate to hold steady.
While the problem is solved for this person, I feel it worth exploring potential causes or fixes - or else a suggestion that, if GZDoom detects a Quadro, this cvar should default to True.
[4.5pre devbuilds] Nvidia Quadro and gl_no_skyclear
Moderator: GZDoom Developers
Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.
If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.
Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.
If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.
Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!
-
- Moderator Team Lead
- Posts: 21590
- Joined: Tue Jul 15, 2003 7:33 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Win10 22H2, Win11 22H2, macOS 11.7
- Graphics Processor: nVidia with Vulkan support
-
- Lead GZDoom+Raze Developer
- Posts: 48537
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [4.5pre devbuilds] Nvidia Quadro and gl_no_skyclear
This sounds like a driver bug. gl_no_skyclear forces rendering the sky as a portal - normally, if there's only a single global sky it gets rendered into the empty framebuffer before the scene.
Forcing this cvar to true is not a solution, it'd only hide the real issue.
Forcing this cvar to true is not a solution, it'd only hide the real issue.