Window resize doesn't work in Abaqus/CAE with EGL backend

[Fancyshirts]

With the EGL backend, I can't get the viewport in Abaqus/CAE to resize correctly. It appears as if the '3D canvas' remains the same size, whilst the window decorations resize correctly. Moving the viewport around on the screen also works fine.

I'm not sure if this is the same 'resize bug' which is referenced in the changelog for version 2.1?

VirtualGL version 3.0-20211119
TurboVNC version 2.2.90-20211222
Rocky 8.5, Linux 4.18.0-348.20.1.el8_5.x86_64
NVidia Driver 510.54 Cuda Vsn 11.6
XFCE4 WM

[Fancyshirts]

Interestingly, after some more fiddling I discovered that everything works if I omit the +wm flag in /opt/TurboVNC/bin/xstartup.turbovnc

[dcommander]

I think it's time to revisit TurboVNC's use of the +wm flag. Normally, VirtualGL monitors the 3D application's X event loop to determine when one of the application windows has been resized. If the 3D application is not monitoring X resize events, then VirtualGL has to monitor them itself. Doing that caused problems with Compiz, which is why the +wm/VGL_WM option exists. (That option prevents VGL from setting up its own X event monitor.) However, Compiz isn't commonly used anymore, since popular compositing WMs (GNOME 3, KDE) have their own compositors these days. I would need to retest the popular window managers on various distributions to ensure that removing +wm doesn't create any unforeseen issues, but I don't suspect that it will. In the meantime, you can work around the issue by executing export VGL_WM=0 in the terminal prior to launching Abaqus/CAE.

[karlkleinpaste]

Just an observation, that compiz is still distributed in both the RedHat (Fedora, Centos) and Ubuntu ecosystems, in conjunction with MATE desktop, including a distinct spin at https://spins.fedoraproject.org/. Losing +wm would make a number of users less happy.

[dcommander]

@karlkleinpaste +wm will still be there. It will just not be enabled by default in TurboVNC. You will be able to easily restore the previous behavior by setting TVNC_VGLRUN='vglrun +wm' in the environment prior to launching a TurboVNC session.

Generally speaking, we do not recommend using a 3D window manager with the TurboVNC Server unless it is necessary. The main reason is performance. Roughly speaking, when using GNOME 3, it is necessary to run the window manager with VirtualGL (and a suitable back-end GPU) in order to get the same MIT-SHM blitting performance as MATE. However, even with VirtualGL, the non-MIT-SHM blitting performance in GNOME 3 will never match that of MATE. Also, if you run an OpenGL application while the 3D window manager is being run with VirtualGL, this causes the rendered frames from the OpenGL application to be passed between the GPU and main memory twice. (VirtualGL reads back the application's rendered frames from the GPU into a shared memory buffer, which the window manager then passes back to the GPU for compositing, and VirtualGL reads back the final composited image to main memory once again.) Streamlining that use case would have similar constraints to implementing GPU-accelerated H.264 encoding in the TurboVNC Server. An optimal solution would require some sort of mechanism that allows VirtualGL to send GPU-resident buffers directly to TurboVNC.

Compiz is a cosmetic add-on and is not necessary when using MATE. (In fact, one of the big reasons why people use MATE is to avoid unnecessary window manager beautification and bloat.) The VirtualGL User's Guide already documents the need to use +wm with Compiz. Philosophically, I would prefer that the default TurboVNC settings break Compiz rather than a popular commercial CAE application. Compiz is generally the domain of advanced users.

[dcommander]

The other thing is: I haven't tested Compiz in probably 10 years. I'm not even sure if modern versions of Compiz require +wm anymore.

[karlkleinpaste]

It does. I use it.

[dcommander]

That's good feedback. Thanks. I will do some testing and report back.

[dcommander]

Compiz is also used by Unity. Even though Unity isn't the default WM in Ubuntu, it is still provided as an option, so I don't think it would be a good idea to remove +wm from the TurboVNC defaults. I would like to further understand the Abaqus/CAE issue and see if perhaps there is a way to work around it within VirtualGL, but unfortunately I have no way to test Abaqus and other commercial applications unless they provide a demo version (which Dassault does not.) For the moment, my best suggestion is to set VGL_WM=0 in the environment prior to launching Abaqus in the TurboVNC session or to set TVNC_VGLRUN=vglrun in the environment prior to starting the TurboVNC session.

[Fancyshirts]

Just a FYI - Dassault actually do offer full-featured evaluation versions, they just don't advertise it and there are a couple of hoops to jump through to get a licence issued. I've had them issued before. Given it's in their interest to have this all working since a number of their large commercial customers are using a VirtualGL+TurboVNC combination to run Abaqus on their clusters, I don't imagine you'd have too much trouble getting them to issue you a short eval licence...

Getting the ear of the right person might be tricky though - easiest way might be to reach out to your closest reseller who should be able to arrange everything required.