Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5

On Thu, Dec 10, 2015 at 17:20:35 +0100, Albina, Frank wrote: > Thank you for the reply. My idea was to run PV-5.0.0-RC1 in parallel on our > cluster, > therefore the need to recompile as the binaries do not usually ship with this > feature > and I guess that you do not necessarily know either

Re: [Paraview] ParaView Environment Variables

This is a good idea and for information Utkarsh started to write this documentation in Utilities/Doxygen/pages/EnvironmentVariables.md For now it is just in a merge request (and it is not complete) but no doubt if will be in master very soon!

Re: [Paraview] 'Plot Data' missing Points X/Y/Z as option for X axis on 5.0-RC?

Giuseppe, You are right. I think this is something we should have addressed with https://gitlab.kitware.com/paraview/paraview/merge_requests/385 So I have just made a patch for this: https://gitlab.kitware.com/paraview/paraview/merge_requests/515 If it is all OK it should be ready for 5.0RC2 (at

Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5

Hi Ben! Thank you very much for the information. I will try to work my way into getting PV 5.0 compiled with OpenSWR-Mesa & MPI. Best regards,   Frank Albina -Original Message- From: Ben Boeckel [mailto:ben.boec...@kitware.com] Sent: Donnerstag, 10. Dezember 2015 17:45 To: Albina,

Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5

> ./configure --enable-64-bit --enable-texture-float --enable-osmesa > --disable-egl --disable-xorg --disable-xvmc --disable-opencl --disable-glx > --disable-dri --disable-va --disable-shared-glapi --enable-gallium-llvm=no > --with-gnu-ld --with-osmesa-bits=8 --disable-vdpau >

[Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5

Hi all! First of all, thanks for all the effort spent on porting the rendering engine to support the OpenGL2 backend by default on PV 5.0.0. Early tests with the binary from the download page shows a massive improvement over the PV 4.1 to 4.3 versions in terms of rendering time. I have

Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5

On Thu, Dec 10, 2015 at 09:18:44 -0500, Ken Martin wrote: > people on this list are more familiar with the specifics of setting up SWR > and Mesa on a cluster but I wanted to at least give you a quick response to > let you know we are working on it :-) The binaries built by our buildbots (and

Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5

Thanks Frank, This is an area we are actively working to cleanup right now. Both in catching it more gracefully and in providing better messages to help people understand what the next step should be. I believe if you are in an Intel based system that using their new SWR backend for mesa (

Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5

Hi Frank, In addition to what Ken said, If you switch to 10.6.5 make sure you have set in your build and runtime. export MESA_GL_VERSION_OVERRIDE=3.2. - Aashish On Thu, Dec 10, 2015 at 9:18 AM, Ken Martin wrote: > Thanks Frank, > > This is an area we are actively

Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5

Dear Aashish & Ken! Thank you very much for your swift replies. I had read from the Kitware blog that OpenSWR would bring additional performance but is still in “alpha” stage, therefore I have been concentrating on “standard” MESA first. I was missing the bit of information requiring to set

Re: [Paraview] OpenGL Backend Identification

Maybe vtkRenderingOpenGLConfigure.h ? That header is configured from a .in file for both the old and new backend. We could define VTK_OPENGL2 in that header and applications could include it as needed. That header appears to get installed. The only issue I see is that if someone built VTK with

Re: [Paraview] OpenGL Backend Identification

vtkRenderingOpenGLConfigure.h seems indeed the right place. I propose to also add a VTK_OPENGL1 - let's get prepared for the future. And we could also add #define VTK_OPENGL_BACKEND_VERSION [1|2] J. 2015-12-10 15:29 GMT+01:00 Ken Martin : > Maybe

Re: [Paraview] OpenGL Backend Identification

On Thu, Dec 10, 2015 at 09:29:27 -0500, Ken Martin wrote: > Maybe vtkRenderingOpenGLConfigure.h ? > > That header is configured from a .in file for both the old and new backend. > We could define VTK_OPENGL2 in that header and applications could include > it as needed. That header appears to get

Re: [Paraview] OpenGL Backend Identification

Yes, and if the header doesn't exist nor does any backend, so that seems reasonable too. On Thu, Dec 10, 2015 at 9:29 AM, Ken Martin wrote: > Maybe vtkRenderingOpenGLConfigure.h ? > > That header is configured from a .in file for both the old and new backend. > We could

Re: [Paraview] OpenGL Backend Identification

And it should appear in a wrapped class so that we can get it at runtime from python. David E DeMarle Kitware, Inc. R Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Dec 10, 2015 at 9:47 AM, Marcus D. Hanwell < marcus.hanw...@kitware.com> wrote: > Yes, and

Re: [Paraview] OpenGL Backend Identification

On Thu, Dec 10, 2015 at 10:08:14 -0500, David E DeMarle wrote: > And it should appear in a wrapped class so that we can get it at runtime > from python. In that case, there should probably be an enum in RenderingCore: enum vtkRenderingBackend { ... }; class

Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5

Dear Ben! Thank you for the reply. My idea was to run PV-5.0.0-RC1 in parallel on our cluster, therefore the need to recompile as the binaries do not usually ship with this feature and I guess that you do not necessarily know either which parallel communication library is going to be used