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

[Rob Clark]

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?)

BR,
-R

> -Emil