New vtkXOpenGLRenderWindow error unable to find valid OpenGL 3.2 or later implementation
Opened this issue · 14 comments
I am hitting a new error that has stopped me in my tracks using vcs8.2. Below is the error text (truncated). The issue is on a terminal on a CDAT8.2 (no-mesa) environment on a RHEL7 machine:
(Pdb) import vcs; x = vcs.init()
~anaconda3/envs/cdat82Py3/lib/python3.7/site-packages/unidata/__init__.py:2: UserWarning: unidata package is deprecated please use genutil.udunits instead of unidata.udunits
warnings.warn("unidata package is deprecated please use genutil.udunits instead of unidata.udunits")
(Pdb) x.plot(climSlice)
2019-12-19 10:54:13.161 ( 10.526s) [ 322A2740]vtkOpenGLRenderWindow.c:761 ERR| vtkXOpenGLRenderWindow (0x55dc36b27d90): Unable to find a valid OpenGL 3.2 or later implementation. Please update your video card driver to the latest version. If you are using Mesa please make sure you have version 11.2 or later and make sure your driver in Mesa supports OpenGL 3.2 such as llvmpipe or openswr. If you are on windows and using Microsoft remote desktop note that it only supports OpenGL 3.2 with nvidia quadro cards. You can use other remoting software such as nomachine to avoid this issue.
2019-12-19 10:54:13.162 ( 10.527s) [ 322A2740] vtkShaderProgram.cxx:447 ERR| vtkShaderProgram (0x55dc33a07560): 1: #version 150
2: #ifndef GL_ES
3: #define highp
4: #define mediump
5: #define lowp
6: #endif // GL_ES
7: #define attribute in
8: #define varying out
9:
10: #define haveColors
11: in vec2 vertexMC;
12: uniform mat4 WCDCMatrix;
13: uniform mat4 MCWCMatrix;
14: #ifdef haveColors
15: in vec4 vertexScalar;
16: out vec4 vertexColor;
17: #endif
18: #ifdef haveTCoords
19: in vec2 tcoordMC;
20: out vec2 tcoord;
21: #endif
22: #ifdef haveLines
23: in vec2 tcoordMC;
24: out float ldistance;
25: #endif
26: void main() {
27: #ifdef haveColors
28: vertexColor = vertexScalar;
29: #endif
30: #ifdef haveTCoords
31: tcoord = tcoordMC;
32: #endif
33: #ifdef haveLines
34: ldistance = tcoordMC.x;
35: #endif
36: vec4 vertex = vec4(vertexMC.xy, 0.0, 1.0);
37: gl_Position = vertex*MCWCMatrix*WCDCMatrix; }
...
Complete error output:
cdat82py3_vcsBug-vtkOpenGLRenderWindow.txt
conda list output:
cdat82py3_conda_list.txt
@downiec @forsyth2 @muryanto1 ping
@danlipsa this is on a RHEL7 machine, using VNC. I'm almost certain that I have hit a very similar issue before (RHEL6 and a much older version of CDAT). Do you remember what the fix required?
@durack1 You should be able to use osmesa fine. if you want to see a window on the screen through vnc you need to follow the instructions in:
https://github.com/CDAT/cdat/wiki/Remote-server-setup-for-VNC
@sankhesh wrote them and both me and him were able to set this up on our recent ubuntu machines.
Indeed, those did not work for rhel6 as the software there was too old. Before you go through this, you have to make sure that OpenGL is setup on that machine correctly. Try to run vcs at the machine console = keyboard and monitor attached to the machine.
@danlipsa thanks for the reply, I had recalled some interaction on this a while back and the URL above is exactly what I remembered, just very poorly, thanks for providing a review.
A problem that we have at LLNL is that the only approved software is VNC provided by RealVNC, or for RHEL7 TigerVNC 1.8.0 or above (which ships with RHEL7). TurboVNC is not approved, and I will have to check on the status for VirtualGL.
Another issue is that most of us are not allowed in the building where these workstations are housed, so testing the OpenGL configuration is not something that is easy to do. If we had a recipe for configuration this could be implemented across machines, but it would have to be done with approved software.
What are the chances that a RHEL7, RealVNC/TigerVNC example could be spun up? I can imagine this will take sometime, and not sure if you have the cycles available to make it happen, certainly not soon?
@danlipsa I have just requested approval for VirtualGL (2.6.3) and TurboVNC (2.2.3), but I am not holding my breath as they already have TigerVNC (1.9.0) approved
@cdatrobot (who are you BTW) yeah, I recalled this too, which was the reason why the solution went nowhere.
That was me, responding directly through email instead of responding from github. That's disapointing that it could not figure out that's the same person - I have the same email address in my profile.
@danlipsa oh well this really seems to be going nowhere, it's a bummer as VCS works better than other graphics packages.
I'll see if we get approval for VirtualGL and TurboVNC but I am not holding my breath. Is there anyway that this could be enabled for VNC sessions without having the jump through all the confusing additional package hoops?
Another software that works well for remote OpenGL is nomachine. It's a lot easier to setup but it is not multi-user. You completely control the remote machine. I currently use this instead of vnc when I work from home because it is faster. But I don't think it would apply for your case = multiple users accessing the same server.
@danlipsa thanks, it seems there is already a request in for nomachine (6.8.1.1) for linux (RHEL7) so hopefully this is approved, is the configuration trivial?
Yes, it is. You just install it and connect. But only one user can use the machine at a time. Not sure what happens if several users connect. They either fight for mouse / keyboard, or they get an error.
@danlipsa, although the docs are a little hard to read, it would seem that the licensed version enables multiple concurrent connections, see https://www.nomachine.com/DT03O00136, so either 4 (Workstation) or 10 (Small Business Server) which I think would work perfectly for our needs
Scalability
This solution provides individual instances of the remote desktops (virtual desktops)
and applications hosted on a single Linux computer. Workstation allows 4 virtual
desktop sessions, Small Business Server allows 10 and Terminal Server provides
an unlimited number. In the case of a larger number of users, you may consider
setting up a multi-host environment with NoMachine Enterprise Terminal Server
to distribute virtual desktops and applications among Terminal Server Node hosts.
This solution allows load-balancing of sessions among multiple hosts.
High-availability of virtual desktops is also possible by setting-up a failover cluster
between two NoMachine Enterprise Terminal Server hosts.
Yes, indeed that seems to be the case. That is cool! Then all you guys have to do is pay the licence. 😄