MESA-LOADER: failed to open swrast

dustyujanin · June 14, 2020, 10:56pm

Hello.
1)I’m install ROS melodic on my Jetson Nano
2) Connecting ssh -X jetson@192.168.1.75
3) trying to run : rosrun rviz rviz and have error:

[ WARN] [1591968633.352928298]: OGRE EXCEPTION(3:RenderingAPIException): Unable to create a suitable GLXContext in GLXContext::GLXContext at /build/ogre-1.9-i02lBV/ogre-1.9-1.9.0+dfsg1/RenderSystems/GL/src/GLX/OgreGLXContext.cpp (line 61)
rviz::RenderSystem: error creating render window: OGRE EXCEPTION(3:RenderingAPIException): Unable to create a suitable GLXContext in GLXContext::GLXContext at /build/ogre-1.9-i02lBV/ogre-1.9-1.9.0+dfsg1/RenderSystems/GL/src/GLX/OgreGLXContext.cpp (line 61)
[ERROR] [1591968633.353122728]: Unable to create the rendering window after 100 tries.
[ INFO] [1591968633.353176531]: Stereo is NOT SUPPORTED
terminate called after throwing an instance of ‘std::logic_error’
what(): basic_string::_M_construct null not valid
Aborted (core dumped)

4) When i run : glxinfo i have error

name of display: :12.0
MESA-LOADER: failed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast
X Error of failed request: GLXBadContext
Major opcode of failed request: 153 (GLX)
Minor opcode of failed request: 6 (X_GLXIsDirect)
Serial number of failed request: 55
Current serial number in output stream: 54

I’m trying DISPLAY=:0 , all is work! But glxgears open window on my JETSON NANO MONITOR,BUT I NEED TO OPEN ON MY PC MONITOR

P.S. On my PC i have AMD RADEON video, not Nvidia. It’s can be a problem?

linuxdev · June 18, 2020, 9:27pm

I don’t use ROS, but know that whenever you forward over ssh (which is what “ssh -X” is doing) that the X events are forwarded and it is the recipient of those events which must have the OpenGL support. It isn’t the Jetson which is missing that support, it is the host PC you are forwarding to.

If you install a virtual desktop (I have no advice on a particular virtual desktop), then X events still render to the Jetson, and the OpenGL support is then provided by the Jetson. The results of the event are forwarded for a virtual desktop, the actual event is forwarded when using “ssh -X”. A virtual desktop is no different than a regular desktop so far as the Jetson is concerned, and the Jetson won’t care if there is no monitor attached, it’ll still work if your DISPLAY environment variable is pointing to the virtual desktop. As is, your current DISPLAY is the host PC’s.

To see what you have on the Jetson you have to log in locally, or at least have a GUI local to the Jetson running and logged in to. The ssh would have to not use “-X” or “-Y”, and you would need to set DISPLAY to the same value as the local GUI session while being logged in as the same user. Then glxinfo would print that session’s OpenGL information.

dustyujanin · June 29, 2020, 9:48pm

Hello.
I make some experiments.

Install to new SD CARD JETPack 4.3
Run ssh -X jetson@192.168.1.78
echo DISPLAY ( Result localhost:10.0)
Run glxgears
Success - i see gears(running on Nano) on my laptop

Install to new SD CARD JETPack 4.4
Run ssh -X jetson@192.168.1.78
echo DISPLAY ( Result localhost:10.0)
Run glxgears

MESA-LOADER: failed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  156 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  41
  Current serial number in output stream:  40

It’s some problem with library versions? How i can debug and fix it? What library i need to copy from 4.3 to 4.4 ?

linuxdev · June 30, 2020, 7:35pm

…the software for OpenGL is running entirely on your laptop for this case.

The second case should also work, but also would require the OpenGL software to be installed on the laptop, not the Jetson. What sometimes happens is that the software release is incompatible. This is worth a bit of elaboration.

The software which creates the events is running on the Jetson. This produces events which are sent to the laptop for interpretation. A given OpenGL version may be expected (the Jetson’s “/usr/lib/aarch64-linux-gnu/dri...” content) based on the version of OpenGL supported by the laptop. If one of those versions changes, then it implies one side or the other is going to fail to find the correct release, but I don’t know which side needs added software. If the Jetson is missing all OpenGL content in “/usr/lib/aarch64-linux-gnu/dri...”, then the Jetson software is at fault. If the Jetson is simply missing the correct version, then you could say either laptop or Jetson are at fault and adding software to either would solve the problem. Not all releases may be available on either the Jetson or the laptop. Don’t know.

At a highter level, the error is looking for a valid context based on attributes such as color depth and direct rendering support. If you log in locally to the Jetson GUI in both versions, and save a log of the following you’ll be able to compare those to what you get from the laptop:
glxinfo | tee log_glxinfo.txt
…most of that information won’t matter, and so you might want to examine a more brief version of this:
glxinfo | egrep -i '(version|nvidia)' | tee brief_glxinfo.txt

If you dont’ have “glxinfo”, then “sudo apt-get install mesa-utils”.

What do you see for the brief log of the working version of the local Jetson glxinfo, the failing version, and the host PC/laptop?

dustyujanin · July 1, 2020, 7:50am

Hello!

Log from PC/laptop

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Version: 19.2.8
Max core profile version: 4.5
Max compat profile version: 4.5
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.2.8
OpenGL core profile shading language version string: 4.50
OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.2.8
OpenGL shading language version string: 4.50
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.2.8
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
GL_EXT_separate_shader_objects, GL_EXT_shader_implicit_conversions,

Log from Jetpack 4.4

server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
GLX version: 1.4
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA Tegra X1 (nvgpu)/integrated
OpenGL core profile version string: 4.6.0 NVIDIA 32.4.2
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL version string: 4.6.0 NVIDIA 32.4.2
OpenGL shading language version string: 4.60 NVIDIA
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 32.4.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
GL_EXT_shader_group_vote, GL_EXT_shader_implicit_conversions,

Log from Jetpack 4.3

server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
GLX version: 1.4
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA Tegra X1 (nvgpu)/integrated
OpenGL core profile version string: 4.6.0 NVIDIA 32.3.1
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL version string: 4.6.0 NVIDIA 32.3.1
OpenGL shading language version string: 4.60 NVIDIA
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 32.3.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
GL_EXT_shader_group_vote, GL_EXT_shader_implicit_conversions,

linuxdev · July 1, 2020, 8:11pm

The versions for OpenGL/GLES appear to be the same for the JetPack4.3 and JetPack4.4, so that shouldn’t be a problem.

I’m probably doing this the hard way, and someone else may be able to go to this more directly, but on the JetPack4.3 install and the JetPack4.4 install, “glxgears” should be located at “/usr/bin/glxgears”. On each JetPack release, what do you see from:
ldd /usr/bin/glxgears

I am thinking perhaps the issue is related to one of the linked files, and I am wondering more specifically if one of the linked files is missing.

Also, could you try with “ssh -Y” instead of “ssh -X”? The “-Y” assumes some parts are secure which “-X” may not.

dustyujanin · July 1, 2020, 8:32pm

JETPACK 4.3

linux-vdso.so.1 (0x0000007f881ab000)
libGL.so.1 => /usr/lib/aarch64-linux-gnu/libGL.so.1 (0x0000007f88047000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f87f8d000)
libX11.so.6 => /usr/lib/aarch64-linux-gnu/libX11.so.6 (0x0000007f87e64000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f87d0b000)
/lib/ld-linux-aarch64.so.1 (0x0000007f88180000)
libGLX.so.0 => /usr/lib/aarch64-linux-gnu/libGLX.so.0 (0x0000007f87ccb000)
libGLdispatch.so.0 => /usr/lib/aarch64-linux-gnu/libGLdispatch.so.0 (0x0000007f87b9f000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f87b73000)
libxcb.so.1 => /usr/lib/aarch64-linux-gnu/libxcb.so.1 (0x0000007f87b43000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f87b2e000)
libXau.so.6 => /usr/lib/aarch64-linux-gnu/libXau.so.6 (0x0000007f87b1b000)
libXdmcp.so.6 => /usr/lib/aarch64-linux-gnu/libXdmcp.so.6 (0x0000007f87b06000)
libbsd.so.0 => /lib/aarch64-linux-gnu/libbsd.so.0 (0x0000007f87ae4000)

JETPACK 4.4

linux-vdso.so.1 (0x0000007f9a416000)
libGL.so.1 => /usr/lib/aarch64-linux-gnu/libGL.so.1 (0x0000007f9a2b2000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f9a1f8000)
libX11.so.6 => /usr/lib/aarch64-linux-gnu/libX11.so.6 (0x0000007f9a0cf000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f99f76000)
/lib/ld-linux-aarch64.so.1 (0x0000007f9a3eb000)
libGLX.so.0 => /usr/lib/aarch64-linux-gnu/libGLX.so.0 (0x0000007f99f36000)
libGLdispatch.so.0 => /usr/lib/aarch64-linux-gnu/libGLdispatch.so.0 (0x0000007f99e0a000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f99dde000)
libxcb.so.1 => /usr/lib/aarch64-linux-gnu/libxcb.so.1 (0x0000007f99dae000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f99d99000)
libXau.so.6 => /usr/lib/aarch64-linux-gnu/libXau.so.6 (0x0000007f99d86000)
libXdmcp.so.6 => /usr/lib/aarch64-linux-gnu/libXdmcp.so.6 (0x0000007f99d71000)
libbsd.so.0 => /lib/aarch64-linux-gnu/libbsd.so.0 (0x0000007f99d4f000)

dustyujanin · July 1, 2020, 9:54pm

BINGO!

I run JETPACK 4.3 and

sudo apt install libdrm-amdgpu1

And 4.3 version is broken too:)
This packet on 4.4 Jetpack is crashing glxgears…
But how i can fix on 4.4 and install old packet? Which installed in 4.3?

dustyujanin · July 1, 2020, 11:08pm

I found the solution
I copy from Jetpack 4.3 to 4.4 file “libdrm_amdgpu.so.1.0.0”
and make symbolik links:
libdrm_amdgpu.so -> libdrm_amdgpu.so.1
libdrm_amdgpu.so.1 -> libdrm_amdgpu.so.1.0.0

And all work fine:)

linuxdev · July 2, 2020, 6:14pm

A rather interesting fix. Does this mean your PC has an AMD graphics card? If so, then that explains a lot.

Whenever you display graphics on your local Jetson display the executable program runs on the Jetson, then the events generated by this are also interpreted on the Jetson. The interpreting part is what the GPU driver is working on. When you display remotely, then the executable is still on the Jetson, but event interpretation is offloaded to the GPU on the remote host PC. The executable and the interpretation are two separate sets of software.

It is natural to provide both executable and event interpretation software on the Jetson. It would be hard to predict that someone would want to do hardware accelerated remote display to an AMD CPU (at least when CUDA is used). I don’t say this for reasons of “taste” or branding, but instead because most people working with a Jetson for edge devices are using CUDA, and AMD does not support CUDA. OpenGL (or ES) is itself a good reason to support both, but it is a much more uncommon case (OpenGL/ES is more or less portable across architectures, but running into the AMD GPU in the middle of the NVIDIA hardware chain is uncommon).

This is not so much a bug as it is error messages not saying something more descriptive about remote display support missing something compatible with a remote PC’s AMD GPU. Of course, if you do not have an AMD GPU on the remote PC, then you can ignore all of the above, and the mystery would deepen.