We can certainly do better? At least IMO forcing the implementation to use a custom mechanism just because it allows us to share with ourselves on Windows, but ultimately forbids us to interop with other implementations and APIs sounds like a dead end and a source of future problems.
It doesn't forbid us to interop on Wine; we can check whether we have a "wrapped" or "unwrapped" handle and deal with either.
It looks to me that the direction native takes is that vendors will eventually be capable of exporting D3D-compatible resources from Vulkan, NVIDIA exports its resources with a descriptor already. We should build things on the same native primitives, with only the extensions we need until they are not needed.
That's... not what I saw when testing? The runtime data for shared resources exported from Vulkan was always empty.
Assuming our understanding of how the driver stack works internally is correct, drivers *cannot* do this, unless they go to the trouble of reverse-engineering the Microsoft format and hardcoding it per Windows version. If Microsoft really wanted to enable this capability, they would need to add something. From my conversation, I didn't see any indication that they were going to do this. They seemed to be satisfied with the reverse path—exporting from d3d and importing into Vulkan—which does work just fine.
The thing is, we're *not* building things on the same native primitives when we do this. GPU drivers don't exist entirely in the kernel, nor are they two completely independent layers with a stable API between them. The D3D runtime does not call directly into D3DKMT APIs; it calls into the user-mode driver component which itself is *supposed* to call into D3DKMT APIs.
We would be trying to reach into the middle of the GPU driver stack, and that's not what wined3d does anywhere else. I find it hard to say it's even conceptually the "right architecture" to do this.
It would be a lot of work to even *try* to make that work on Windows, and I'm thoroughly unconvinced it will *ever* pan out. I certainly don't think we should commit to that approach in Wine without having a working prototype first.
If the Vulkan exported resource doesn't contain the descriptor we need, which would happen on Windows but perhaps not on Wine -assuming we can implement 2) and export the descriptor in our Vulkan wrappers-, we could put them in some side channel indeed, that would make sure our D3D implementation can import its own resources.
How? We can't inject metadata into an arbitrary NT handle.
I'm also not sure if you're betting on (2) or (3). Note that if (2), there's no impetus to implement D3DKMT APIs; wined3d won't be calling them and vulkan/gl/etc. will already be on the Unix side.