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

Derek Lesho dlesho at codeweavers.com
Tue May 4 15:21:14 CDT 2021


On 5/4/21 4:13 PM, Paul Gofman wrote:

> On 5/4/21 23:05, Derek Lesho wrote:
>> On 5/4/21 3:56 PM, Paul Gofman wrote:
>>
>>> 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.
> If a separate process (say, ntoskrnl.exe) can hold all the required data
> independently of the process which created the shared resource, can't
> shared memory hold that instead (possibly using some other global
> [named?] objects already supported by wineserver?
>
>
I think the problem is, if you find a way to store a reference to the 
object in the shared memory object, how do you know when to release that 
reference once the shared memory object is destroyed. As for making all 
the objects global, I'm not sure how that solves the problem, what code 
is releasing the reference that was in the shared memory before destruction?



More information about the wine-devel mailing list