On 29 July 2016 at 20:08, Marek Olšák <mar...@gmail.com> wrote: > On Fri, Jul 29, 2016 at 8:01 PM, Rob Herring <r...@kernel.org> wrote: >> On Fri, Jul 29, 2016 at 12:51 PM, Marek Olšák <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev