[Mesa-dev] [PATCH v4 07/11] amdgpu: use common screen ref counting

Emil Velikov emil.l.velikov at gmail.com
Mon Jan 9 19:20:52 UTC 2017


On 29 July 2016 at 20:08, Marek Olšák <maraeo at gmail.com> wrote:
> On Fri, Jul 29, 2016 at 8:01 PM, Rob Herring <robh at kernel.org> wrote:
>> On Fri, Jul 29, 2016 at 12:51 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>> The fd table and reference counting in the winsys is required by the
>>> GL-VDPAU interop.
>>>
>>> radeon_drm_winsys_create and amdgpu_winsys_create are publicly
>>> exported by both *_dri.so and libvdpau_*.so, and whichever is loaded
>>> first will effectively provide the gallium driver implementation for
>>> both of them. The second loaded lib can't create its own winsys &
>>> screen & contexts because of the public *_winsys_create functions
>>> always invoking the first loaded lib.
>>
>> Yes, I'm aware of this as it was discussed in the RFC version, and it
>> was my intent to maintain that. I believe this version should support
>> this case as the ref counting is done within
>> radeon_drm_winsys_create/amdgpu_winsys_create. Where specifically do
>> you think it is broken?
>
> Hm, maybe not.
>
> Where is fd == -1 handled in the common code? Will this not match all
> devices to one hash table entry and one screen?
>
Afaict Rob H has tried to be nice here, using the common code for
amdgpu yet it's not a perfect fit.
Fwiw, I'd just opt out of converting/touching amdgpu for now.

Alternatively one could lift the amdgpu implementation to u_screen*
having a second hash table/associated compare_foo. Thus during
pipe_screen_reference() and/or pipe_screen_reference_init() one can
say "use compare opaque", which is tracked in pipe_screen/elsewhere
and the corresponding table is managed.

Then again I'd imagine one can think of other route to archiving the
ultimate goal.
Emil


More information about the mesa-dev mailing list