[Mesa-dev] [PATCH] pipe-loader: abstract GALLIUM_STATIC_TARGETS behind pipe_loader API
emil.l.velikov at gmail.com
Fri Oct 2 11:41:59 PDT 2015
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?
>>> 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
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
More information about the mesa-dev