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.