Crash when using Vulkan

[Uli_S]

vk_listdevices output nothing if started in OpenGL mode.
However if I launch gzdoom with +vk_device 1 and select "Vulkan" backend it starts up.

And the command gives me this output:
]vk_listdevices
#0 - Microsoft Direct3D12 (NVIDIA GeForce GT 1030)
#1 - NVIDIA GeForce GT 1030
#2 - Microsoft Direct3D12 (Microsoft Basic Renderer Driver)

[Rachael]

Interesting. So other people should be able to do +vk_device 1 and hopefully get past this problem. It might be a bit more complicated for people with dual-GPU laptops though, but it's a start.

[dpJudas]

Great, so some application seems to be installing Mesa system-wide. Once that happens the device selection logic picks it over the native driver as the default. That's why reinstalling the display driver didn't help.

The question is how to reliably make this device go last. I would hate to have a system that has been *BEEEP*ed in this way though. While GZDoom crashed on it (which it shouldn't have, of course), this driver is basically redirecting all kinds of vulkan apps on the system to not use the driver the GPU vendor intended. GG! Thanks Microsoft/Mesa! Really appreciate it!

[dpJudas]

OK, just for completeness (in case any other vulkan devs read this): seems the correct way to detect this kind of driver is to look for the VK_MSFT_layered_driver extension and check if underlyingAPI is set to 1. If it is, sort it to the bottom of discrete/integrated GPU categories.

[Uli_S]

Is Mesa something WSL related?
Some days ago I ran graphical Linux apps in WSL the first time
Had this changed my system and caused this Error?

[dpJudas]

It's possible. We haven't figured out exactly what causes this change, except it isn't just Windows 11 on its own as then it would be happening on my and Rachael's systems too.

[dpJudas]

I created a pull request that should take layered drivers into account and sort them last. Note that when this PR is applied vk_device 0 will once again become the GPU vendor driver, so you may have to do a +vk_device 0 on the next release if you applied the workaround.

The Microsoft Direct3D 12 driver still crashes GZDoom though. Could be a bug in GZD, could be a bug in the driver. Hard to say for sure. If someone has the driver installed and is willing to install the Vulkan SDK, running GZD with vk_debug 1 enabled could be useful (note: remember to turn off vk_debug after you're done since its quite bad for performance to have enabled). I'm not willing to try install this driver on my system (however you actually do that) since I like my computer clean.

[Uli_S]

I tried to build this, but I am struggling, since I have no experience with C++ development.
If someone could provide me a ready to run build, I will test this.

[Rachael]

You have no need to build it, just wait 24 hours. (And 24 hours have already passed in this case, just grab the top one)
https://devbuilds.drdteam.org/gzdoom/

[Uli_S]

Unfortunately doesn't work for me.

OS: Windows 11 (or higher) (NT 10.0) Build 22631
GZDoom version g4.12pre-378-gf369cd7f6
I_InitInput
I_StartupMouse
I_StartupKeyboard
I_StartupXInput
I_StartupRawPS2
I_StartupDirectInputJoystick
Vulkan device: IMicrosoft Direct3D12 (NVIDIA GeForce GT 1030)
Vulkan device type: discrete gpu
Vulkan version: 1.2.276 (api) 24.0.99 (driver)
Max. texture size: 16384
Max. uniform buffer range: 65536
Min. uniform buffer offset alignment: 256
Resolution: 1920 x 1080
W_Init: Init WADfiles.
adding C:/Users/uli/Downloads/gzdoom-x64-g4.12pre-378-gf369cd7f6/gzdoom.pk3, 678 lumps
adding C:/Users/uli/Downloads/gzdoom-x64-g4.12pre-378-gf369cd7f6/game_support.pk3, 3307 lumps
adding C:/Program Files (x86)/Steam/steamapps/common/ultimate doom/base/DOOM.WAD, 2306 lumps
adding C:/Users/uli/Downloads/gzdoom-x64-g4.12pre-378-gf369cd7f6/lights.pk3, 7 lumps
adding C:/Users/uli/Downloads/gzdoom-x64-g4.12pre-378-gf369cd7f6/brightmaps.pk3, 499 lumps
adding C:/Users/uli/Downloads/gzdoom-x64-g4.12pre-378-gf369cd7f6/game_widescreen_gfx.pk3, 214 lumps
S_Init: Setting up sound.
I_InitSound: Initializing OpenAL
Opened device IOpenAL Soft on OUT 1-2 (BEHRINGER UMC 202HD 192k)
EFX enabled
I_Init: Setting up machine state.
CPU speed: 2904 MHz
CPU Vendor ID: GenuineIntel
Name: Intel(R) Core(TM) i7-10700F CPU @ 2.90GHz
Family 6, Model 165, Stepping 5
Features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AVX AVX2 F16C FMA3 BMI1 BMI2 HyperThreading
V_Init: allocate screen.

Execution could not continue.
Could not create graphics pipeline: out of host memory

[dpJudas]

Did you change vk_device back to zero? (launch with +vk_device 0) The changes I did weren't trying to fix this device, but rather make sure it doesn't default to using the Microsoft Direct3D12 driver.

About the error itself, quite interesting that it says out of host (system) memory while creating a graphics pipeline. That implies a driver error since pipelines really shouldn't be consuming memory of any amount worth mentioning. It could be related to the OpenGL issue that Blzut3 brought up about the OpenGL backend: a large uniform buffer causes Mesa to shit its pants. Creating a pipeline is not the same as committing to using it or creating such an uniform buffer, but GZDoom shouldn't be trying to create such a large buffer in the first place. That's just speculation on my part though. Could be entirely unrelated.

Edit: can't be related to the OpenGL Mesa issue, since this driver advertised a max uniform buffer size of 64 KB. Unless the validation layer (+vk_debug 1 with the Vulkan SDK installed) reports something else then I'd say is most certainly a driver bug with that error message.

[Uli_S]

dpJudas hat geschrieben:
> Did you change vk_device back to zero? (launch with +vk_device 0) The
> changes I did weren't trying to fix this device, but rather make sure it
> doesn't default to using the Microsoft Direct3D12 driver.

No but I deleted my gzdoom.ini file and now it works.

[dpJudas]

Excellent, so the workaround does work. Thanks for testing it.