Hi Yvan,
Thanks for the update.
I haven't seen anything like this yet but if I'm able to reproduce it I'll
see if I can track down the issue.
Best,
Andy
On Mon, Jan 22, 2018 at 9:16 PM, <yvan.fourn...@free.fr> wrote:
> 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
>
_______________________________________________
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
