vkcube with VK_KHR_display fails when acquirable displays are on not-the-first physical devices

[jjulianoatnv]

The way that vkcube's support for VK_KHR_display is implemented, vkcube fails when no direct-to-display VkDisplayKHR can be acquired on the vkPhysicalDevice that is sorted first in the list of physical devices, even when additional physical devices do have displays that can be acquired.

This is an app bug. It prevents using vkcube to test some multi-GPU scenarios.

This bug happens because vkcube is "lazy" in how it selects a physical device. It always selects the first physical device, even if this physical device does not have any displays that can be acquired.

        VkPhysicalDevice *physical_devices = malloc(sizeof(VkPhysicalDevice) * gpu_count);
        err = vkEnumeratePhysicalDevices(demo->inst, &gpu_count, physical_devices);
        assert(!err);
        /* For cube demo we just grab the first physical device */
        demo->gpu = physical_devices[0];

demo->gpu is hard-coded to the first physical device without regard to the presence of an acquirable display on the physical device.

[cubanismo]

Note this isn't specific to VK_KHR_display. It will also fail on NVIDIA Linux drivers with multiple GPUs and an X11 screen on each GPU, since we don't currently support cross-GPU presentation on X11.

I think the right way to solve both is to use vkGetPhysicalDeviceSurfaceSupportKHR(). That will only fix the X11 issue on the very latest NVIDIA drivers, but it should fix the VK_KHR_display issue (assuming additional changes cause vkcube to try to enumerate displays on all GPUs before selecting a GPU for actual rendering) everywhere as well.

[achea]

As a workaround on an Optimus system, I'm able to set VK_ICD_FILENAMES=/path/to/nvidia_icd.json. I don't know how Vulkan works, but what I think this does is override the list of available drivers to just one, so that vkcube will 'lazily' select the only available ICD, which is nvidia's in my case.

This "fix" has been floating around on various wikis and projects, and also works with vulkaninfo (i.e. shows just the one nvidia driver, not both intel and nvidia). I just want to leave this crumb in case anyone else find this issue when testing vkcube.

[TonyBarbour]

I've looked into this a little, and it looks like detecting which physical devices have WSI support via vkGetPhysicalDeviceSurfaceSupportKHR would be a pretty big refactor to what is meant to be a fairly simple demo. I've not seen any demos that consider a physical device with no WSI support, including the Khronos sanctioned samples, which simply look for a discrete GPU and if not found, use the first physical device. So I propose adding a command line option to vkcube and vkcupepp to allow specifying which physical device to use. That, to me, seems like the best compromise between the problem described here, and code simplicity.

[TonyBarbour]

Closing with workaround

[jjulianoatnv]

I disagree with the proposed workaround upon which this issue was closed.

vkcube serves as sample code that ISVs can mimick when writing their code. A bad sample encourages ISVs to write (and ship) bad code.

The issue here is not that some physical devices HAVE WSI SUPPORT while other physical devices LACK WSI SUPPORT. The issue is that a given physical device might not have any devices that are usable via VK_KHR_display. Or, the app could be trying to use a particular display, and it needs to find the physical device to which that display is connected.

A typical user does not know which number to use in a hacky command line argument that selects the Nth GPU.

Rather than a hacky command line argument enabling the user to specify a chosen GPU, and letting vkcube find ANY display on that GPU; I'd prefer that a command line argument enables the user to specify a chosen display, and vkcube finds a physical device that can present to the chosen display. Then a QA testplan could run vkcube several times, once for each display. Indirectly, this would cover all physical devices that can present to at least one physical display.

Related is #494.

Related is #429.

[KarenGhavam-lunarG]

vkcube serves as sample code that ISVs can mimick when writing their code. A bad sample encourages ISVs to write (and ship) bad code.

vkcube is not advertised as a sample to be mimicked but rather a "turn on" test for your Vulkan installation. Good samples for ISVs are in the KhronosGroup/Vulkan-Samples repository. Perhaps you may want to do a PR to this repository demonstrating the technique?

Due to the work effort of the refactor, if you are willing to submit a PR for this change we would be willing to code review and test it. Otherwise I believe the work-around is an acceptable solution.

A typical user does not know which number to use in a hacky command line argument that selects the Nth GPU.

It isn't a hacky command line argument. It is easy to determine the GPU by running vulkaninfo and choosing the GPU you desire.