[vulkan] bug: picking wrong driver and fails with "vulkan unsupported"

[UnkwUsr]

The problem originates from:

bxt-rs/src/modules/capture/vulkan.rs

Line 781 in 3ef9d8b

if id_properties.driver_uuid == uuids.driver_uuid

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)

[YaLTeR]

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?

[UnkwUsr]

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

[YaLTeR]

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?

[UnkwUsr]

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?

[YaLTeR]

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).