Interesting but somehow it helps to write all the problems and steps up again.
I fixed the issue(s) now as follows: - tried a pvbatch example (parallelSphere.py) and fixed the python install first, by setting: -DPYTHON_INCLUDE_DIR=$PYTHON_ROOT/include/python2.7 -DPYTHON_LIBRARY=$PYTHON_ROOT/lib/libpython2.7.so for CMake's FindPythonLib module (our system has several parallel installed python versions, some in system paths -.- ). - one has to set a bunch of entries in LD_LIBRARY_PATH and PYTHONPATH, that were: export LD_LIBRARY_PATH= $LD_LIBRARY_PATH:$PVHOME/lib/paraview-4.1 export LD_LIBRARY_PATH= $LD_LIBRARY_PATH:$PVHOME/lib/paraview-4.1/site-packages/paraview/ export LD_LIBRARY_PATH= $LD_LIBRARY_PATH:$PVHOME/lib/paraview-4.1/site-packages/paraview/vtk/ export LD_LIBRARY_PATH= $LD_LIBRARY_PATH:$PVHOME/lib/paraview-4.1/site-packages/vtk export PYTHONPATH= $PVHOME/lib/paraview-4.1/site-packages:$PYTHONPATH export PYTHONPATH= $PVHOME/lib/paraview-4.1/site-packages/paraview:$PYTHONPATH export PYTHONPATH= $PVHOME/lib/paraview-4.1/site-packages/paraview/vtk:$PYTHONPATH export PYTHONPATH= $PVHOME/lib/paraview-4.1/site-packages/vtk:$PYTHONPATH - realized libgl and x11 libs were still linked, e.g. in: ldd $BUILD/lib/paraview-4.1/libvtkRenderingOpenGL-pv4.1.so \ | grep -i "gl" changing the CMake flags to -DOPENGL_gl_LIBRARY:PATH= helped (with my old setting it auto-set the systems libgl.so during config). My full CMake flags are now (with the same dependencies as below): cmake \ -DCMAKE_INSTALL_PREFIX=$HOME/bin/paraview-4.1.0-1008-g5493984 \ -DPARAVIEW_BUILD_QT_GUI=OFF -DBUILD_TESTING=OFF \ -DCMAKE_BUILD_TYPE=Debug -DPARAVIEW_ENABLE_CATALYST=OFF \ -DPARAVIEW_ENABLE_PYTHON=ON \ -DPYTHON_INCLUDE_DIR=$PYTHON_ROOT/include /python2.7 \ -DPYTHON_LIBRARY=$PYTHON_ROOT/lib/libpython2.7.so \ -DPARAVIEW_USE_MPI=ON -DPARAVIEW_USE_SYSTEM_MPI4PY=ON \ -DVTK_USE_X=OFF -DOPENGL_INCLUDE_DIR=$MESA_ROOT/include \ -DOSMESA_INCLUDE_DIR=$MESA_ROOT/include \ -DVTK_OPENGL_HAS_OSMESA=ON -DOPENGL_gl_LIBRARY:PATH= \ -DOPENGL_glu_LIBRARY=$MESA_ROOT/lib/libGLU.so \ -DOSMESA_LIBRARY=$MESA_ROOT/lib/libOSMesa.so \ -DVTK_USE_OFFSCREEN=ON -DPARAVIEW_BUILD_PLUGIN_AdiosReader=ON \ -DVTK_Group_MPI=ON -DVTK_Group_Imaging=ON -DVTK_Group_Rendering=ON \ -DVTK_XDMF_USE_MPI=ON -DXDMF_BUILD_MPI=ON \ -GNinja ~/src/ParaView Finally it's one issue left that prevents me from rendering my data in Paraview itself. Paraview -> Source "Sphere" -> Filter -> "Clean to Grid" and Volume Rendering gives me a "ERROR: src/ParaView/VTK/Filters/Parallel/vtkPKdTree.cxx, line 295 vtkPKdTree (0x6022160) (process 0) NumberOfDatasets = 0, cannot determine volume bounds." (same for my xdmf/hdf5 data sets). Best regards, Axel Huebl On 05.07.2014 13:47, Huebl, Axel wrote: > Hi ParaView list, > > > I am trying to set up a offscreen rendering setup with the current > ParaView master (g5493984) and OSMesa. > > The target platform is a CPU-only cluster with several nodes, each > containing four sockels with AMD Bulldozer CPUs (64 physical cores per > node). > > I get everything up and running in parallel, connections via rc work > perfectly and I can load my data. > > But the problems start with rendering the data. Do you have any > recommendations which versions of OSMesa and llvmpipe are tested and stable? > > The recommendations in the wiki > > > http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D#OSMesa.2C_Mesa_without_graphics_hardware > > http://www.paraview.org/Wiki/ParaView/Users_Guide/Parallel_Rendering > > Look a bit outdated to me. > > > E.g. > - Mesa 9.2.5 (and newer versions) already split libgl and libglu > which versions are recommended? > - does OSMesa Gallium llvmpipe run with llvm X.Y (e.g. 3.3) ? > - what do I have to set for the DISPLAY environment with OSMesa ? > - is it necessary/forbidden to have a X11 server running in that setup > (on the server nodes)? > - I am confused if the mentioned "SOFTWARE_DEPTH_BITS=31" bug is > already fixed in mesa > - are some of my dependencies (OpenMPI, gcc, python) too new/old ? > > I configured the server side with a whole bunch of flags now: > > cmake -DCMAKE_INSTALL_PREFIX=$HOME/bin/paraview-4.1.0-1008-g5493984 \ > -DPARAVIEW_BUILD_QT_GUI=OFF -DBUILD_TESTING=OFF \ > -DCMAKE_BUILD_TYPE=Debug -DPARAVIEW_ENABLE_CATALYST=OFF \ > -DPARAVIEW_ENABLE_PYTHON=ON -DPARAVIEW_USE_MPI=ON \ > -DPARAVIEW_USE_SYSTEM_MPI4PY=ON -DVTK_USE_X=OFF \ > -DOPENGL_INCLUDE_DIR=$MESA_ROOT/include \ > -DOSMESA_INCLUDE_DIR=$MESA_ROOT/include -DVTK_OPENGL_HAS_OSMESA=ON \ > -DOPENGL_gl_LIBRARY=IS-NOTFOUND \ > -DOPENGL_glu_LIBRARY=$MESA_ROOT/lib/libGLU.so \ > -DOSMESA_LIBRARY=$MESA_ROOT/lib/libOSMesa.so -DVTK_USE_OFFSCREEN=ON \ > -DPARAVIEW_BUILD_PLUGIN_AdiosReader=ON \ > -DVTK_Group_MPI=ON -DVTK_Group_Imaging=ON -DVTK_Group_Rendering=ON \ > -DVTK_XDMF_USE_MPI=ON -DXDMF_BUILD_MPI=ON \ > -GNinja ~/src/ParaView > > and I am starting my servers with > > mpiexec -npernode 8 -n 32 `which pvserver` --use-offscreen-rendering \ > -sp=$NUM_PORT -rc -ch=$HEAD_NODE > > and used the following separately compiled dependencies: > - python 2.7.5 > - icet 2.1.1 (probably compiled again by paraview) > - gcc 4.8.2 > - OpenMPI 1.7.4 (with infiniband support) > - cmake 2.8.10 > > I tried a couple of flags for more than two weeks, three different > OSMesa versions, environment tweaks, ... but never ended up with a > stable setup (as soon as server side rendering kicks in). > > I can trigger that by loading a sphere, setting the remote/local > rendering threshold to 0MB. > > and usually end up with an error in OpenGLInit (see attached). > > > Do you have any ideas? > > > Best regards, > Axel Huebl >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview