[Mesa-dev] Commit 'gallium: fix autotools build of pipe_msm.la' broke Clover - bisected
Jan Vesely
jan.vesely at rutgers.edu
Tue Apr 2 07:28:09 UTC 2019
On Tue, 2019-04-02 at 02:37 +0200, Dieter Nützel wrote:
> Am 01.04.2019 07:43, schrieb Jan Vesely:
> > Hi,
> >
> > On Mon, 2019-04-01 at 06:24 +0200, Dieter Nützel wrote:
> > > Hello,
> > >
> > > commit #356ec7a2196 'gallium: fix autotools build of pipe_msm.la'
> > > broke
> > > Clover.
> > >
> > > biseted:
> > > 356ec7a21960d77db282f67af577dcdb46966b5a is the first bad commit
> > > commit 356ec7a21960d77db282f67af577dcdb46966b5a
> > > Author: Timur Kristóf <timur.kristof at gmail.com>
> > > Date: Thu Mar 14 15:32:37 2019 +0100
> > >
> > > gallium: fix autotools build of pipe_msm.la
> > >
> > > Signed-off-by: Vinson Lee <vlee at freedesktop.org>
> > > Fixes: 9a834447d652 ("tgsi_to_nir: Produce optimized NIR for a
> > > given
> > > pipe_screen.")
> > > Bugzilla: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D109929&data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ca161a421657d40f6011908d6b70370c0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C636897622770137680&sdata=QJFTMLeoBK4TjYtc34RHvrJ7NeloOORard6nQ5eBQVQ%3D&reserved=0
> > >
> > > :040000 040000 601ddeba6f98a1872a8f49667c89224601afe31b
> > > cee6467ed172beb890455d0874a2e883e6c95e14 M src
> > >
> > > Reverting it bring Clover back.
> >
> > I'm guessing you use autotools to build clover?
> > My digging shows that the culprit is
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F225&data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ca161a421657d40f6011908d6b70370c0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C636897622770137680&sdata=1g%2B7aR%2FuaegKvF7fpvErlzP113xy8nsSKs4z5oudh3k%3D&reserved=0 which
> > makes users of gallium/axuiliary pull in libglsl.
> > 356ec7a21 tries to fix it by adding libglsl to pipe_loader, thus
> > making pipe drivers require glsl symbols and breaking every state
> > tracker that does not provide them. I'd expect omx and vdpau state
> > trackers would fail in similar manner.
>
> I didn't use omx (do not compile, but can try), but vdpau works with
> 'meson build'.
>
> > > The most annoying thing for me is, that even 'meson build' of Clover
> > > do
> > > NOT work for me (hello Dylan? ;-)):
> > >
> > > ../src/gallium/state_trackers/clover/api/event.cpp: In function
> > > ‘cl_int
> > > clGetEventProfilingInfo(cl_event, cl_profiling_info, size_t, void*,
> > > size_t*)’:
> > > ../src/gallium/state_trackers/clover/api/event.cpp:256:58: error:
> > > ‘dynamic_cast’ not permitted with -fno-rtti
> > > hard_event &hev = dynamic_cast<hard_event &>(obj(d_ev));
> > > ^
> > > ../src/gallium/state_trackers/clover/api/event.cpp:287:23: warning:
> > > ignoring attributes on template argument ‘cl_ulong’ {aka ‘long
> > > unsigned
> > > int’} [-Wignored-attributes]
> > > } catch (lazy<cl_ulong>::undefined_error &e) {
> > > ^
> > > In file included from
> > > ../src/gallium/state_trackers/clover/core/event.hpp:29,
> > > from
> > > ../src/gallium/state_trackers/clover/api/event.cpp:24:
> > > ../src/gallium/state_trackers/clover/core/object.hpp: In instantiation
> > > of ‘static void clover::detail::descriptor_traits<T, D>::validate(D*)
> > > [with T = clover::soft_event; D = _cl_event]’:
> > > ../src/gallium/state_trackers/clover/core/object.hpp:148:48:
> > > required
> > > from ‘typename clover::detail::descriptor_traits<T, D>::object_type&
> > > clover::obj(D*) [with T = clover::soft_event; D = _cl_event; typename
> > > clover::detail::descriptor_traits<T, D>::object_type =
> > > clover::soft_event]’
> > > ../src/gallium/state_trackers/clover/api/event.cpp:42:36: required
> > > from here
> > > ../src/gallium/state_trackers/clover/core/object.hpp:72:18: error:
> > > ‘dynamic_cast’ not permitted with -fno-rtti
> > > !dynamic_cast<object_type *>(o))
> > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > This looks like the -fno-rtti flags got there from 'llvm-config --
> > cxxflags'.
>
> Yes.
>
> /home/dieter> llvm-config --cxxflags
> -I/usr/local/include -std=c++11 -fno-exceptions -fno-rtti
> -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
> -D__STDC_LIMIT_MACROS
>
> > Clover makes use of rtti(as you've found out), and I'd say
> > that you need it in LLVM too.
> > Mixing Clover/rtti and llvm/no-rtti
> > would probably complain about missing symbols in llvm libraries.
>
> But why is this?
> My 'autotools' Mesa/Clover compilations worked for ages with my current
> LLVM settings.
It might be OK to just filter out the -fno-rtti flag. If the llvm's
rtti information is not used, it should work.
I honestly don't know what determines whether llvm's rtti info is used
or not. It might be ifdef/assert or anything else in the headers which
would get interpreted differently when building llvm vs. mesa.
I remember quite a lot of discussion about llvm-config not reporting
the flag correctly, and issues with rtti/no-rtti combination, at which
point I switched my llvm builds to rtti and never looked back.
It's interesting that you don't see the issue with autotools,
'strip_unwanted_llvm_flags' takes care to preserve the -fno-rtti flag.
Jan
>
> cmake -DLLVM_TARGETS_TO_BUILD="X86;AMDGPU" -DLLVM_APPEND_VC_REV=OFF
> -DCMAKE_BUILD_TYPE="Release" -DLLVM_LINK_LLVM_DYLIB=ON
> -DLLVM_PARALLEL_COMPILE_JOBS="9" ../
>
> My Mesa autotools settings:
> ./autogen.sh --prefix=/usr/local --with-dri-drivers=""
> --with-platforms=drm,x11 --with-gallium-drivers=r600,radeonsi,swrast
> --with-vulkan-drivers=radeon --enable-nine --enable-opencl
> --disable-opencl_icd --enable-libglvnd --enable-autotools
>
> And Clover worked, too:
>
> Number of platforms 1
> Platform Name Clover
> Platform Vendor Mesa
> Platform Version OpenCL 1.1 Mesa
> 19.1.0-devel (git-ebe05b8148)
> Platform Profile FULL_PROFILE
> Platform Extensions cl_khr_icd
> Platform Extensions function suffix MESA
>
> Platform Name Clover
> Number of devices 1
> Device Name Radeon RX 580 Series
> (POLARIS10, DRM 3.27.0, 5.0.5-1.g0fb0b14-default, LLVM 9.0.0)
> Device Vendor AMD
> Device Vendor ID 0x1002
> Device Version OpenCL 1.1 Mesa
> 19.1.0-devel (git-ebe05b8148)
> Driver Version 19.1.0-devel
> Device OpenCL C Version OpenCL C 1.1
> Device Type GPU
> Device Profile FULL_PROFILE
> Device Available Yes
> Compiler Available Yes
> Max compute units 36
> Max clock frequency 1411MHz
> [snip]
>
> /opt/opencl-example> ./run_tests.sh
> Running ./math-int add 1 2 3
> Passed
>
> [snip]
>
> Running ./vec-load
> Passed
> 71 passes, 0 fails
>
> But I would run with meson (must in the future)...;-)))
>
> It is 3 times faster on my 4/8 Xeon X3470.
> GREAT work Dylan!
> But I'm learning 'meson'...
>
> Dieter
>
> > > meson config:
> > > meson ../ --strip --buildtype debugoptimized -Ddri-drivers=
> > > -Dplatforms=drm,x11 -Dgallium-drivers=r600,radeonsi,swrast
> > > -Dvulkan-drivers=amd -Dgallium-nine=true -Dgallium-opencl=icd
> > > -Dglvnd=true -Dgallium-va=false -Dgallium-xvmc=false
> > > -Dgallium-omx=disabled -Dgallium-xa=false
> > >
> > > Only -Dgallium-opencl=disabled works.
> > >
> > > Thanks,
> > > Dieter
> > > _______________________________________________
> > > mesa-dev mailing list
> > > mesa-dev at lists.freedesktop.org
> > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ca161a421657d40f6011908d6b70370c0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C636897622770137680&sdata=HKTgTnd4tKx75vP1ijG6eO8BgJkQab6mnZxU3SFkZWI%3D&reserved=0
--
Jan Vesely <jan.vesely at rutgers.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190402/44f4ecfb/attachment-0001.sig>
More information about the mesa-dev
mailing list