View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002888 | ThirdParty | Patch | public | 2018-03-24 23:58 | 2018-08-21 13:24 |
| Reporter | wyldckat | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | sometimes |
| Status | new | Resolution | open | ||
| Platform | GNU/Linux | ||||
| Product Version | dev | ||||
| Summary | 0002888: Notes on how to deal with OpenGL support on ParaView 5.5 or newer | ||||
| Description | My apologies, but I don't have a patch ready yet for this, but before I forget to write about this and in case the solution is needed before then, here goes what I've gathered so far: a. The "OpenGL" render option has been dropped as of ParaView 5.5 (currently in RC3), as hinted by the issue fixed with report #2779: https://bugs.openfoam.org/view.php?id=2779 b. The solution is to use the Mesa drivers that will either partially support newer OpenGL implementations with older GPU chips or will simply use a software-based render implementation, e.g. when its running inside a virtual machine. - Although there is a bug when using VMs, where the Mesa drivers default to OpenGL 2.1 and ParaView 5.5 needs at least OpenGL 3.3. The solution is documented here: https://www.paraview.org/Wiki/ParaView:Build_And_Install#Notes_on_VM_with_linux This translates to the following details in OpenFOAM's dealing with ParaView: a. The option "-rendering OpenGL" will not work as expected in 'makeParaView' with ParaView 5.5 and newer. Therefore, it might be easier to simply drop this option from this script 'makeParaView', given that the next solution also works on ParaView 5.4. b. Regarding the bug with the Mesa drivers when running within virtual machines, it's possible to use the following commands within 'paraFoam' to deploy a hack when necessary, but I haven't got the final script code yet, but here are the notes on what needs to be done: - The following command will get us the current OpenGL version, e.g. it will return '2.1' when running inside a VM (source of this command: https://askubuntu.com/a/387449 ): glxinfo | awk '/OpenGL version/ {print $4}' - If the value is 2.1 or smaller than 3.3, then the version override that can be deployed by running: export MESA_GL_VERSION_OVERRIDE=3.3 - This hack should only be deploy if it's the Mesa driver currently being used, which should be caught with this command: glxinfo | grep "client glx vendor.*Mesa.*" Note: This will also give a positive catch if the OS installation is using Mesa to communicate with the actual GPU drivers, e.g. as it does with Intel and AMD drivers. c. The Mesa drivers have to be installed. The minimum package needed on Ubuntu for building ParaView with Mesa is 'libglu1-mesa-dev'. | ||||
| Additional Information | I was able to use ParaView 5.4 (along with OpenFOAM 5.x) with the OpenGL2 rendering engine within a VM running CentOS 7, which has the Mesa drivers installed. This way I did not need to rebuild ParaView 5.4 with the outdated OpenGL rendering engine. @Chris and @Henry: If you prefer, this report can be closed+suspended until the patch is ready. | ||||
| Tags | No tags attached. | ||||
|
|
Did you manage to build ParaView-5.5.0 on the old OS-s? As well as the OpenGL issues, Qt-4 has also been dropped by ParaView-5.5.0, and Qt-5 is not available by default on CentOS 7, nor is it at the required version on Ubuntu 14.04. |
|
|
No, I haven't yet tried building ParaView 5.5 nor Qt 5.x on older Linux distributions. However... OK, I found the breadcrumbs from when I looked into Qt 5 for ParaView 5.4 and in in the report #2673 I had a look into this and wrote about it: https://bugs.openfoam.org/view.php?id=2673#c8627 In a nutshell, the Qt project also provides pre-built binaries for Linux, but I only vaguely remember testing it with Ubuntu 16.04, so I don't know if there will be any broken dependencies for glib or stdc++. Nonetheless, the SCL for RHEL/CentOS might provide some of the missing dependencies: https://wiki.centos.org/AdditionalResources/Repositories/SCL - more specifically, the package "devtoolset-6" will provide a more recent GCC version (I can't remember which one), so at least any issues with stdc++ will be solved by that... As for Ubuntu 14.04... I haven't tested it yet, but the following wiki page makes the indication that the Qt 5.7.0 binary package works on Ubuntu 12.10: https://wiki.qt.io/Install_Qt_5_on_Ubuntu |
|
|
Not sure who posted this: "I was able to use ParaView 5.4 (along with OpenFOAM 5.x) with the OpenGL2 rendering engine within a VM running CentOS 7, which has the Mesa drivers installed. This way I did not need to rebuild ParaView 5.4 with the outdated OpenGL rendering engine." Is it possible you have some instructions on how you rebuilt ParaView 5.4 with OpenGL2 rendering engine in the VM? I am workin with openfoam5-linux docker script. |
|
|
The instructions are here: https://openfoam.org/download/source/ ... with additional information above. The problem I have also experienced is: - The Docker image uses Ubuntu 16.04 - The OpenGL version is 3.0 in the mesa-utils library on Ubuntu 16.04 - "ParaView 5.5 [and 5.4] needs at least OpenGL 3.3" - see above That's why we use OpenGL in the Ubuntu packs. |
|
|
I've got more news regarding how to continue using the more modern ParaView versions with machines that do not have support for OpenGL 3.3. I've dealt with this for the past week or so, because there were reports on the forum@CFD-Online that using the 'MESA_GL_VERSION_OVERRIDE' trick within VirtualBox did not work as intended. So after some considerable going back and forth with OSMesa and Ubuntu's Mesa installation, the conclusion I reached was the same as published here: https://blog.kitware.com/messing-with-mesa-for-paraview-5-0vtk-7-0/ The trick published there is that we can do a custom build of Mesa with explicit CPU-based OpenGL that can be used to replace directly the default OpenGL libraries, without the need to link directly to them. In other words, if we let ParaView build and link to the system's OpenGL, whichever version it supports, we can then add the custom build Mesa drivers to the 'LD_LIBRARY_PATH' to replace 'libGL.so' and use it instead of the system's one. Furthermore, ParaView provides the command line arguments '--mesa', '--mesa-llvm' and 3 others, as can be seen here: https://gitlab.kitware.com/paraview/paraview/blob/v5.5.2/CMake/pv-forward.c.in#L107 This means that by having the custom build of Mesa with explicit CPU-based OpenGL, placed inside the folder "ParaView-*/lib/mesa", ParaView will load in these libraries on-request through the command line options. So with this in mind, here are the instructions on how we can build Mesa with explicit CPU-based OpenGL on Ubuntu 18.04 (after ParaView is already built): 1. Install the base packages needed for building Mesa from source code: sudo apt-get install mesa-utils libglu1-mesa-dev scons llvm-dev 2. Also turn on the source repositories, so that we can get the source code for the Mesa version used in Ubuntu 18.04, along with also installing the dependencies for building Mesa from source code: sudo sed -i~orig -e 's/# deb-src/deb-src/' /etc/apt/sources.list sudo apt-get update sudo apt-get build-dep mesa 3. For building it, it's now fairly easy to do with normal user permissions: cd $WM_THIRD_PARTY_DIR mkdir $ParaView_DIR/lib/mesa apt-get source mesa cd mesa-18.0.5 scons build=release texture_float=yes libgl-xlib > log.makeMesa 2>&1 && \ cp -vr build/linux-x86_64/gallium/targets/libgl-xlib/* $ParaView_DIR/lib/mesa/ 4. And that's it! We can now launch ParaView 5.5.x with the additional argument '--mesa' and it will use the CPU-based render instead. It will use process threads to try and speed things up on its own, but it will still be somewhat slow to render. On the aforementioned blog post at kitware.com, they do mention that there are additional implementations that rely on AVX and AVX2 to speed things up a bit more, but I have not idea how much faster it really is, specially within a virtual machine. The pre-built versions of ParaView provided at ParaView.org do already provide several of the Mesa builds and its ready to use out-of-the-box, so it would be a matter of testing further with that. Nonetheless, it still feels a bit hard to decide how to address this in the future. Building Mesa from source code is somewhat simple, given their "scons" approach, but still feels like a bit of a fairly long workaround to get it to work on just a few situations. Either way, if you want, I can provide a build script for it and a more general installation instructions, instead of something as tightly linked to Ubuntu 18.04. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-03-24 23:58 | wyldckat | New Issue | |
| 2018-05-15 08:45 | will | Note Added: 0009574 | |
| 2018-05-15 22:13 | wyldckat | Note Added: 0009583 | |
| 2018-06-06 20:21 | joseph@n04-138.net | Note Added: 0009714 | |
| 2018-06-07 09:07 | chris | Note Added: 0009718 | |
| 2018-08-21 13:24 | wyldckat | Note Added: 0009979 |
