On Fri, Oct 2, 2015 at 11:49 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > 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).
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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
