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

[Derek Lesho]

On 5/5/21 6:37 AM, Paul Gofman wrote:

> On 5/4/21 23:44, Derek Lesho wrote:
>> The problem is not with the graphics APIs closing the handles they use
>> to get the FDs or the shared memory handles, the problem is with the
>> user code closing the shared memory object and wine having no way to
>> know how to release the reference that now-destroyed shared memory
>> holds to the fd object.  This also assumes that there is a indeed a
>> way to hold a global reference to the fd object from the shared
>> memory, which I don't think there is.
> Yes, indeed, at least my limited (to say the least) involvement into
> this problem doesn't allow me to see such a solution. Yet it looks a bit
> weird me to introduce a whole driver taking a separate process and
> acting just as a placeholder for handle and shared object. Are you sure
> there is no good way to add some support to wineserver (maybe keeping
> away some specific 3D details from it)?

Well, we could add a separate API to ntdll that allows naming the 
objects created through fds, add a server call to associate private data 
with either these types of objects or any objects, and for KMT handles 
try to erect a global memory section with a table that contains pairs of 
object HANDLEs and process PIDs, removed by the Vulkan object's 
destruction routine.  For the KMT handles, we could also add support for 
global non-referencing handles for non-named objects to wineserver.

As for my opinion, I think we should either fully commit to the 
wineserver path or the device object path, and not try to go with the 
wineserver path while keeping stuff generic.  Since there are accuracy 
benefits to be reaped by going with wineserver (object type information 
could be accurate, and access/permissions could be handled better), I 
think we should take advantage of that if we go down that path.

All in all, I still think the least intrusive system is the .sys using 
device objects as frontends for fd objects.