On Wed Sep 4 22:14:35 2024 +0000, Elizabeth Figura wrote:
As far as I can see the resource descriptor lives in the
pPrivateRuntimeData buffer, which can be set on creation, or queried/opened later. The buffer structure isn't documented and apparently has changed a bit across windows versions but looking at it it seems to be simply the texture descriptor with some header (the header has grown from W8 to W11, the descriptor stayed the same), it should be possible to test and reverse it to be compatible. The instability across Windows versions is one problem, yes. I think the bigger problem is probably the rest of the driver-private data, which, as you mention, is driver-specific and unstable, not just in theory but in practice. There may very well be other hidden things that the driver does. Trying to use d3dkmt functions directly from wined3d and on Windows is essentially trying to replace exactly one half of the GPU driver, and I don't think it can be expected to work. Proposal (4) will only allow wined3d to interop with itself, but we can't do any better.
_(I haven't confirmed it but I suspect that either you cannot import
Vulkan-created images into D3D unless the Vulkan driver adds that descriptor, or they use some driver-specific callbacks to parse the driver data which we probably can't do, and driver data seems much more unstable.)_ I have confirmed it—word from a Microsoft Direct3D developer is you cannot export from Vulkan and import into Direct3D on Windows. The capability exists in the Vulkan API, but that path simply doesn't work.
Then, for wined3d running on GL on Windows, the problem is even
bigger, as there's simply no way to export GL underlying resources. So, if we want wined3d/GL shared resources to work on Windows, we'll need to create the D3DKMT resource upfront and import it (instead of using a Wine-specific extension for export). Yes, there's no way to make export work when using the GL backend. It's unfortunate but there's nothing we can do about it.
Haven't explored this idea yet, but if there's a stable API for accessing driver ddi implementations from the adapter/device, we could just call that and import the resource. Should work on windows, and on wine we'd have our own "ddi implementation" just for shared resource stuff using d3dkmt methods