[Mesa-dev] [PATCH] gallium: introduce load_pipe_screen()

[Emil Velikov]

On 22 February 2016 at 15:48, Rob Herring <robh at kernel.org> wrote:
> On Thu, Feb 18, 2016 at 1:15 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 18 February 2016 at 17:47, Rob Clark <robdclark at gmail.com> wrote:
>>> On Thu, Feb 18, 2016 at 11:48 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>> Hi Rob,
>>>>
>>>> On 10 February 2016 at 22:56, Rob Herring <robh at kernel.org> wrote:
>>>>> Introduce load_pipe_screen() public entry point for other code which
>>>>> dlopen()'s gralloc_dri.so for purposes of loading a pipe_screen. This way
>>>>> drm_gralloc can avoid static linking of each gallium winsys and driver,
>>>>> and avoid duplicated logic to figure out which pipe driver to load.
>>>>>
>>>>> This is based on Rob Clark's work. I moved it into pipe_loader which seems
>>>>> to be a better spot.
>>>>>
>>>> As Rob C might have mentioned it, I'm not at all a fan of this.
>>>> Although unless (until?) Android fixes their runtime to honour
>>>> --dynamic-list(s) we can keep it in. Please ensure it's Android
>>>> specific (add a bunch of ifdef ANDROID guards) add a few
>>>> notes/warnings "hack: we need this for android because..."
>>>
>>> I know you weren't a fan..  but IMHO we need to do *something* to
>>> simplify the "give me a pipe_screen, kthx" problem.. and ideally make
>>> the mega-driver vs non-mega-driver cases more similar.  I seem to
>>> remember you had a counter-proposal somewhere but lost track of the
>>> state of that..
>>>
>> The rework of static vs dynamic pipe-loader has landed for a while.
>
Note: the "static vs dynamic pipe-loader" quote does not refer to the
dynamic-lists business.

> Maybe I'm missing something, but how does dynamic-lists help? AIUI, it
> fixes only the static linking problem.
Dynamic-lists would promote the winsys_create symbol from library X,
thus any library that needs it (be that same one or not) will use it.
There is no need for dlopen/dlsym as things happen transparently.

> That would still leave gralloc
> calling a driver specific create screen function and require updating
> gralloc for each new driver would it not?
>
Android does not support dynamic-list, so it won't work here.

>> What I said above was "add a comment why we need it and keep it
>> Android specific", although my introductionary sentence might have
>> inspired enough momentum for people to miss it :-)
>
> I've got no problem with that solution.
>
Great, thank you.

Emil