On Fri, Mar 24, 2017 at 3:50 PM, Andy Furniss <adf.li...@gmail.com> wrote: > Marek Olšák wrote: >> >> On Fri, Mar 24, 2017 at 12:24 PM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> >>> On 24 March 2017 at 11:02, Nicolai Hähnle <nhaeh...@gmail.com> wrote: >>>> >>>> On 24.03.2017 01:00, Marek Olšák wrote: >>>>> >>>>> >>>>> From: Marek Olšák <marek.ol...@amd.com> >>>>> >>>>> This should fix this radeonsi error: >>>>> "mesa: for the -simplifycfg-sink-common option: may only occur zero >>>>> or >>>>> one >>>>> times!" >>> >>> Can we have some commit message. Feel free to reuse the following: >>> >>> Earlier commit added a LLVM 4.0 workaround by passing >>> -simplifycfg-sink-common=false to LLVM. >>> When using multiple drivers, for example GL/dri and VAAPI, we may end >>> up with the option being parsed multiple times. >>> Hence we'll see errors like >>> >>> "mesa: for the -simplifycfg-sink-common option: may only occur zero or >>> one >>> times!" >>> >>> Workaround this by exporting the driver entry point. This will lead to >>> the function being called once. >>> >>> Fixes: 7751ed39e40 ("radeonsi: disable sinking common instructions >>> down to the end block") >>> >>>>> --- >>>>> src/gallium/targets/va/va.sym | 2 ++ >>>>> 1 file changed, 2 insertions(+) >>>>> >>>>> diff --git a/src/gallium/targets/va/va.sym >>>>> b/src/gallium/targets/va/va.sym >>>>> index c925b2e..b19bc36 100644 >>>>> --- a/src/gallium/targets/va/va.sym >>>>> +++ b/src/gallium/targets/va/va.sym >>>>> @@ -1,6 +1,8 @@ >>>>> { >>>>> global: >>>>> __vaDriverInit_*_*; >>>>> + radeon_drm_winsys_create; >>>>> + amdgpu_winsys_create; >>> >>> >>> Please add a reference to the si_shader_tgsi_setup.c and vice-versa. >>> Otherwise we will end up removing one but not the other. >> >> >> It's actually not a workaround. It's a fix of va.sym that happens to >> fix that bug and it would be the correct thing to do even if there was >> no issue. Thus, I think a reference to si_shader_tgsi_setup is >> unnecessary. I'm not fixing the bug here. I'm just enforcing one >> screen+winsys per device per process like we already do between GL and >> VDPAU. >> >>> >>>> >>>> >>>> Oof, that's ugly, but at least it's only a change to va and the chance >>>> of >>>> collision is low. Have you verified that it fixes the bug? >> >> >> I've not verified that, no. If it doesn't fix the bug, we still need >> this patch because of aforementioned reasons, and then we have to fix >> the bug. > > > It fixes mpv for me testing vaapi hw decode + gl display. > > It doesn't fix ffmpeg cli though. > > ffmpeg -hwaccel vaapi -i testfile -f null - > > still gets the message.
Thanks for testing. I wonder what other Mesa libs ffmpeg loads that are missing the exported symbols. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev