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.kris...@gmail.com>
> > > Date: Thu Mar 14 15:32:37 2019 +0100
> > >
> > > gallium: fix autotools build of pipe_msm.la
> > >
> > > Signed-off-by: Vinson Lee <v...@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@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.ves...@rutgers.edu>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
