vkcube should use the first available physical device

[kvark]

Highly related to #153

Code in question -

Vulkan-Tools/cube/cube.c

Line 4185 in a2224ab

/* Try to auto select most suitable device */

As a result of this logic, vkcube always picks a discrete GPU on multi-gpu systems. This is in conflict with the principle of vkEnumeratePhysicalDevice returning the adapters in a "preferred" order by the system (see KhronosGroup/Vulkan-Loader#153 (comment) for context). If Vulkan loader is indeed trying to return the first adapter as the preferred, and/or there are applications expecting them, then I think vkcube should just pick the first (available) physical device instead of doing any kind of sorting. If you want to demonstrate a more comprehensive use of Vulkan, you could keep the sorting functionality behind an option.

The context here is - some systems returning Intel GPU as the first but actually failing to present with it. See https://gitlab.freedesktop.org/mesa/mesa/-/issues/4688 and https://gitlab.freedesktop.org/mesa/mesa/-/issues/12212 for examples. vkcube is often used to simply check "does Vulkan work on your system", and always returning the discrete GPU isn't actually providing this signal, which causes confusion.

Examples of confusion:

• https://bbs.archlinux.org/viewtopic.php?id=280222

[water-chika]

If you want to demonstrate a more comprehensive use of Vulkan, you could keep the sorting functionality behind an option.

vkcube --gpu_number 0 could help you always select first GPU.

vkcube is often used to simply check "does Vulkan work on your system", and always returning the discrete GPU isn't actually providing this signal, which causes confusion.

If you want to check all physical devices could work on your system, you could get total number GPU number and run vkcube --gpu_number <index> in a loop.

[jjulianoatnv]

I'm opposed to the premise of this issue's problem statement.

We intentionally added sorting to bring Vulkan on par with APIs like D3D12 on Windows. On Windows, there is OS arbitration of physical device sorting. This sorting spans devices from separate IHVs (which is this issue's configuration.) The OS provides centralized user control that overrides the default heuristics. Users do use these capabilities. Matching D3D12 behavior in Vulkan is desired.

Linux lacks centralized control that spans IHVs. In part, there is an allergic reaction from linux maintainers to the concept of centralized arbitration that spans drivers. Recent discussion within the Vulkan working group has seemed to come to realize that centralized arbitration might in fact be good, and there might be an "education campaign" in the coming months. The future is TBD.

In the absence of centralized arbitration, the Vulkan loader for linux has implemented its own heuristics. The topic of the current github issue is really about the heuristics that were implemented inside the Vulkan loader for linux. This is a narrower scope than how the issue topic is currently written.

My words do not debate the quality and efficacy of those heuristics. I do not oppose change to the Linux heuristics. What I'm doing in this comment is clarifying the problem space and providing some background that is relevant to the discussion.

[kvark]

@jjulianoatnv thank you for a well-thought response!
If there is a gap in Linux support for Vulkan with regards to supporting multiple IHV, I don't think vkcube is the right place to solve it. Introducing adapter sorting in vkcube is not going to magically bring Vulkan on par with D3D12 for everybody.
The proper solution would lie somewhere in writing the Vulkan layers (like the MESA device select), working with linux maintainers (like you mentioned), etc. vkcube should assume a healthy system, not try to fix it.