Vulkan renderer is broken on multi GPU or multi monitor

[Albert Bundale]

On a system with two GPUs, the Vulkan presentation path disregards the device specified in options and always goes for the device the physical display is attached to, so despite having an RTX 2080 in my laptop GZDoom always uses the Intel GPU, resulting in a peak framerate of 38 FPS.

[vsonnier]

Works for me, (HD630 + GTX 1050Ti) provided I force "Nvidia high perfomance processor" (or whatever it is called in your favorite language) for the GZDoom executable in the 3D settings of the Nvidia Control Panel.
I do the same for all my game executables so they are garanteed to run on the GPU and not the Intel chipset.

[sherief]

Hi, I'm the original filer of that issue - I wasn't able to register before due to the anti-spam questions requiring very specific answers.

You shouldn't be using that force flag with Vulkan, and even if I do it's still not working correctly - the swapchain doesn't seem to be handling the display topology correctly. I bet it works for you on the internal laptop display, but have you tried running it on the internal laptop display while another external display is connected to either the iGPU or dGPU? If it works fine, can you show me your display topology using this tool: https://code.sherief.fyi/sherief/displa ... y/releases ?

I wouldn't mind stepping in and fixing this myself, do you happen to have some pointers as to where in the code should I be looking?

[dpJudas]

The swap chain is handled by the VulkanSwapChain class in vk_swapchain.cpp/h. The general vulkan device selection is done by the VulkanDevice::SelectPhysicalDevice function in vk_device.cpp/h.

[sherief]

Interesting development: I built from source and now FPS works fine, and PresentMon reports a latency of 35ms even when running on dGPU and displaying on iGPU @ 4K via a blit. Digging deeper it looks like something in my .ini file is driving it into this broken code path. I'll diff the fresh ini and my existing ini and see where the differences might be. Thanks for the help!

[sherief]

Okay, I think I have a solid repro. With VSync off the composition goes through the fast path and it's super smooth. Once I turn VSync on it goes to the slow path and never recovers, even if I set VSync to off again. The latency difference is an additional 90ms, which is very noticeable for me.

What code paths take care of VSync on / off under the Vulkan renderer?

[dpJudas]

If you search for vsync in vk_swapchain.cpp there's basically two changes when vsync is on vs off:

1. First difference is the number of swap chain images used. When vsync is on we only want two images. This creates a slight performance penalty in exchange for reduced input latency (less mouse lag). When vsync is off we want three images as it allows us to generate new images even during the vertical blanking period where one entry is being used by the presentation engine (*).

2. The other difference is that for vsync it uses VK_PRESENT_MODE_FIFO_RELAXED_KHR (fallback to VK_PRESENT_MODE_FIFO_KHR). When vsync is off it uses VK_PRESENT_MODE_MAILBOX_KHR (fallback to VK_PRESENT_MODE_IMMEDIATE_KHR or VK_PRESENT_MODE_FIFO_KHR).

Note that the slight performance penalty for using two swap images instead of three shouldn't ever become 90 ms unless there's something truly moronic going on inside the drivers.

*) When the presentation mode is mailbox the rendering is unsynchronized like for traditional vsync off, except the tearing isn't there. Essentially the engine keeps on producing images regardless of when vsync happens and then the presentation engine always uses the last delivered image whenever its time to vsync. Thus vsync off may have a slightly different behavior than OpenGL here, depending on what drivers support and what they chose to do for OpenGL.

[sherief]

Thank you, that's a great overview. Does this behavior change based on fullscreen and windowed modes? I'll keep digging and if it's, as you put it, "something truly moronic going on inside the drivers" I should be able to take care of it swiftly. If, on the other hand, this is a DWM bug then.. well...

[dpJudas]

It uses the same settings regardless of whether it is fullscreen or windowed (gzdoom doesn't use/support the vulkan exclusive fullscreen feature).

The presentation engine (which does the blit you were referring to) is part of vulkan and thus not controllable much beyond the present modes I mentioned. You could try make it always use three swap chain images to see if it helps. I don't have this kind of hardware so I can't really tell you anything about what to do here. I also haven't seen any documentation or recommendations for how exactly they imagine game engines should support this kind of setup.

[sherief]

Don't feel bad about not getting it right - even iD Software couldn't get it right in 2020: https://sherief.fyi/post/hell-and-other ... computers/

GZDoom actually gets it better than Doom Eternal - by allowing the user to select the Vulkan device they want at least you have enough control over the presentation path to get it right with some manual tweaking. I suspect the fix for this might be outside of GZDoom's domain, but it's too early to tell. I'll keep you posted, and once again thanks for all the help so far.