I am exploring a couple of things, mostly because I wanted to share images between APIs for compositing, and it ends up being very related to shared resources, but I don't really have anything implemented or planned yet except maybe for a basic architecture of D3DKMT objects.
Testing these D3DKMT primitives however gives some interesting clues on how we could implement them. I think we should be able to store the linux primitives inside of them (dma-buf/sync/opaque fds on linux, IOSurface through mach_port on macOS), probably on wineserver side for the "global" D3DKMT objects.
There's a separate level of D3DKMT handles, which are meant to be used locally, and which could stay in-process. The local handles can in theory be local-only, but I don't think that's very useful for us, and otherwise operate as a reference on a global object.
Then, D3DKMT objects can be bundled together (or alone), with the D3DKMTShareObjects call, and be exported as a NT handle. That handle is a true handle, which can be duplicated etc... and it can either be exported as is from Vk, or used to unwrap it to D3DKMT local objects.
I'm mostly interested in sharing images, but there's also synchronization primitives there, and I have no idea how they are supposed to work. They can be of various nature, and D3DKMT has functions to wait and signal them, from CPU or GPU side, and I don't know how that would work. Proton uses some very ugly mechanisms for them (some shared memory with mutexes, background threads, etc), so I'm thinking involving wineserver there too might be necessary.