[RFC PATCH 3/4] winevulkan: Add support for named video resources.

[Zebediah Figura (she/her)]

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?