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

[Rob Clark]

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

>>
>>> The idea that I have in mind is roughly as:
>>> 1) abstract most of the 'target-helpers' as 'static' pipe-loader,
>>> providing pipe-loader like interface.
>>> 2) drop the ifdefs in the former, add dummy
>>> nouveau_drm_screen_create&co implementations.
>>> 3) remove all the ifdefs in the state-trackers.
>>> 4) add a configure switch that allows one to toggle/choose which how
>>> the modules will be build. default to 'mega' (static).
>>
>> hmm, that sounds harder than just building it twice..
>>
> Indeed it's quite hairy, so if you can come with a better idea I'm all ears.
>
>>> If you want to hack on that be my guest, but be aware that the
>>> pipe-loader interface has some non-obvious fd ownership patterns ;-)
>>>
>>> Atm, I'm having fun with drm_gralloc and mesa. Expect patches on that
>>> one later on today/tomorrow.
>>
>> finally moving drm_gralloc into mesa?  That would be helpful, I think
>> that should happen before we try to cleanup and merge the dmabuf
>> parts..
>>
> Yea... that one is rather fun, as I would like to preserve as much of
> the history as possible, while avoiding commits from people named
> "Somebody" and alike. I think I got it, will need to see how fast my
> laptop is going to build it.

cool!

BR,
-R

> Thanks
> Emil