[PATCH 0/4] Add support for Vulkan shared memory in wine.

Derek Lesho dlesho at codeweavers.com
Mon Nov 4 13:10:10 CST 2019

On 11/4/19 1:00 PM, Alexandre Julliard wrote:
> Derek Lesho <dlesho at codeweavers.com> writes:
>> On 11/4/19 11:50 AM, Alexandre Julliard wrote:
>>> Derek Lesho <dlesho at codeweavers.com> writes:
>>>> On 11/4/19 9:39 AM, Alexandre Julliard wrote:
>>>>> Derek Lesho <dlesho at codeweavers.com> writes:
>>>>>> This patchset adds support for Vulkan shared memory in wine, which can
>>>>>> in turn be used by API layers like DXVK or D9VK to support D3D shared
>>>>>> resources.  The final commit in the patchset adds a wine extension
>>>>>> allowing layers to associate a custom struct describing a resource, so
>>>>>> that they can recreate it with no outside information.  In the case of
>>>>>> DXVK and D3D11 shared resources, this is a D3D11_COMMON_TEXTURE_DESC.
>>>>>> While this is the simplest solution, it may be a better idea to define
>>>>>> a standard structure/s, so that interop between i.e. DXVK and vkd3d
>>>>>> would be possible.
>>>>>> Keep in mind that this functionality may also be used for resources
>>>>>> other than textures/surfaces, like synchronization primtives.
>>>>> This looks like something that belongs in the D3D layers, not in the
>>>>> server or ntdll.
>>>> I assume you're referring to the custom data associated with the
>>>> resource?  I think you're right, since they could instead create a
>>>> shared memory handle which they use to store a KMT handle and the
>>>> resource desc.
>>>> If you're referring to the whole patchset, I think we need to at-least
>>>> export some of the file descriptor<->handle functions in ntdll so we
>>>> can turn the FD provided by VK_EXTERNAL_MEMORY_fd into a handle for
>>>> the win32 extension.
>>> We already have fd<->handle conversion functions in ntdll, you should be
>>> able to build something on top of that.
>> Yeah, I did build the shared resource functions off of those
>> conversion functions in ntdll, then exported the shared resource
>> functions.
>> Would you rather we keep this or export the fd<->handle conversion
>> functions themselves?  If we just export them, what object type would
>> we store the vulkan resource as?
> They are already exported. You should be able to build what you need on
> top of files, or mappings, or some other kernel primitive, and not
> change ntdll at all.
> Adding new kernel object types or changing the server should be the last
> resort, so if you want to do that, you'll have to make a very convincing
> argument that the existing primitives can't be used for this.
Ah, I didn't see that, should have looked.  I can try to redo the 
patchset using those in winevulkan.  One issue though is the use of KMT 
handles, which are pretty much just resource IDs like PIDs or TIDs.  How 
do propose we implement that without support in the server?  Maybe we 
could use ConvertToGlobalHandle?  The issue then is that the global 
handle isn't supposed to contain a reference to the resource.

More information about the wine-devel mailing list