[Mesa-dev] [PATCH] pipe-loader: abstract GALLIUM_STATIC_TARGETS behind pipe_loader API

[Emil Velikov]

On 2 October 2015 at 19:02, Rob Clark <robdclark at gmail.com> wrote:
> On Fri, Oct 2, 2015 at 1:46 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 2 October 2015 at 17:11, Rob Clark <robdclark at gmail.com> wrote:
>>> On Fri, Oct 2, 2015 at 11:49 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>> On 1 October 2015 at 20:44, Rob Clark <robdclark at gmail.com> wrote:
>>>>> From: Rob Clark <robclark at freedesktop.org>
>>>>>
>>>>> Signed-off-by: Rob Clark <robclark at freedesktop.org>
>>>>> ---
>>>>> Drop the idea of more ambitious re-arrangement if libs, but keep the
>>>>> pipe-loader refactoring.  With this at least drm_gralloc could still
>>>>> dlopen() gallium_dri.so and then use the pipe-loader API to figure
>>>>> out which pipe driver to load and hand back a screen.
>>>>>
>>>>> The nine st is not updated.. but I don't claim to understand the whole
>>>>> screen + sw-screen thing.  So I figured I'd let someone who knew what
>>>>> they were doing update nine.  Once that happens, we should change to
>>>>> not expose the dd_xyz fxns outside of pipe-loader, imho..
>>>>>
>>>> If the intent here is to consolidate/abstract things, this patch isn't
>>>> the way I'm afraid.
>>>>
>>>> Namely, it drops support for software only pipe-driver. It also
>>>> removes pipe-driver support for dri, xa and vl-based modules. All of
>>>> which used to work fine last time I've tested them (admittedly ~6
>>>> months ago).
>>>
>>> I assume you mean !GALLIUM_STATIC_TARGETS support?
>>>
>> Precisely.
>>
>>> I think we just need to build pipe-driver twice, once in each mode,
>>> and link either the static-pipe or dynamic-pipe version per state
>>> tracker depending on how you want things..  but wasn't sure the best
>>> way to go about that..
>>>
>> I believe that won't work as the pipe-loader itself dlopens the
>> pipe-driver (pipe_foo.so).
>
> I could be being dense, but why wouldn't that work properly if we
> built pipe-loader twice?  Ie. the non-GALLIUM_STATIC_TARGETS build
> should be built with the right CFLAGS so the code path that tries to
> open pipe_foo.so ends up in the binary
>
> (I do wonder a bit why the search-path gets passed in externally from
> pipe-loader, since all the state trackers using the
> non-GALLIUM_STATIC_TARGETS would presumably want to look in the same
> place for pipe_foo.so, but maybe that is a separate clean-up..)
>
I wouldn't say that you're dense - could be tired and/or my
explanation leaves something to be desired. Let me try it from another
angle.

If we build pipe-loader as is, it is part of the 'API' library - dri,
vdpau.... To work, it uses the separate/standalone pipe-drivers.

Even if we 'build pipe-loader twice' this won't bring us anything as
the pipe-driver(s) will still be external module. And as soon as you
start hacking around dlopen you effectively rewrite the
target-helpers.

-Emil