Skip to content
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

Info on remote display issues page is outdated #1398

Closed
michaelkarlcoleman opened this issue Jul 13, 2018 · 6 comments

Comments

@michaelkarlcoleman
Copy link

commented Jul 13, 2018

The Linux and Display Issues documentation pages state that mrview/etc. won't work for remote displays. This might have been true in the past, but it's not true for the current Debian release (for example), which has a software renderer that supports OpenGL 3.3.

Although mrview doesn't work natively on our RHEL release, I was able to get it work by running the Singularity/Debian container here: https://singularity-hub.org/collections/729 There'a pretty good chance that this would provide remote X11 display for almost any platform, and this alternative would be good to mention in the docs.

@jdtournier

This comment has been minimized.

Copy link
Member

commented Jul 16, 2018

Thanks for the info - that's the first I'd heard of it. My understanding of OpenGL handling was that it was handled by the GLX library, which explicitly didn't support anything beyond version 2. Maybe that's changed, or maybe the setup you refer to is different altogether?

I'm also not familiar with these singularity containers (first time I've heard of these). Any chance I could get access to an instance to have a rummage...?

@michaelkarlcoleman

This comment has been minimized.

Copy link
Author

commented Jul 16, 2018

I didn't know this was supported either, until a user pointed it out to me. It's certainly not well-documented. As I understand it, the LLVMpipe software rasterizer simply renders the OpenGL calls into a 2D X11 window, and there's nothing stopping that from being done on a remote display. The whole thing could be quite slow for some applications (e.g., first-person shooters), but it seems snappy enough for mrview on a local-ish network.

Note that Singularity wouldn't typically need to be a part of this. Rather, it's just a way to deal with existing systems that have older and/or misconfigured OpenGL stacks. If Debian works, I'd guess that modern versions of other flavors like Ubuntu, Fedora, etc., also would. We're dealing here with RHEL, which is somewhat behind, and perhaps our local system has some bit-rot as well.

I could ask about access, but IMO, you'd be miles ahead to just spin up a Debian instance in VirtualBox or on a crap PC and try it yourself.

@jdtournier

This comment has been minimized.

Copy link
Member

commented Jul 17, 2018

Yes, I've seen the mesa software rasteriser used on different environments, for example VMs running in VMware, or using something like MobaXterm in combination with the Windows Subsystem for Linux. I'm not sure how to set that up reliably though. I don't think it's a server-only setup, since for instance MobaXterm works using the mesa software rasteriser, but fails when hardware acceleration is enabled - but this is a client-dependent parameter. I've just tried to render from my Arch Linux setup (up to date as of last week, mesa 18.1.3-1), but that won't render over ssh -X to an Ubuntu 14.04 system (might because it's running the NVIDIA drivers, so using a different libGL.so - might look into that). So it sounds to me like there's some non-trivial interaction in there that I'm not confident I fully understand, and until I do, I'm hesitant to update the docs substantially...

We could however mention that the mesa libraries can work with software rendering, but that setting this up properly is still unclear at this stage. Is any of this documented anywhere, BTW? I can't find anything relevant about OpenGL3+ remote rendering with mesa in a quick Google search, other than the links you provided...

@michaelkarlcoleman

This comment has been minimized.

Copy link
Author

commented Jul 20, 2018

As you say, there are things going on that seem under- or un-documented, and I also noticed on both the client and server side, merely having 3D hardware around seemed to affect whether this option worked. This stuff seems fiendishly complicated, and even after all these years not really something we can expect to "just work".

I do think it would be worth relating that this option has been seen to work in the wild. In my case, I relied on the doc page in question, and then was mildly embarrassed when a scientist pointed out that it worked fine for them. Oops. :-)

Edit: affect :-P

@jdtournier

This comment has been minimized.

Copy link
Member

commented Jul 27, 2018

Agreed. I'll make a few changes along those lines. As you say, it can't hurt...

jdtournier added a commit that referenced this issue Jul 27, 2018

@jdtournier

This comment has been minimized.

Copy link
Member

commented Jul 27, 2018

Changes in #1411 - closing this, please carry on discussion on the pull request.

@jdtournier jdtournier closed this Jul 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.