On Fri, Oct 2, 2015 at 1:46 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 2 October 2015 at 17:11, Rob Clark <robdcl...@gmail.com> wrote: >> 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? >> > 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).
I could be being dense, but why wouldn't that work properly if we built pipe-loader twice? Ie. the non-GALLIUM_STATIC_TARGETS build should be built with the right CFLAGS so the code path that tries to open pipe_foo.so ends up in the binary (I do wonder a bit why the search-path gets passed in externally from pipe-loader, since all the state trackers using the non-GALLIUM_STATIC_TARGETS would presumably want to look in the same place for pipe_foo.so, but maybe that is a separate clean-up..) >> >>> 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. cool! BR, -R > Thanks > Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
