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

[Rob Clark]

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


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

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

BR,
-R

> Cheers,
> Emil