Implement D3DKMTEnumAdapters2 and D3DKMTQueryAdapterInfo (for WDDM_2_7_CAPS)

[liam-middlebrook]

Implementations needed to support querying a D3DKMT adapter for WDDM_2_7_CAPS information. This work has partial overlap with commits which are already in upstream wine; individual commit messages contain reasoning for why they exist rather than cherry-picking patches from upstream.

Most notably, the third commit is the only commit which would need to be carried over in a rebase on-top of upstream Wine. It would need to be slightly re-written, some more notes in the commit message.

Hopefully the additional notes on change integration are helpful for you @ivyl

[ryzendew]

Not sure where to Report this but doing it here Black myth wukong starts with dlss FG enabled but than if you turn it off it refuses to turn back on and says this

Fast edit thanks for not deleting my report unlike on that other repo ...

[shelterx]

Not sure where to Report this but doing it here Black myth wukong starts with dlss FG enabled but than if you turn it off it refuses to turn back on and says this !

For me it started with FG off and I can't turn it on, so it's basically the same thing I mentioned here. But once DLSS-FG landed I think it's better to put an issue for each game, the HAGS issue must be resolved tho' since more games might depend on it.

[shelterx]

Hmm having HAGS exposed seem to cause stutter in Cyberpunk 2077 even if FG isn't enabled.

[philipl]

I don't know how useful it is to mention here, but I tried the new Proton Experimental release and while FG works well in Cyberpunk, I cannot turn it on in Everspace 2 because the game reports that HAGS is not enabled. As I understand it, this PR is present in this Proton release so it ought to work.

[philipl]

I don't know how useful it is to mention here, but I tried the new Proton Experimental release and while FG works well in Cyberpunk, I cannot turn it on in Everspace 2 because the game reports that HAGS is not enabled. As I understand it, this PR is present in this Proton release so it ought to work.

For the record, this seems to be specific to multi-GPU scenarios. I have the Intel iGPU active in the system, and it seems like HAGS detection failed when I was hiding the Intel GPU from Vulkan (due to the game crashing when it was visible). The developers gave me a work around to avoid hiding it and then detection worked. I assume, in some very hand wavy way that hiding the iGPU from the game while the system is able to see it leads to some kind of mismatch in device identification when querying the device properties in this change, but I'm not in a position to say precisely what's going on.

[Triang3l]

Does the "PCI" enumerator also include software devices like the Microsoft Basic Display Adapter with the WARP software Direct3D UMD, as well as non-PCI GPUs such as the Host1x-attached Nvidia Tegra 3's GPU in the Microsoft Surface RT?

For enumerating all display devices, CM_Get_Device_Interface_List for GUID_DISPLAY_DEVICE_ARRIVAL can be used alternatively (however you need D3DKMTOpenAdapterFromDeviceName aka NtGdiDdDDIOpenAdapterFromDeviceName implemented somehow to actually obtain the D3DKMT adapter handle from the device name returned by it — and in upstream Wine, as of now, that function simply does NtGdiDdDDIOpenAdapterFromLuid for a zeroed LUID), it does include the software adapter, although I'm not sure how well-implemented cfgmgr32 is in Wine on non-Windows hosts overall.

One usage example is available at https://gitlab.freedesktop.org/Triang3l/mesa/-/blob/Terakan/src/amd/terascale/vulkan/winsys/wddm/terakan_physical_device_wddm.c (see terakan_physical_device_wddm_enumerate).

Note the kind of dependency reversal in that current implementation of NtGdiDdDDIOpenAdapterFromDeviceName in Wine also (which is of course fine as for now it's just a stub that opens the first available adapter or something like that). FromDeviceName has existed since Windows Vista, while FromLuid was added in Windows 8, and is itself can be implemented as calling FromDeviceName and comparing the LUID for each adapter returned by CM_Get_Device_Interface_List.

[Triang3l]

According to https://learn.microsoft.com/en-us/windows-hardware/drivers/install/enumerating-installed-device-interface-classes, SetupDiGetClassDevs also can be used for the purposes of enumeration, but the Enumerator argument can be NULL. And yeah, since you can query the LUID this way (via DEVPROPKEY_GPU_LUID) without actually calling D3DKMTOpenAdapterFromDeviceName, it should be more straightforward than using the Configuration Manager. Is the "PCI" enumerator needed for anything important in Wine, and what happens if you don't pass it?

Edit: The Configuration Manager also has CM_Get_Device_Interface_Property for the same purpose, so it doesn't really matter which one of the two is used — and the Setup API also appears to be much older, though CfgMgr appears to have been added in Vista, which is the first release to have WDDM at all.

Edit 2: Which Windows version has gotten DEVPKEY_Gpu_Luid at all first? If it's actually something as recent as some Windows 10 update rather than Vista, the D3DKMTOpenAdapterFromDeviceName approach may be more preferable. Though if you can get the device name from the Setup API rather than the Configuration Manager as well, the selection between the two also doesn't matter.