Hello,
I recently encountered issues related to the OpenGL2 support for off-screen
Mesa. Up to at least ParaView V5.1.2, I could use ParaView/Catalyst built with
OSMesa with no specific issues (I mostly used OSMesa compiled without LLVM, as
rendering did not represent a huge portion of my compute time.
I'm using Catalyst in the context of the Code_Saturne CFD code. By default, the
code includes a plugin, linked to both ParaView or a Catalys edition (based on
the info from the cmake entry in ParaView installs when
-DPARAVIEW_INSTALL_DEVELOPMENT_FILES=ON is used). On Linux systems, the plugin
is loaded with dlopen(<plugin_so_path>, RTLD_LAZY).
We use Catalyst Python scripts, so the plugin goes through ParaView's Python
layer also to render images.
On my personal PC, running Arch Linux I have not encountered any specific issue
with recent ParaView changes and the move to OpenGL2 (actually, for on-screen
redering, the Intel graphics driver/QT5 rendering issue leading to spurious
transparencies that I had before seem to have disappeared, so things are
actually better.
On company machines (workstations and clusters using EDF's Debian 8 flavor,
with gcc version (Debian 4.9.2-10) 4.9.2, things are not working so well, as I
get an error message related to missing OpenGL features starting with ParaView
5.2 (and up to today's master).
I switched to Mesa 13.0.1, then 13.0.4, following the new instructions on the
ParaView Wiki, but I still always get the following error:
"""
ERROR: In
/home/D43345/src/paraview/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line
733
vtkOSOpenGLRenderWindow (0x808db80): GL version 2.1 with the gpu_shader4
extension is not supported by your graphics driver but is required for the new
OpenGL rendering backend. Please update your OpenGL driver. If you are using
Mesa please make sure you have version 10.6.5 or later and make sure your
driver in Mesa supports OpenGL 3.2.
GL_Version: 3.3 (Core Profile) Mesa 13.0.4.
"""
My mesa build used the following options (from the ParaView wiki) :
./configure --prefix=$HOME/opt/Mesa-13.0/arch/calibre9 --enable-opengl
--disable-gles1 --disable-gles2 --disable-va --disable-xvmc --disable-vdpau
--enable-shared-glapi --disable-texture-float --enable-gallium-llvm
--enable-llvm-shared-libs --with-gallium-drivers=swrast,swr --disable-dri
--with-dri-drivers= --disable-egl --with-egl-platforms= --disable-gbm
--disable-glx --disable-osmesa --enable-gallium-osmesa
--with-llvm-prefix=$HOME/opt/llvm-3.9/arch/calibre9
I tried both using the local llvm install (v3.5, which worked in part and could
not compile OpenSwr), and a local build of LLVM 3.9.1 (shown above). I also
added --enable-debug for my latest tests.
Things work slightly better with LLVM 3.9 than with 3.5, but I still get the
above error mentioning the gpu_shader4 extension, whether exporting
GALLIUM_DRIVER=llvmpipe or softpipe. With GALLIUM_DRIVER=swr, I have another
error:
"""
Using OpenSWR :
SWR detected AVX2
SWR library load failure:
/home/D43345/opt/Mesa-13.0/arch/calibre9/lib/libswrAVX2.so: undefined symbol:
_glapi_Context
"""
During my testing, I also built a static version of my code, with a static
build of ParaView (and the plugin replaced by a static link), but keeping the
same dynamic library for OSMesa. And surprise, that version worked normally,
producing the expected images (at least with the LLVM 3.9 build; with LLVM 3.5,
I had the color map labels, but no colored slice...).
So the issue seems to be on the ParaView side more than on the OSMesa side. I
have a debug build of the Code_Saturne/ParaView/OSMesa stack, but although I
can explore where the final error occurs (in vtkOpenGLRenderWindow.cxx), and
some GLES querying before that, I don't realy know where to look .
As the error occurs with a dynamic but not static build, is seems to be related
to initialization issues, but I don't know VTK well enough to provide more
precise info.
Has anybody encounted this issue ? Does anybody have suggestions ? I'm planning
on trying other options than RTLD_LAZY on my plugin's side, but if that does
not work, I'll be out of ideas.
Best regards,
Yvan
PS: in case they are useful as a reference, the build options for Mesa used by
Arch Linux (recently switched from 13 to 17), on the system on which I had zero
issue, are the following:
./configure --prefix=/usr \
--sysconfdir=/etc \
--with-dri-driverdir=/usr/lib/xorg/modules/dri \
--with-gallium-drivers=r300,r600,radeonsi,nouveau,svga,swrast,virgl \
--with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \
--with-egl-platforms=x11,drm,wayland \
--with-vulkan-drivers=intel,radeon \
--disable-xvmc \
--enable-gallium-llvm \
--enable-llvm-shared-libs \
--enable-shared-glapi \
--enable-libglvnd \
--enable-egl \
--enable-glx \
--enable-glx-tls \
--enable-gles1 \
--enable-gles2 \
--enable-gbm \
--enable-dri \
--enable-osmesa \
--enable-texture-float \
--enable-xa \
--enable-vdpau \
--enable-omx \
--enable-nine \
--enable-opencl \
--enable-opencl-icd \
--with-clang-libdir=/usr/lib
There is also a patch related to glapi linkage which I might try in case it
solved my glapi missing symbol issue with OpenSWR...
_______________________________________________
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
Search the list archives at: http://markmail.org/search/?q=ParaView
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
