bicubicTexture] No protocol specified
[bicubicTexture] freeglut (/home/ubuntu/NVIDIA_CUDA-7.0_Samples/3_Imaging/bicubicTexture/bicubicTexture): failed to open display ‘:0’
[bicubicTexture]
This tends to mean the environment was not set up to point at a display. Is this a remote connection running the program, e.g., over ssh?
yes… i m using host(laptop) to connect tx1 remotely
Remote execution complicates things. From the very start X11 was designed to display graphics on a workstation which was remotely connected to a mainframe, or to both execute and display graphics on the same workstation.
In the case of everything being on the workstation, any of the program’s graphics requirements are also fulfilled by libraries or infrastructure of the workstation. If the workstation had everything required, e.g., OpenGL libraries, and everything the program itself wanted, e.g., various C libraries, life was simple.
As soon as you separate display and execution machines you get a division of required infrastructure. Things needed for execution are required on the remote machine, but the remote machine no longer requires any of the graphics support because the graphics is offloaded to the display machine. Suddenly the display machine requires the graphics support, e.g., the OpenGL libraries.
X11 uses the environment variable “$DISPLAY” to know where graphics infrastructure is to be found. If you log in locally under X11, DISPLAY is automatically set to the local machine (typically “:0”). If you log in remotely, then you have to tell the remote execution program via that variable where to display…typically if your IP address is “1.2.3.4”, it would be “1.2.3.4:0”. Missing “$DISPLAY” means you get the errors above which you found.
Under ssh you may need some setup to allow remote display using ssh’s automated environment setting…try what follows to find out. ssh has basically two mechanisms to support remote X11 graphics forwarding, one of which is non-secure (“-X”), the other is somewhat more secure (“-Y”). When I do remote graphics display on my x86_64 desktop from my Jetson, I log in to Jetson from the desktop via (address not really “1.2.3.4”, adjust as needed):
ssh -Y ubuntu@1.2.3.4
Running an application via that ssh login then results in display and interaction on the desktop PC monitor. There are some details which you should know about which may mean things are not as you expect.
First, the graphical support is from the desktop. If you have a newer or faster version of OpenGL on your desktop, then your desktop resources are used, not the Jetson’s. Sometimes the GPU from CUDA is mistaken for graphics, and performance may be from offloading CUDA from Jetson to desktop…if that desktop has over 1000 CUDA cores, and if CUDA cores limit performance, you’ll see some very interesting performance changes.
If the program requires OpenGLES, and if your desktop does not have OpenGLES, the program will fail complaining about missing libraries. If the program wants a different version of OpenGL or OpenGLES than what your desktop has, you may also get errors which do not occur when running natively on the Jetson.
If you run from ssh via Windows without somethig like Cygwin, it just won’t work even if Windows has OpenGL capability.
Hardware acceleration in general may be lost to some extent…if the same program runs natively on desktop at very high speed or natively on Jetson at very high speed, then the remote display version may run at a much lower frame rate than the application running natively on either Jetson or desktop (a performance drop in excess of what might be considered to be network throughput as a bottleneck).