[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106187

--- Comment #9 from Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl> ---
So I think there are several issues in this bug:

1) Running on a GPU that is not connected to the display is slower. Arguably we
should be able to optimize this a bit, especially if the two cards are
identical, but there is always some extra bus traffic that is going to happen
(and not sure if card B can directly scanout from memory in card A).

2) radv does not return the "primary" GPU first. The problem here is that there
is not really a primary GPU. You can have multiple cards, with multiple X
server, and we only know which one we are going to use for display once the app
gives us an X surface, which is after we have listed the devices. Of course the
common case is that there is only one X server running. I'm wondering if we
could reasonably do some out of band communication to figure out if there is
one X server and what GPU it uses and then preferably list that?

However, generally this is not solvable, especially when the GPUs are not
duplicate. e.g. when there is an intel iGPU + Radeon dGPU the driver does not
decide the ordering at all, the loader does.

Apps should be able to check this by checking if a specific GPU supports
present from any of its queues, but then again we enabled PRIME by default, so
radv always says yes ....

A solution might be disabling PRIME by default, but that breaks any game which
just picks device 0, which is likely a lot of them ... And IMO slower
performance is better than complete breakage, especially since those games
often don't really provide a workaround.

3) As for remembering GPUs even in the duplicate case, the external memory
extensions have a GPU identifier. I know it is technically not guarantueed to
be stable, but for radv at least it should be stable across reboots (and mostly
across driver upgrades), and probably the best you can get.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180423/81c8ad93/attachment.html>