[Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5
Albina, Frank
frank.albina at sauber-motorsport.com
Thu Dec 17 11:19:52 EST 2015
Dear Utkarsh!
It's now one week since I have written my last email in this thread. I would have liked to have replied earlier, but since then ParaView 5.0.0-RC2 was made available for download and hence, I had to restart all compilations and tests from scratch. The tests I am most interested in are summarized in a few benchmarks that I can pass you if you fancy. Please liaise with me directly if you wish to do so and I might be able upload data and benchmark instructions to the server of your choice.
The benchmarks are divided in 2 categories:
1) pressure contours on a generic (and quite outdated) F1 car geometry.
2) surfaceLIC of the flow-field on the surface of the aforementioned F1 car geometry.
The expected results are shown in the enclosed pictures 1.jpg for the pressure contours and 2.jpg for the surfaceLIC representation.
In order to run ParaView v5.0.0-rc2 using the OpenGL2 backend in batch with Mesa, I had to set:
a) MESA_GL_VERSION_OVERRIDE = 3.2
b) MESA_GLSL_VERSION_OVERRIDE = 150
For my tests, I used compiled Mesa v10.6.9 and 11.0.7 which are delivering similar results in terms of performance, therefore I will focus mainly on the latest Mesa v11.0.7 release.
I have compiled 2 flavors:
1) the "classic" osmesa:
----------------------------
./configure --prefix=${installDir} --enable-texture-float --enable-osmesa --disable-egl --disable-xvmc
--disable-opencl --disable-glx --disable-dri --disable-va --enable-gallium-llvm=no --with-gnu-ld
--with-osmesa-bits=8 --disable-vdpau --enable-dependency-tracking --with-gallium-drivers=""
--with-dri-drivers="" --with-egl-platforms=""
2) the "llvm" backend:
-----------------------------
./configure --enable-texture-float --disable-egl --disable-xvmc --disable-opencl --disable-glx --disable-dri --disable-va
--enable-gallium-llvm=yes --with-gnu-ld --with-osmesa-bits=8 --disable-vdpau --enable-dependency-tracking
--with-gallium-drivers="swrast" --enable-gallium-osmesa --with-dri-drivers="" --with-egl-platforms=""
--enable-gallium-llvm --enable-llvm-shared-libs
The reason is that I tried both flavors with Mesa-10.5.5 together with Paraview v4.3.1 and found out that the "classic" flavor on the Mesa v10.5.5 release was faster by a substantial amount (up to 40%) compared to the "llvm" flavor.
For this reason, I have used Paraview v5.0.0-rc2 with both Mesa libraries, with following options to force building with an OpenGL2 backend and also support for SurfaceLIC.
cmake $sourceDir \
-DBUILD_SHARED_LIBS:BOOL=ON\
-DBUILD_TESTING:BOOL=OFF\
-DBUILD_DOCUMENTATION:BOOL=OFF\
-DCMAKE_BUILD_TYPE:STRING=Release\
-DPARAVIEW_ENABLE_CATALYST:BOOL=ON\
-DPARAVIEW_ENABLE_VTK_MODULES_AS_NEEDED:BOOL=TRUE\
-DPARAVIEW_USE_MPI:BOOL=ON\
-DPARAVIEW_USE_UNIFIED_BINDINGS:BOOL=OFF\
-DPARAVIEW_ENABLE_WEB:BOOL=OFF\
-DVTK_OPENGL_HAS_OSMESA:BOOL=ON\
-DVTK_USE_MANGLED_MESA:BOOL=OFF\
-DOPENGL_gl_LIBRARY:FILEPATH=\
-DOPENGL_glu_LIBRARY:FILEPATH=$mesaPath/mesa-11.0.7/lib/libGLU.so\
-DOPENGL_xmesa_INCLUDE_DIR:PATH==$mesaPath/mesa-11.0.7/include\
-DOSMESA_LIBRARY:PATH= $mesaPath/mesa-11.0.7/lib/libOSMesa.so\
-DOSMESA_INCLUDE_PATH:PATH=$mesaPath/generic/mesa-11.0.7/include\
-DPARAVIEW_BUILD_PLUGIN_SurfaceLIC:BOOL=ON\
-DPARAVIEW_ENABLE_VTK_MODULES_AS_NEEDED:BOOL=TRUE\
-DPARAVIEW_USE_MPI:BOOL=ON\
-DVTK_USE_OFFSCREEN:BOOL=ON\
-DVTK_USE_X:BOOL=OFF\
-DVTK_USE_QT=OFF\
-DVTK_USE_DISPLAY=ON\
-DVTK_USE_GUI_SUPPORT:BOOL=OFF\
-DPARAVIEW_BUILD_QT_GUI:BOOL=OFF\
-DCMAKE_INSTALL_PREFIX:PATH=$installDir\
-DPARAVIEW_ENABLE_PYTHON:BOOL=ON\
-DPYTHON_ENABLE_MODULE_MPIPython:BOOL=ON\
-DMAKE_CXX_COMPILER:FILEPATH=$gccPath/bin/g++\
-DCMAKE_C_COMPILER:FILEPATH=$gccPath/bin/gcc\
-DCMAKE_Fortran_COMPILER:FILEPATH=$gccPath/bin/gfortran\
-DMPI_COMPILER:FILEPATH=$MPI_HOME/bin/mpicxx\
-DMPI_INCLUDE_PATH:FILEPATH=$MPI_HOME/include\
-DMPI_Fortran_COMPILER:FILEPATH=$MPI_HOME/bin/mpif90\
-DMPI_Fortran_LIBRARIES:FILEPATH=$MPI_HOME/lib/libmpifort.so\
-DMPI_Fortran_INCLUDE_PATH:FILEPATH=$MPI_HOME/include\
-DMPI_LIBRARY:FILEPATH=$MPI_HOME/lib/libmpi.so\
-DMPI_C_LIBRARIES:FILEPATH=$MPI_HOME/lib/libmpi.so\
-DMPI_CXX_LIBRARIES:FILEPATH=$MPI_HOME/lib/libmpicxx.so\
-DPYTHON_LIBRARY:FILEPATH=$PYTHON_HOME/lib/libpython2.7.so\
-DPYTHON_INCLUDE_DIR:PATH=$PYTHON_HOME/include/python2.7\
-DPYTHON_EXECUTABLE:FILEPATH=$PYTHON_HOME/bin/python2.7\
-DVTK_RENDERING_BACKEND:STRING=OpenGL2\
-DModule_vtkRenderingLICOpenGL2:BOOL=ON\
Here is a summary of the tests I have performed for the different benchmarks:
1) Pressure contour benchmark
a) Rendering time with the "classic" mesa flavor is much slower that the "llvmpipe" flavor. There is a factor of 3 difference on 1 core, a factor of 6 on 2 cores.
The generated images using 1 core are as if lighting went missing (see 3.jpg). In batch and in parallel, when more than one core is involved, it looks like only the bits owned by the master process are displayed (see attached filed 4.jpg).
b) Images rendered using the "llvmpipe" flavor are generated correctly.
2) surfaceLIC benchmark
Not used using the "classic" mesa flavor, only with the "llvmpipe". I am getting an odd behavior where the benchmark hangs randomly in parallel. Restarting the parallel process by hand usually works but I can get corrupted images.
Also, when using more than one core in parallel, one can see clearly which part of the image is processed by which core (see file 5.jpg). This is something I did not recall seeing using PV versions from 4.1 to 4.3.
I am wondering if this is an expected behavior?
Finally, I have tried compile openswr-mesa-11.0 on my compute platform. After resolving all kind of dependencies, I could not get the libOSMESA.so compiled using swr as driver. Here are my compilation options:
./configure --enable-gallium-osmesa --enable-dependency-tracking --enable-gallium-llvm=yes
--enable-llvm-shared-libs --enable-swr-native --enable-sysfs --enable-texture-float
--disable-dri --disable-egl --disable-glx --disable-gles1 --disable-gles2 --disable-opencl
--disable-vdpau --disable-va --disable-xvmc --with-dri-drivers="" --with-egl-platforms=""
--with-gallium-drivers="swr,swrast" --with-gnu-ld
--with-osmesa-bits=8 --with-swr-arch="CORE_AVX2"
And the compilation finally fails because of unresolved references in the llvm library (v3.7.0):
../../../../src/gallium/drivers/swr/.libs/libmesaswr.a(builder_gen.o):(.data.rel.ro._ZTIN4llvm15InsertValueInstE[_ZTIN4llvm15InsertValueInstE]+0x10): undefined reference to `typeinfo for llvm::Instruction'
../../../../src/gallium/drivers/swr/.libs/libmesaswr.a(builder_gen.o):(.data.rel.ro._ZTIN4llvm17GetElementPtrInstE[_ZTIN4llvm17GetElementPtrInstE]+0x10): undefined reference to `typeinfo for llvm::Instruction'
../../../../src/gallium/drivers/swr/.libs/libmesaswr.a(builder_gen.o):(.data.rel.ro._ZTIN4llvm8ICmpInstE[_ZTIN4llvm8ICmpInstE]+0x10): undefined reference to `typeinfo for llvm::CmpInst'
../../../../src/gallium/drivers/swr/.libs/libmesaswr.a(builder_gen.o):(.data.rel.ro._ZTIN4llvm8FCmpInstE[_ZTIN4llvm8FCmpInstE]+0x10): undefined reference to `typeinfo for llvm::CmpInst'
../../../../src/gallium/drivers/swr/.libs/libmesaswr.a(builder_gen.o):(.data.rel.ro._ZTIN4llvm7PHINodeE[_ZTIN4llvm7PHINodeE]+0x10): undefined reference to `typeinfo for llvm::Instruction'
../../../../src/gallium/drivers/swr/.libs/libmesaswr.a(builder_gen.o):(.data.rel.ro._ZTIN4llvm10SelectInstE[_ZTIN4llvm10SelectInstE]+0x10): undefined reference to `typeinfo for llvm::Instruction'
../../../../src/gallium/drivers/swr/.libs/libmesaswr.a(builder_gen.o):(.data.rel.ro._ZTIN4llvm9VAArgInstE[_ZTIN4llvm9VAArgInstE]+0x10): undefined reference to `typeinfo for llvm::UnaryInstruction'
../../../../src/gallium/drivers/swr/.libs/libmesaswr.a(builder_gen.o):(.data.rel.ro._ZTIN4llvm16ExtractValueInstE[_ZTIN4llvm16ExtractValueInstE]+0x10): undefined reference to `typeinfo for llvm::UnaryInstruction'
collect2: error: ld returned 1 exit status
As far as I understood, openSWR is meant as a replacement for the libGL.so library, so I am wondering if my intents are doomed to failure because it is not meant to be used as a replacement for libOSMESA.so? Any hints would be much appreciated.
Anyway, I am already happy that the new ParaView release is already a good chunk faster the 4.x series and I can' t wait to have to test the final released version.
Any comments welcome.
Cheers,
Frank.
-----Original Message-----
From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com]
Sent: Donnerstag, 10. Dezember 2015 18:19
To: Albina, Frank
Cc: paraview at paraview.org
Subject: Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5
> ./configure --enable-64-bit --enable-texture-float --enable-osmesa
> --disable-egl --disable-xorg --disable-xvmc --disable-opencl
> --disable-glx --disable-dri --disable-va --disable-shared-glapi
> --enable-gallium-llvm=no --with-gnu-ld --with-osmesa-bits=8
> --disable-vdpau --enable-dependency-tracking --with-gallium-drivers=”” --with-dri-drivers=””
> --with-egl-platforms=””
Frank,
One thing I noticed is that you're not using LLVM. Using the new rendering backend without LLVM is not recommended at all. It will be painfully slow since the new rendering backend no longer uses fixed pipeline and it has to process GLSL code. You should stick with llvmpipe. I used the following for OSMesa build with Mesa 11.0.4. Hope that helps. You still need the MESA_GL_VERSION_OVERRIDE flag that Aashish mentioned.
./configure --disable-xvmc --disable-glx --disable-dri --with-dri-drivers= --with-gallium-drivers=swrast --enable-texture-float --disable-egl --with-egl-platforms= --enable-gallium-osmesa --enable-gallium-llvm=yes --prefix=/opt/apps/mesa-11.0.4/llvm-osmesa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.jpg
Type: image/jpeg
Size: 181445 bytes
Desc: 1.jpg
URL: <http://public.kitware.com/pipermail/paraview/attachments/20151217/4d0a7ae4/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.jpg
Type: image/jpeg
Size: 185539 bytes
Desc: 2.jpg
URL: <http://public.kitware.com/pipermail/paraview/attachments/20151217/4d0a7ae4/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3.jpg
Type: image/jpeg
Size: 153915 bytes
Desc: 3.jpg
URL: <http://public.kitware.com/pipermail/paraview/attachments/20151217/4d0a7ae4/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.jpg
Type: image/jpeg
Size: 66416 bytes
Desc: 4.jpg
URL: <http://public.kitware.com/pipermail/paraview/attachments/20151217/4d0a7ae4/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5.jpg
Type: image/jpeg
Size: 197494 bytes
Desc: 5.jpg
URL: <http://public.kitware.com/pipermail/paraview/attachments/20151217/4d0a7ae4/attachment-0009.jpg>
More information about the ParaView
mailing list