Data initialization done.
Initializing GLUT…
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 150 (GLX)
Minor opcode of failed request: 24 (X_GLXCreateNewContext)
Value in failed request: 0x0
Serial number of failed request: 33
Current serial number in output stream: 34
Hi,
Do you mean X11 forwarding over ssh? It is not supported/verified in default release. It may not work properly. Other users may have tried it and can share experience.
Without forwarding you need to be running in a GUI on the Jetson, or have exported the DISPLAY variable to a running GUI. In the case of “-X” forwarding, it implies your PC must have the correct version of OpenGL or other direct rendering support (or even CUDA if that is used).
I have set the DISPLAY and used the SDK Manager to install the SDK packages on the host. X application display just fine. Can you specify the exact OpenGL libraries needed?
I do not know of specific files (e.g., OpenGL files), but the idea is that when you run and display to a Jetson, then it is the Jetson which must have all of the GPU-related support installed. As soon as you remote display from a Jetson to another computer, it becomes the responsibility of that other computer to have all GPU-related support. In this latter case there is nothing the Jetson could do to fix the issue, it would be entirely up to the PC to make this work.
However, fixing the PC to work is not what most people want. Most people want the Jetson to do the GPU work. To have the Jetson do the GPU work while remote displaying to some other PC implies that the Jetson would run a virtual X server without a monitor, and then the remote PC would use a remote virtual client to connect. The Jetson would not be forwarding X events in this case; instead, the desktop itself would be forwarded. Events imply GPU processing, desktop implies a simple data copy after the GPU has already done its job.
Not sure, but my understanding so far is that opengl is not supported through X forwarding over SSH.
Trying:
ssh -X <my_jetson>
# I have never been able to succesfully run :
glxgears
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Value in failed request: 0x0
Serial number of failed request: 27
Current serial number in output stream: 28
# Nor:
gst-launch-1.0 videotestsrc ! nvvidconv ! nvegltransform ! nveglglessink
nvbuf_utils: Could not get EGL display connection
Setting pipeline to PAUSED ...
Using winsys: x11
ERROR: Pipeline doesn't want to pause.
Setting pipeline to NULL ...
Freeing pipeline ...
These only work with a local display, without X forwarding, and DISPLAY variable set accordingly.
Connecting to xrdp on the Jetson should fit the bill for the latter scenario, right? All the software should be installed on the Jetson, but I get
[CUDA Mandelbrot/Julia Set] - Starting…
GPU Device 0: “Maxwell” with compute capability 5.3
Data initialization done.
Initializing GLUT…
libGL error: 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: 154 (GLX)
Minor opcode of failed request: 6 (X_GLXIsDirect)
Serial number of failed request: 45
Current serial number in output stream: 44
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 24 (X_GLXCreateNewContext)
Value in failed request: 0x0
Serial number of failed request: 44
Current serial number in output stream: 45
Hi,
We would need your help so that we can do further debug. Please share a test sample and steps so that we can replicate it on JP4.4.1/Jetson Nano. The graphics_demos samples probably do not cover this usecase.
I think you are correct, although the reason is likely that software rendering would be required rather than hardware rendering. Something like glxgears might work if both ends were using software-only rendering.
In the case of OpenGL @Honey_Patouceul is probably correct, and that OpenGL may be problematic (and you don’t want to switch to software rendering, this would also cause CUDA to go away).
On the other hand, CUDA can be made to work, but the CUDA arch has to be compiled for the GPU running on the PC. If your Jetson uses compute capability 5.3, then your software would have to also be compiled for whatever compute capability the GPU of your PC uses. For example, many video cards on a PC will be Pascal or Volta (or in the near future, Ampere), and the binary could be compiled with multiple compute capabilities so that it would work with any of the above.
At the very least, if someone were to work on making forwarding work for your case, you’d still need to compile your CUDA app for all involved CUDA architectures.
At the moment I’m just looking for any solution that will run the sample apps remotely, that is, short of having to attach the Jetson to an HDMI monitor.
Just for reference, if you run the following on the host PC, what do you see? glxinfo | egrep -i '(nvidia|version)'
If you don’t have that command, then it can be installed with “sudo apt-get install mesa-utils”.
Similarly, what do you see if you run that same command on the Jetson? Basically this just lists some abilities and their version and who provides it. It might be useful to know ahead of time what each system supports.
EDIT: Note that if you use “ssh -Y” or “ssh -X” to forward, then you’d need to see a non-error response to "glxinfo | egrep -i '(nvidia|version)' before an OpenGL app would succeed. Demos might not need OpenGL, but they could.