[vulkan] bug: picking wrong driver and fails with "vulkan unsupported"
UnkwUsr opened this issue · comments
The problem originates from:
bxt-rs/src/modules/capture/vulkan.rs
Line 781 in 3ef9d8b
Content of compared variables with different drivers installed:
amdvlk (maintained by AMD)
id_properties [65, 77, 68, 45, 76, 73, 78, 85, 88, 45, 68, 82, 86, 0, 0, 0]
uuids [65, 77, 68, 45, 77, 69, 83, 65, 45, 68, 82, 86, 0, 0, 0, 0]
radv (part of Mesa)
id_properties [65, 77, 68, 45, 77, 69, 83, 65, 45, 68, 82, 86, 0, 0, 0, 0]
uuids [65, 77, 68, 45, 77, 69, 83, 65, 45, 68, 82, 86, 0, 0, 0, 0]
OS: archlinux
amdvlk version: 2023.Q2.3
radv version: 23.1.3
I've tried to manually override this comparison with simple true
and it seems work normal on both drivers (i.e. even if check "meant to fail" (on amdvlk) - it still seems to work)
Huh, I didn't even know there could be multiple Vulkan drivers installed at once.
The EXT_external_objects extension says:
Applications must only import external semaphore handles exported
from the same device or set of devices used by the current context,
and from compatible driver versions. To determine which devices are
used by the current context, first call GetIntegerv with <pname> set
to NUM_DEVICE_UUIDS_EXT, then call GetUnsignedBytei_vEXT with <target>
set to DEVICE_UUID_EXT, <index> set to a value in the range [0,
<number of device UUIDs>), and <data> set to point to an array of
UUID_SIZE_EXT unsigned bytes. To determine the driver ID of the
current context, call GetUnsignedBytevEXT with <pname> set to
DRIVER_UUID_EXT and <data> set to point to an array of UUID_SIZE_EXT
unsigned bytes.
These device and driver ID values can be used to correlate devices
and determine driver compatibility across process and API boundaries.
Which kinda seems like what I'm currently doing, although "determine driver compatibility" sounds pretty muddy. Do you perhaps know of any well-known code bases which use EXT_external_objects and do the driver check differently?
Do you perhaps know of any well-known code bases which use EXT_external_objects and do the driver check differently?
No, I don't even have experience with graphics
So, do I understand correctly that you have amdvlk and radv on your system at once, and in this case bxt-rs fails to find a Vulkan device? Or you have only amdvlk or only radv, and when you have amdvlk, bxt-rs fails to find a Vulkan device, but when you have only radv, it succeeds?
Yes, second:
you have only amdvlk or only radv, and when you have amdvlk, bxt-rs fails to find a Vulkan device, but when you have only radv, it succeeds
For testing purposes I'm leaving only 1 driver installed at a time, even tried rebooting whole machine for cleanest test, and now even clearing vulkan shaders cache folder in steam (~/.steam/steam/steamapps/shadercache/70
) (yes, idk why there it is for hl1, but it is). And each time amdvlk fails on comparing uuids.
I see it looks very suspicious that when I run with only amdvlk driver installed, it tries to compare against those uuid from radv driver. Am I right or it is not uuid of drivers or something like that?
I see it looks very suspicious that when I run with only amdvlk driver installed, it tries to compare against those uuid from radv driver. Am I right or it is not uuid of drivers or something like that?
Yeah, I'm honestly not sure how this works. Remember that those driver UUIDs I'm getting from the OpenGL context used by Half-Life, which is presumably Mesa (and radv would be Mesa too). I don't know how amdvlk plays into the picture here. The idea is to select the same Vulkan GPU that runs Half-Life's OpenGL (to be able to share a texture between them).