On Fri, Oct 2, 2015 at 2:41 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 2 October 2015 at 19:02, Rob Clark <robdcl...@gmail.com> wrote: >> 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..) >> > I wouldn't say that you're dense - could be tired and/or my > explanation leaves something to be desired. Let me try it from another > angle.
probably explanations are not clear on both sides, although probably mostly my fault for being a bit new/naive to the way the build is laid out.. > If we build pipe-loader as is, it is part of the 'API' library - dri, > vdpau.... To work, it uses the separate/standalone pipe-drivers. > > Even if we 'build pipe-loader twice' this won't bring us anything as > the pipe-driver(s) will still be external module. And as soon as you > start hacking around dlopen you effectively rewrite the > target-helpers. if I'm understanding things properly, src/gallium/targets/* links directly against libpipe_loader.la currently.. what I'm proposing (I think) is we split libpipe_loader.la into libpipe_loader_static.la and libpipe_loader_dynamic.la (or, well, maybe those aren't the best names but I'll use them for now), which is what I meant by compile pipe-loader twice, and depending on whether st wants "mega" or not it pulls in either libpipe_loader_dynamic.la or libpipe_loader_static.la.. I mean, that doesn't completely get rid of the per-target 'if HAVE_GALLIUM_STATIC_TARGETS' bit which statically pulls in the individual pipe drivers via $TARGET_LIB_DEPS.. (although maybe there is even a clever way to pull those in indirectly via libpipe_loader_static.la?) BR, -R > -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
