Hello Derek, it looks like you've put a lot of thought into this problem. I assume you've already discussed this privately in detail with our Direct3D maintainers, but for the benefit of the rest of us, I have a few questions:
1. How do you plan to accomodate the following (whether in the near or distant future):
* CL_KHR_d3d11_sharing
* CL_KHR_gl_sharing
* Shared resources in d3d9-11, when using the OpenGL backend
* Shared resources in d3d12
* Shared resources between d3d9-12 devices, when using wined3d or libvkd3d on Windows
* Shared resources between d3d9-12 devices and OpenGL or Vulkan, when using wined3d or libvkd3d on Windows
2. What is the reason for the "weak" reference counting introduced in this patch?
3. Why is winevideo.sys necessary at all, if wine_server_fd_to_handle() and wine_server_handle_to_fd() provide the necessary wrapping of an external FD object?
4. What kind of objects are Vulkan or Direct3D shared handles on Windows? E.g. what does NtQueryObject(ObjectTypeInformation) return? Are named Vulkan objects implemented using the NT namespace? How is this different between e.g. D3D11_RESOURCE_MISC_SHARED and D3D11_RESOURCE_MISC_SHARED_NTHANDLE, or between VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT and VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_KMT_BIT?
5. Are D3D11_RESOURCE_MISC_SHARED / KMT handles cross-process? If not, should they be implemented using a process-local handle table somewhere instead of using NT handles? (Could/should we use D3DKMT* APIs from gdi32?)
6. Would it make more sense to use wineserver to manage shared resources instead of a separate driver, and thereby avoid introducing hacks into ntoskrnl?