[RFC PATCH 5/9] wined3d: Support adapter LUID via SetupAPI.

[Zhiyi Zhang]

On 16/01/2019 19:05, Józef Kucia wrote:
> On Wed, Dec 26, 2018 at 1:49 PM Henri Verbeet <hverbeet at gmail.com> wrote:
>> On Fri, 21 Dec 2018 at 11:32, Józef Kucia <joseph.kucia at gmail.com> wrote:
>>> On Thu, Dec 20, 2018 at 9:02 PM Henri Verbeet <hverbeet at gmail.com> wrote:
>>>> Well, maybe. There also exist Win32 builds of wined3d though, and
>>>> setupapi would have the advantage of working there as well, while we
>>>> wouldn't necessarily be able to rely on any particular OpenGL
>>>> extension being available.
>>> The "DEVPROPKEY_DISPLAY_ADAPTER_LUID" property seems to be available
>>> only on Windows 10. The OpenGL extension should also work on older
>>> Windows versions.
>> That's true.
> The best option might be to use the EXT_external_objects_win32
> extension, and fallback to setupapi when the extension is not
> available.
>
>
The problem is that opengl doesn't have a proper way to enumerate

graphics cards. There are vendor specific extensions like WGL_NV_gpu_affinity

and WGL_AMD_gpu_association but they are usually unavailable on consumer

products, let alone not portable.


We could use the EXT_external_objects_win32 but then it will only report

UUID and LUID for the primary graphics card, which is sort of useless because

using setupapi will also fallback to reporting a default graphics card if Vulkan

enumeration failed.


And as a kind of related topic. I think I found a way to implement EnumDisplayDevices

by using xrandr 1.4.0 protocol[1]. Turns out I missed this path because somehow www.x.org puts

an xrandr 1.2 on its front page and I didn't read carefully enough to know there is more.


I plan to implement EnumDisplayDevices as follows:

winex11.drv init -> libxrandr enumerates adapters and monitors -> stores info via setupapi

-> EnumDisplayDevices gets the info via setupapi. And also listen monitor/gpu change

notify from libxrandr to refresh the info.


Having a working EnumDisplayDevices won't help much here though. As the adapters in libxrandr

might not be opengl/vulkan-capable. And I haven't found a way to uniquely identify a libxrandr adapter to

opengl/vulkan adapter (VK_EXT_pci_bus_info[2] might be a way to go, but it's not widely available yet).

Even if we could, native opengl uses the one adapter on the DISPLAY anyway. So not much use for opengl.

Thus will stay with using vulkan to enumerate d3d adapters for now. As for reporting different

adapters count using vulkan and libxrandr, it's not a problem because Windows doesn't report

the same either.


[1]: https://lists.x.org/archives/xorg-devel/2012-July/032350.html

[2]: https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkPhysicalDevicePCIBusInfoPropertiesEXT.html