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

[Alexandre Julliard]

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.

-- 
Alexandre Julliard
julliard at winehq.org