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

[Derek Lesho]

On 5/4/21 3:56 PM, Paul Gofman wrote:

> On 5/4/21 22:39, Derek Lesho wrote:
>>> Extending this to objects which aren't resources (e.g. semaphores,
>>> fences) is left as an exercise to the reader; it could be done with a
>>> separate pair of ioctls or by extending the above structure.
>>>
>>> I will of course disclaim that I have thought this approach through
>>> completely, or that it is the best approach (in particular, I still
>>> am inclined to think that server-side management probably isn't that
>>> bad)
>> Yeah I'm not necessarily opposed to server-side management either, but
>> at the very least it seemed to me like it was off the table in 2019.
> I am sorry, I might have not following the topic precisely and my
> question might be a bit off, but still, why additional support for the
> handles is needed at all? Given the exact replication of related Windows
> handles mechanics is not planned?
>
> Can't those handles be just, say, mapping handles with the specific
> resource description, fd etc. data filled in and interpreted by the
> interested graphic layers?
The main reason why this wouldn't be feasible is the edge case of a 
process which creates a shared resource then shuts down.  The process 
into which the resource was copied would still have an open handle to 
the mapping, but the mapping wouldn't hold a reference to the actual 
resource.  (It would probably just contain the PID of the process which 
created the resource + that process's HANDLE, for use in DuplicateHandle).
>