subject:"\[Paraview\] Issues with OpenGL2 support for off\-screen Mesa"

Re: [Paraview] Issues with OpenGL2 support for off-screen Mesa

2017-03-10 Thread Yvan Fournier

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

2017-02-24 Thread yvan . fournier

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

Re: [Paraview] Issues with OpenGL2 support for off-screen Mesa

2017-02-23 Thread Chuck Atkins

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,  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), 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 \
>

[Paraview] Issues with OpenGL2 support for off-screen Mesa

2017-02-22 Thread yvan . fournier

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] Issues with OpenGL2 support for off-screen Mesa

Re: [Paraview] Issues with OpenGL2 support for off-screen Mesa

Re: [Paraview] Issues with OpenGL2 support for off-screen Mesa

[Paraview] Issues with OpenGL2 support for off-screen Mesa

4 matches

Site Navigation

Mail list logo

Footer information