Hello,
I made further progress on this old thread, so am answering myself to close
this issue...
With recent versions of OSMesa (17.2 or 17.8), I observed that using LD_PRELOAD
with OSMesa.so.8 also avoided the incorrect initialization issue of OSMesa
leading to Catalyst complaining aboit OpenGL2 features not being available.
On an Arch Linux system, I had also reproduced the reported issue at one time,
but do not reproduce it anymore with Mesa 17.3.
On a Debian 8 based system, I still reproduce it, but running new tests,
instead of LD_PRELOAD, using RTLD_LAZY | RTLD_GLOBAL as dlopen flags solves the
issue (either RTLD_LAZY or RTLD_NOW work with RTLD_GLOBAL, none work wth
RTLD_LOCAL). I am pretty sure I had run similar tests a few month ago with
older versions, with less success.
I assume the improvements come from Mesa updates, though as the behavior of
dlopen is concerned, it might also be due to lower level patches.
In any case, I started building a small test case to reproduce this, but it was
not working yet (trying to get the
correct libraries to link in a minimal setting, or other options correct while
not being familiar with CMake), so as I have a good work, I guess I'll leave it
there and hope the issue does not resurfaces.
Best regards,
Yvan
----- Mail original -----
De: "Yvan Fournier" <yvan.fourn...@free.fr>
À: paraview@paraview.org
Envoyé: Jeudi 25 Mai 2017 02:18:04
Objet: Re: [Paraview] Catalyst dlopen issues with OpenGL2 support for
off-screen Mesa
Hello,
I reproduced the issue described 2 months ago relative to detection of OSMesa
OpenGL2 support using dynamically loaded shared libraries on another machine.
I had reproduced this issue on Debian-9 based systems, but not with the
preconfigured Mesa/OSMesa from Arch Linux. Recently, I had other issues with the
packaged library on Arch (Mesa 17.1.0, including both off-screen and on-screen
drivers), as glGetString and a few other symbols were not found.
So I recompiled Mesa for off-screen mode, using the recommendations from the
ParaView Wiki (with the packaged LLVM 4.0), and encounter the following error
again when starting Catalyst:
--------------------------------
ERROR: In
/home/yvan/src/ParaView/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line
831
vtkOSOpenGLRenderWindow (0x72e3c00): GL version 2.1 with the gpu_shader4
extension is not supported by your graphics driver but is required fo
r 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.
--------------------------------
Trying to force usage of OpenSWR (using "export GALLIUM_DRIVER=swr") I have
another error:
--------------------------------
SWR detected AVX2
SWR library load failure: /home/yvan/opt/osmesa/lib/libswrAVX2.so: undefined
symbol: _glapi_tls_Dispatch
--------------------------------
So this seems quite reproducible on various systems, and both with LLVM 3.9 or
LLVM 4, Mesa 13 or 17.
When linking ParaView (Catalyst) normally (rather than linking them with a
smaller module loaded as a plugin with dlopen), both the default LLVMpipe and
OpenSwr errors dissapear, and things work fine
Does anybody have an idea what I may be missing when loading with dlopen ?
Best regards,
Yvan
From: Yvan Fournier <yvan.fourn...@free.fr>
To: paraview@paraview.org
Objet: Re: [Paraview] Issues with OpenGL2 support for off-screen Mesa
Date: Sat, 11 Mar 2017 00:36:00 +0100
> Hello,
>
> I made some progress using OpenGL2 for offs-screen Mesa on a Debian 8-based
> system:
>
> I don't need to compile my code or ParaView in static: compiling everything
> with
> dyanmic libraries works, as long as I link everything together instead of
> loading a plugin (consisting of some Code_Saturne libraries, ParaView
> Libraries,
> and OSMesa/Gallium).
>
> So it seems some things re not initialized correctly when I load ParaView and
> OSMesa as a plugin, so I'm not took sure the problem comes from ParaView,
> OSMesa, or LLVM. I tried OSMesa 13.0.3 and 17.0.1, and LLVM 3.5 (packaged with
> Debian 8) and 3.9 (local build), with identical results.
>
> I also tried using RTLD_NOW and even RTLD_NOW | RTLD_GLOBAL instead of the
> usual
> RTLD_LAZY when using dlopen, with no difference in behavior (I have not tried
> RTLD_DEEPBIND).
>
> Has anyone encountered similar issues or does anyone have an idea what could
> be
> missing in the initialization stage using dlopen for a plugin linked with
> Catalyst ? I do not encounter this issue on an Arch-Linux-based system, but
> encounter it on a Debian 8 ("Jessie") system ?
>
> Using a plugin is not an absolute must, but it would be preferable if I
> managed
> to get it working again with that build option.
>
> Best regards,
>
> Yvan
>
>
> Friday Feb 24 février 2017 at 18:25 +0100, yvan.fourn...@free.fr wrote:
>
> > Hi Chuck,
> >
> > here is what I have in /home/D43345/opt/Mesa-13.0/arch/calibre9/lib:
> >
> > -rwxr-xr-x 1 D43345 rdusers 1098 Feb 22 15:24 libOSMesa.la
> > lrwxrwxrwx 1 D43345 rdusers 18 Feb 22 15:24 libOSMesa.so ->
> > libOSMesa.so.8.0.0
> > lrwxrwxrwx 1 D43345 rdusers 18 Feb 22 15:24 libOSMesa.so.8 ->
> > libOSMesa.so.8.0.0
> > -rwxr-xr-x 1 D43345 rdusers 47309888 Feb 22 15:24 libOSMesa.so.8.0.0
> > -rwxr-xr-x 1 D43345 rdusers 962 Feb 22 15:24 libglapi.la
> > lrwxrwxrwx 1 D43345 rdusers 17 Feb 22 15:24 libglapi.so ->
> > libglapi.so.0.0.0
> > lrwxrwxrwx 1 D43345 rdusers 17 Feb 22 15:24 libglapi.so.0 ->
> > libglapi.so.0.0.0
> > -rwxr-xr-x 1 D43345 rdusers 1400520 Feb 22 15:24 libglapi.so.0.0.0
> > -rwxr-xr-x 1 D43345 rdusers 1018 Feb 22 15:24 libswrAVX.la
> > lrwxrwxrwx 1 D43345 rdusers 18 Feb 22 15:24 libswrAVX.so ->
> > libswrAVX.so.0.0.0
> > lrwxrwxrwx 1 D43345 rdusers 18 Feb 22 15:24 libswrAVX.so.0 ->
> > libswrAVX.so.0.0.0
> > -rwxr-xr-x 1 D43345 rdusers 97879312 Feb 22 15:24 libswrAVX.so.0.0.0
> > -rwxr-xr-x 1 D43345 rdusers 1024 Feb 22 15:24 libswrAVX2.la
> > lrwxrwxrwx 1 D43345 rdusers 19 Feb 22 15:24 libswrAVX2.so ->
> > libswrAVX2.so.0.0.0
> > lrwxrwxrwx 1 D43345 rdusers 19 Feb 22 15:24 libswrAVX2.so.0 ->
> > libswrAVX2.so.0.0.0
> > -rwxr-xr-x 1 D43345 rdusers 96655416 Feb 22 15:24 libswrAVX2.so.0.0.0
> > drwxr-xr-x 2 D43345 rdusers 4096 Feb 22 15:24 pkgconfig
> >
> >
> > And here is the summary after configuration of Mesa:
> >
> > prefix: /home/D43345/opt/Mesa-13.0/arch/calibre9
> > exec_prefix: ${prefix}
> > libdir: ${exec_prefix}/lib
> > includedir: ${prefix}/include
> >
> > OpenGL: yes (ES1: no ES2: no)
> >
> > OSMesa: libOSMesa (Gallium)
> >
> > GLX: no
> >
> > EGL: no
> >
> > Vulkan drivers: no
> >
> > llvm: yes
> > llvm-config: /home/D43345/opt/llvm-3.9/arch/calibre9/bin/llvm-
> > config
> > llvm-version: 3.9.1
> >
> > Gallium drivers: swrast swr
> > Gallium st: mesa
> >
> > HUD extra stats: no
> > HUD lmsensors: no
> >
> > Shader cache: yes
> > With SHA1 from: libcrypto
> >
> > Shared libs: yes
> > Static libs: no
> > Shared-glapi: yes
> >
> > CFLAGS: -g -O2 -Wall -std=c99 -Werror=implicit-function-
> > declaration -Werror=missing-prototypes -fno-math-errno -fno-trapping-math
> > CXXFLAGS: -g -O2 -Wall -fno-math-errno -fno-trapping-math
> > Macros: -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
> > -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS -DNDEBUG
> > -DUSE_X86_64_ASM
> > -DHAVE_XLOCALE_H -DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF -DHAVE_MKOSTEMP
> > -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_SHA1 -DMESA_EGL_NO_X11_HEADERS
> > -DHAVE_LLVM=0x0309 -DMESA_LLVM_VERSION_PATCH=1
> >
> > LLVM_CFLAGS: -I/home/D43345/opt/llvm-
> > 3.9/arch/calibre9/include -
> > D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> > LLVM_CXXFLAGS: -I/home/D43345/opt/llvm-
> > 3.9/arch/calibre9/include -W -Wno-unused-parameter -Wwrite-strings -Wno-
> > missing-field-initializers -Wno-long-long -Wno-maybe-uninitialized
> > -Wdelete-
> > non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -
> > D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> > LLVM_CPPFLAGS: -I/home/D43345/opt/llvm-
> > 3.9/arch/calibre9/include -
> > D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> > LLVM_LDFLAGS: -L/home/D43345/opt/llvm-3.9/arch/calibre9/lib
> >
> > PYTHON2: python2.7
> >
> > Run 'make' to build Mesa
> >
> >
> > Best regards,
> >
> > Yvan
> >
> > ----- Mail original -----
> > De: "Chuck Atkins" <chuck.atk...@kitware.com>
> > À: "yvan fournier" <yvan.fourn...@free.fr>
> > Cc: "ParaView Mailing List" <paraview@paraview.org>
> > Envoyé: Jeudi 23 Février 2017 19:14:03
> > Objet: Re: [Paraview] Issues with OpenGL2 support for off-screen Mesa
> >
> >
> >
> > Hi Yvan,
> > What are the resulting libraries in /home/D43345/opt/Mesa-
> > 13.0/arch/calibre9/lib after the Mesa install? It looks like something has
> > gone a bit awry with the Mesa build. Also, what does the summary look like
> > that's printed out at the end of ./configure for Mesa?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ----------
> > Chuck Atkins
> > Staff R&D Engineer, Scientific Computing
> > Kitware, Inc.
> >
> >
> >
> > On Wed, Feb 22, 2017 at 7:00 PM, < yvan.fourn...@free.fr > wrote:
> >
> >
> > 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/opensourc
> > e/
> > opensource.html
> >
> > Please keep messages on-topic and check the ParaView Wiki at: http://paravie
> > w.
> > 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
_______________________________________________
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:
https://paraview.org/mailman/listinfo/paraview
