Weird performance issues

[Ihavequestions]

I have noticed some big performance drops on Vulkan on a few occasions. I would get very random performance numbers that sometimes seemed to change with every restart of GZDoom, at other times they would not change.

When they did not change any further, the game would get stuck at either around 18 fps, or 36 fps, or 48 fps, or 78 fps in a spot that would give me around 80-85 fps on OpenGL. I noticed large differences in reported CPU and GPU usage, per MSI Afterburner. On Vulkan, at 18 fps, CPU usage would be around 8-10% and GPU usage around 10-12%; on OpenGL those would be 2-3% and 40%, respectively. (A full single-core load would be equal to 12-13%, since I'm running an 8-core CPU with SMT deactivated.)

After reinstalling the NVidida driver a few times, thoroughly using DDU, trying a different driver version each time, I was able to further it down to a setting called "Vulkan/OpenGL present method" that can be found in the "Manage 3D settings" task of the NVidia Control Panel.

Apparently, changing this value can cause the described behavior, although I am not sure if that is even a requirement or would have happened anyway. When I restarted the game on Vulkan a few times, I got the FPS up from around 18 to 78. Not having changed said setting again, I am now only getting around 36 fps for no obvious reason.

I tested for this error with g4.7.1 and g4.10.0, and NVidia's 5.16, 5.26 and 5.27 drivers on Windows 11 22H2, all with very similar results. The map spot in question is visible in the screenshots. It's not necessarily something that can be noticed on a simple vanilla map like Entryway.

[dpJudas]

Are you seeing the same behavior with older versions of GZDoom, or does this only apply to the last one?

[Ihavequestions]

4.7.1 also had it. That was the older version I tested it with. The bug was consistent across both versions as well as five versions of the NVidia driver.

However, after a larger Windows update a few hours ago, it seems to be gone. I am currently not able to reproduce it.

[CandiceJoy]

Are you measuring average fps or instantaneous fps? I know on my setup I get lag spikes every now and then, I'm assuming due to the GC, but I'd have to profile it to be certain

[dpJudas]

4.7.1 also had it. That was the older version I tested it with. The bug was consistent across both versions as well as five versions of the NVidia driver.

Thanks. I wanted to rule out it could be related to the swap chain update coming from moving to ZVulkan.

Sounds like it might been something system specific with that Windows update fixing it.

[Ihavequestions]

Are you measuring average fps or instantaneous fps?

Instanteneous. I'm now getting highly consistent results:
4.7.1 on Vulkan: 72 fps, on OpenGL: 84 fps
4.10.0 on Vulkan: 78 fps, on OpenGL: 81 fps.

I know on my setup I get lag spikes every now and then, I'm assuming due to the GC, but I'd have to profile it to be certain

My pro tip against spikes is to set the CPU to run at its maximum clock rate (for lowest frametimes and highest 0.1% lows) and combine that with a reasonable fps limit, to keep the CPU and/or GPU from throttling.

How that can be achieved depends on your system. On Wintel, ThrottleStop is the way to go since Intel CPUs have a function called SpeedShift that can be used to indirectly specifiy the clock range and the speed of clock adjustments, and ThrottleStop allows you to do that with ease.

Sounds like it might been something system specific with that Windows update fixing it.

That's what I also thought. Might have just been something that was introduced with an update a few days or weeks ago which remained unnoticed by me due to holiday business.

[Graf Zahl]

Are you measuring average fps or instantaneous fps? I know on my setup I get lag spikes every now and then, I'm assuming due to the GC, but I'd have to profile it to be certain

The GC shouldn't cause lag spikes - it was written not to overburden the CPU and only do small slices of work each frame.

[Ihavequestions]

So I was going to write a lenghty, detailed post about my latest findings but then decided to make it short.

The issues described here seem to be related to a weird hardware or driver or Windows bug or a combination thereof, and it relates to multi-monitoring on my laptop.

I can reliably reproduce it with several other games, and I have found a way to reliably mitigate it. I sometimes get this and other bugs, like certain games running several times slower than they should or G-Sync/FreeSync not working, after a display configuration change that go away after a reboot or a reconfiguration, and the key to mitigation is to keep a certain display config.

In my case, I had to make sure that my single desktop monitor has two active connections to my laptop (via DP & HDMI)... Yeah, don't ask. Blame NVidia or whomever. There's many more details to that.

So, everyone: Contact me if you should experience similar weird errors, especially when on a gaming laptop. I might have the solution for you.

[dpJudas]

There certainly seem to be some kind of issue with the Nvidia drivers the last year or something (not exactly when it started). The vulkan swap chain doesn't respect vsync properly, mailbox doesn't work properly, g-sync doesn't work properly. I've spent quite a lot of hours trying to debug it and from what I can tell there's nothing wrong on the GZDoom side of things here. Since I'm not a big studio I can't call Nvidia and ask them what is up with this, so all you really can do is pray it begins to bug for a studio with enough pull to do something about it.

[Ihavequestions]

Those drivers sure get worse by the day, haha.

BTW, I have found a critical bug in the Microsoft Basic Display Adapter driver while playing GZDoom.

When you use it along with NVidia drivers for different screens on an Optimus laptop and move a game window that's supposed to run on the NVidia dGPU to the screen that's running on the Intel iGPU via the MSBDA driver, and then activate and deactivate V-sync (in-game), you will get a hard freeze and BSOD.

I first discovered this error on the latest Windows Server preview from the Insider channel, but I was able to replicate it on my normal Win 11 installation (had to uninstall the Intel drivers), so this seems to be a bug in the MSBDA driver rather than something Windows Server-related.

But why would you risk a BSOD? Because enabling V-sync seems to fix the performance issues described in the OP (in certain configurations). You can then disable it again, but you need to be extra careful not to crash the whole thing. The game needs to be running on the screen powered by the dGPU.