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). > >> 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. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
