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