-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New vtkXOpenGLRenderWindow error unable to find valid OpenGL 3.2 or later implementation #430
Comments
@danlipsa 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: 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 |
What I remember from when I set this up is that TurboVNC is the only one
that works with VirtualGL - it was developed and modified specially for
that. The other VNC variants don't work.
…On Thu, Dec 19, 2019 at 4:18 PM Paul J. Durack ***@***.***> wrote:
@danlipsa <https://github.com/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?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#430?email_source=notifications&email_token=AEW527CWALZHJLFAHFLZ3J3QZPQLVA5CNFSM4J5NWTAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHLB7AY#issuecomment-567680899>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEW527H5JW4ZZMARYS6LDX3QZPQLVANCNFSM4J5NWTAA>
.
|
@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
|
Yes, indeed that seems to be the case. That is cool! Then all you guys have to do is pay the licence. 😄 |
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:Complete error output:
cdat82py3_vcsBug-vtkOpenGLRenderWindow.txt
conda list output:
cdat82py3_conda_list.txt
@downiec @forsyth2 @muryanto1 ping
The text was updated successfully, but these errors were encountered: