On 1 October 2015 at 20:44, Rob Clark <robdcl...@gmail.com> wrote: > From: Rob Clark <robcl...@freedesktop.org> > > Signed-off-by: Rob Clark <robcl...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
