vkCreateDevice failed (VkResult: -8) with gamescope >= 3.13.0

[michaelneverwins]

If I build gamescope from tag 3.12.5 on Linux Mint 22, it seems to work. Meanwhile, 3.12.6 and 3.12.7 actually fail to build with

../src/reshade_effect_manager.cpp:17:10: fatal error: stb_image_resize.h: No such file or directory

but that may not be worth investigating as it doesn't occur with 3.13.0, which builds successfully and then fails to run:

No CAP_SYS_NICE, falling back to regular-priority compute and threads.
Performance will be affected.
wlserver: [backend/headless/backend.c:68] Creating headless backend
WARNING: radv is not a conformant Vulkan implementation, testing use only.
vulkan: selecting physical device 'AMD Radeon HD 7900 Series (RADV TAHITI)': queue family 1 (general queue family 0)
vulkan: physical device does not support DRM format modifiers
vulkan: vkCreateDevice failed (VkResult: -8)
Failed to initialize Vulkan

This is also the case with all newer versions I've tried, including 3.14.24:

[gamescope] [Info]  console: gamescope version 3.14.24
No CAP_SYS_NICE, falling back to regular-priority compute and threads.
Performance will be affected.
WARNING: radv is not a conformant Vulkan implementation, testing use only.
[gamescope] [Info]  vulkan: selecting physical device 'AMD Radeon HD 7900 Series (RADV TAHITI)': queue family 1 (general queue family 0)
[gamescope] [Info]  vulkan: physical device does not support DRM format modifiers
[gamescope] [Error] vulkan: vkCreateDevice failed (VkResult: -8)
terminate called without an active exception
Aborted (core dumped)

You can see there that my GPU is old, and this is probably the most relevant information about my system. It's my understanding that Vulkan support for this card is incomplete. It may be the case that it simply isn't supported by gamescope anymore (although it apparently was), in which case I'm not sure whether it would be considered a bug/regression or just a sad consequence of still using old hardware.

Note that "physical device does not support DRM format modifiers" is logged with version 3.12.5 as well, and it works anyway:

No CAP_SYS_NICE, falling back to regular-priority compute and threads.
Performance will be affected.
wlserver: [backend/headless/backend.c:68] Creating headless backend
WARNING: radv is not a conformant Vulkan implementation, testing use only.
vulkan: selecting physical device 'AMD Radeon HD 7900 Series (RADV TAHITI)': queue family 1
vulkan: physical device does not support DRM format modifiers
vulkan: supported DRM formats for sampling usage:
vulkan:   AR24 (0x34325241)
vulkan:   XR24 (0x34325258)
vulkan:   AB24 (0x34324241)
vulkan:   XB24 (0x34324258)
vulkan:   NV12 (0x3231564E)
vulkan:   AB4H (0x48344241)
vulkan:   XB4H (0x48344258)
vulkan:   AB48 (0x38344241)
vulkan:   XB48 (0x38344258)
vulkan:   AB30 (0x30334241)
vulkan:   XB30 (0x30334258)
vulkan:   AR30 (0x30335241)
vulkan:   XR30 (0x30335258)
wlserver: Running compositor on wayland display 'gamescope-0'
wlserver: [backend/headless/backend.c:16] Starting headless backend
wlserver: [xwayland/server.c:108] Starting Xwayland on :1
...

Therefore I assume the relevant part of newer versions' output is this:

vulkan: vkCreateDevice failed (VkResult: -8)

I had seen the same thing with the Flatpak version of gamescope on Linux Mint 21.3. I don't have any Flatpak packages installed right now, but at the time, I had noticed that gamescope had stopped working in Bottles, and had fixed it by undoing updates to the gamescope package:

sudo flatpak update --system --commit 9e2ba1b79351dde28e2984b75b11701cbfba1444ba1b0260b61f45ad159c8c74 org.freedesktop.Platform.VulkanLayer.gamescope//23.08
flatpak mask --system org.freedesktop.Platform.VulkanLayer.gamescope//23.08

If I remember correctly, this had effectively put gamescope at a pre-3.13.0 version whereas the update that broke it was post-3.13.0, so it seems the problem I'm having with gamescope 3.13.0 and later as compiled on my own system is the same as what I saw with the Flatpak build.

If I'm stuck with 3.12.5 until I get around to that long-overdue hardware upgrade, then so be it. However, any insight would be appreciated.