SWR triggers an assertion failure when rendering with OSMesa in the current Meson build. This did not happen previously with the autotools build. Steps to reproduce: 1. Build with meson using -Dosmesa=gallium -Dgallium-drivers=swrast,swr 2. Use the ParaView OSMesa prebuilt binaries for 5.6.0 from https://www.paraview.org/download/ 3. Run the benchmark with llvmpipe (success): GALLIUM_DRIVER=llvmpipe LD_LIBRARY_PATH=/home/khq.kitware.com/chuck.atkins/Code/mesa/install/master/lib64:$LD_LIBRARY_PATH ../ParaView-5.6.0-osmesa-MPI-Linux-64bit/bin/pvpython ../ParaView-5.6.0-osmesa-MPI-Linux-64bit/lib/python2.7/site-packages/paraview/benchmark/manyspheres.py Generating bounding box Generating all spheres Assigning colors source 0: generating 100 spheres from 0 to 100 Repositioning initial camera Rendering first frame Saving frame 0 screenshot Gathering geometry counts Beginning benchmark loop ... Frames / Sec: 49.29 Polys / Frame: 1612 MiPolys / Sec: 0.076 Points / Frame: 1008 4. Run the benchmark with swr (fail): GALLIUM_DRIVER=swr LD_LIBRARY_PATH=/path/to/mesa/install/lib64:$LD_LIBRARY_PATH /path/to/ParaView-5.6.0-osmesa-MPI-Linux-64bit/bin/pvpython /path/to/ParaView-5.6.0-osmesa-MPI-Linux-64bit/lib/python2.7/site-packages/paraview/benchmark/manyspheres.py Generating bounding box Generating all spheres Assigning colors source 0: generating 100 spheres from 0 to 100 Repositioning initial camera Rendering first frame SWR detected AVX2 instruction support (using: libswrAVX2.so). ../../source/master/src/gallium/drivers/swr/rasterizer/core/ringbuffer.h(45): ASSERT: ((1ULL << 32) % numEntries) == 0 Init 400 is not evenly divisible into 2 ^ 32. Wrap errors will occur! Trace/breakpoint trap (core dumped) Note that the same test works correctly for both llvm pipe and SWR wnen using the gallium-xlib GLX implementation. This only fails for swr and OSMesa
Hi Chuck, thanks for reporting this bug. I've tried to reproduce it with master top mesa but without success (works fine). What is exact version of mesa you've build? And one comment to autotools->meson change. With autotools default build mode was without asserts. With meson default buildtype is debugoptimized. To have the same buildtype as it was in autotools please add --buildtype=release parameter to meson.
(In reply to Krzysztof Raszkowski from comment #1) > And one comment to autotools->meson change. With autotools default build > mode was without asserts. With meson default buildtype is debugoptimized. > To have the same buildtype as it was in autotools please add > --buildtype=release parameter to meson. I believe the point of this bug report is to fix the bug, not to silence the assert() reporting it ;) Either the assert is correct and there's a bug that needs to be fixed, or the assert is wrong and it needs to be fixed.
(In reply to Eric Engestrom from comment #2) > (In reply to Krzysztof Raszkowski from comment #1) > > And one comment to autotools->meson change. With autotools default build > > mode was without asserts. With meson default buildtype is debugoptimized. > > To have the same buildtype as it was in autotools please add > > --buildtype=release parameter to meson. > > I believe the point of this bug report is to fix the bug, not to silence the > assert() reporting it ;) > > Either the assert is correct and there's a bug that needs to be fixed, or > the assert is wrong and it needs to be fixed. You're absolutely right. That's why I'm asking about exact version of mesa. Second part of my response is only explanation about the difference between autotools and meson.
> Comment # 1 on bug 110716 from Krzysztof Raszkowski > I've tried to reproduce it with master top mesa but without success (works > fine). What is exact version of mesa you've build? master as of this afternoon, 810b95e, > And one comment to autotools->meson change. With autotools default build mode > was without asserts. With meson default buildtype is debugoptimized. > To have the same buildtype as it was in autotools please add > --buildtype=release parameter to meson. The full configuration I'm using, basically trying to build bare-bones GLX and OSMesa libraries that only contain software OpenGL renderers: meson --buildtype=release -Dprefix=/path/to/install/master -Dglvnd=false -Dgallium-nine=false -Dgallium-omx=disabled -Dgallium-opencl=disabled -Dgallium-va=false -Dgallium-vdpau=false -Dgallium-xa=false -Dgallium-xvmc=false -Dvulkan-drivers= -Dosmesa=gallium -Dglx=gallium-xlib -Degl=false -Dgbm=false -Dopengl=true -Dgles1=false -Dgles2=false -Dshared-glapi=true -Dllvm=true -Dswr-arches=avx2 -Dplatforms=x11,surfaceless -Dgallium-drivers=swrast,swr -Ddri-drivers= /path/to/source/master If I do a release build to silence the assert then I get a segfault. Note that release or debug, swr works with glx via libGL.so and segfaults when using libOSMesa.so
Chuck, I've noticed that libOSMesa is distributed in two places (I use ParaView-5.6.0-osmesa-MPI-Linux-64bit.tar.gz): - ParaView-5.6.0-osmesa-MPI-Linux-64bit/lib/libOSMesa.so - ParaView-5.6.0-osmesa-MPI-Linux-64bit/lib/mesa/libOSMesa.so What I see after adding to LD_LIBRARY_PATH my mesa build libraries Paraview always load this "ParaView-5.6.0-osmesa-MPI-Linux-64bit/lib/libOSMesa.so" instead of what I've build (without removing it I've also had some weird errors). Could you verify that this test load libraries you think it should load? You can do it using strace command: strace bin/pvpython /root/ParaView-5.6.0-osmesa-MPI-Linux-64bit/lib/python2.7/site-packages/paraview/benchmark/manyspheres.py &> strace.out Then cat strace.out | grep open | grep libOSMesa and cat strace.out | grep open | grep libswr Thanks, Krzysztof
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/205.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.