On Mon Oct 6 19:05:44 2025 +0000, Paul Gofman wrote:
Ok, I quick dumped dxgi and d3d11 exports on Windows dll. DXGI doesn't seem to export any D3DKMT functions at all, is it right to export those from dxgi.dll? d3d11 does export a bunch, but from the look of winedump doesn't look like they are forwarded. How exactly that is broken now without adding anything? If that is for calling those functions from Wine that should be correctly resolved to gdi I guess? And if that is about calling D3DKMT functions from dxvk, maybe the best bet for now in this case do that with GetProcAddress there? Before we know what does it mean that those functions are dupicated in d3d11 and what those versions are supposed to do.
Like described in the patch, dxgi on Windows 10 doesn't export them anymore, but it was on Windows 8.1. And as MinGW import lib has them, and until they get removed from there, and until the toolchain update is widespread enough, it doesn't seem like a huge deal to have them too.
Regarding what these duplicated functions do, I don't think it's interesting at all and I'm not going to spend time looking into this. They are probably just wrappers around the syscalls because they didn't want to pull gdi32 or win32u directly.
It's also IMO inconvenient if all these concerns are now requiring us to use GetProcAddress everywhere, just to make sure we get the gdi32 function. I had this initially to workaround the issue but it's not a nice solution and I would even expect it to be slowing down the adoption of D3DKMT for shared resources in DXVK because there's no good reason to have to do it when linking is supposed to just work.
Then I would like to add that even though this MR adds new dxgi exports, several of the d3d11 D3DKMT forwards were already present before, and they didn't raise the same concerns that were raised here (and even, some exports have been added which were never supposed to be there).