Unclear if a device should advertise support for rendering to a desktop rendered by another device

[axeldavy]

On some systems there can be several cards available.

Examples are: . Crossfire/SLI configurations: one of the cards is connected to the display and renders the desktop . Laptops: iGPU renders the desktop and is connected to the display OR dGPU renders the desktop and iGPU is used to communicate the rendered content to the display.

With GL, rendering to another device than the one used to render the desktop implies some hidden operations (allocation of buffer both devices can understand in some shared memory, potentially some hidden copies, etc).

Current WSI spec of vkGetPhysicalDeviceSurfaceSupportKHR doesn't specify if the cards not used for the rendering of the desktop should advertise support or not.

Both not advertising support and supporting but with some hidden operations seem allowed by the current spec. Could it be clarified ?

I believe it is important to specify it.

1) If only the device used for desktop rendering is allowed to advertise support, then apps would have to iterate over the devices to find the one supporting the surface (And I guess with some future extension it will be possible to render with other devices and share buffers such that you could present with the device supporting rendering to the surface).

2) If all devices are allowed to advertise support, it seems rather difficult for the apps to pick one, and it may result in suboptimal choice.

I guess the behaviour is linked to the -likely being written- extension to share data accross devices, and my guess is that 1) implies that the work done to render to a different gpu than the desktop will have to be done by the app, whereas 2) will hide that in the driver. I prefer 1) personally.

[jjulianoatnv]

Thank you for this feedback.

We agree that some cases (including this one) are under-specified. That was a conscious decision made for sake of staying on schedule. We plan to revisit post 1.0.

Some of the contributing factors will need to be worked through. It might be helpful if you explain how your code might respond to this information. E.g., if a Boolean attribute was added to the queries from VK_KHR_display to indicate that a display is directly connected vs. "implicit cross adapter present", would that address your concern?

[axeldavy]

In my understanding, desktop apps shouldn't use use VK_KHR_display for rendering, but the other extensions, so It won't be sufficient to add a boolean attribute there.

Probably things could be like that: . It is made clear it is possible a given device would support no platform (to support the case the device is connected but has no way to present. Then the device could be used for compute or other things) . Have a query that would work for all wsi extensions, and that would tell whether the device is doing direct presentations or is doing presentation via another device.

That would enable the following: . Apps have to handle the fact a device would support no platform, and not crash. . If a driver is doing some optimised behaviour to be able to do presentation via another device, it would advertise support to render to the platform and the surface, and the app would not need to initialize the other device and do the work to have the presentation work well. However with the query, the app would be aware of that, and if it wants to it could do the presentation work via the other device manually. Doing this manually could be useful for example if the app is choosing to put some final post processing steps on the other device. My suggestion also allows the driver to not implement being able to present to another device in the driver, and then the app would have to do the manual way.

[axeldavy]

On top of that, what would be really good would be to have a way to get the user preferred device.

On laptops with igpu + dedicated cards, the driver lets user decide which card should be used on an app basis.

The way to enforce the app to use the card the user decided is implemented in a lot of different ways depending on the driver. It would be good if Vulkan would define a clean way to do that:

For example there could be a query to tell which device is preferred by the user. I understand that is a bit difficult since the driver devices are not talking to each other, but if there would be some way, it would be really great.

If such a clean way to get the preferred gpu is not defined, I'm afraid the drivers would have to do hacky things to enable user to pick gpu, for example by replacing the vulkan system library by a custom one that would advertise only one device: the one user wants you to render to, which can be suboptimal if app could some compute stuff or postprocessing on the other device.

[jjulianoatnv]

Thank you again for the feedback. This topic is on the list of things we are looking at. I do not have answers for you at this time.

While there are several factors to consider, what you describe does resonate with some of the points that have been discussed.

[oddhack]

Tagging with "Future" milestone.

[axeldavy]

I'm surprised by the addition of the "Future" milestone to this issue, as AMD Windows driver is said to support laptops with iGPU+dGPU, so I'd thought there had been some internal agreement. Also I'd expect Nvidia to release soon similar support for their Optimus systems.

[jjulianoatnv]

Adding a quick note to say that I noticed this old issue in the backlog, and I've been thinking about the points you have made.

[krOoze]

Looks like it would help explicitness. Other APIs at least seem to have a way to query which display is hooked to which device. @jjulianoatnv Now wiser with age, have you figured something out with this?