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

[Rob Herring]

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.

Maybe I'm missing something, but how does dynamic-lists help? AIUI, it
fixes only the static linking problem. That would still leave gralloc
calling a driver specific create screen function and require updating
gralloc for each new driver would it not?

> 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.

Rob