Results could not display, but no error message (running on remote servers)

[wlhsiao]

When I run make tests, at the test_launch_smoke_test, a blank window popped up but before any results could be shown, it closed. Tracing down the code, I found that the window popped up at self.mvs = MeshViewers(shape=[2, 2]) in tests/test_meshviewer.py, and closed soon after reaching self.mvs[0][0].set_static_meshes([self.meshes[0]]). Specifically, it seems to be this line self.client.send_pyobj({'label': label, 'obj': obj, 'which_window': which_window}) in the psbody.mesh.meshviewer that triggers the window to close. 

I was expecting to see a sphere or a cube displayed in the window, as opposed to automatically closing without showing anything. I'm wondering how I could fix this? I'm running the code on a remote server. Any advice or help is greatly appreciated!

[neonb88]

I am facing the same issue on my gcloud compute instance, but it works on my local machine. Please let me know if you resolved this issue :smile:

[ioreshnikov]

@wlhsiao @neonb88 Hey! Thanks for reporting the issue. Before we can proceed with solving it, could you please provide us with a more detailed explanation how you run the tests, especially how you connect to the remote machine?

[wlhsiao]

My local machine is a Mac with an Intel graphic card and my remote machine is a Ubuntu machine with Nvidia 1080 Ti graphic card. It seems like Mac is known for unresolved incompatibility with XQuartz and indirect GLX rendering, so I first configured my Mac to enable indirect GLX rendering, and ssh to the remote machine with +iglx and -X -Y options. After logging in to the remote machine, I ran this command export LIBGL_ALWAYS_INDIRECT=1to make sure indirect rendering is indeed enabled, and by trying out glxgears I could see the rotating gears working.

When I run make tests, I set multiple breakpoints in the meshviewer.py to see which line triggers the program to quit unexpectedly, and it seems to be this line self.client.send_pyobj({'label': label, 'obj': obj, 'which_window': which_window}) in the psbody.mesh.meshviewer. With an attempt to catch the error message from the program, the error I caught was:

X Error of failed request:  BadRequest (invalid request code or no such operation)
Major opcode of failed request:  149 (GLX)
Minor opcode of failed request:  187 ()
Serial number of failed request:  216
Current serial number in output stream:  216

I also ended up saving the mesh out from the remote machine to copy back to my local machine for rendering. Rendering works perfectly on my local Mac, so I guess the culprit should be communication with X server. Thanks for your time and effort releasing this amazing software and kindly supporting!

[ioreshnikov]

@wlhsiao Sorry for the long reply.

I followed on your comment and tried to reproduce the issue and got even more unlucky then you are. My setup is a bit different -- I used a Linux laptop as my local machine and an Ubuntu VM as my remote. In my case indirect rendering didn't work even for glxgears and the window was freezing after the first rendered frame (while reporting some insane FPS in the terminal :).

Anyhow, I think the issues we experience might be due to this bug: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1776447 Looks like indirect rendering has been broken in Xorg for at least four years.

However, we found a work-around. The next release should include a utility that will allow you render the meshes over the network without the need to copy. I don't have an ETA yet, but it should be soon.

[ioreshnikov]

@wlhsiao @neonb88 we've just released a new version. Please see this section of the README

https://github.com/MPI-IS/mesh#viewing-the-meshes