vkcube doesn't validate presentation support for physical devices

[CendioOssman]

vkcube's device selection is unfortunately a bit optimistic and it blindly assumes that all devices it can enumerate are usable from its context. This is not always the case, and hence it can end up failing to start properly.

This issue showed up when running vkcube in a VNC session (TigerVNC/tigervnc#1674). In that case, the hardware device cannot be use because DRI3 isn't available. But vkcube fails to fall back to the CPU device.

I am a complete newbie when it comes to Vulkan, so I have no idea how applications are supposed to pick devices.

The noticable difference between the VNC environment and a "regular" one (according to vulkaninfo), is that you only get presentable surfaces for working devices. So perhaps that is a good method?

What is the de facto method for picking devices? Is there something TigerVNC can do to help applications make the right choice?

[charles-lunarg]

(Apologies for a later response than I'd like, an SDK release took all available cycles)

The thing about vkcube is that it is a 1.0 application with almost no usage of exotic or poorly supported features.
This means it doesn't need to do a lot of feature checking.

Typically, applications validates each VkPhysicalDevice for suitability before picking the device (where they use both hard requirements and heuristics) but its not uncommon to just pick the first VkPhysicalDevice.

Looking at the linked thread, I see discussion of vkcube vs vulkaninfo. Vulkaninfo doesn't pick a device, it creates a VkDevice on all available VkPhysicalDevices. It also doesn't try to create a swapchain which means it doesn't have the same requirements as vkcube.

What is the specific thing that is causing vkcube to fail? And is it something that can be checked before use?

[CendioOssman]

Looking at the linked thread, I see discussion of vkcube vs vulkaninfo. Vulkaninfo doesn't pick a device, it creates a VkDevice on all available VkPhysicalDevices. It also doesn't try to create a swapchain which means it doesn't have the same requirements as vkcube.

vulkaninfo failed because it assumed the first X11 visual it got was suitable for a top level window, which I don't think is a safe assumption. It's an issue we've seen with other applications as well, though, so we added a workaround to TigerVNC for that. vulkaninfo now works fine.

What is the specific thing that is causing vkcube to fail? And is it something that can be checked before use?

It picks the first vulkan device, which isn't compatible with the current X11 display, and fails:

$ vkcube
Selected GPU 0: Intel(R) UHD Graphics 630 (CFL GT2), type: IntegratedGpu
vulkan: No DRI3 support detected - required for presentation
Note: you can probably enable DRI3 in your Xorg config
Could not find both graphics and present queues

I'm afraid that since I don't know the vulkan API, I don't know how to check for presentation support. But vulkaninfo shows "Presentable surfaces", so there seems to be some way.

[CendioOssman]

To add, it seems vkcube is the glxgears of the vulkan world. So it would be nice if it worked out-of-box in TigerVNC as an easy smoke test.

[charles-lunarg]

I agree, making vkcube work would be nice.

So Could not find both graphics and present queues is vkcube saying that the call to vkGetPhysicalDeviceSurfaceSupportKHR told cube 'no', but the logic to decide the physical device has already run, so it just aborts. So yeah, vkcube just straight up doesn't take into account presentation support when choosing a GPU.

I'll update the issue's description to match that reality, but I will say that this is a low priority issue for me. I'll gladly look at PR's but I know that this is not a simple change and my priorities are elsewhere at the moment.