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.