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

[Emil Velikov]

On 2 October 2015 at 19:59, Rob Clark <robdclark at gmail.com> wrote:
> On Fri, Oct 2, 2015 at 2:41 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> 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.
>
> probably explanations are not clear on both sides, although probably
> mostly my fault for being a bit new/naive to the way the build is laid
> out..
>
>> 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.
>
> if I'm understanding things properly, src/gallium/targets/* links
> directly against libpipe_loader.la currently..  what I'm proposing (I
> think) is we split libpipe_loader.la into libpipe_loader_static.la and
> libpipe_loader_dynamic.la (or, well, maybe those aren't the best names
> but I'll use them for now), which is what I meant by compile
> pipe-loader twice, and depending on whether st wants "mega" or not it
> pulls in either libpipe_loader_dynamic.la or
> libpipe_loader_static.la..
>
> I mean, that doesn't completely get rid of the per-target 'if
> HAVE_GALLIUM_STATIC_TARGETS' bit which statically pulls in the
> individual pipe drivers via $TARGET_LIB_DEPS..  (although maybe there
> is even a clever way to pull those in indirectly via
> libpipe_loader_static.la?)
>
I think I see what's happening here. I can bet that the
targets/pipe-loader naming has gotten you confused.

So let me try from (yet) another angle. Here is what we have today in
the default case:
DRI (static targets)
 - targets/dri, does _not_ link libpipe_loader, but libfoo.a
.- libfoo.a 'opens' the statically linked drivers/$bar.

Clover ('dynamic'/pipe-loader/pipe-driver targets)
 - targets/opencl, links against libpipe_loader.a (i.e. static)
 - libpipe_loader.a dlopens the separate/dynamic/external modules.
 - the latter are generated in targets/pipe-loader (note name should
really be pipe-drivers)

We cannot split libpipe_loader, as it only handles the 'dynamic'. If
you look at the makefile you'll see

if HAVE_GALLIUM_STATIC_TARGETS

x_SOURCES += target.c // aka libfoo.a above

else # HAVE_GALLIUM_STATIC_TARGETS

x_LIBADD += libpipe_loader.la

endif # HAVE_GALLIUM_STATIC_TARGETS


Hopefully this time things are more obvious.

-Emil