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

[Emil Velikov]

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

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

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.

Cheers,
Emil