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/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 > _______________________________________________ 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