[PATCH v7 4/4] winevulkan: Implement VK_KHR_external_memory_win32 for images.

Derek Lesho dlesho at codeweavers.com
Wed May 26 09:21:11 CDT 2021


On 5/25/21 10:07 PM, Zebediah Figura (she/her) wrote:

>
>>>
>>> * Shared resources in d3d9-11, when using the OpenGL backend
>>
>> As mentioned, the EXT_external_objects extension exists, (
>> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects.txt 
>>
>> ), which accepts and produces file descriptors compatible with the ones
>> Vulkan produces and accepts.  The interactions here seem to be well 
>> defined.
>
> According to my reading, neither GL_EXT_external_objects nor 
> GL_EXT_external_objects_fd provide for export of an object from an 
> OpenGL context; they only allow importing objects created by Vulkan.

Yeah, from what I can see, openGL has no standard way to share memory 
across processes without the use of this extension and Vulkan.  I 
suspect this would be difficult due to all the user mode driver code 
protecting against invalid use of resources.  I think the most 
reasonable path forward is to create a Vulkan dummy object in wined3d, 
then import it into GL.  Of course, this would make shared resources 
unsupported for old GPUs and systems that don't support Vulkan, but the 
API is half a decade old at this point, and only GPUs from almost a 
decade ago don't support it.

Alternatively we could get try to use platform-specific buffer sharing 
APIs like EGLStreams or GBM, or just support in-process shared resources 
through the eglCreateContext API, which allows the creation of "shared 
contexts", in which the GPU resources are shared.

>>>
>>> * Shared resources between d3d9-12 devices, when using wined3d or
>>> libvkd3d on Windows
>> Putting aside how rare and questionable of a use-case this must be, I
>> don't think this concerns any of my patches.  My future patches would
>> provide a way for translation layers on wine to store metadata alongside
>> the host handlers, it doesn't have any correspondence to Windows.  If
>> you really wanted to (why?), you could probably create your own backing
>> storage in a shared memory object and accept the caveats that come along
>> with that.
>
> I suspect those of us who have worked with Direct3D for multiple 
> decades would take issue with "rare and questionable", but regardless, 
> part of the point here is to ask: *is* it possible to use a native set 
> of APIs, like perhaps the D3DKMT*() functions from gdi32, to share 
> resources? I.e. should the implementation live in gdi32 instead of 
> winevulkan/opengl32/wined3d? Just from a quick scan I see several 
> which look like the ones we want, and they're even documented.

Could you link these APIs so I can look further into them?  I conferred 
with Josh and he didn't find anything.

Also, if there are APIs which allow registering resources retrieved from 
Vulkan with certain metadata, winevulkan would still have roughly the 
same role.  The only difference would be in the translation layers, 
where instead of using IOCTLs on the HANDLEs to shared resources they 
have to get/set metadata, they would use some D3DKMT API you've found.

>
>>>
>>> I note your tests also don't seem very interesting; they only share
>>> objects within the same device. Sharing objects across multiple
>>> devices, and across multiple processes, strikes me as more interesting.
>>
>> In my opinion, given that the semantics for VK_KHR_external_memory_fd
>> and VK_KHR_external_memory_win32 are so similar, I wonder how relevant
>> such tests would be, it seems like the kind of thing the Vulkan CTS
>> should add for testing drivers.
>>
>> I think the tests should be more for testing the properties of the
>> HANDLEs we get, as this is what we are implementing ourselves. Maybe I
>> should add more tests looking at the locations of the named objects in
>> the NT directory, or tests relating to types of the objects and their
>> access permissions.
>>
>>
>
> The point is more of a smoke test, because it's easy to get it wrong, 
> and not too hard to verify that we got it right.
>
> It'd also be nice to demonstrate what the behaviour of KMT handles is 
> across processes.
>
An in-process intra-device test tests the same amount of winevulkan 
behavior as a cross-process inter-device test.  All the implementation 
details of cross-process and cross-device sharing are handled on the 
host and through wineserver's well established HANDLE<->FD mapping.



More information about the wine-devel mailing list