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

[Emil Velikov]

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

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

Thanks
Emil