Re: [Paraview] Catalyst dlopen issues with OpenGL2 support for off-screen Mesa
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,
>
> Yva
[Paraview] Question about plugins with Catalyst and Python scripts
Hello, We have been using Catalyst (with Python coprocessing scripts) in our code for quite a while now, and am trying to see how to make thing more user-friendly. One of the main issues we have is that if plugins are loaded in ParaView when using the Coprocessing Generator plugin, extra lines regarding those plugins may appear in the script, even when not dreclty used. For example, when the PointSprite plugins is enabled in PV 5.1, it adds opacity transfer function informations. This particular example might not be relevant to PV 5.4 with integrated PointGaussian, but other plugins may add similar entries, whether used or not in a particular view. This causes issues using Catalyst, as those plugins are not enabled in Catalyst (even using a full ParaView install with OSMesa as Catalyst, not editions, often too incomplete). One solution is to remove the "offending" lines (i.e. run once, check lines reported in error logs, removec those, run again, ...) which while not complicated, tends to scare users and requires multiple additional iterations to setup a visualization. A better solution would be to allow loading of plugins from the Python script (especially as I expect it would allow using plugins such as SurfaceLIC from within Catalyst), but I can't find any documentation for this. I seem to remember some people from Kitware mentioning this was possible in a live discussion I had, but have no additional details. Is there a way to tell ParaView/Catalyst to load a particular plugin from within a Python script ? IF yes, what's the syntax ? Best regards, Yvan ___ 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
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
> > l
Re: [Paraview] Issues with OpenGL2 support for off-screen Mesa
ORMAT_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 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(, 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), b
Re: [Paraview] Issues with OpenGL2 support for off-screen Mesa
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 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 dl
[Paraview] Issues with OpenGL2 support for off-screen Mesa
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(, 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 \
Re: [Paraview] Automating contour isosurface values in parallel Catalyst Python script
Hi Andy and Joachim,
I adapted Andy's suggestions, and my script is now both slightly simpler (no
mpi4py or numpy dependencies) and works on both machines.
PS. I cc'd the ParaView mailing list, since I started this thread on it, and
forgot "reply to all" in one of my own responses...
Thanks again for the help, and best regards,
Yvan
- Mail original -
De: "Andy Bauer" <andy.ba...@kitware.com>
À: "Yvan Fournier" <yvan.fourn...@free.fr>, "Joachim Pouderoux"
<joachim.pouder...@kitware.com>
Envoyé: Jeudi 16 Février 2017 16:15:03
Objet: Re: [Paraview] Automating contour isosurface values in parallel Catalyst
Python script
Hi Yvan,
I inlined some answers below...
Best,
Andy
ps. I cc'ed Joachim since it looks like you meant to cc him but did not.
On Thu, Feb 16, 2017 at 6:25 AM, < yvan.fourn...@free.fr > wrote:
Hi Andy and Joachim,
Thanks for your answers. I suspected I would need a solution of this sort.
I prefer computing the min and max myself rather than adapting a Catalyst
edition, as I often use full/default ParaView with OSMesa instead of Catalyst
Editions (I only got a "standard" base + Python + extensions... edition working
very recently; with older versions of the editions, some filter was always
missing and I could not use Python scripts generated by the Coprocessing
Generator plugin).
I generally just use the full PV version also. It is only when I need to be
very light on memory that I switch to the Catalyst editions. Others have noted
that the Catalyst editions are easier to build on HPC systems though and prefer
that route.
I made good progress, and now have a solution which works with a 1 or
2-week-old build from the master branch, using numpy, but does not work on a
build with ParaView 5.1.2 on an older machine due to missing features:
- "from paraview.vtk.numpy_interface.algorithms import *" fails, complaining it
does not find numpy and tells me to check it was installed properly (it is
installed, though might have been installed after the ParaView build)
I do not know about this issue as I have not seen it before and was not
involved with the integration. Maybe Joachim knows. Otherwise I would suggest
going back to the PV mailing list.
- using:
controller =
coprocessing.vtkCompositeMultiProcessController.GetGlobalController()
if controller and controller.IsA("vtkMPIController") and
controller.GetNumberOfProcesses() > 1:
from mpi4py import MPI
comm = vtkMPI4PyCommunicator.ConvertToPython(controller.GetCommunicator())
In cases like this I just use:
import vtk
controller = vtk.vtkMultiProcessController.GetGlobalController()
c.AllReduce(, , , vtk.vtkCommunicator.MAX_OP)
to get the max values. vtkCommunicator has the named constants for operations.
The "global" communicator will be the one that Catalyst uses which may be a
subcommunicator of MPI_COMM_WORLD. I'm not sure if mpi4py will be over the
Catalyst MPI processes or all of them. Also, you may want to try "from paraview
import vtk" instead of just "import vtk". Less VTK Python stuff should be
imported then but it may be missing something you want. I don't use
vtkMPI4PYCommunicator so I cannot say how well that should work for your needs.
I have a "NameError: global name 'vtkMPI4PyCommunicator' is not defined"
message
In my earlier tests, I tried simply using the AllReduce() method from the
controller, with vtkArrays, but I was stuck on finding the correct value for
the last argument, which seems to be an integer describing the collective
reduction operation (I need min and max). But I was unable to find any examples
for this in Python, (whether Googling for examples or printing dict() and
(help() of various Python objects).
The documentation only specifies some methods may not be available in Python...
Are there named constants describing those operations in the Python wrappers of
vtkMPIController ?
I assume I could find the integer values in the C++ documentation/sources, but
I would rather have named constants for readability and in case of future
changes.
I guess using the vtkMPIController would slightly simplify the code and reduce
dependancy to some external Python modules.
Thanks for the help, and best regards,
Yvan
----- Mail original -
De: "Andy Bauer" < andy.ba...@kitware.com >
À: "Joachim Pouderoux" < joachim.pouder...@kitware.com >
Cc: "Yvan Fournier" < yvan.fourn...@free.fr >, "ParaView" <
paraview@paraview.org >
Envoyé: Mardi 14 Février 2017 21:27:06
Objet: Re: [Paraview] Automating contour isosurface values in parallel Catalyst
Python script
Hi Yvan,
Another option is just to compute it yourself. The reason that the global min
and max aren't know in Catalyst is that it requires comm
[Paraview] Automating contour isosurface values in parallel Catalyst Python script
Hello,
I'm in the process of migrating some VTK scripts in the Code_Saturne (code-
saturne.org) test suite to Catalyst Python scripts, and am having some
difficulty automating some cases using contour plots:
For time-dependent data, I do not know the value ranges in advance, and would
like to query them so as to build an Isosurface values array spanning that
range.
I can manage to access the point and cell data arrays and ther ranges, but
printing the ranges in parallel, it seems I have local values only, while I need
a global range.
I searched for examples in the documentation, on the Wiki, ..., and found an
example for MinMax, but don't seem to ba able to access the correct type of
Proxy under Catalyst (the default servermanager is not connected in the usual
way.
For scalar bar color look-up tables, I can manage with
"coprocessor.WriteImages(datadescription, rescale_lookuptable=True)" in the
coprocessing script, but for a more general case such as thar needed for contour
plots, I've been running around in circles in the last hours trying to find and
adapt a relevant example.
Does anyone have a suggestion ? Thanks in advance,
Yvan Fournier
___
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
Re: [Paraview] Possible regression ? Error when generating Coprocessing script
Hello, OK, rebuilding from a new build directory seems to have fixed the issue (rerunning cmake and building did not; also, I used raw cmake instead of "ccmake -i" just in case... Sorry for the false alarm. Best regards, Yvan ___ 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
[Paraview] Possible regression ? Error when generating Coprocessing script
Hello, When trying to generate a coprocessing script with ParaView 5.2.0-RC3- 14-gc56cebd (based on rather simple EnSight data), I have the following error: Traceback (most recent call last): File "", line 1, in File "/home/yvan/opt/paraview-5.2/lib/paraview-5.2/site- packages/paraview/cpexport.py", line 75, in from paraview import cpstate File "/home/yvan/opt/paraview-5.2/lib/paraview-5.2/site- packages/paraview/cpstate.py", line 13, in from paraview import smtrace, smstate, servermanager File "/home/yvan/opt/paraview-5.2/lib/paraview-5.2/site- packages/paraview/smtrace.py", line 68, in import paraview.servermanager as sm File "/home/yvan/opt/paraview-5.2/lib/paraview-5.2/site- packages/paraview/servermanager.py", line 53, in from paraview import vtk File "/home/yvan/opt/paraview-5.2/lib/paraview-5.2/site- packages/paraview/vtk/__init__.py", line 7, in from paraview.vtk.vtkCommonCore import * File "/home/yvan/opt/paraview-5.2/lib/paraview-5.2/site- packages/paraview/vtk/vtkCommonCore.py", line 9, in from vtkCommonCorePython import * ImportError: No module named vtkCommonCorePython Error: Could not import vtkCommonComputationalGeometry I had the same error with an earlier RC1 version, while I had never encountered this issue before (upgrading my ParaView build from master every few weeks, and using the Coprocessing generator plugin on and off for the last 2 years or more). Is it something with my build, or have others encountered this issue ? All of PARAVIEW_ENABLE_PYTHON, PARAVIEW_ENABLE_CATALYST, and PARAVIEW_USE_MPI are enabled in my builds. Best regards, Yvan Fournier ___ 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
Re: [Paraview] Ensight Files - crash with 3.10 and 3.12
Hello, I'll let the ParaView developpers confirm this, but this is almost definitely a bug in OpenFoam, not ParaView. The error message says it all: some faces are not oriented correctly. I had already encountered this bug a few years ago when testing The OpenFoam meshing output with another CFD code, which can read EnSight fold files, but as I was only running quick tests and had other issues, I forgot to send a bug report to its developpers (sorry). The issue is as follows: the EnSight Gold format specifies that nfaced (polyhedron) elements are defined by their faces (polygons), with normals pointing outwards (with normals defined in the trigonometric sense. As faces in the OpenFoam structure are shared by 2 cells, their normal points inwards for 1 of every 2 cells. Correct EnSight Gold output would thus require that a face's vertices order be reversed when outputting it to EnSight if that face's normal points inwards, but in OpenFoam's conversion/ensight/ensightPartCells.C file, there only seems to be a loop on faces, with an inner loop on face vertices, an no orientation check. Now the reason things seemed to work prior to ParaView 3.8 is that there was no true polyhedron support, so the reader just wrote polyhedra as convex point sets. This would produce some display artifacts, but at least allowed reading EnSight files with polyhedra (that patch was submitted to Kitware, between ParaView 3.4 and 3.6 if I remember correctly). As convex point sets have no notion of orientation, the incorrect output from OpenFoam was not an issue. With version 3.10, true polyhedra support has arrived, and the readers have been updated, so things look nicer, but the readers are stricter regarding the file format. In any case, with another code doing things as required by the EnSight documentation, polyhedron support works pretty well with both ParaView 3.10 and 3.12. Best regards, Yvan Message: 4 Date: Sat, 03 Dec 2011 09:45:58 +0100 From: Fabian Braennstroem f.braennstr...@gmx.de Subject: [Paraview] Ensight Files - crash with 3.10 and 3.12 To: paraview@paraview.org Message-ID: 4ed9e1c6.8080...@gmx.de Content-Type: text/plain; charset=ISO-8859-15; format=flowed Hello, I have a problem with Ensight files created by OpenFOAM. Paraview crashs as soon as I try to create a slice directly after loading the file... but only for version 3.10 and 3.12, but it works for 3.8. fbraenns@elephant: /data2/WORK/fbraenns/R2N/CFD/Saloon/VI2N_VI1N/M02_B03_G07_OF__Mesh_82Mio_Case1 $ pv12 Find an unexpected case. The input polyhedron cell may not be a water tight or the polygonal faces may not be planar. Contouring will continue, but this cell may not be processed correctly. Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted fbraenns@elephant: /data2/WORK/fbraenns/R2N/CFD/Saloon/VI2N_VI1N/M02_B03_G07_OF__Mesh_82Mio_Case1 $ pv10 Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted As written this does not happen with the 3.8. version. Do you have an idea? Best Regards Fabian ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
