![]() (But that can be done in other ways.)Įven on older O/S distributions that re-used the same X server connection between the display manager and the local login, the display manager would still reset the X server connection when the user logged out, and that had the effect of killing any applications that were currently running in VGL. The machine is a server, and they want to administer it.(But if that's the case, why would they also need to allow other users to access it remotely?) The machine is their personal workstation.The only reasons I can fathom why anyone would want to log in locally on a VGL server are: Use the new EGL back end (currently available for testing in the 3.0 evolving pre-release build), which eliminates the need for 3D X server access and thus eliminates any conflict between VirtualGL and local logins. Use a dedicated X server running on a different (perhaps lower-spec) GPU for local logins, and reserve the 3D X server solely for VirtualGL.Leave the 3D X server at the login prompt and either: There unfortunately isn't anything we can do about that. ![]() The 1 fps performance issue is very likely due to vglrun starts off fine after a graphics manager reset but slows to a crawl after several minutes #120, in which case modifying nf as recommended in that issue and restarting the 3D X server should resolve Thanks for the clarification. As to why vglconnect -s didn't previously work, that was likely due to Issue 1 above. That explains why vglconnect -s works but vglconnect with no arguments doesn't. Given that you aren't seeing a connection message in the vglclient logs, it's very likely that the issue with vglconnect is due to a firewall on your client machine. Thus, when you re-ran vglserver_config, this issue was eliminated. VGL 2.6.2 was the first release that addressed that issue, and it was necessary to re-run vglserver_config after upgrading to VGL >= 2.6.2 in order to receive the fix. Ubuntu 18.04 was the first Wayland-enabled Ubuntu release, which explains why VGL stopped working when you upgraded to that release. If you're the only user of the machine, then it's fine to allow local logins on the 3D X server, but doing so requires either disabling local Wayland logins (by running vglserver_config) or logging in with an Xorg session and leaving the session logged in. If local logins are desired on a VGL server, best practices are to use a dedicated low-end GPU for the local console and a dedicated high-end GPU, configured for headless operation, for VGL. Most systems that are configured for use as VirtualGL servers aren't used for local logins.īest practices are to not allow local logins on the 3D X server, because when someone logs in and out locally, that will reset the 3D X server, thus causing any applications currently running with VirtualGL to abort. Unfortunately, that disables local Wayland logins, but: (With GDM/Wayland, the 3D X server either isn't running at the login prompt, or it is running on top of Wayland and thus can't be assigned the proper permissions for use with VirtualGL.) VGL 2.6.2 introduced changes to vglserver_config that work around this problem by forcing GDM to use X11 rather than Wayland. The OpenGL error you initially reported was very likely due to the fact that modern GDM releases use Wayland by default, which means that VirtualGL can't connect to the 3D X server while the 3D X server is sitting at the login prompt. There are three separate issues at work, here. | GPU GI CI PID Type Process name GPU Memory | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr.
0 Comments
Leave a Reply. |