Re: [Paraview] Paraview python script: passing images to PIL (python image library)
David, this leads me to another question. Looking at file raster_wrangler.py in lib/paraview-5.1/site-packages/paraview/cinemaIO, one tries to import PIL. However, even though numpy is provided by the SuperBuild, PIL is not. So I guess that I have to compile my own version of Python including PIL and pass it to the SuperBuild as system python installation. Is my assumption correct? Or have I been missing something? Cheers, Frank. From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Albina, Frank Sent: Mittwoch, 12. Oktober 2016 20:01 To: David E DeMarle Cc: Del Citto, Francesco; paraview@paraview.org Subject: Re: [Paraview] Paraview python script: passing images to PIL (python image library) David, that’s excellent. Thanks a lot. Frank. From: David E DeMarle [mailto:dave.dema...@kitware.com] Sent: Mittwoch, 12. Oktober 2016 19:56 To: Albina, Frank Cc: paraview@paraview.org<mailto:paraview@paraview.org>; Del Citto, Francesco Subject: Re: [Paraview] Paraview python script: passing images to PIL (python image library) Look into the cinemaIO directory of ParaView. We move back and forth between paraview, numpy and PIL often there. For example: image = self.view.CaptureWindow(1) ext = image.GetExtent() width = ext[1] - ext[0] + 1 height = ext[3] - ext[2] + 1 imagescalars = image.GetPointData().GetScalars() idata = numpy_support.vtk_to_numpy(imagescalars) image.UnRegister(None) imageslice = idata.reshape(height, width, 3) imageslice = numpy.flipud(imageslice) pimg = PIL.Image.fromarray(imageslice) David E DeMarle Kitware, Inc. R Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Oct 12, 2016 at 1:42 PM, Albina, Frank <frank.alb...@sauber-motorsport.com<mailto:frank.alb...@sauber-motorsport.com>> wrote: All, A simple question: my incentive is to manipulate images using PIL in a pvbatch script. At the time being, I am writing the images to file in PNG format and reading the file again from disc using PIL. I have found out that the underlying image writing is performed by the vtkPNGWriter class and that this class allows to write to memory (vtkPNGWriter.SetWriteToMemory). Hence my question: Is it possible to “write” a PNG file to memory so that I can process it further using PIL? If so, how shall I proceed? Thank you very much in advance. Cheers, Frank. ___ Powered by www.kitware.com<http://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
Re: [Paraview] Paraview python script: passing images to PIL (python image library)
David, that’s excellent. Thanks a lot. Frank. From: David E DeMarle [mailto:dave.dema...@kitware.com] Sent: Mittwoch, 12. Oktober 2016 19:56 To: Albina, Frank Cc: paraview@paraview.org; Del Citto, Francesco Subject: Re: [Paraview] Paraview python script: passing images to PIL (python image library) Look into the cinemaIO directory of ParaView. We move back and forth between paraview, numpy and PIL often there. For example: image = self.view.CaptureWindow(1) ext = image.GetExtent() width = ext[1] - ext[0] + 1 height = ext[3] - ext[2] + 1 imagescalars = image.GetPointData().GetScalars() idata = numpy_support.vtk_to_numpy(imagescalars) image.UnRegister(None) imageslice = idata.reshape(height, width, 3) imageslice = numpy.flipud(imageslice) pimg = PIL.Image.fromarray(imageslice) David E DeMarle Kitware, Inc. R Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Oct 12, 2016 at 1:42 PM, Albina, Frank <frank.alb...@sauber-motorsport.com<mailto:frank.alb...@sauber-motorsport.com>> wrote: All, A simple question: my incentive is to manipulate images using PIL in a pvbatch script. At the time being, I am writing the images to file in PNG format and reading the file again from disc using PIL. I have found out that the underlying image writing is performed by the vtkPNGWriter class and that this class allows to write to memory (vtkPNGWriter.SetWriteToMemory). Hence my question: Is it possible to “write” a PNG file to memory so that I can process it further using PIL? If so, how shall I proceed? Thank you very much in advance. Cheers, Frank. ___ Powered by www.kitware.com<http://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
[Paraview] Paraview python script: passing images to PIL (python image library)
All, A simple question: my incentive is to manipulate images using PIL in a pvbatch script. At the time being, I am writing the images to file in PNG format and reading the file again from disc using PIL. I have found out that the underlying image writing is performed by the vtkPNGWriter class and that this class allows to write to memory (vtkPNGWriter.SetWriteToMemory). Hence my question: Is it possible to "write" a PNG file to memory so that I can process it further using PIL? If so, how shall I proceed? Thank you very much in advance. Cheers, Frank. ___ 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] ParaView 5.2 Release Candidate 1 available for download
Issue being configuration messages. -Original Message- From: Ben Boeckel [mailto:ben.boec...@kitware.com] Sent: Mittwoch, 12. Oktober 2016 15:53 To: Albina, Frank Cc: Gena Bug; paraview@paraview.org Subject: Re: [Paraview] ParaView 5.2 Release Candidate 1 available for download On Wed, Oct 12, 2016 at 15:36:24 +0200, Albina, Frank wrote: > I have been having similar issue when compiling ParaView 5.1.2 from > source with QT4 support, which depends on the fontconfig project. > I could get rid of it by setting FONTCONFIG_PATH to /etc/fonts on my > system. "Issue" being the crappy font rendering or the configuration messages? --Ben ___ 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] ParaView 5.2 Release Candidate 1 available for download
All, I have been having similar issue when compiling ParaView 5.1.2 from source with QT4 support, which depends on the fontconfig project. I could get rid of it by setting FONTCONFIG_PATH to /etc/fonts on my system. HTH. Frank. -Original Message- From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Ben Boeckel Sent: Mittwoch, 12. Oktober 2016 15:29 To: Gena Bug Cc: paraview@paraview.org Subject: Re: [Paraview] ParaView 5.2 Release Candidate 1 available for download On Tue, Oct 11, 2016 at 23:30:16 +0300, Gena Bug via ParaView wrote: > I've just tried the 5.2rc and noticed this in the console: > > $ Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", > line > 72: non-double matrix element > Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line > 72: non-double matrix element > Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", > line > 80: saw unknown, expected number This is due to the way we now package fontconfig. We used to have it just use the (non-existent) config files from the package, so you got crappy fonts usually. Now, we use the system configuration and you should get the same fonts as the system, but it seems that we probably need to update our fontconfig. Other than that, the messages are harmless as far as we've been able to tell. > And a fontconfig folder is created in the run directory with a bunch > of cache-files. Yeah, not sure how to fix this; I had tried putting them into /var/cache like the system, but it seems that that flag is insufficient :( . --Ben ___ 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
Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR.
Chuck, thank you very much for the info. This is most useful. Frank. From: Chuck Atkins [mailto:chuck.atk...@kitware.com] Sent: Dienstag, 11. Oktober 2016 21:28 To: Albina, Frank Subject: Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR. b)Use the configuration option paraview_FROM_GIT:BOOL=ON to check out the latest paraview sources (which will be 5.2.0 RC1) Almost. Setting paraview_FROM_GIT=ON will use the latest paraview sources which is the git master branch and a few commits ahead of RC1. The sb has been updated to use the RC1 source tarball so if you set paraview_FROM_GIT=OFF then you'll get the source for 5.2.0-RC1. So FROM_GIT=OFF gives you 5.2.0-RC1 and FROM_GIT=On gives you whatever is in master, which right now is "v5.2.0-RC1-7-g52f2ad6" which means 7 commits past RC1. ___ 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] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR.
Chuck, thanks to your help, I could compile ParaView v5.1.2 with Mesa v12.0.3 (release version, not from GIT repository) using the master git checkout (hash 26eb1fa8f5364242d9f9c03b598f0ee735cf88e4) from last week. It was not easy but probably due my lack of experience using the superbuild system and not knowing which external projects I had to enable/disable. A few comments regarding the build on my system (OpenSuSE 12.3): 1. Cmake v3.6.x is required for building. Not a big deal but this is new wrt. the release checkout. 2. There are still libraries built into /path/to/build/install/lib64. · projects/apple-unix/szip.cmake · projects/unix/mesa.common.cmake · projects/apple-unix/freetye.cmake For these libraries, I had to specify in the cmake file the additional option –libdir=/lib 3. Building Mesa v12.0.3 works like a charm. However, the libOSMesa relies on additional libraries such as: · libglapi.so · libswrAVX.so · libswrAVX2.so which are not copied into the archive when packing the binaries using: “ctest -V -R cpack-paraviewsdk-TGZ” 4. Compared to the ParaView v5.1.2 binary for Linux, the compiled version with mesa v12.0.3 is substantially slower than with the OpenSWR version shipped with the binary. I have let my standard benchmark running to give you some numbers. The benchmark consists in rendering pressure-contours on a generic F1 & sports car as shown hereafter. The surface mesh of the sports car is roughly twice as fine as on the F1 car. [cid:image001.jpg@01D2208D.A36EF080] Rendering time Generic F1 car Generic sports car PV 5.1.2 binary 27.06s 77.95s PV 5.1.2 MESA3D v12.0.3 81.10s 272.05s From the comparison, the version compiled with MESA 3D v12.0.3 is slower by a factor of 3 to 3.5. The compiler used is gcc v4.8.5 and in all cases the same server has been used. The SWR AVX2 rendering was set by giving –mesa-swr-avx2 from the command line for the downloaded binary, by setting the environment variable GALLIUM_DRIVER=swr for the compiled version. Is this something which was expected? Or did I miss something when compiling the source code? Thank you very much in advance for any feedback. Cheers, Frank. From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Albina, Frank Sent: Donnerstag, 29. September 2016 13:55 To: Chuck Atkins; Ben Boeckel Cc: Del Citto, Francesco; paraview@paraview.org Subject: Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR. Hi Chuck, Thank you very much for your reply. It is very interesting and I will try my best to get ParaView compiled following your recommendations. Unfortunately, others duties are holding me off this week from concentrating on this but I will share my test results comparing ParaView on GPU, with mesa-llvm and mesa-swr-avx2. Talk to you soon. Best regards, Frank. From: Chuck Atkins [mailto:chuck.atk...@kitware.com] Sent: Mittwoch, 28. September 2016 21:18 To: Ben Boeckel Cc: Albina, Frank; David E DeMarle; Del Citto, Francesco; paraview@paraview.org<mailto:paraview@paraview.org> Subject: Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR. > My intention is to compile paraview without GUI to run it in batch on > our cluster. This is the main reason why I am using a specific test > suite to check the performance of mesa-llvm vs. mesa-swr vs. GPU. At > the moment, on CPUs supporting AVX2 instruction set, mesa-swr shows a > very decent performance. Hence, my interest also to try out the latest > mesa 12.0.3 version, which I have downloaded today and started > compiling. In this regard, do you have any configuration options you > can share for use in offscreen mode? If this is handled already by the > latest superbuild version, then please disregard the questions above. Chuck (Cc'd) does this quite a bit. There are scripts he has committed which are used to build for specific platforms which you may be able to start using, but he's the best source of instructions for those. Hi Frank, The updated superbuild uses a common shared set of packages that we use for several different projects and then the top level project which is ParaView specific. To use this, you'll want to check out the current master branch in the paraview-superbuild, run "git submodule init", and then "git submodule update". This will put you at the current state of things. You can browse the build script I have committed in Scripts/sites for linux clusters and Cray systems at Los Alamos National Labs and the DoD HPC network. They but they're a bit complicated though as I use them in a very generic fashion with lots of options for a lot of different build configurations. The gist of it though is to encode all of the options you would need to turn on in a pre-configured CMake cache script. Note that this is ac
Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR.
Hi Chuck, Thank you very much for your reply. It is very interesting and I will try my best to get ParaView compiled following your recommendations. Unfortunately, others duties are holding me off this week from concentrating on this but I will share my test results comparing ParaView on GPU, with mesa-llvm and mesa-swr-avx2. Talk to you soon. Best regards, Frank. From: Chuck Atkins [mailto:chuck.atk...@kitware.com] Sent: Mittwoch, 28. September 2016 21:18 To: Ben Boeckel Cc: Albina, Frank; David E DeMarle; Del Citto, Francesco; paraview@paraview.org Subject: Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR. > My intention is to compile paraview without GUI to run it in batch on > our cluster. This is the main reason why I am using a specific test > suite to check the performance of mesa-llvm vs. mesa-swr vs. GPU. At > the moment, on CPUs supporting AVX2 instruction set, mesa-swr shows a > very decent performance. Hence, my interest also to try out the latest > mesa 12.0.3 version, which I have downloaded today and started > compiling. In this regard, do you have any configuration options you > can share for use in offscreen mode? If this is handled already by the > latest superbuild version, then please disregard the questions above. Chuck (Cc'd) does this quite a bit. There are scripts he has committed which are used to build for specific platforms which you may be able to start using, but he's the best source of instructions for those. Hi Frank, The updated superbuild uses a common shared set of packages that we use for several different projects and then the top level project which is ParaView specific. To use this, you'll want to check out the current master branch in the paraview-superbuild, run "git submodule init", and then "git submodule update". This will put you at the current state of things. You can browse the build script I have committed in Scripts/sites for linux clusters and Cray systems at Los Alamos National Labs and the DoD HPC network. They but they're a bit complicated though as I use them in a very generic fashion with lots of options for a lot of different build configurations. The gist of it though is to encode all of the options you would need to turn on in a pre-configured CMake cache script. Note that this is actually a CMake script that sets the initial cache values and not and not just a list of variables like in CMakeCache.txt . See cmake/sites for a few examples. Doing this simplifies your build to just: cd /path/to/build/location cmake -C /path/to/MySystem-Cache.cmake /path/to/superbuild/source # no -j here but don't worry, the subprojects will build in parallel make # Make the resulting ParaView package ctest -R cpack-paraview-TGZ The end result is ParaView-5.1.2-OpenGL2-MPI-Linux-64bit.tar.gz that you can extract anywhere to install. Using ctest to drive the packaging is a bit weird, I know, but trust me that there were various reasons for that which could warrant it's own separate thread. This allows you to keep MySystem-Cache.cmake under source control to maintain a consistent build. For your configuration, the specific options of interest to run on are ENABLE_osmesa and ENABLE_ospray. Our default configuration of osmesa will enable SWR. What you'll end up with is a pvserver / pvbatch that uses OSMesa for off-screen CPU based rendering without X but with both llvmpipe and swr drivers built. You can switch between the by setting the GALLIUM_DRIVER env var to either llvmpipe or swr. Hope that gives you a good place to get started. ___ 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] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR.
Ben, Thank you very much for the information in your email. >> 3. You need a GNU compiler v4.8.0 or above to build. My Linux >> distribution comes with gcc v4.7.2. Fortunately, I had gcc v4.9.2 >> installed with which I could perform a successful build. > What subproject required this? I had to recompile from scractch, which took a bit of time. Actually, the GNU compiler requirement is coming from building the OSPRAY project, as shown hereafter: [...] CMake Error at cmake/gcc.cmake:48 (MESSAGE): GCC version 4.8.0 or greater is required to build OSPRay. Call Stack (most recent call first): cmake/ospray.cmake:97 (INCLUDE) common/CMakeLists.txt:17 (CONFIGURE_OSPRAY) -- Configuring incomplete, errors occurred! [...] > The new superbuild has support for building mesa 12.0.3 as part of the build. > We used prebuilt binaries before because our build machine was Debian 6 which > was not easily capable of compiling the LLVM -> Mesa chain > without a > self-compiled compiler and such, so it was built once and that was it. I > think it did contain SWR since it was a git snapshot. > Utkarsh? As additional information, I have cloned the git repository and did: git checkout origin/release which I then used to build Paraview V5.1.2 along with all dependencies. If the new superbuild has support for building mesa 12.0.3, I would be interested in trying this out. Are there any instructions I can follow to do that? My intention is to compile paraview without GUI to run it in batch on our cluster. This is the main reason why I am using a specific test suite to check the performance of mesa-llvm vs. mesa-swr vs. GPU. At the moment, on CPUs supporting AVX2 instruction set, mesa-swr shows a very decent performance. Hence, my interest also to try out the latest mesa 12.0.3 version, which I have downloaded today and started compiling. In this regard, do you have any configuration options you can share for use in offscreen mode? If this is handled already by the latest superbuild version, then please disregard the questions above. Thanks a lot in advance. Regards, Frank. -Original Message- From: Ben Boeckel [mailto:ben.boec...@kitware.com] Sent: Mittwoch, 28. September 2016 14:45 To: Albina, Frank Cc: David E DeMarle; Del Citto, Francesco; paraview@paraview.org Subject: Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR. On Wed, Sep 28, 2016 at 10:06:15 +0200, Albina, Frank wrote: > In this regard, I would like to point out a few things I have found > while performing the build process on the aforementioned Linux > distribution. Note that my incentive is to help improve the ParaView > software suite as well as helping others to be able to build and use > the software. Thanks for the feedback. Responses inline. > 2. You definitely need cmake at least cmake v3.5 (and not v3.3) to > compile ParaView from SuperBuild. Ah, ParaView is 3.3, but the superbuild is 3.5. As a heads up, the new superbuild which will be used for ParaView 5.2 will require at least 3.6.1. > 3. You need a GNU compiler v4.8.0 or above to build. My Linux > distribution comes with gcc v4.7.2. Fortunately, I had gcc v4.9.2 > installed with which I could perform a successful build. What subproject required this? > 4. Dependencies such libsz, libxml, libbzip2 are built and stored > in the /install/lib64 directory on my platform. This creates > linking issues which I could partly resolve by pushing the missing > libraries into the /install/lib directory. This is not ideal > but could be solved by forcing the lib directory to > /install/lib using the --libdir option. Hrm. I'm on Fedora (which also uses lib64) and though I had gotten all the lib64-isms out of the superbuild. Maybe I had missed some before 5.1.2 (the superbuild now uses common infrastructure shared between other similar superbuilds). > 5. The vistrails plugin cannot be built. After 3 attempts, the git > clone from https://kwgitlab.kitware.com/paraview/vistrails.git fails. > Either the link is wrong or the server is unreachable. vistrails should be hidden behind a "USE_NONFREE_COMPONENTS" flag. vistrails (and acusolve) are not FOSS, so their git repos are on our internal server. > 6. The mesa libraries are pre-compiled and downloaded to > /mesa-downloads. They are unpacked and moved into the ParaView > installation directory when performing “make install”. These libraries > are dating from May 3rd, hence prior to the release of Mesa 12.0 which > embeds OpenSWR as a build option. Is there a way to build new libGL.so > and libOSMesa.so libraries based on Mesa3D v12.0 and replace the > currently pre-compiled binaries? If so,what are the typical > configuration options used in this case? The new superbuild has support for building
Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR.
David, I could manage to get Paraview 5.1.2 compiled using the ParaView superbuild on my Linux desktop running OpenSuSE 12.3. In this regard, I would like to point out a few things I have found while performing the build process on the aforementioned Linux distribution. Note that my incentive is to help improve the ParaView software suite as well as helping others to be able to build and use the software. 1. I found it this page quite useful for having at least a starting point for building ParaView v5.1.2 on Linux: https://cmake.org/Wiki/ParaView/Binaries 2. You definitely need cmake at least cmake v3.5 (and not v3.3) to compile ParaView from SuperBuild. 3. You need a GNU compiler v4.8.0 or above to build. My Linux distribution comes with gcc v4.7.2. Fortunately, I had gcc v4.9.2 installed with which I could perform a successful build. 4. Dependencies such libsz, libxml, libbzip2 are built and stored in the /install/lib64 directory on my platform. This creates linking issues which I could partly resolve by pushing the missing libraries into the /install/lib directory. This is not ideal but could be solved by forcing the lib directory to /install/lib using the --libdir option. 5. The vistrails plugin cannot be built. After 3 attempts, the git clone from https://kwgitlab.kitware.com/paraview/vistrails.git fails. Either the link is wrong or the server is unreachable. 6. The mesa libraries are pre-compiled and downloaded to /mesa-downloads. They are unpacked and moved into the ParaView installation directory when performing “make install”. These libraries are dating from May 3rd, hence prior to the release of Mesa 12.0 which embeds OpenSWR as a build option. Is there a way to build new libGL.so and libOSMesa.so libraries based on Mesa3D v12.0 and replace the currently pre-compiled binaries? If so,what are the typical configuration options used in this case? Any feedback/comments are most welcome. Regards, Frank. From: Albina, Frank Sent: Montag, 26. September 2016 15:51 To: 'David E DeMarle' Cc: paraview@paraview.org; Del Citto, Francesco Subject: RE: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR. Perfect! Thanks. Frank. From: David E DeMarle [mailto:dave.dema...@kitware.com] Sent: Montag, 26. September 2016 15:49 To: Albina, Frank Cc: paraview@paraview.org<mailto:paraview@paraview.org>; Del Citto, Francesco Subject: Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR. 3.3 David E DeMarle Kitware, Inc. R Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Sep 26, 2016 at 9:42 AM, Albina, Frank <frank.alb...@sauber-motorsport.com<mailto:frank.alb...@sauber-motorsport.com>> wrote: Hi David! Thanks for the swift feedback. As I have been compiling ParaView from source for at least the last 6 years, it never came to my mind trying out the super-build. £ I’ll try it out and report if I find myself stuck. By the way, which CMake version do you recommend for building ParaView v5.1.2 from the git repository? Best regards, Frank. From: David E DeMarle [mailto:dave.dema...@kitware.com<mailto:dave.dema...@kitware.com>] Sent: Montag, 26. September 2016 15:37 To: Albina, Frank Cc: paraview@paraview.org<mailto:paraview@paraview.org>; Del Citto, Francesco Subject: Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR. I recommend the ParaView superbuild. All of the incantations that we use to setup and build paraview, mesa and the rest of our dependencies are written down and maintained there. https://gitlab.kitware.com/paraview/paraview-superbuild We've used it for our Desktop binaries for years, and more and more often we use it for our HPC installs as well. David E DeMarle Kitware, Inc. R Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Sep 26, 2016 at 5:17 AM, Albina, Frank <frank.alb...@sauber-motorsport.com<mailto:frank.alb...@sauber-motorsport.com>> wrote: Dear all, after having downloaded last week the latest ParaView release (v5.1.2) for Linux, I have found out that the binary version has the following folder structure in lib/paraview-5.1: mesa-llvm |-- libGL.so -> libGL.so.1 |-- libGL.so.1 -> libGL.so.1.5 |-- libGL.so.1.5 |-- libOSMesa.so -> libOSMesa.so.8 |-- libOSMesa.so.8 -> libOSMesa.so.8.0.0 `-- libOSMesa.so.8.0.0 mesa-swr-avx |-- libGL.so -> libGL.so.1 |-- libGL.so.1 -> libGL.so.1.5 |-- libGL.so.1.5 |-- libOSMesa.so -> libOSMesa.so.8 |-- libOSMesa.so.8 -> libOSMesa.so.8.0.0 `-- libOSMesa.so.8.0.0 mesa-swr-avx2 |-- libGL.so -> libGL.so.1 |-- libGL.so.1 -> libGL.so.1.5 |-- libGL.so.1.5 |-- libOSMesa.so -> libOSMesa.so.8 |-- libOSMesa.so.8 -> libOSMesa.so.8.0.0 `-- libOSMesa.so.8.0.0 Which is an elegant way of providing a binary package for GPU and non-GPU arc
Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR.
Perfect! Thanks. Frank. From: David E DeMarle [mailto:dave.dema...@kitware.com] Sent: Montag, 26. September 2016 15:49 To: Albina, Frank Cc: paraview@paraview.org; Del Citto, Francesco Subject: Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR. 3.3 David E DeMarle Kitware, Inc. R Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Sep 26, 2016 at 9:42 AM, Albina, Frank <frank.alb...@sauber-motorsport.com<mailto:frank.alb...@sauber-motorsport.com>> wrote: Hi David! Thanks for the swift feedback. As I have been compiling ParaView from source for at least the last 6 years, it never came to my mind trying out the super-build. £ I’ll try it out and report if I find myself stuck. By the way, which CMake version do you recommend for building ParaView v5.1.2 from the git repository? Best regards, Frank. From: David E DeMarle [mailto:dave.dema...@kitware.com<mailto:dave.dema...@kitware.com>] Sent: Montag, 26. September 2016 15:37 To: Albina, Frank Cc: paraview@paraview.org<mailto:paraview@paraview.org>; Del Citto, Francesco Subject: Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR. I recommend the ParaView superbuild. All of the incantations that we use to setup and build paraview, mesa and the rest of our dependencies are written down and maintained there. https://gitlab.kitware.com/paraview/paraview-superbuild We've used it for our Desktop binaries for years, and more and more often we use it for our HPC installs as well. David E DeMarle Kitware, Inc. R Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Sep 26, 2016 at 5:17 AM, Albina, Frank <frank.alb...@sauber-motorsport.com<mailto:frank.alb...@sauber-motorsport.com>> wrote: Dear all, after having downloaded last week the latest ParaView release (v5.1.2) for Linux, I have found out that the binary version has the following folder structure in lib/paraview-5.1: mesa-llvm |-- libGL.so -> libGL.so.1 |-- libGL.so.1 -> libGL.so.1.5 |-- libGL.so.1.5 |-- libOSMesa.so -> libOSMesa.so.8 |-- libOSMesa.so.8 -> libOSMesa.so.8.0.0 `-- libOSMesa.so.8.0.0 mesa-swr-avx |-- libGL.so -> libGL.so.1 |-- libGL.so.1 -> libGL.so.1.5 |-- libGL.so.1.5 |-- libOSMesa.so -> libOSMesa.so.8 |-- libOSMesa.so.8 -> libOSMesa.so.8.0.0 `-- libOSMesa.so.8.0.0 mesa-swr-avx2 |-- libGL.so -> libGL.so.1 |-- libGL.so.1 -> libGL.so.1.5 |-- libGL.so.1.5 |-- libOSMesa.so -> libOSMesa.so.8 |-- libOSMesa.so.8 -> libOSMesa.so.8.0.0 `-- libOSMesa.so.8.0.0 Which is an elegant way of providing a binary package for GPU and non-GPU architectures at the same time. Hence my question: How do I build ParaView v5.1.2 from source to have the same folder structure so that I have one version for GPU and software rendering? I understand that swr-avx(2) should be also available from Mesa v12.x. Is there anything I’d need to consider / take care of before building the different OSMesa libraries with LLVM / OpenSWR? Frank Albina ___ Powered by www.kitware.com<http://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
Re: [Paraview] Paraview v5.1.2: SurfaceLIC & software rendering issues
Benson, if you re-distribute, please state in the code where this file originates from. Talking about "parallel computing packages are used in industry", I would really appreciate if this SurfaceLIC benchmark would become a standard benchmark to measure rendering times across a variety of platforms and ParaView versions. This would be also a good candidate benchmark to check new ParaView release candidates, I think. Frank. From: Benson Muite [mailto:benson_mu...@yahoo.com] Sent: Montag, 26. September 2016 15:16 To: Albina, Frank; paraview@paraview.org Cc: Del Citto, Francesco Subject: Re: [Paraview] Paraview v5.1.2: SurfaceLIC & software rendering issues Frank, Will see if can generate an example data set, in case am able to do so, can I redistribute the file (in particular would like to show several students how some of these parallel computing packages are used in industry)? Line 640 makes it difficult to re-distribute. Benson On 09/26/2016 03:23 PM, Albina, Frank wrote: Benson, I won't be able to provide you with the dataset you are requesting since the IP is protected. I might be able to provide it to Kitware for debugging purposes with the condition of not distributing it to any third parties. However, I can access your request to share the benchmarking code. Please find attached the code I am using for my benchmark. Hope you will find it useful. Nonetheless, I would it useful if someone could point me towards a resolution of the issue I reported in my original email. Regards, Frank. From: Benson Muite [mailto:benson_mu...@yahoo.com] Sent: Montag, 26. September 2016 11:30 To: Albina, Frank; paraview@paraview.org<mailto:paraview@paraview.org> Cc: Del Citto, Francesco Subject: Re: [Paraview] Paraview v5.1.2: SurfaceLIC & software rendering issues Both would be great if possible. On 09/26/2016 12:22 PM, Albina, Frank wrote: Benson, do you need the data and the example code, or only the example code? Frank. From: Benson Muite [mailto:benson_mu...@yahoo.com] Sent: Montag, 26. September 2016 11:17 To: Albina, Frank; paraview@paraview.org<mailto:paraview@paraview.org> Cc: Del Citto, Francesco Subject: Re: [Paraview] Paraview v5.1.2: SurfaceLIC & software rendering issues Hi, Is the benchmark available? Would be interested in looking at this if possible to get example code. Regards, Benson On 09/26/2016 11:55 AM, Albina, Frank wrote: Dear all, I have downloaded from the paraview.org the latest binaries for Linux of ParaView v5.1.2. My main purpose is to make use of ParaView with software rendering in a clustered environment without GPU and, as such, I have been going through my small benchmark on a generic F1 car. This what I have found so far when generating a SurfaceLIC representation on the whole car surface in batch mode. Using pvbatch -mesa-llvm works fine. This is one of the produced images for reference: [cid:image001.jpg@01D2180D.86C9A890] Using 4 cores to perform the same task (with the same script) with mpiexec -np 4 pvbatch --mesa-llvm shows a good speed-up but the background is black instead of white (although view.Backgound = [1,1,1] is set explicitely), as shown hereafter: [cid:image002.jpg@01D2180D.86C9A890] On the same server (Intel Xeon ES-2650 v3), the CPU is AVX2 capable, so I tried also the same script with pvbatch --mesa-swr-avx2. The image background is corrupted with leftover frames apparently, as shown hereafter: [cid:image003.jpg@01D2180D.86C9A890] Was this behavior to be expected? Please let me know if there is any interest in providing with my benchmark. Frank Albina ___ Powered by www.kitware.com<http://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
Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR.
Hi David! Thanks for the swift feedback. As I have been compiling ParaView from source for at least the last 6 years, it never came to my mind trying out the super-build. £ I’ll try it out and report if I find myself stuck. By the way, which CMake version do you recommend for building ParaView v5.1.2 from the git repository? Best regards, Frank. From: David E DeMarle [mailto:dave.dema...@kitware.com] Sent: Montag, 26. September 2016 15:37 To: Albina, Frank Cc: paraview@paraview.org; Del Citto, Francesco Subject: Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR. I recommend the ParaView superbuild. All of the incantations that we use to setup and build paraview, mesa and the rest of our dependencies are written down and maintained there. https://gitlab.kitware.com/paraview/paraview-superbuild We've used it for our Desktop binaries for years, and more and more often we use it for our HPC installs as well. David E DeMarle Kitware, Inc. R Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Sep 26, 2016 at 5:17 AM, Albina, Frank <frank.alb...@sauber-motorsport.com<mailto:frank.alb...@sauber-motorsport.com>> wrote: Dear all, after having downloaded last week the latest ParaView release (v5.1.2) for Linux, I have found out that the binary version has the following folder structure in lib/paraview-5.1: mesa-llvm |-- libGL.so -> libGL.so.1 |-- libGL.so.1 -> libGL.so.1.5 |-- libGL.so.1.5 |-- libOSMesa.so -> libOSMesa.so.8 |-- libOSMesa.so.8 -> libOSMesa.so.8.0.0 `-- libOSMesa.so.8.0.0 mesa-swr-avx |-- libGL.so -> libGL.so.1 |-- libGL.so.1 -> libGL.so.1.5 |-- libGL.so.1.5 |-- libOSMesa.so -> libOSMesa.so.8 |-- libOSMesa.so.8 -> libOSMesa.so.8.0.0 `-- libOSMesa.so.8.0.0 mesa-swr-avx2 |-- libGL.so -> libGL.so.1 |-- libGL.so.1 -> libGL.so.1.5 |-- libGL.so.1.5 |-- libOSMesa.so -> libOSMesa.so.8 |-- libOSMesa.so.8 -> libOSMesa.so.8.0.0 `-- libOSMesa.so.8.0.0 Which is an elegant way of providing a binary package for GPU and non-GPU architectures at the same time. Hence my question: How do I build ParaView v5.1.2 from source to have the same folder structure so that I have one version for GPU and software rendering? I understand that swr-avx(2) should be also available from Mesa v12.x. Is there anything I’d need to consider / take care of before building the different OSMesa libraries with LLVM / OpenSWR? Frank Albina ___ Powered by www.kitware.com<http://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
Re: [Paraview] Paraview v5.1.2: SurfaceLIC & software rendering issues
Benson, I won't be able to provide you with the dataset you are requesting since the IP is protected. I might be able to provide it to Kitware for debugging purposes with the condition of not distributing it to any third parties. However, I can access your request to share the benchmarking code. Please find attached the code I am using for my benchmark. Hope you will find it useful. Nonetheless, I would it useful if someone could point me towards a resolution of the issue I reported in my original email. Regards, Frank. From: Benson Muite [mailto:benson_mu...@yahoo.com] Sent: Montag, 26. September 2016 11:30 To: Albina, Frank; paraview@paraview.org Cc: Del Citto, Francesco Subject: Re: [Paraview] Paraview v5.1.2: SurfaceLIC & software rendering issues Both would be great if possible. On 09/26/2016 12:22 PM, Albina, Frank wrote: Benson, do you need the data and the example code, or only the example code? Frank. From: Benson Muite [mailto:benson_mu...@yahoo.com] Sent: Montag, 26. September 2016 11:17 To: Albina, Frank; paraview@paraview.org<mailto:paraview@paraview.org> Cc: Del Citto, Francesco Subject: Re: [Paraview] Paraview v5.1.2: SurfaceLIC & software rendering issues Hi, Is the benchmark available? Would be interested in looking at this if possible to get example code. Regards, Benson On 09/26/2016 11:55 AM, Albina, Frank wrote: Dear all, I have downloaded from the paraview.org the latest binaries for Linux of ParaView v5.1.2. My main purpose is to make use of ParaView with software rendering in a clustered environment without GPU and, as such, I have been going through my small benchmark on a generic F1 car. This what I have found so far when generating a SurfaceLIC representation on the whole car surface in batch mode. Using pvbatch -mesa-llvm works fine. This is one of the produced images for reference: [cid:image001.jpg@01D21801.1883A400] Using 4 cores to perform the same task (with the same script) with mpiexec -np 4 pvbatch --mesa-llvm shows a good speed-up but the background is black instead of white (although view.Backgound = [1,1,1] is set explicitely), as shown hereafter: [cid:image002.jpg@01D21801.1883A400] On the same server (Intel Xeon ES-2650 v3), the CPU is AVX2 capable, so I tried also the same script with pvbatch --mesa-swr-avx2. The image background is corrupted with leftover frames apparently, as shown hereafter: [cid:image003.jpg@01D21801.1883A400] Was this behavior to be expected? Please let me know if there is any interest in providing with my benchmark. Frank Albina ___ Powered by www.kitware.com<http://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 renderBenchmarkSurfaceLIC.py Description: renderBenchmarkSurfaceLIC.py ___ 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] Paraview v5.1.2: SurfaceLIC & software rendering issues
Benson, do you need the data and the example code, or only the example code? Frank. From: Benson Muite [mailto:benson_mu...@yahoo.com] Sent: Montag, 26. September 2016 11:17 To: Albina, Frank; paraview@paraview.org Cc: Del Citto, Francesco Subject: Re: [Paraview] Paraview v5.1.2: SurfaceLIC & software rendering issues Hi, Is the benchmark available? Would be interested in looking at this if possible to get example code. Regards, Benson On 09/26/2016 11:55 AM, Albina, Frank wrote: Dear all, I have downloaded from the paraview.org the latest binaries for Linux of ParaView v5.1.2. My main purpose is to make use of ParaView with software rendering in a clustered environment without GPU and, as such, I have been going through my small benchmark on a generic F1 car. This what I have found so far when generating a SurfaceLIC representation on the whole car surface in batch mode. Using pvbatch -mesa-llvm works fine. This is one of the produced images for reference: [cid:image001.jpg@01D217E8.426FCB40] Using 4 cores to perform the same task (with the same script) with mpiexec -np 4 pvbatch --mesa-llvm shows a good speed-up but the background is black instead of white (although view.Backgound = [1,1,1] is set explicitely), as shown hereafter: [cid:image002.jpg@01D217E8.426FCB40] On the same server (Intel Xeon ES-2650 v3), the CPU is AVX2 capable, so I tried also the same script with pvbatch --mesa-swr-avx2. The image background is corrupted with leftover frames apparently, as shown hereafter: [cid:image003.jpg@01D217E8.426FCB40] Was this behavior to be expected? Please let me know if there is any interest in providing with my benchmark. Frank Albina ___ Powered by www.kitware.com<http://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
[Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR.
Dear all, after having downloaded last week the latest ParaView release (v5.1.2) for Linux, I have found out that the binary version has the following folder structure in lib/paraview-5.1: mesa-llvm |-- libGL.so -> libGL.so.1 |-- libGL.so.1 -> libGL.so.1.5 |-- libGL.so.1.5 |-- libOSMesa.so -> libOSMesa.so.8 |-- libOSMesa.so.8 -> libOSMesa.so.8.0.0 `-- libOSMesa.so.8.0.0 mesa-swr-avx |-- libGL.so -> libGL.so.1 |-- libGL.so.1 -> libGL.so.1.5 |-- libGL.so.1.5 |-- libOSMesa.so -> libOSMesa.so.8 |-- libOSMesa.so.8 -> libOSMesa.so.8.0.0 `-- libOSMesa.so.8.0.0 mesa-swr-avx2 |-- libGL.so -> libGL.so.1 |-- libGL.so.1 -> libGL.so.1.5 |-- libGL.so.1.5 |-- libOSMesa.so -> libOSMesa.so.8 |-- libOSMesa.so.8 -> libOSMesa.so.8.0.0 `-- libOSMesa.so.8.0.0 Which is an elegant way of providing a binary package for GPU and non-GPU architectures at the same time. Hence my question: How do I build ParaView v5.1.2 from source to have the same folder structure so that I have one version for GPU and software rendering? I understand that swr-avx(2) should be also available from Mesa v12.x. Is there anything I'd need to consider / take care of before building the different OSMesa libraries with LLVM / OpenSWR? Frank Albina ___ 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] Paraview v5.1.2: SurfaceLIC & software rendering issues
Dear all, I have downloaded from the paraview.org the latest binaries for Linux of ParaView v5.1.2. My main purpose is to make use of ParaView with software rendering in a clustered environment without GPU and, as such, I have been going through my small benchmark on a generic F1 car. This what I have found so far when generating a SurfaceLIC representation on the whole car surface in batch mode. Using pvbatch -mesa-llvm works fine. This is one of the produced images for reference: [cid:image001.jpg@01D217E4.08171B00] Using 4 cores to perform the same task (with the same script) with mpiexec -np 4 pvbatch --mesa-llvm shows a good speed-up but the background is black instead of white (although view.Backgound = [1,1,1] is set explicitely), as shown hereafter: [cid:image002.jpg@01D217E4.08171B00] On the same server (Intel Xeon ES-2650 v3), the CPU is AVX2 capable, so I tried also the same script with pvbatch --mesa-swr-avx2. The image background is corrupted with leftover frames apparently, as shown hereafter: [cid:image003.jpg@01D217E4.08171B00] Was this behavior to be expected? Please let me know if there is any interest in providing with my benchmark. Frank Albina ___ 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] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5
Dear All! Sorry for the delay in the reply, but I had a very long Christmas break and I just came back a few days ago. I managed to compile OpenSWR with Osmesa support using the autotools but it was not much faster than any of the OSMesa versions I tried, i.e. v10.5.5 and 11.0.7. I compiled the OpenSWR with libglx support and that might be the reason why the performance I experience is not so good as expected. I have included hereafter the configure options I used on my CentOS 6.5 platform for reference: ./configure --prefix= --enable-gallium-osmesa --enable-dependency-tracking --enable-gallium-llvm=yes --enable-llvm-shared-libs --enable-swr-native --enable-sysfs --enable-texture-float --disable-dri --disable-egl --disable-glx --disable-gles1 --disable-gles2 --disable-opencl --disable-vdpau --disable-va --disable-xvmc --with-dri-drivers= --with-egl-platforms= --with-gallium-drivers=swr,swrast --with-gnu-ld --with-osmesa-bits=8 --with-swr-arch=CORE_AVX2 Hope this helps bringing a bit of clarity. Nonetheless, I was already very pleased with the improved rendering performance using the RC2 version. Now that PV 5.0.0 has been released, I will proceed to installation and repeat my benchmarks, the outcome of which I will be feeding back of course. Cheers, Frank Albina From: Chuck Atkins [mailto:chuck.atk...@kitware.com] Sent: Freitag, 8. Januar 2016 20:41 To: Utkarsh Ayachit Cc: Albina, Frank; paraview@paraview.org Subject: Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5 Hi Frank, The easiest way to build OpenSWR is probably to use the SCons build instead of autotools. Here's a docker file we use to generate re-distributable libGL and libOSMesa binaries: https://github.com/chuckatkins/mesa-builds/blob/master/Dockerfile . In short though, you'll want to do the following: git clone https://github.com/OpenSWR/openswr-mesa.git mesa-swr cd mesa-swr scons build=release texture_float=yes swr_arch=core-avx2 libgl-xlib osmesa The libgl-xlib target will create a build/linux-x86_64/gallium/targets/libgl-xlib/libGL.so.1.5 output and the osmesa target will create a build/linux-x86_64/gallium/targets/osmesa/libosmesa.so output. You can also change swr_arch=core-avx2 to swr_arch=avx if you want to build for AVX instead of AVX2. - Chuck On Tue, Dec 22, 2015 at 10:14 AM, Utkarsh Ayachit <utkarsh.ayac...@kitware.com<mailto:utkarsh.ayac...@kitware.com>> wrote: > Also, thank you for liaising with the OpenSWR team in order to check if they > support or plan supporting OSMESA. Frank, I am told that OpenSWR on Github should work with OSMesa. I haven't tried it out myself, will give it a go once I get the a few other issues ironed out. Just wanted to let you know if you wanted to give it another go. Utkarsh ___ Powered by www.kitware.com<http://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
[Paraview] Paraview v5.0.0-rc2 with OpenGL2 backend failing to start in parallel
Dear all! I recompiled Paraview-v5.0.0-rc2 from scratch using OpenMPI v1.6.5 and GCC v4.7.2 on my workstation. The QT & Python versions are the default system versions and are resp. 4.8.4 & 2.7.3. After successful compilation and installation, I start 8 parallel pvserver instances with: mpirun -np 8 pvserver -sp=7436 Then, I start paraview and connect to the server running on the same machine. After connection is established, paraview fails with a segmentation fault. Waiting for client... Connection URL: cs://ws334:7436 Accepting connection(s): ws334:7436 Client connected. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Parallel/Core/vtkSocketCommunicator.cxx, line 809 vtkSocketCommunicator (0x2b7a600): Could not receive tag. 1 ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. [...] ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. -- mpirun noticed that process rank 0 with PID 13964 on node ws334 exited on signal 11 (Segmentation fault). -- I have included hereafter how Paraview was compiled: cmake $sourceDir \ -DBUILD_SHARED_LIBS:BOOL=ON\ -DBUILD_TESTING:BOOL=OFF\ -DBUILD_DOCUMENTATION:BOOL=ON\ -DCMAKE_BUILD_TYPE:STRING=Release\ -DPARAVIEW_ENABLE_CATALYST:BOOL=ON\ -DPARAVIEW_ENABLE_VTK_MODULES_AS_NEEDED:BOOL=TRUE\ -DPARAVIEW_USE_MPI:BOOL=ON\ -DPARAVIEW_USE_UNIFIED_BINDINGS:BOOL=ON\ -DPARAVIEW_ENABLE_WEB:BOOL=ON\ -DVTK_OPENGL_HAS_OSMESA:BOOL=OFF\ -DPARAVIEW_BUILD_PLUGIN_SurfaceLIC:BOOL=TRUE\ -DPARAVIEW_ENABLE_VTK_MODULES_AS_NEEDED:BOOL=TRUE\ -DVTK_USE_OFFSCREEN:BOOL=OFF\ -DVTK_USE_X:BOOL=ON\ -DVTK_USE_QT=ON\ -DVTK_USE_DISPLAY=ON\ -DVTK_USE_GUI_SUPPORT:BOOL=ON\ -DPARAVIEW_BUILD_QT_GUI:BOOL=ON\ -DCMAKE_INSTALL_PREFIX:PATH=$installDir\ -DPARAVIEW_ENABLE_PYTHON:BOOL=ON\ -DPYTHON_ENABLE_MODULE_MPIPython:BOOL=ON\ -DQT_QMAKE_EXECUTABLE:FILEPATH=/usr/bin/qmake\ -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2\ -DPYTHON_INCLUDE_DIR:FILEPATH=/usr/include/python2.7\ -DPYTHON_LIBRARY:FILEPATH=/usr/lib64/libpython2.7.so\ -DPYTHON_UTIL_LIBRARY:FILEPATH=/usr/lib64/libutil.so\ -DVTK_RENDERING_BACKEND:STRING=OpenGL2\ -DModule_vtkRenderingLICOpenGL2:BOOL=ON I must have missed something since I guess that Paraview using parallel servers should run, even when there is only one GPU available. Any hints would be greatly appreciated. Best regards, Frank Albina ___ 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] Paraview v5.0.0-rc2 with OpenGL2 backend failing to start in parallel
Hi Cory! I have compiled the source code from the Paraview v5.0.0-RC2 source files that I downloaded earlier this week from http://www.paraview.org/download/. No GIT repository there and none to be found in the top-level directory of the source files. Paraview client & server are from the same build, since I am starting both server and client from the same command line on the (Linux) workstation, hence I am using the same environement. HTH, Frank. From: Cory Quammen [mailto:cory.quam...@kitware.com] Sent: Freitag, 18. Dezember 2015 15:08 To: Albina, Frank Cc: paraview@paraview.org Subject: Re: [Paraview] Paraview v5.0.0-rc2 with OpenGL2 backend failing to start in parallel Hi Frank, Since you said you recompiled ParaView, I suspect that maybe you forgot to update the submodules ParaView uses. In the ParaView source tree, run git status If VTK is listed, it may say there are new commits available for VTK. To update VTK, run git submodule update This has been an issue a few folks have encountered in the past. Also, double-check that your ParaView client and server are truly from the same build. HTH, Cory On Fri, Dec 18, 2015 at 8:30 AM, Albina, Frank <frank.alb...@sauber-motorsport.com<mailto:frank.alb...@sauber-motorsport.com>> wrote: Dear all! I recompiled Paraview-v5.0.0-rc2 from scratch using OpenMPI v1.6.5 and GCC v4.7.2 on my workstation. The QT & Python versions are the default system versions and are resp. 4.8.4 & 2.7.3. After successful compilation and installation, I start 8 parallel pvserver instances with: mpirun –np 8 pvserver –sp=7436 Then, I start paraview and connect to the server running on the same machine. After connection is established, paraview fails with a segmentation fault. Waiting for client... Connection URL: cs://ws334:7436 Accepting connection(s): ws334:7436 Client connected. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Parallel/Core/vtkSocketCommunicator.cxx, line 809 vtkSocketCommunicator (0x2b7a600): Could not receive tag. 1 ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. […] ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. -- mpirun noticed that process rank 0 with PID 13964 on node ws334 exited on signal 11 (Segmentation fault). -- I have included hereafter how Paraview was compiled: cmake $sourceDir \ -DBUILD_SHARED_LIBS:BOOL=ON\ -DBUILD_TESTING:BOOL=OFF\ -DBUILD_DOCUMENTATION:BOOL=ON\ -DCMAKE_BUILD_TYPE:STRING=Release\ -DPARAVIEW_ENABLE_CATALYST:BOOL=ON\ -DPARAVIEW_ENABLE_VTK_MODULES_AS_NEEDED:BOOL=TRUE\ -DPARAVIEW_USE_MPI:BOOL=ON\ -DPARAVIEW_USE_UNIFIED_BINDINGS:BOOL=ON\ -DPARAVIEW_ENABLE_WEB:BOOL=ON\ -DVTK_OPENGL_HAS_OSMESA:BOOL=OFF\ -DPARAVIEW_BUILD_PLUGIN_SurfaceLIC:BOOL=TRUE\ -DPARAVIEW_ENABLE_VTK_MODULES_AS_NEEDED:BOOL=TRUE\ -DVTK_USE_OFFSCREEN:BOOL=OFF\ -DVTK_USE_X:BOOL=ON\ -DVTK_USE_QT=ON\ -DVTK_USE_DISPLAY=ON\ -DVTK_USE_GUI_SUPPORT:BOOL=ON\ -DPARAVIEW_BUILD_QT_GUI:BOOL=ON\ -DCMAKE_INSTALL_PREFIX:PATH=$installDir\ -DPARAVIEW_ENABLE_PYTHON:BOOL=ON\ -DPYTHON_ENABLE_MODULE_MPIPython:BOOL=ON\ -DQT_QMAKE_EXECUTABLE:FILEPATH=/usr/bin/qmake\ -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2\ -DPYTHON_INCLUDE_DIR:FILEPATH=/usr/include/python2.7\ -DPYTHON_LIBRARY:FILEPATH=/usr/lib64/libpython2.7.so<http://libpython2.7.so>\ -DPYTHON_UTIL_LIBRARY:FILEPATH=/usr/lib64/libutil.so\ -DVTK_RENDERING_BACKEND:STRING=OpenGL2\ -DModule_vtkRende
Re: [Paraview] Paraview v5.0.0-rc2 with OpenGL2 backend failing to start in parallel
Hi Cory! Thank you very much for that. As said earlier in another post, I am very keen to see PV v5.0.0 release so I am happy to help and report issues before the new version gets unleashed. Cheers, Frank. From: Cory Quammen [mailto:cory.quam...@kitware.com] Sent: Freitag, 18. Dezember 2015 15:39 To: Albina, Frank Cc: paraview@paraview.org Subject: Re: [Paraview] Paraview v5.0.0-rc2 with OpenGL2 backend failing to start in parallel Frank, Thanks for the info on where you got the code. Maybe there's a problem with the source packaging? I'll try out that download and see if I can reproduce the problem. Thanks, Cory On Fri, Dec 18, 2015 at 9:15 AM, Albina, Frank <frank.alb...@sauber-motorsport.com<mailto:frank.alb...@sauber-motorsport.com>> wrote: Hi Cory! I have compiled the source code from the Paraview v5.0.0-RC2 source files that I downloaded earlier this week from http://www.paraview.org/download/. No GIT repository there and none to be found in the top-level directory of the source files. Paraview client & server are from the same build, since I am starting both server and client from the same command line on the (Linux) workstation, hence I am using the same environement. HTH, Frank. From: Cory Quammen [mailto:cory.quam...@kitware.com<mailto:cory.quam...@kitware.com>] Sent: Freitag, 18. Dezember 2015 15:08 To: Albina, Frank Cc: paraview@paraview.org<mailto:paraview@paraview.org> Subject: Re: [Paraview] Paraview v5.0.0-rc2 with OpenGL2 backend failing to start in parallel Hi Frank, Since you said you recompiled ParaView, I suspect that maybe you forgot to update the submodules ParaView uses. In the ParaView source tree, run git status If VTK is listed, it may say there are new commits available for VTK. To update VTK, run git submodule update This has been an issue a few folks have encountered in the past. Also, double-check that your ParaView client and server are truly from the same build. HTH, Cory On Fri, Dec 18, 2015 at 8:30 AM, Albina, Frank <frank.alb...@sauber-motorsport.com<mailto:frank.alb...@sauber-motorsport.com>> wrote: Dear all! I recompiled Paraview-v5.0.0-rc2 from scratch using OpenMPI v1.6.5 and GCC v4.7.2 on my workstation. The QT & Python versions are the default system versions and are resp. 4.8.4 & 2.7.3. After successful compilation and installation, I start 8 parallel pvserver instances with: mpirun –np 8 pvserver –sp=7436 Then, I start paraview and connect to the server running on the same machine. After connection is established, paraview fails with a segmentation fault. Waiting for client... Connection URL: cs://ws334:7436 Accepting connection(s): ws334:7436 Client connected. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Parallel/Core/vtkSocketCommunicator.cxx, line 809 vtkSocketCommunicator (0x2b7a600): Could not receive tag. 1 ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. […] ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. ERROR: In /cfdcode/opensuse12/opt/ParaView/SRC/paraview-5.0.0-rc2/VTK/Common/System/vtkSocket.cxx, line 572 vtkClientSocket (0x293e940): Socket error in call to send. Broken pipe. -- mpirun noticed that process rank 0 with PID 13964 on node ws334 exited on signal 11 (Segmentation fault). -- I have included hereafter how Paraview was compiled: cmake $sourceDir \ -DBUILD_SHARED_LIBS:BOOL=ON\ -DBUILD_TESTING:BOOL=OFF\ -DBUILD_DOCUMENTATION:BOOL=ON\ -DCMAKE_BUILD_TYPE:STRING=Release\ -DPARAVIEW_ENABLE_CATALYST:BOOL=ON\ -DPARAVIEW_ENABLE_VTK_MODULES_AS_NEEDED:BOOL=TRUE\ -DPARAVIEW_USE_MPI:BOOL=ON\ -DPARAVIEW_USE_UNIFIED_BINDINGS:BOOL=ON\ -DPARAVIEW_ENABLE_WEB:BOOL=ON\ -DVTK_OPENGL_HAS_OSMESA:BOOL=OFF\
Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5
Dear Utkarsh! Thank you very much for your swift reply and for sending the patch to the MESA libraries. I will apply it asap. Also, thank you for liaising with the OpenSWR team in order to check if they support or plan supporting OSMESA. It is of interest for us, since any gain in reducing rendering times during post-processing of our simulations has a substantial impact in the longer term on the number of simulations we can perform (i.e. less time spent in post-processing means that there are more resources left for running simulations). Concerning the surfaceLIC, we are using it primarily on GPUs but it would have been great to have the possibility to switch to software rendering under ParaView 5.0.0. This was also motivated by the fact that the software has made a good step in reducing rendering times. To underline this, below is a summary of the rendering times in seconds for generating 60 pressure-contours images on the same compute cluster: Paraview 3.8.1 Paraview 4.3.1 Paraview 5.0.0-rc2 Intel MPI 5.0.1.035 Intel MPI 5.0.1.035 Intel MPI 5.0.1.035 MESA v10.5.5MESA v10.5.5llvm-MESA-11.0.7 Cores python v2.7.8 python v2.7.8 python v2.7.10 1 339.32 502.49320.29 2 177.62 276.19 86.43 4 95.91 142.9450.64 8 57.17 87.4733.71 16 34.91 50.4926.12 32 22.51 32.4417.36 Basically, I can't wait to get my hands on the new ParaView release. On my side I will continue today to perform additional tests which are part of the way we use ParaView on our compute cluster. I'll keep you posted on that . Talk to you soon. Frank. -Original Message- From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com] Sent: Donnerstag, 17. Dezember 2015 19:05 To: Albina, Frank Cc: paraview@paraview.org Subject: Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5 Frank, First of all, thanks for all your exhausting testing, it's greatly appreciated! * OSMesa and MESA_GL_VERSION_OVERRIDE Communicating with the Mesa team, we learnt that MESA_GL_VERSION_OVERRIDE is a bad idea since it doesnt' really create the specified OpenGL context. Thus if anything tries to use features from the specific OpenGL version, the rendering would crash and burn. Working with Brian Paul from the Mesa team, Ken recently pushed a fix to VTK (after the RC2) that uses new OSMesa API to create the correct OpenGL context. This new OSMesa API will appear in Mesa 11.2, however. Earlier version can be patched using the "alpha" patch that Brian provided us (attached). * Classic v/s llvm Your observation is indeed correct. llvmpipe is the way to go for software rendering. On my builds, classic mesa was painstakingly slow for rendering even small geometries. * Issues with LIC Another correct observation. There are a few regressions in the new implementation for SurfaceLIC. Realistically, we may not be able to address these before the 5.0 release. If you're using SurfaceLIC heavily, I'd suggest building ParaView 5.0 with the older OpenGL backend (or sticking with 4.4) for the interim. * OSMesa + SWR While currently I am not sure openswr+osmesa builds are possible, I wouldn't be surprised if that on the roadmap. I am going to try to contact the OpenSWR team to see if they have any thoughts on that. Utkarsh ___ 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] 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, Frank Cc: Ken Martin; paraview@paraview.org Subject: 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 which parallel communication library is going to be > used on the end user's compute platform. > > If the binaries ship with SWR using prebuilt mesa binaries, is there > any documentation on how to build the mesa binaries with SWR support? > I might eventually figure it out by myself (or not) but I would be grateful > for any hints. Here's the relevant subset of the Dockerfile Utkarsh used: #-- WORKDIR /opt/tools/src/openswr-mesa RUN git clone https://github.com/OpenSWR/openswr-mesa.git src-avx2 --depth 1 -b 11.0-openswr WORKDIR /opt/tools/src/openswr-mesa/src-avx2 RUN scons build=release texture_float=yes swr_arch=core-avx2 libgl-xlib WORKDIR /opt/tools/mesa-swr-avx2 RUN cp /opt/tools/src/openswr-mesa/src-avx2/build/linux-x86_64/gallium/targets/libgl-xlib/libGL.so.1.5 . && \ ln -s libGL.so.1 libGL.so && \ ln -s libGL.so.1.5 libGL.so.1 #-- WORKDIR /opt/tools/src/openswr-mesa RUN git clone https://github.com/OpenSWR/openswr-mesa.git src-avx --depth 1 -b 11.0-openswr WORKDIR /opt/tools/src/openswr-mesa/src-avx RUN scons build=release texture_float=yes swr_arch=avx libgl-xlib WORKDIR /opt/tools/mesa-swr-avx RUN cp /opt/tools/src/openswr-mesa/src-avx/build/linux-x86_64/gallium/targets/libgl-xlib/libGL.so.1.5 . && \ ln -s libGL.so.1 libGL.so && \ ln -s libGL.so.1.5 libGL.so.1 --Ben ___ 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] 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 repeated the test over a few
different GPUs and got the same results.
Which brought me to thinking that similar performance improvements could be
also achieved when performing software rendering with the MESA libraries. I
downloaded the PV sources for the 5.0.0-RC1 release yesterday and compiled it
with MESA and MPI support. MPI version is Intel 5.0.1 and MESA version is
10.5.5. The MESA libraries are compiled using:
./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 --enable-dependency-tracking
--with-gallium-drivers="" --with-dri-drivers="" --with-egl-platforms=""
Which corresponds to a "classic" compilation without LLVM support. Believe it
or not, this was found to run faster on our CPU cluster than with the LLVM
drivers.
After linking PV 5.0.0 against the MESA libs with the OpenGL2 backend, I
started running a simple benchmark to check possible performance benefits and
here is the error output I got:
GL_Version: 2.1 Mesa 10.5.5
Warning: In
/panfs/srvpan01/code/repo/build/paraview-5.0.0-rc1/src/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx,
line 549
vtkOSOpenGLRenderWindow (0x3c0eef60): VTK is designed to work with OpenGL
version 3.2 but it appears it has been given a context that does not support
3.2. VTK will run in a compatibility mode designed to work with OpenGL 2.1 but
some features may not work.
ERROR: In
/panfs/srvpan01/code/repo/build/paraview-5.0.0-rc1/src/VTK/Rendering/OpenGL2/vtkShaderProgram.cxx,
line 369
vtkShaderProgram (0x4d4dbfe0): 1: #version 120
2: #extension GL_EXT_gpu_shader4 : require
3: #define highp
4: #define mediump
5: #define lowp
6:
7: /*=
8:
9: Program: Visualization Toolkit
10: Module:vtkPolyDataFS.glsl
11:
12: Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen
13: All rights reserved.
14: See Copyright.txt or http://www.kitware.com/Copyright.htm for details.
15:
16: This software is distributed WITHOUT ANY WARRANTY; without even
17: the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
18: PURPOSE. See the above copyright notice for more information.
19:
20: =*/
21: // Template for the polydata mappers fragment shader
22:
23: uniform int PrimitiveIDOffset;
24:
25: // VC position of this fragment
26: varying vec4 vertexVCVSOutput;
27:
28: // optional color passed in from the vertex shader, vertexColor
29: uniform bool OverridesColor;
30: uniform float opacityUniform; // the fragment opacity
31: uniform vec3 ambientColorUniform; // intensity weighted color
32: uniform vec3 diffuseColorUniform; // intensity weighted color
33: uniform vec3 specularColorUniform; // intensity weighted color
34: uniform float specularPowerUniform;
35:
36:
37: // optional surface normal declaration
38: uniform int cameraParallel;
39:
40: // extra lighting parameters
41: uniform int numberOfLights;
42: uniform vec3 lightColor[6];
43: uniform vec3 lightDirectionVC[6]; // normalized
44: uniform vec3 lightHalfAngleVC[6]; // normalized
45:
46: // Texture coordinates
47: varying vec2 tcoordVCVSOutput; uniform sampler2D texture1;
48:
49: // picking support
50: //VTK::Picking::Dec
51:
52: // Depth Peeling Support
53: //VTK::DepthPeeling::Dec
54:
55: // clipping plane vars
56: //VTK::Clip::Dec
57:
58: // the output of this shader
59: //VTK::Output::Dec
60:
61: // Apple Bug
62: //VTK::PrimID::Dec
63:
64: void main()
65: {
66: // Apple Bug
67: //VTK::PrimID::Impl
68:
69: //VTK::Clip::Impl
70:
71: vec3 ambientColor;
72: vec3 diffuseColor;
73: float opacity;
74: vec3 specularColor;
75: float specularPower;
76: ambientColor = ambientColorUniform;
77: diffuseColor = diffuseColorUniform;
78: opacity = opacityUniform;
79: specularColor = specularColorUniform;
80: specularPower = specularPowerUniform;
81: vec4 texColor = texture2D(texture1, tcoordVCVSOutput.st);
82: diffuseColor = texColor.rgb;
83: opacity = opacity*texColor.a;
84: if (OverridesColor) {
85: ambientColor = ambientColorUniform;
86: diffuseColor = diffuseColorUniform; }
87:
88:
89: // VC position of this fragment
90: vec4 vertexVC = vertexVCVSOutput;
91:
92: // Generate the normal if we are not passed in one
93: vec3 fdx =
normalize(vec3(dFdx(vertexVC.x),dFdx(vertexVC.y),dFdx(vertexVC.z)));
94: vec3 fdy =
normalize(vec3(dFdy(vertexVC.x),dFdy(vertexVC.y),dFdy(vertexVC.z)));
95:
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 the MESA_GL_VERSION_OVERRIDE. I will therefore arrange to compile a newer MESA version and re-compile PV-5.0.0-rc1 and will let you know the outcome. If everything runs smoothly, I should be able to give you feedback on what the results of my test benchmarks are. Cheers, Fran,. From: Aashish Chaudhary [mailto:aashish.chaudh...@kitware.com] Sent: Donnerstag, 10. Dezember 2015 15:55 To: Ken Martin Cc: Albina, Frank; paraview@paraview.org Subject: 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 <ken.mar...@kitware.com<mailto:ken.mar...@kitware.com>> wrote: 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 ( http://openswr.org/ ) might give the best software rendering performance. I think it requires a more recent version of Mesa, we suggest Mesa 10.6.5 or later for VTK. Other 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 :-) Thanks Ken On Thu, Dec 10, 2015 at 8:47 AM, Albina, Frank <frank.alb...@sauber-motorsport.com<mailto:frank.alb...@sauber-motorsport.com>> wrote: 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 repeated the test over a few different GPUs and got the same results. Which brought me to thinking that similar performance improvements could be also achieved when performing software rendering with the MESA libraries. I downloaded the PV sources for the 5.0.0-RC1 release yesterday and compiled it with MESA and MPI support. MPI version is Intel 5.0.1 and MESA version is 10.5.5. The MESA libraries are compiled using: ./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 --enable-dependency-tracking --with-gallium-drivers=”” --with-dri-drivers=”” --with-egl-platforms=”” Which corresponds to a “classic” compilation without LLVM support. Believe it or not, this was found to run faster on our CPU cluster than with the LLVM drivers. After linking PV 5.0.0 against the MESA libs with the OpenGL2 backend, I started running a simple benchmark to check possible performance benefits and here is the error output I got: GL_Version: 2.1 Mesa 10.5.5 Warning: In /panfs/srvpan01/code/repo/build/paraview-5.0.0-rc1/src/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 549 vtkOSOpenGLRenderWindow (0x3c0eef60): VTK is designed to work with OpenGL version 3.2 but it appears it has been given a context that does not support 3.2. VTK will run in a compatibility mode designed to work with OpenGL 2.1 but some features may not work. ERROR: In /panfs/srvpan01/code/repo/build/paraview-5.0.0-rc1/src/VTK/Rendering/OpenGL2/vtkShaderProgram.cxx, line 369 vtkShaderProgram (0x4d4dbfe0): 1: #version 120 2: #extension GL_EXT_gpu_shader4 : require 3: #define highp 4: #define mediump 5: #define lowp 6: 7: /*= 8: 9: Program: Visualization Toolkit 10: Module:vtkPolyDataFS.glsl 11: 12: Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen 13: All rights reserved. 14: See Copyright.txt or http://www.kitware.com/Copyright.htm for details. 15: 16: This software is distributed WITHOUT ANY WARRANTY; without even 17: the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR 18: PURPOSE. See the above copyright notice for more information. 19: 20: =*/ 21: // Template for the polydata mappers fragment shader 22: 23: uniform int PrimitiveIDOffset; 24: 25: // VC position of this fragment 26: varying vec4 vertexVCVSOutput; 27: 28: // optional color passed in from the vertex shader, vertexColor 29: uniform bool Overr
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 on the end user's compute platform. If the binaries ship with SWR using prebuilt mesa binaries, is there any documentation on how to build the mesa binaries with SWR support? I might eventually figure it out by myself (or not) but I would be grateful for any hints. Cheers, Frank. -Original Message- From: Ben Boeckel [mailto:ben.boec...@kitware.com] Sent: Donnerstag, 10. Dezember 2015 17:07 To: Ken Martin Cc: Albina, Frank; paraview@paraview.org Subject: 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 uploaded to the website) have SWR available using prebuilt mesa binaries. If you have AVX CPU extensions available, passing: --mesa-swr-avx should enable it. There's also --mesa-swr-avx2 if you have AVX2 extensions available. --Ben ___ 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] Nvidia K20x on cluster
IMHO, the issue is that you need to tell the NVIDIA driver that a screen will be connected at any time to the GPU, but you need to supply the driver with the screen data via a custom EDID file, like so in your xorg.conf file: Section Device Identifier Device0 [...] Option CustomEDID DFP-0:/etc/X11/edid-DELL_P2212H.bin Option ConnectedMonitor DFP-0 EndSection Section Screen Identifier Screen0 Device Device0 MonitorMonitor0 DefaultDepth24 [...] EndSection Hope this helps. Frank. -Original Message- From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Felipe Bordeu Sent: Montag, 7. Juli 2014 16:37 To: Paraview Mailing list (to use with ec-nantes) Subject: [Paraview] Nvidia K20x on cluster -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, We have a computer (node in a cluster) with 2 Nvidia K20x GPUs (plus a chipset for low-end visu). Is It possible to use these GPUs to accelerate ParaView visualization even if theses cards don't have a video output??? I know how to use the pvserver/paraview. But my problem is about the X11 configuration. If I put a 'Section Screen' for these cards in the xorg.conf, nvidia complains that these cards don't have outputs. and if I eliminate the 'Screen' section, the card are not available. (tried display :0, 0:0 1:0...) Any Ideas?? Thanks Felipe - -- Felipe Bordeu Weldt Ingénieur de Recherche - - Tél. : 33 (0)2 40 37 16 57 Fax. : 33 (0)2 40 74 74 06 felipe.bor...@ec-nantes.fr Institut GeM - UMR CNRS 6183 École Centrale Nantes 1 Rue de La Noë, 44321 Nantes, FRANCE - - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTurB+AAoJEE/fMfNgU9/DVdcH/1IYsRVTtl94L+PYqYOIgkAz 7Yx4rAFBdRVWAV8lUkFqnW/vyFNxqGcp2kuRKu/iH7cIWsEojETVbv2xcEbYaE0d Zo/UKE1HfkAX9LFb/94igJDmgNJQXSL+QfABo+bmtpfbx+e6i63aKk+9VxRwB7t+ XEi+GKOJ0q+oQ8Rpa1J+uYWfgMQ6uPAisPQdXQWDa9sLPP4UFYi0YW60f5hzMopO XyMHOFUVdu0NiF+Y+oqKmS44KpQt6BJHU+uHqq0Sn16DUvIuDFgdUXnFOlZM/nJU Cya7ae2aHF+3umX7PMNeDdXjWC3NrevuZBilv9Off09XtGACyDXIG8SpnJDnd9Q= =EaqR -END PGP SIGNATURE- ___ 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://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 Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
Re: [Paraview] SurfaceLIC and python interface
Hi Seb!
I found out that the following works without having the need to access the C++
API explicitly and this is what I am using now:
from paraview.simple import *
LoadPlugin(libSurfaceLIC.so,ns=globals())
[...]
view = GetRenderView()
source = GetActiveSource()
rep = Show(source,view)
rep.Representation = 'Surface LIC'
rep.SetPropertyWithName('LICIntensity',0.9)
rep.SetPropertyWithName('LICStepSize',0.5)
view.StillRender()
[...]
I discovered that the Surface LIC properties of the rep object are listed when
calling print rep.ListProperties(). Their respective values can be output with
rep.GetPropertyValue(Property name).
Cheers,
Frank.
-Original Message-
From: Sebastien Jourdain [mailto:sebastien.jourd...@kitware.com]
Sent: Donnerstag, 26. Juli 2012 16:32
To: Albina, Frank
Cc: paraview@paraview.org
Subject: Re: [Paraview] SurfaceLIC and python interface
Hi Frank,
normally loading that specific plugin on the server should be enough
as it doesn't have any custom Qt-GUI component in it.
Seb
On Thu, Jul 26, 2012 at 9:57 AM, Albina, Frank
frank.alb...@sauber-motorsport.com wrote:
Hi Sebastien!
Thank you very much for the invaluable information. I had found on the
internet the following PV bug:
http://www.paraview.org/Bug/print_bug_page.php?bug_id=12360, which shows that
you have to load the plugin for both server and client when running pvbatch.
I had to find the hard way that loading the plugin for the server only does
not work. BTW, when loading the plugin for both server and client, I get the
following warning messages:
Warning: In
/cfdcode/opt/ParaView/SRC/paraview-3.14.1/ParaViewCore/ServerManager/vtkSMProxy.cxx,
line 889
vtkSMPVRepresentationProxy (0x1a51fe0): Proxy SurfaceLICRepresentation
already exists. Replacing
Warning: In
/cfdcode/opt/ParaView/SRC/paraview-3.14.1/ParaViewCore/ServerManager/vtkSMProxy.cxx,
line 889
vtkSMPVRepresentationProxy (0x1ba4470): Proxy SurfaceLICRepresentation
already exists. Replacing
Warning: In
/cfdcode/opt/ParaView/SRC/paraview-3.14.1/ParaViewCore/ServerManager/vtkSMProxy.cxx,
line 889
vtkSMPVRepresentationProxy (0x1ceeed0): Proxy SurfaceLICRepresentation
already exists. Replacing
[]
Warning: In
/cfdcode/opt/ParaView/SRC/paraview-3.14.1/ParaViewCore/ServerManager/vtkSMProxy.cxx,
line 889
vtkSMPVRepresentationProxy (0x6dce5a0): Proxy SurfaceLICRepresentation
already exists. Replacing
Warning: In
/cfdcode/opt/ParaView/SRC/paraview-3.14.1/ParaViewCore/ClientServerCore/vtkCompositeRepresentation.cxx,
line 99
vtkPVCompositeRepresentation (0x7184cc0): Replacing existing representation
for key: Surface LIC
The same happens with the PV binaries downloaded from KitWare. The platform
is x86_64 running under SLED10 Linux.
However, loading the plugin and using the C++ API works just fine.
Thanks again.
Cheers,
Frank.
-Original Message-
From: Sebastien Jourdain [mailto:sebastien.jourd...@kitware.com]
Sent: Donnerstag, 26. Juli 2012 14:04
To: Albina, Frank
Cc: paraview@paraview.org
Subject: Re: [Paraview] SurfaceLIC and python interface
Hi Frank,
I think you need to use the C++ API as the representation was already
wrapped based on another type of representation that was not providing
those properties
Here is an example on how to set one of your property.
DataRepresentation1.SMProxy.GetProperty('LICIntensity').SetElement(0,1.0)
Alternatively, when you load you plugin, you can try to provide your
globals as argument. That might solve the problem too.
LoadPlugin('file', True, globals() )
Seb
On Thu, Jul 26, 2012 at 4:48 AM, Albina, Frank
frank.alb...@sauber-motorsport.com wrote:
Hi!
Forgot to tell that the PV version is 3.14.1.
Cheers,
Frank.
From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org]
On Behalf Of Albina, Frank
Sent: Donnerstag, 26. Juli 2012 10:26
To: paraview@paraview.org
Subject: [Paraview] SurfaceLIC and python interface
Dear All!
I am trying to run the SurfaceLIC representation under pvbatch. From the
python trace tool under the GUI, I could find the following output which
helps me setting the LIC intensity and LICStepSize:
RenderView1 = GetRenderView()
DataRepresentation1 = Show()
DataRepresentation1.Representation = 'Surface LIC'
DataRepresentation1.InterpolateScalarsBeforeMapping = 0
DataRepresentation1.LICIntensity = 1.0
DataRepresentation1.LICStepSize = 0.25
Unfortunately, doing the same within a python script does not work, since I
get :
AttributeError: Attribute LICIntensity does not exist. This class does not
allow addition of new attributes to avoid mistakes due to typos. Use
add_attribute() if you really want to add this attribute.
The above attributes LICIntensity and LICStepSize are not available from the
python shell either, even after having set the representation to 'Surface
LIC'. I get the same issue either with the Kitware binaries
[Paraview] SurfaceLIC and python interface
Dear All! I am trying to run the SurfaceLIC representation under pvbatch. From the python trace tool under the GUI, I could find the following output which helps me setting the LIC intensity and LICStepSize: RenderView1 = GetRenderView() DataRepresentation1 = Show() DataRepresentation1.Representation = 'Surface LIC' DataRepresentation1.InterpolateScalarsBeforeMapping = 0 DataRepresentation1.LICIntensity = 1.0 DataRepresentation1.LICStepSize = 0.25 Unfortunately, doing the same within a python script does not work, since I get : AttributeError: Attribute LICIntensity does not exist. This class does not allow addition of new attributes to avoid mistakes due to typos. Use add_attribute() if you really want to add this attribute. The above attributes LICIntensity and LICStepSize are not available from the python shell either, even after having set the representation to 'Surface LIC'. I get the same issue either with the Kitware binaries or those compiled by myself. Even forcing the load of the SurfaceLIC plugin with paraview.servermanager.LoadPlugin(libSurfaceLIC.so) does not solve the issue. I am surely missing one step. Could someone tell me which? Thanks a lot in advance. Cheers, Frank Albina. ___ 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
Re: [Paraview] SurfaceLIC and python interface
Hi! Forgot to tell that the PV version is 3.14.1. Cheers, Frank. From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org] On Behalf Of Albina, Frank Sent: Donnerstag, 26. Juli 2012 10:26 To: paraview@paraview.org Subject: [Paraview] SurfaceLIC and python interface Dear All! I am trying to run the SurfaceLIC representation under pvbatch. From the python trace tool under the GUI, I could find the following output which helps me setting the LIC intensity and LICStepSize: RenderView1 = GetRenderView() DataRepresentation1 = Show() DataRepresentation1.Representation = 'Surface LIC' DataRepresentation1.InterpolateScalarsBeforeMapping = 0 DataRepresentation1.LICIntensity = 1.0 DataRepresentation1.LICStepSize = 0.25 Unfortunately, doing the same within a python script does not work, since I get : AttributeError: Attribute LICIntensity does not exist. This class does not allow addition of new attributes to avoid mistakes due to typos. Use add_attribute() if you really want to add this attribute. The above attributes LICIntensity and LICStepSize are not available from the python shell either, even after having set the representation to 'Surface LIC'. I get the same issue either with the Kitware binaries or those compiled by myself. Even forcing the load of the SurfaceLIC plugin with paraview.servermanager.LoadPlugin(libSurfaceLIC.so) does not solve the issue. I am surely missing one step. Could someone tell me which? Thanks a lot in advance. Cheers, Frank Albina. ___ 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
Re: [Paraview] SurfaceLIC and python interface
Hi Sebastien!
Thank you very much for the invaluable information. I had found on the internet
the following PV bug:
http://www.paraview.org/Bug/print_bug_page.php?bug_id=12360, which shows that
you have to load the plugin for both server and client when running pvbatch. I
had to find the hard way that loading the plugin for the server only does not
work. BTW, when loading the plugin for both server and client, I get the
following warning messages:
Warning: In
/cfdcode/opt/ParaView/SRC/paraview-3.14.1/ParaViewCore/ServerManager/vtkSMProxy.cxx,
line 889
vtkSMPVRepresentationProxy (0x1a51fe0): Proxy SurfaceLICRepresentation already
exists. Replacing
Warning: In
/cfdcode/opt/ParaView/SRC/paraview-3.14.1/ParaViewCore/ServerManager/vtkSMProxy.cxx,
line 889
vtkSMPVRepresentationProxy (0x1ba4470): Proxy SurfaceLICRepresentation already
exists. Replacing
Warning: In
/cfdcode/opt/ParaView/SRC/paraview-3.14.1/ParaViewCore/ServerManager/vtkSMProxy.cxx,
line 889
vtkSMPVRepresentationProxy (0x1ceeed0): Proxy SurfaceLICRepresentation already
exists. Replacing
[]
Warning: In
/cfdcode/opt/ParaView/SRC/paraview-3.14.1/ParaViewCore/ServerManager/vtkSMProxy.cxx,
line 889
vtkSMPVRepresentationProxy (0x6dce5a0): Proxy SurfaceLICRepresentation already
exists. Replacing
Warning: In
/cfdcode/opt/ParaView/SRC/paraview-3.14.1/ParaViewCore/ClientServerCore/vtkCompositeRepresentation.cxx,
line 99
vtkPVCompositeRepresentation (0x7184cc0): Replacing existing representation for
key: Surface LIC
The same happens with the PV binaries downloaded from KitWare. The platform is
x86_64 running under SLED10 Linux.
However, loading the plugin and using the C++ API works just fine.
Thanks again.
Cheers,
Frank.
-Original Message-
From: Sebastien Jourdain [mailto:sebastien.jourd...@kitware.com]
Sent: Donnerstag, 26. Juli 2012 14:04
To: Albina, Frank
Cc: paraview@paraview.org
Subject: Re: [Paraview] SurfaceLIC and python interface
Hi Frank,
I think you need to use the C++ API as the representation was already
wrapped based on another type of representation that was not providing
those properties
Here is an example on how to set one of your property.
DataRepresentation1.SMProxy.GetProperty('LICIntensity').SetElement(0,1.0)
Alternatively, when you load you plugin, you can try to provide your
globals as argument. That might solve the problem too.
LoadPlugin('file', True, globals() )
Seb
On Thu, Jul 26, 2012 at 4:48 AM, Albina, Frank
frank.alb...@sauber-motorsport.com wrote:
Hi!
Forgot to tell that the PV version is 3.14.1.
Cheers,
Frank.
From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org]
On Behalf Of Albina, Frank
Sent: Donnerstag, 26. Juli 2012 10:26
To: paraview@paraview.org
Subject: [Paraview] SurfaceLIC and python interface
Dear All!
I am trying to run the SurfaceLIC representation under pvbatch. From the
python trace tool under the GUI, I could find the following output which
helps me setting the LIC intensity and LICStepSize:
RenderView1 = GetRenderView()
DataRepresentation1 = Show()
DataRepresentation1.Representation = 'Surface LIC'
DataRepresentation1.InterpolateScalarsBeforeMapping = 0
DataRepresentation1.LICIntensity = 1.0
DataRepresentation1.LICStepSize = 0.25
Unfortunately, doing the same within a python script does not work, since I
get :
AttributeError: Attribute LICIntensity does not exist. This class does not
allow addition of new attributes to avoid mistakes due to typos. Use
add_attribute() if you really want to add this attribute.
The above attributes LICIntensity and LICStepSize are not available from the
python shell either, even after having set the representation to 'Surface
LIC'. I get the same issue either with the Kitware binaries or those
compiled by myself. Even forcing the load of the SurfaceLIC plugin with
paraview.servermanager.LoadPlugin(libSurfaceLIC.so) does not solve the
issue.
I am surely missing one step. Could someone tell me which?
Thanks a lot in advance.
Cheers,
Frank Albina.
___
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
___
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
Re: [Paraview] show only edges?
Can you try: Filters - Extract Surface, then Filters-Feature Edges and see if this is what you want? HTH. Frank. -Original Message- From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org] On Behalf Of Nico Schlömer Sent: Dienstag, 29. Mai 2012 15:51 To: paraview@paraview.org Subject: [Paraview] show only edges? Hi all, I have this tetrahedron as a VTK file. Is there any way to just display its edges? I found the Extract Edges filter, but that show all the edges of the discretization (whereas I'm only interested in the edges of the geometry). Cheers, Nico ___ 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 ___ 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
[Paraview] Rendering performance issue?
Dear ParaView users developers, I am trying to reduce the time spent in performing generic 3D surface rendering. A lot has been achieved by using ParaView driven by python scripting already but actually I'd like to achieve more. At the time being, all rendering is performed using CPU rendering with the MESA libraries and I have started investigating if it could be worth performing the rendering using GPUs instead of using N CPUs in parallel. For the purpose of checking the GPU performance over CPUs, I have devised a simple benchmark with a python script which drives the surface rendering. The script performs the generation of 60 images and dumps them onto disk in JPEG format. When performing this task, I have been tumbling upon the following rendering times for the generation of the aforementioned 60 images, using different versions of paraview on an old workstation, which is my guinea pig for this benchmark: Paraview 3.8.1 Paraview 3.10.1 Paraview 3.12.0 Paraview 3.14.1 138.12s 591.06s 592.53s 594.10s What is striking is that the rendering time is 4 times less(!) with PV v3.8.1 than with all subsequent versions. I had already noticed something similar when running MESA on dissimilar architectures, but I assumed that the culprit were the MESA libraries used. Here, the HW and libraries are the same, so I am enclined to believe that I am missing something here in the general rendering settings which do not affect PV v3.8.1 but induce a big performance hit for all PV versions above 3.10. Is anybody aware of rendering settings which could induce such a performance difference? BTW, for each rendering, a window opens with the OpenGL tag in the window title bar, so I am quite sure that I am not using any SW rendering, all the more as all the PV versions I have compiled have VTK_OPENGL_HAS_OSMESA set to off. A few more details concerning the test I have been running: - Workstation: Linux workstation with SuSE SLED 10 2 x Intel Xeon Dual core 5160 @ 3.00GHz 2 x NVIDIA Quadro FX3500 (NV71GL chipset) - Paraview version 3.8.1, 3.10.1, 3.12.0 and 3.14.1 were compiled with OpenGL support, Qt v4.6.x, python v2.7, OpenMPI v1.4.x using the GCC compiler v4.5.x. - The script is run using pvpython (and not pvbatch) in order to force the assignement of the graphics card: pvserver -display localhost:0.0 Then the rendering script runs with pvpython from the command line. Within the script, a Connect(localhost,1) forces the connection to the pvserver running on localhost. Any suggestions welcome. Best regards Frank Albina. ___ 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
Re: [Paraview] Load many VTK from different folders at once
Hi Lorenzo! Maybe you'd better off with reading the OpenFOAM solution with the built-in OpenFOAM reader. Just create in your case directory an empty OF.foam file and you can start reading the solution by opening this file from the GUI. Hope this helps. Frank. -Original Message- From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org] On Behalf Of Lorenzo Sent: Freitag, 23. März 2012 17:11 To: paraview@paraview.org Subject: Re: [Paraview] Load many VTK from different folders at once I was thinking: maybe there's a way to create a text files (or something in another format) which contains the paths to the vtk files I need to open and this file could be submitted to paraview to automate the whole process of opening every each one of the vtk files... What do you think? Thank you! Il giorno 22/mar/2012, alle ore 20:26, lore ha scritto: Hi all, I am using openFoam and when I run foamToVTK I get many vtk files every each one of which is contained in a different folder. If my geometry is made up by many .stl different files then I get the same number of folders. This is quite annoying when I need to load up the whole geometry because I need to enter the first folder and load the first .vtk, then go to file--open--enter the second folder and load the second .vtk and so on until I loaded all the files I need. As you may understand this is quite time consuming... Any way to do the whole process at once? I think the best way would be to link together all of these vtk files into one single file (even of a different format) using a script (sh, python, bash...??). This is something you may do with the .stl files, if they are in binary format you may concatenate the content of each one of them into a single different file and then load just that one to have everything at once... What do you think? Thank you! ___ 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 ___ 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 ___ 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
[Paraview] Is there a way to get the Paraview version from within a python script in batch?
Dear All! Is there a way to get the paraview version from within a python script? I could get the underlying VTK version with paraview.vtk.vtkVersion.GetVTKVersion(), but I could not manage to achieve the same with the paraview version, although it pops up to the output when performing: from paraview.simple import *. Cheers, Frank Albina. Mail frank.alb...@sauber-motorsport.commailto:albina.fr...@sauber-motorsport.com Web http://www.sauber-motorsport.comhttp://www.sauber-motorsport.com/ P please consider the environment before printing this e-mail. ___ 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
Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on.
I think I have solved the issue I was having just now. I could not pursue it for a while because of other job priorities and we were at the time still having a functioning system with ParaView v3.8.1. This is the reason of the late reply. I have managed to have a working solution for the following constellation on my SLES10 64bits box: + gcc v4.5.1 + OpenMPI v1.5.3 + Qt v4.6.3 + Python v2.7 + Mesa v7.10.3 + cmake v2.8.4 Mesa was compiled with following options: ./configure --with-x --build=x86_64-suse-linux --prefix=/data/CFD/develop/opt/MESA/Mesa-7.10.3 --disable-egl --enable-pic --disable-gallium --enable-static EXTRA_LIB_PATH=-L/usr/X11R6/lib64 --with-driver=xlib The reason why I am not building the Mesa libs using the --with-driver=osmesa option, is that I want to be able to use X and not rely on the OGL HW implementation, but rather on OSMESA. This way, I can also require to use off-screen rendering for batch jobs through pvbatch or pvserver from the same compiled binaries with Mesa and have a graphical front-end for test purposes. Until now I have tried without success so far to make use of the shared Mesa libraries, ie. I still got a segmentation fault, no matter how I compiled the Mesa libraries on my system. Since the culprit was the libGL.so mismatch between system, Mesa own libGL.so and libOSMesa.so, I switched to static libraries which ultimately worked. Here are my configuration variables: OPENGL_INCLUDE_DIR /data/CFD/develop/opt/MESA/Mesa-7.10.3/include OPENGL_gl_LIBRARY /data/CFD/develop/opt/MESA/Mesa-7.10.3/lib/libGL.a OPENGL_glu_LIBRARY /data/CFD/develop/opt/MESA/Mesa-7.10.3/lib/libGLU.a OPENGL_xmesa_INCLUDE_DIR /data/CFD/develop/opt/MESA/Mesa-7.10.3/include OSMESA_INCLUDE_DIR /data/CFD/develop/opt/MESA/Mesa-7.10.3/include OSMESA_LIBRARY /data/CFD/develop/opt/MESA/Mesa-7.10.3/lib/libOSMesa.a VTK_USE_OFFSCREENOFF VTK_OPENGL_HAS_OSMESAON VTK_USE_XON I am not sure that this procedure works 100%. I will keep you in touch in case I can manage another successful build on a different computer. HTH. Cheers, Frank. -Original Message- From: Kevin H. Hobbs [mailto:hob...@ohio.edu] Sent: Montag, 25. April 2011 15:42 To: Albina, Frank Cc: David Partyka; paraview@paraview.org Subject: Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on. On 04/20/2011 11:42 AM, Albina, Frank wrote: I think I should be able to fix the issue by building correctly the MESA libs for my purpose then. Have you succeeded? ___ 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
Re: [Paraview] Surface LIC
It does not work with OSMesa. Tried it already. But it shall work with a proper GPU. If I recall it correctly, there was some information flying around in this forum about which type of GPU is needed. -Original Message- From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org] On Behalf Of Burlen Loring Sent: Freitag, 20. Mai 2011 05:26 To: paraview@paraview.org Subject: [Paraview] Surface LIC Hi All, For some reason Surface LIC doesn't work for me. Should the surface LIC work with osmesa ? thanks Burlen ___ 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 ___ 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
Re: [Paraview] make install seems to built a mirror of all the libs
I think this has to do with the variable PARAVIEW_INSTALL_THIRD_PARTY_LIBRARIES which is set to ON by default. You could try to switch it off and see if it fixes the issue. Cheers, Frank. -Original Message- From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org] On Behalf Of Jérôme Sent: Mittwoch, 20. April 2011 10:40 To: paraview-users Subject: [Paraview] make install seems to built a mirror of all the libs Hi, I git pull pv-3.11.1 this morning and built without any problem. But when I execute make install, the installation process seems to copy all the lib that can be found in /usr/lib64 into my /usr/local/lib/paraview-3.11/lib64. Example : ... -- Installing: /usr/local/lib/paraview-3.11/lib64/osgPlugins-2.8.3/osgdb_bmp.so -- Installing: /usr/local/lib/paraview-3.11/lib64/osgPlugins-2.8.3/osgdb_svg.so -- Installing: /usr/local/lib/paraview-3.11/lib64/osgPlugins-2.8.3/osgdb_ive.so -- Installing: /usr/local/lib/paraview-3.11/lib64/osgPlugins-2.8.3/osgdb_iv.so ... System is Fedora14. I removed the build tree before recompiling Paraview from scratch. Does anybody note this before ? If not, how can I track down the origin of this strange behaviour ? I attached my CMakeCache as it should be helpful. Thanks a lot ! Jerome ___ 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
Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on.
Hi Kevin! Thank you very much for the support so far. What I am trying to achieve is to have: a) the whole paraview suite, i.e. paraview, pvbatch, pvserver built from scratch. b) with X, independently of offscreen or onscreen rendering c) with Mesa using xlib drivers: ./configure --prefix=/code/CFD/develop/opt/share/Mesa-7.9.2 --with-x --enable-gl-osmesa --build=x86_64-suse-linux --with-driver=xlib --enable-glu --enable-glw --enable-pic --enable-opengl What I'd like to achieve is a stand-alone paraview version with X support, from which one can start pvserver for performing offscreen rendering via MESA. If one does not start the pvserver remotely, one should still be able to use paraview with onscreen rendering, still using MESA as the rendering engine (i.e. without system OpenGL support, in other words without GPU rendering). Please let me know if this is still unclear. Following the steps on the paraview WIKI does not seem to work, unless I am mistaken, which I guess I am at the time being. Again, I had had no issues building and running paraview v3.8.1, whereas paraview v3.10.x is giving me a segmentation fault at screen start. Thank you very much for the script anyway. I sure will make good use of it. Cheers, Frank. -Original Message- From: Kevin H. Hobbs [mailto:hob...@ohio.edu] Sent: Dienstag, 19. April 2011 19:50 To: Albina, Frank Cc: David Partyka; paraview@paraview.org Subject: Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on. On 04/19/2011 12:29 PM, Albina, Frank wrote: Dear Kevin! To put things more clearly and to avoid confusion, I'd like to build a paraview v3.10.x executable with X. In this regard, I'd like to use paraview as the client and start remotely the paraview server with mpirun -np N --use-offscreen-rendering. I build paraview with X and the accelerated drivers for my graphics card and pvserver with OSMesa and MPI. I start paraview on my workstation and pvserver on our cluster. I *should* be able to build paraview with X using offscreen rendering, based on the MESA libraries. Yes, you can but three of these terms are not precise enough to be useful in this conversation: Paraview paraview pvbatch pvserver Offscreen with X and hardware with X without X Mesa hardware accelerated DRI drivers xlib drivers OSMesa needs GL OSMesa conflicts with GL Again, this worked with paraview v3.8.1, but I fail getting it up and running with paraview 3.10.x performing the same configuration steps as with paraview 3.8.1. Parview may have adapted to the requirements of the newer OSMesa Library. I do not really know without knowing *exactly* what you were and are doing. If I understood you well, one cannot link an application to libOSMESA.so and libGL.so/libGLU.so at the same time. Older versions of Mesa could produce an OSMesa library that had to be linked to Mesa's GL library ( so long as that GL library was not built with hardware acceleration support ) *or* they could produce an OSMesa library that did not depend on GL (or X) and could not be linked with any other GL library. Newer versions of Mesa only produce an OSMesa that does not depend on GL (or X) and can not be linked with any other GL library. I link to the libGLU.so produced along with libOSMesa.so all the time. If this is correct, then it would explain why I get a segmentation fault straight away. I believe it does. On the other hand, what are then the libGL.so and libGLU.so one has to link against, if not the ones from MESA v7.x according to the WIKI: That depends. [ big snip ] Sorry, I can't really respond to most of that right now. Thank you very for your help anyway and please let me know if you have made any progress with building paraview on your cluster. I build the development versions every night so it shouldn't be too much trouble. I'm just putting *everything* together in one script (well really just a sequence of commands) adjusted for release versions, installed to /opt, and so on. ___ 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
Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on.
Hi Kevin! Got the message. In fact, the culprit is not paraview but how MESA is built and how OSMESA links against the OpenGL libs (either from the system or the MESA lib itself). I think I should be able to fix the issue by building correctly the MESA libs for my purpose then. Thanks a lot for the effort. Cheers, Frank. -Original Message- From: Kevin H. Hobbs [mailto:hob...@ohio.edu] Sent: Mittwoch, 20. April 2011 16:44 To: Albina, Frank Cc: David Partyka; paraview@paraview.org Subject: Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on. On 04/20/2011 05:22 AM, Albina, Frank wrote: Hi Kevin! Thank you very much for the support so far. What I am trying to achieve is to have: a) the whole paraview suite, i.e. paraview, pvbatch, pvserver built from scratch. b) with X, independently of offscreen or onscreen rendering c) with Mesa using xlib drivers: ./configure --prefix=/code/CFD/develop/opt/share/Mesa-7.9.2 --with-x --enable-gl-osmesa --build=x86_64-suse-linux --with-driver=xlib --enable-glu --enable-glw --enable-pic --enable-opengl If you are going to use X with all of ParaView then you will need to link against libGL.so from mesa-7.9.2 which conflicts with libOSMesa.so from mesa-7.9.2 so there is no point in adding the --enable-gl-osmesa flag. What I'd like to achieve is a stand-alone paraview version with X support, from which one can start pvserver for performing offscreen rendering via MESA. If one does not start the pvserver remotely, one should still be able to use paraview with onscreen rendering, still using MESA as the rendering engine (i.e. without system OpenGL support, in other words without GPU rendering). Please let me know if this is still unclear. You can have this but it's more complicated : even though your pvserver will use offscreen rendering it will still open a window, you will need an X server running on each of the compute nodes, you will have to have the display variable set to point to the X server on each compute node, and each pvserver process will have to have permissions to use the server on its node. The the windows that each pvserver process renders into will not be visible on monitors ( if there are any ) connected to the compute nodes. They will not be covered or cover any other window so you won't get random bits of other programs showing up in the final output. But they will exist. Following the steps on the paraview WIKI does not seem to work, unless I am mistaken, which I guess I am at the time being. The steps on the wiki are a bit of a mix of what you can do with old and new versions of Mesa. Again, I had had no issues building and running paraview v3.8.1, whereas paraview v3.10.x is giving me a segmentation fault at screen start. I can not comment on what might have changed. Thank you very much for the script anyway. I sure will make good use of it. Cheers, Frank. ___ 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
Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on.
Hi Kevin! Thanks a lot for the offer. To be honest, I am still having trouble to run paraview v3.10.0/v3.10.1 to have CPU rendering only with additional X support. On the one hand, I am performing the same configuration steps with CMake as for paraview 3.8.1, for which I have had no issues whatsoever wrt. running paraview in this configuration for the last 4 months. I am relying heavily on paraview for post-processing simulation results and it runs on my compute cluster daily in parallel. On the other hand, performing the same configuration steps with CMake for paraview 3.10.0 or 3.10.1 creates an executable which cannot run without producing a segmentation fault, which does appear just after the logo window has popped up. For information, I am compiling the paraview sources from scratch. I have been having the issue on two different computers now: one Linux x86_64 workstation running under SuSE SLES10 and one Linux x86_64 laptop running under OpenSuSE 11.1. It is not a compiler issue, since I have been able to reproduce the problem using different compilers versions (i.e. gcc v4.1.2, v4.5.1, v4.5.2 and v4.6.0) on the same architecture. Here are the settings I am using by default: //Path to a file. OPENGL_INCLUDE_DIR:PATH=/code/CFD/develop/opt/share/Mesa-7.9.2/include //Path to a library. OPENGL_gl_LIBRARY:FILEPATH=/code/CFD/develop/opt/share/Mesa-7.9.2/lib/libGL.so //Path to a library. OPENGL_glu_LIBRARY:FILEPATH=/code/CFD/develop/opt/share/Mesa-7.9.2/lib/libGLU.so //Path to a file. OPENGL_xmesa_INCLUDE_DIR:PATH=/code/CFD/develop/opt/share/Mesa-7.9.2/include //Path to a file. OSMESA_INCLUDE_DIR:PATH=/code/CFD/develop/opt/share/Mesa-7.9.2/include //Path to a library. OSMESA_LIBRARY:FILEPATH=/code/CFD/develop/opt/share/Mesa-7.9.2/lib/libOSMesa.so //Build classes for the X11 window system. VTK_USE_X:BOOL=ON // VTK_OPENGL_HAS_OSMESA:BOOL=ON Note that the same problem arises also on the Linux workstation using Mesa v7.10.1 and v7.10.2. Mesa v7.9.2 was compiled using the following steps: make realclean ./configure --prefix=/code/CFD/develop/opt/share/Mesa-7.9.2 --with-x --enable-gl-osmesa --build=x86_64-suse-linux --with-driver=xlib --enable-glu --enable-glw --enable-pic --enable-opengl make -j 4 make install Furthermore, the problem does not arise when I am disabling MPI support (i.e. VTK_USE_MPI:INTERNAL=OFF) or having conventional OpenGL support with MPI enabled (i.e. using system OpenGL libraries and MPI support). Here is the list of libraries I am using for the build of paraview with MPI, MESA and PYTHON support: + Mesa v7.9.2 + OpenMPI v1.4.3 + Python v2.7.1 + Qt v4.6.3 Paraview v3.8.1 was compiled with the following library versions: + Mesa v7.7.1 + OpenMPI v1.4.3 + Python v2.7 + Qt v4.6.2 I would be very grateful if you could help me find out was I could be doing wrong. Again, the procedure works for paraview v3.8.1, so I am quite at loss when it does not work anymore for paraview v3.10.x. Please, let me know if you need more information. Cheers, Frank. -Original Message- From: Kevin H. Hobbs [mailto:hob...@ohio.edu] Sent: Montag, 18. April 2011 20:59 To: David Partyka Cc: Albina, Frank; paraview@paraview.org Subject: Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on. On 04/18/2011 07:50 AM, David Partyka wrote: For example, here is how Kevin Hobes builds mesa and configures ParaView on his RedHat cluster. Frank, I am willing to help you out if you are still having trouble. ___ 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
Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on.
Hi Arjun! Thanks for the info. I tried this one too, but it does not work either. Just to be sure, I rebuilt it from scratch and I am having a different issue (Illegal instruction instead of segmentation fault), but at the same place: [...] #0 0x00b14f90 in ?? () #1 0x2aaab68640b7 in vtkOpenGLRenderWindow::OpenGLInit (this=0x1501cc0) at /scratch/fal/COMPILE/ParaView-3.10.1/src/VTK/Rendering/vtkOpenGLRenderWindow.cxx:241 #2 0x2aaab68c18c1 in vtkXOpenGLRenderWindow::WindowInitialize (this=0x1501cc0) at /scratch/fal/COMPILE/ParaView-3.10.1/src/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1043 #3 0x2aaab68c1907 in vtkXOpenGLRenderWindow::Initialize (this=0x1501cc0) at /scratch/fal/COMPILE/ParaView-3.10.1/src/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1052 #4 0x2aaab68c1dbb in vtkXOpenGLRenderWindow::Start (this=0x1501cc0) at /scratch/fal/COMPILE/ParaView-3.10.1/src/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1185 #5 0x2aaab677ae0d in vtkRenderWindow::DoStereoRender (this=0x1501cc0) at /scratch/fal/COMPILE/ParaView-3.10.1/src/VTK/Rendering/vtkRenderWindow.cxx:687 #6 0x2aaab677adde in vtkRenderWindow::DoFDRender (this=0x1501cc0) at /scratch/fal/COMPILE/ParaView-3.10.1/src/VTK/Rendering/vtkRenderWindow.cxx:676 #7 0x2aaab677a873 in vtkRenderWindow::DoAARender (this=0x1501cc0) at /scratch/fal/COMPILE/ParaView-3.10.1/src/VTK/Rendering/vtkRenderWindow.cxx:563 #8 0x2aaab6779e22 in vtkRenderWindow::Render (this=0x1501cc0) at /scratch/fal/COMPILE/ParaView-3.10.1/src/VTK/Rendering/vtkRenderWindow.cxx:376 #9 0x2aaab68c4755 in vtkXOpenGLRenderWindow::Render (this=0x1501cc0) at /scratch/fal/COMPILE/ParaView-3.10.1/src/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1845 #10 0x2ddf7a2d in vtkPVRenderView::Render (this=0x14758b0, interactive=false, skip_rendering=false) at /scratch/fal/COMPILE/ParaView-3.10.1/src/Servers/Filters/vtkPVRenderView.cxx:752 #11 0x2ddf72b7 in vtkPVRenderView::StillRender (this=0x14758b0) at /scratch/fal/COMPILE/ParaView-3.10.1/src/Servers/Filters/vtkPVRenderView.cxx:592 #12 0x2d75837e in vtkPVRenderViewCommand (arlu=0xcafee0, ob=0x14758b0, method=0x155b2c9 StillRender, msg=@0x7fff8a20, resultStream=@0xce6900) [...] So I guess that your configuration differs from mine. Do you have by chance an excerpt of your CMakeCache.txt file in your build directory showing which settings you are using for OpenGL, when running MESA instead of GPU rendering? For comparison, here are mine (which do not work): OPENGL_INCLUDE_DIR:PATH=/code/CFD/develop/opt/share/Mesa-7.7.1/include OPENGL_gl_LIBRARY:FILEPATH=/code/CFD/develop/opt/share/Mesa-7.7.1/lib/libGL.so OPENGL_glu_LIBRARY:FILEPATH=/code/CFD/develop/opt/share/Mesa-7.7.1/lib/libGLU.so OPENGL_xmesa_INCLUDE_DIR:PATH=/code/CFD/develop/opt/share/Mesa-7.7.1/include OSMESA_INCLUDE_DIR:PATH=/code/CFD/develop/opt/share/Mesa-7.7.1/include OSMESA_LIBRARY:FILEPATH=/code/CFD/develop/opt/share/Mesa-7.7.1/lib/libOSMesa.so VTK_USE_X:BOOL=ON VTK_OPENGL_HAS_OSMESA:BOOL=ON Again, these settings work fine with paraview 3.8.1 and the compiled paraview executable does not produce a segmentation fault. Cheers, Frank. -Original Message- From: Arjun Yadav [mailto:y-arjun...@srigroup.co.jp] Sent: Dienstag, 19. April 2011 08:10 To: Albina, Frank Cc: Kevin H. Hobbs; David Partyka; paraview@paraview.org Subject: Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on. Try messa 7.7.1 We use paraview3.10.0 and messa7.7.1 with mpi support. It does work. Arjun 差出人 : Albina, Frank frank.alb...@sauber-motorsport.com 宛先 : Kevin H. Hobbs hob...@ohio.edu,David Partyka david.part...@kitware.com 件名 : Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on. 送信日時 : 2011/04/19 15:00:32 Hi Kevin! Thanks a lot for the offer. To be honest, I am still having trouble to run paraview v3.10.0/v3.10.1 to have CPU rendering only with additional X support. On the one hand, I am performing the same configuration steps with CMake as for paraview 3.8.1, for which I have had no issues whatsoever wrt. running paraview in this configuration for the last 4 months. I am relying heavily on paraview for post-processing simulation results and it runs on my compute cluster daily in parallel. On the other hand, performing the same configuration steps with CMake for paraview 3.10.0 or 3.10.1 creates an executable which cannot run without producing a segmentation fault, which does appear just after the logo window has popped up. For information, I am compiling the paraview sources from scratch. I have been having the issue on two different computers now: one Linux x86_64 workstation running under SuSE SLES10 and one Linux x86_64 laptop running under OpenSuSE 11.1. It is not a compiler issue, since I have been able to reproduce the problem using different compilers versions (i.e. gcc v4.1.2, v4.5.1, v4.5.2 and v4.6.0) on the same architecture. Here are the settings
