<div dir="ltr"><div><div><div><div>Hi Yvan,<br><br></div>Thanks for the update. <br><br></div>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.<br><br></div>Best,<br></div>Andy<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 22, 2018 at 9:16 PM, <span dir="ltr"><<a href="mailto:yvan.fournier@free.fr" target="_blank">yvan.fournier@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I made further progress on this old thread, so am answering myself to close this issue...<br>
<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
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.<br>
<br>
In any case, I started building a small test case to reproduce this, but it was not working yet (trying to get the<br>
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.<br>
<span class=""><br>
Best regards,<br>
<br>
Yvan<br>
<br>
----- Mail original -----<br>
</span>De: "Yvan Fournier" <<a href="mailto:yvan.fournier@free.fr">yvan.fournier@free.fr</a>><br>
À: <a href="mailto:paraview@paraview.org">paraview@paraview.org</a><br>
Envoyé: Jeudi 25 Mai 2017 02:18:04<br>
Objet: Re: [Paraview] Catalyst dlopen issues with OpenGL2 support for off-screen Mesa<br>
<div><div class="h5"><br>
Hello,<br>
<br>
I reproduced the issue described 2 months ago relative to detection of OSMesa<br>
OpenGL2 support using dynamically loaded shared libraries on another machine.<br>
<br>
I had reproduced this issue on Debian-9 based systems, but not with the<br>
preconfigured Mesa/OSMesa from Arch Linux. Recently, I had other issues with the<br>
packaged library on Arch (Mesa 17.1.0, including both off-screen and on-screen<br>
drivers), as glGetString and a few other symbols were not found.<br>
<br>
So I recompiled Mesa for off-screen mode, using the recommendations from the<br>
ParaView Wiki (with the packaged LLVM 4.0), and encounter the following error<br>
again when starting Catalyst:<br>
<br>
------------------------------<wbr>--<br>
ERROR: In<br>
/home/yvan/src/ParaView/VTK/<wbr>Rendering/OpenGL2/<wbr>vtkOpenGLRenderWindow.cxx, line<br>
831<br>
<br>
vtkOSOpenGLRenderWindow (0x72e3c00): GL version 2.1 with the gpu_shader4<br>
extension is not supported by your graphics driver but is required fo<br>
r the new OpenGL rendering backend. Please update your OpenGL driver. If you are<br>
using Mesa please make sure you have version 10.6.5 or later<br>
and make sure your driver in Mesa supports OpenGL 3.2.<br>
------------------------------<wbr>--<br>
<br>
Trying to force usage of OpenSWR (using "export GALLIUM_DRIVER=swr") I have<br>
another error:<br>
<br>
------------------------------<wbr>--<br>
SWR detected AVX2<br>
<br>
SWR library load failure: /home/yvan/opt/osmesa/lib/<wbr>libswrAVX2.so: undefined<br>
symbol: _glapi_tls_Dispatch<br>
------------------------------<wbr>--<br>
<br>
So this seems quite reproducible on various systems, and both with LLVM 3.9 or<br>
LLVM 4, Mesa 13 or 17.<br>
<br>
When linking ParaView (Catalyst) normally (rather than linking them with a<br>
smaller module loaded as a plugin with dlopen), both the default LLVMpipe and<br>
OpenSwr errors dissapear, and things work fine<br>
<br>
Does anybody have an idea what I may be missing when loading with dlopen ?<br>
<br>
Best regards,<br>
<br>
Yvan<br>
<br>
<br>
From: Yvan Fournier <<a href="mailto:yvan.fournier@free.fr">yvan.fournier@free.fr</a>><br>
To: <a href="mailto:paraview@paraview.org">paraview@paraview.org</a><br>
Objet: Re: [Paraview] Issues with OpenGL2 support for off-screen Mesa<br>
Date: Sat, 11 Mar 2017 00:36:00 +0100<br>
<br>
> Hello,<br>
><br>
> I made some progress using OpenGL2 for offs-screen Mesa on a Debian 8-based<br>
> system:<br>
><br>
> I don't need to compile my code or ParaView in static: compiling everything<br>
> with<br>
> dyanmic libraries works, as long as I link everything together instead of<br>
> loading a plugin (consisting of some Code_Saturne libraries, ParaView<br>
> Libraries,<br>
> and OSMesa/Gallium).<br>
><br>
> So it seems some things re not initialized correctly when I load ParaView and<br>
> OSMesa as a plugin, so I'm not took sure the problem comes from ParaView,<br>
> OSMesa, or LLVM. I tried OSMesa 13.0.3 and 17.0.1, and LLVM 3.5 (packaged with<br>
> Debian 8) and 3.9 (local build), with identical results.<br>
><br>
> I also tried using RTLD_NOW and even RTLD_NOW | RTLD_GLOBAL instead of the<br>
> usual<br>
> RTLD_LAZY when using dlopen, with no difference in behavior (I have not tried<br>
> RTLD_DEEPBIND).<br>
><br>
> Has anyone encountered similar issues or does anyone have an idea what could<br>
> be<br>
> missing in the initialization stage using dlopen for a plugin linked with<br>
> Catalyst ? I do not encounter this issue on an Arch-Linux-based system, but<br>
> encounter it on a Debian 8 ("Jessie") system ?<br>
><br>
> Using a plugin is not an absolute must, but it would be preferable if I<br>
> managed<br>
> to get it working again with that build option.<br>
><br>
> Best regards,<br>
><br>
> Yvan<br>
><br>
><br>
> Friday Feb 24 février 2017 at 18:25 +0100, <a href="mailto:yvan.fournier@free.fr">yvan.fournier@free.fr</a> wrote:<br>
><br>
> > Hi Chuck,<br>
> ><br>
> > here is what I have in /home/D43345/opt/Mesa-13.0/<wbr>arch/calibre9/lib:<br>
> ><br>
> > -rwxr-xr-x 1 D43345 rdusers 1098 Feb 22 15:24 libOSMesa.la<br>
> > lrwxrwxrwx 1 D43345 rdusers 18 Feb 22 15:24 libOSMesa.so -><br>
> > libOSMesa.so.8.0.0<br>
> > lrwxrwxrwx 1 D43345 rdusers 18 Feb 22 15:24 libOSMesa.so.8 -><br>
> > libOSMesa.so.8.0.0<br>
> > -rwxr-xr-x 1 D43345 rdusers 47309888 Feb 22 15:24 libOSMesa.so.8.0.0<br>
> > -rwxr-xr-x 1 D43345 rdusers 962 Feb 22 15:24 <a href="http://libglapi.la" rel="noreferrer" target="_blank">libglapi.la</a><br>
> > lrwxrwxrwx 1 D43345 rdusers 17 Feb 22 15:24 libglapi.so -><br>
> > libglapi.so.0.0.0<br>
> > lrwxrwxrwx 1 D43345 rdusers 17 Feb 22 15:24 libglapi.so.0 -><br>
> > libglapi.so.0.0.0<br>
> > -rwxr-xr-x 1 D43345 rdusers 1400520 Feb 22 15:24 libglapi.so.0.0.0<br>
> > -rwxr-xr-x 1 D43345 rdusers 1018 Feb 22 15:24 libswrAVX.la<br>
> > lrwxrwxrwx 1 D43345 rdusers 18 Feb 22 15:24 libswrAVX.so -><br>
> > libswrAVX.so.0.0.0<br>
> > lrwxrwxrwx 1 D43345 rdusers 18 Feb 22 15:24 libswrAVX.so.0 -><br>
> > libswrAVX.so.0.0.0<br>
> > -rwxr-xr-x 1 D43345 rdusers 97879312 Feb 22 15:24 libswrAVX.so.0.0.0<br>
> > -rwxr-xr-x 1 D43345 rdusers 1024 Feb 22 15:24 libswrAVX2.la<br>
> > lrwxrwxrwx 1 D43345 rdusers 19 Feb 22 15:24 libswrAVX2.so -><br>
> > libswrAVX2.so.0.0.0<br>
> > lrwxrwxrwx 1 D43345 rdusers 19 Feb 22 15:24 libswrAVX2.so.0 -><br>
> > libswrAVX2.so.0.0.0<br>
> > -rwxr-xr-x 1 D43345 rdusers 96655416 Feb 22 15:24 libswrAVX2.so.0.0.0<br>
> > drwxr-xr-x 2 D43345 rdusers 4096 Feb 22 15:24 pkgconfig<br>
> ><br>
> ><br>
> > And here is the summary after configuration of Mesa:<br>
> ><br>
> > prefix: /home/D43345/opt/Mesa-13.0/<wbr>arch/calibre9<br>
> > exec_prefix: ${prefix}<br>
> > libdir: ${exec_prefix}/lib<br>
> > includedir: ${prefix}/include<br>
> ><br>
> > OpenGL: yes (ES1: no ES2: no)<br>
> ><br>
> > OSMesa: libOSMesa (Gallium)<br>
> ><br>
> > GLX: no<br>
> ><br>
> > EGL: no<br>
> ><br>
> > Vulkan drivers: no<br>
> ><br>
> > llvm: yes<br>
> > llvm-config: /home/D43345/opt/llvm-3.9/<wbr>arch/calibre9/bin/llvm-<br>
> > config<br>
> > llvm-version: 3.9.1<br>
> ><br>
> > Gallium drivers: swrast swr<br>
> > Gallium st: mesa<br>
> ><br>
> > HUD extra stats: no<br>
> > HUD lmsensors: no<br>
> ><br>
> > Shader cache: yes<br>
> > With SHA1 from: libcrypto<br>
> ><br>
> > Shared libs: yes<br>
> > Static libs: no<br>
> > Shared-glapi: yes<br>
> ><br>
> > CFLAGS: -g -O2 -Wall -std=c99 -Werror=implicit-function-<br>
> > declaration -Werror=missing-prototypes -fno-math-errno -fno-trapping-math<br>
> > CXXFLAGS: -g -O2 -Wall -fno-math-errno -fno-trapping-math<br>
> > Macros: -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS<br>
> > -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS -DNDEBUG<br>
> > -DUSE_X86_64_ASM<br>
> > -DHAVE_XLOCALE_H -DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF -DHAVE_MKOSTEMP<br>
> > -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_SHA1 -DMESA_EGL_NO_X11_HEADERS<br>
> > -DHAVE_LLVM=0x0309 -DMESA_LLVM_VERSION_PATCH=1<br>
> ><br>
> > LLVM_CFLAGS: -I/home/D43345/opt/llvm-<br>
> > 3.9/arch/calibre9/include -<br>
> > D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS<br>
> > LLVM_CXXFLAGS: -I/home/D43345/opt/llvm-<br>
> > 3.9/arch/calibre9/include -W -Wno-unused-parameter -Wwrite-strings -Wno-<br>
> > missing-field-initializers -Wno-long-long -Wno-maybe-uninitialized<br>
> > -Wdelete-<br>
> > non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -<br>
> > D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS<br>
> > LLVM_CPPFLAGS: -I/home/D43345/opt/llvm-<br>
> > 3.9/arch/calibre9/include -<br>
> > D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS<br>
> > LLVM_LDFLAGS: -L/home/D43345/opt/llvm-3.9/<wbr>arch/calibre9/lib<br>
> ><br>
> > PYTHON2: python2.7<br>
> ><br>
> > Run 'make' to build Mesa<br>
> ><br>
> ><br>
> > Best regards,<br>
> ><br>
> > Yvan<br>
> ><br>
> > ----- Mail original -----<br>
> > De: "Chuck Atkins" <<a href="mailto:chuck.atkins@kitware.com">chuck.atkins@kitware.com</a>><br>
> > À: "yvan fournier" <<a href="mailto:yvan.fournier@free.fr">yvan.fournier@free.fr</a>><br>
> > Cc: "ParaView Mailing List" <<a href="mailto:paraview@paraview.org">paraview@paraview.org</a>><br>
> > Envoyé: Jeudi 23 Février 2017 19:14:03<br>
> > Objet: Re: [Paraview] Issues with OpenGL2 support for off-screen Mesa<br>
> ><br>
> ><br>
> ><br>
> > Hi Yvan,<br>
> > What are the resulting libraries in /home/D43345/opt/Mesa-<br>
> > 13.0/arch/calibre9/lib after the Mesa install? It looks like something has<br>
> > gone a bit awry with the Mesa build. Also, what does the summary look like<br>
> > that's printed out at the end of ./configure for Mesa?<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > ----------<br>
> > Chuck Atkins<br>
> > Staff R&D Engineer, Scientific Computing<br>
> > Kitware, Inc.<br>
> ><br>
> ><br>
> ><br>
> > On Wed, Feb 22, 2017 at 7:00 PM, < <a href="mailto:yvan.fournier@free.fr">yvan.fournier@free.fr</a> > wrote:<br>
> ><br>
> ><br>
> > Hello,<br>
> ><br>
> > I recently encountered issues related to the OpenGL2 support for off-screen<br>
> > Mesa. Up to at least ParaView V5.1.2, I could use ParaView/Catalyst built<br>
> > with<br>
> > OSMesa with no specific issues (I mostly used OSMesa compiled without LLVM,<br>
> > as<br>
> > rendering did not represent a huge portion of my compute time.<br>
> ><br>
> > I'm using Catalyst in the context of the Code_Saturne CFD code. By default,<br>
> > the code includes a plugin, linked to both ParaView or a Catalys edition<br>
> > (based on the info from the cmake entry in ParaView installs when<br>
> > -DPARAVIEW_INSTALL_<wbr>DEVELOPMENT_FILES=ON is used). On Linux systems, the<br>
> > plugin<br>
> > is loaded with dlopen(<plugin_so_path>, RTLD_LAZY).<br>
> > We use Catalyst Python scripts, so the plugin goes through ParaView's Python<br>
> > layer also to render images.<br>
> ><br>
> > On my personal PC, running Arch Linux I have not encountered any specific<br>
> > issue with recent ParaView changes and the move to OpenGL2 (actually, for<br>
> > on-<br>
> > screen redering, the Intel graphics driver/QT5 rendering issue leading to<br>
> > spurious transparencies that I had before seem to have disappeared, so<br>
> > things<br>
> > are actually better.<br>
> ><br>
> > On company machines (workstations and clusters using EDF's Debian 8 flavor,<br>
> > with gcc version (Debian 4.9.2-10) 4.9.2, things are not working so well, as<br>
> > I<br>
> > get an error message related to missing OpenGL features starting with<br>
> > ParaView<br>
> > 5.2 (and up to today's master).<br>
> > I switched to Mesa 13.0.1, then 13.0.4, following the new instructions on<br>
> > the<br>
> > ParaView Wiki, but I still always get the following error:<br>
> ><br>
> > """<br>
> > ERROR: In<br>
> > /home/D43345/src/paraview/VTK/<wbr>Rendering/OpenGL2/<wbr>vtkOpenGLRenderWindow.cxx,<br>
> > line 733<br>
> > vtkOSOpenGLRenderWindow (0x808db80): GL version 2.1 with the gpu_shader4<br>
> > extension is not supported by your graphics driver but is required for the<br>
> > new<br>
> > OpenGL rendering backend. Please update your OpenGL driver. If you are using<br>
> > Mesa please make sure you have version 10.6.5 or later and make sure your<br>
> > driver in Mesa supports OpenGL 3.2.<br>
> > GL_Version: 3.3 (Core Profile) Mesa 13.0.4.<br>
> > """<br>
> ><br>
> > My mesa build used the following options (from the ParaView wiki) :<br>
> ><br>
> > ./configure --prefix=$HOME/opt/Mesa-13.0/<wbr>arch/calibre9 --enable-opengl --<br>
> > disable-gles1 --disable-gles2 --disable-va --disable-xvmc --disable-vdpau --<br>
> > enable-shared-glapi --disable-texture-float --enable-gallium-llvm --enable-<br>
> > llvm-shared-libs --with-gallium-drivers=swrast,<wbr>swr --disable-dri --with-dri-<br>
> > drivers= --disable-egl --with-egl-platforms= --disable-gbm --disable-glx --<br>
> > disable-osmesa --enable-gallium-osmesa --with-llvm-prefix=$HOME/opt/<wbr>llvm-<br>
> > 3.9/arch/calibre9<br>
> ><br>
> > I tried both using the local llvm install (v3.5, which worked in part and<br>
> > could not compile OpenSwr), and a local build of LLVM 3.9.1 (shown above). I<br>
> > also added --enable-debug for my latest tests.<br>
> ><br>
> > Things work slightly better with LLVM 3.9 than with 3.5, but I still get the<br>
> > above error mentioning the gpu_shader4 extension, whether exporting<br>
> > GALLIUM_DRIVER=llvmpipe or softpipe. With GALLIUM_DRIVER=swr, I have another<br>
> > error:<br>
> ><br>
> > """<br>
> > Using OpenSWR :<br>
> ><br>
> > SWR detected AVX2<br>
> > SWR library load failure: /home/D43345/opt/Mesa-<br>
> > 13.0/arch/calibre9/lib/<wbr>libswrAVX2.so: undefined symbol: _glapi_Context<br>
> > """<br>
> ><br>
> > During my testing, I also built a static version of my code, with a static<br>
> > build of ParaView (and the plugin replaced by a static link), but keeping<br>
> > the<br>
> > same dynamic library for OSMesa. And surprise, that version worked normally,<br>
> > producing the expected images (at least with the LLVM 3.9 build; with LLVM<br>
> > 3.5, I had the color map labels, but no colored slice...).<br>
> ><br>
> > So the issue seems to be on the ParaView side more than on the OSMesa side.<br>
> > I<br>
> > have a debug build of the Code_Saturne/ParaView/OSMesa stack, but although I<br>
> > can explore where the final error occurs (in vtkOpenGLRenderWindow.cxx), and<br>
> > some GLES querying before that, I don't realy know where to look .<br>
> ><br>
> > As the error occurs with a dynamic but not static build, is seems to be<br>
> > related to initialization issues, but I don't know VTK well enough to<br>
> > provide<br>
> > more precise info.<br>
> ><br>
> > Has anybody encounted this issue ? Does anybody have suggestions ? I'm<br>
> > planning on trying other options than RTLD_LAZY on my plugin's side, but if<br>
> > that does not work, I'll be out of ideas.<br>
> ><br>
> > Best regards,<br>
> ><br>
> > Yvan<br>
> ><br>
> > PS: in case they are useful as a reference, the build options for Mesa used<br>
> > by<br>
> > Arch Linux (recently switched from 13 to 17), on the system on which I had<br>
> > zero issue, are the following:<br>
> ><br>
> > ./configure --prefix=/usr \<br>
> > --sysconfdir=/etc \<br>
> > --with-dri-driverdir=/usr/lib/<wbr>xorg/modules/dri \<br>
> > --with-gallium-drivers=r300,<wbr>r600,radeonsi,nouveau,svga,<wbr>swrast,virgl \<br>
> > --with-dri-drivers=i915,i965,<wbr>r200,radeon,nouveau,swrast \<br>
> > --with-egl-platforms=x11,drm,<wbr>wayland \<br>
> > --with-vulkan-drivers=intel,<wbr>radeon \<br>
> > --disable-xvmc \<br>
> > --enable-gallium-llvm \<br>
> > --enable-llvm-shared-libs \<br>
> > --enable-shared-glapi \<br>
> > --enable-libglvnd \<br>
> > --enable-egl \<br>
> > --enable-glx \<br>
> > --enable-glx-tls \<br>
> > --enable-gles1 \<br>
> > --enable-gles2 \<br>
> > --enable-gbm \<br>
> > --enable-dri \<br>
> > --enable-osmesa \<br>
> > --enable-texture-float \<br>
> > --enable-xa \<br>
> > --enable-vdpau \<br>
> > --enable-omx \<br>
> > --enable-nine \<br>
> > --enable-opencl \<br>
> > --enable-opencl-icd \<br>
> > --with-clang-libdir=/usr/lib<br>
> ><br>
> > There is also a patch related to glapi linkage which I might try in case it<br>
> > solved my glapi missing symbol issue with OpenSWR...<br>
> > ______________________________<wbr>_________________<br>
> > Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
> ><br>
> > Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensourc" rel="noreferrer" target="_blank">http://www.kitware.com/<wbr>opensourc</a><br>
> > e/<br>
> > opensource.html<br>
> ><br>
> > Please keep messages on-topic and check the ParaView Wiki at: <a href="http://paravie" rel="noreferrer" target="_blank">http://paravie</a><br>
> > w.<br>
> > org/Wiki/ParaView<br>
> ><br>
> > Search the list archives at: <a href="http://markmail.org/search/?q=ParaView" rel="noreferrer" target="_blank">http://markmail.org/search/?q=<wbr>ParaView</a><br>
> ><br>
> > Follow this link to subscribe/unsubscribe:<br>
> > <a href="http://public.kitware.com/mailman/listinfo/paraview" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/paraview</a><br>
______________________________<wbr>_________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/<wbr>opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the ParaView Wiki at: <a href="http://paraview.org/Wiki/ParaView" rel="noreferrer" target="_blank">http://paraview.org/Wiki/<wbr>ParaView</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=ParaView" rel="noreferrer" target="_blank">http://markmail.org/search/?q=<wbr>ParaView</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
</div></div><a href="https://paraview.org/mailman/listinfo/paraview" rel="noreferrer" target="_blank">https://paraview.org/mailman/<wbr>listinfo/paraview</a><br>
</blockquote></div><br></div>