I had used the installer method, summarized in, to install JetPack 4.5.1:
Where should the cudart CUDA 10.2 lib located? Is there a method I can leverage the aforementioned method just to try and install CUDA 10.2 only, if it somehow did not get installed?
thanks all!
-t
Hi,
CUDA is located at /usr/local/cuda-10.2/.
You can install with the following command:
$ sudo apt update
$ sudo apt install nvidia-cuda
Thanks.
Hi AastaLLL
that did not work.
----------- code below -------------------------
astro@spock:/usr/local$ sudo apt install nvidia-cuda
Reading package lists… Done
Building dependency tree
Reading state information… Done
You might want to run ‘apt --fix-broken install’ to correct these.
The following packages have unmet dependencies:
cuda-command-line-tools-11-4 : Depends: cuda-cupti-dev-11-4 (>= 11.4.100) but it is not going to be installed
cuda-drivers-470 : Depends: libnvidia-compute-470 (>= 470.57.02) but it is not going to be installed
Depends: libnvidia-gl-470 (>= 470.57.02) but it is not going to be installed
cuda-libraries-dev-11-4 : Depends: libcublas-dev-11-4 (>= 11.5.4.8) but it is not going to be installed
Depends: libcufft-dev-11-4 (>= 10.5.1.100) but it is not going to be installed
Depends: libcusolver-dev-11-4 (>= 11.2.0.100) but it is not going to be installed
Depends: libcusparse-dev-11-4 (>= 11.6.0.100) but it is not going to be installed
Depends: libnvjpeg-dev-11-4 (>= 11.5.2.100) but it is not going to be installed
libnvidia-decode-470 : Depends: libnvidia-compute-470 (= 470.57.02-0ubuntu1) but it is not going to be installed
libnvidia-ifr1-470 : Depends: libnvidia-gl-470 but it is not going to be installed
nvidia-compute-utils-470 : Depends: libnvidia-compute-470 but it is not going to be installed
nvidia-cuda : Depends: cuda-toolkit-10-2 (= 10.2.89-1) but it is not going to be installed
nvidia-driver-470 : Depends: libnvidia-gl-470 (= 470.57.02-0ubuntu1) but it is not going to be installed
Depends: libnvidia-compute-470 (= 470.57.02-0ubuntu1) but it is not going to be installed
nvidia-utils-470 : Depends: libnvidia-compute-470 but it is not going to be installed
E: Unmet dependencies. Try ‘apt --fix-broken install’ with no packages (or specify a solution).
------------------ end code ---------------------------
Actually I see CUDA 11.4 was installed. It looks like it was installed locally from a CUDA-11.4 repo under var/cuda-repo-unbuntu1804-11-4-local. I found
this reference to try and remove it:
But it seems like the nvidia drivers (and dependencies) are still there. (?).
thanks,
-ted
To answer my own post–
The nvidia-cuda install worked after going into local terminal mode Ctl-Alt-F4, and removing the packages, referring to:
Is there a way I can make sure the OpenGL related drivers are installed correctly?
-ted
Not exactly what you are asking, but this should show as NVIDIA and will provide some information on versions:
glxinfo | egrep -i '(version|nvidia)'
If not properly installed, then either the command won’t run, or it will say something about mesa drivers.
If you don’t have “glxinfo”, then use “sudo apt-get install mesa-utils” (don’t confuse a utility program for a driver…some mesa programs are still useful while running entirely on an NVIDIA driver).
Hi,
OpenGL ES should work by default with JetPack flashing and installing all the components.
Do you meet any issues or errors when using it?
Thanks.
Hi linuxdev,
thanks for this suggestion. Well, it outputs:
astro@spock:/usr/local/zed/samples/object detection/image viewer/python$ glxinfo | egrep -i ‘(version|nvidia)’
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 Xavier (nvgpu)/integrated
OpenGL core profile version string: 4.6.0 NVIDIA 32.5.1
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL version string: 4.6.0 NVIDIA 32.5.1
OpenGL shading language version string: 4.60 NVIDIA
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 32.5.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
GL_EXT_shader_group_vote, GL_EXT_shader_implicit_conversions,
Our problem is that ZED SDK Jetson 4.5 tools seem to try and connect to Mesa instead of hardware (EGL not EGS??). I thought perhaps it is because we had nomachine server running on it. But we shut that service down and the same output persists. We are running the programs directly on the physical monitor that is plugged in. Seems like it tries to use MESA (??). Here is typical output from one of the tools:
astro@spock:/usr/local/zed/samples/object detection/image viewer/python$ python3 object_detection_image_viewer.py /NVME/SVO_RECORDINGS/20210526_182313.svo
nvbuf_utils: Could not get EGL display connection
nvbuf_utils: ERROR getting proc addr of eglCreateImageKHR
nvbuf_utils: ERROR getting proc addr of eglDestroyImageKHR
Using SVO file: /NVME/SVO_RECORDINGS/20210526_182313.svo
Opening in BLOCKING MODE
Opening in BLOCKING MODE
NvMMLiteOpen : Block : BlockType = 261
NVMEDIA: Reading vendor.tegra.display-size : status: 6
NvMMLiteBlockCreate : Block : BlockType = 261
Opening in BLOCKING MODE
libv4l2_nvvidconv (0):(802) (INFO) : Allocating (8) OUTPUT PLANE BUFFERS Layout=1
libv4l2_nvvidconv (0):(818) (INFO) : Allocating (8) CAPTURE PLANE BUFFERS Layout=0
[ZED] [Object Detection] SL_AI_NOT_FOUND
libGL: screen 0 does not appear to be DRI2 capable
libGL: MESA-LOADER: failed to open /usr/lib/aarch64-linux-gnu/dri/swrast_dri.so: /usr/lib/aarch64-linux-gnu/libdrm_amdgpu.so.1: undefined symbol: drmSyncobjTimelineSignal
libGL: MESA-LOADER: failed to open $${ORIGIN}/dri/swrast_dri.so: $${ORIGIN}/dri/swrast_dri.so: cannot open shared object file: No such file or directory
libGL: MESA-LOADER: failed to open /usr/lib/dri/swrast_dri.so: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory
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 AastaLLL
From linuxdev response, our problem is that ZED SDK Jetson 4.5 tools seem to try and connect to Mesa instead of hardware (EGL not EGS??). I thought perhaps it is because we had nomachine server running on it. But we shut that service down and the same output persists. We are running the programs directly on the physical monitor that is plugged in. Seems like it tries to use MESA (??). Here is typical output from one of the tools:
astro@spock:/usr/local/zed/samples/object detection/image viewer/python$ python3 object_detection_image_viewer.py /NVME/SVO_RECORDINGS/20210526_182313.svo
nvbuf_utils: Could not get EGL display connection
nvbuf_utils: ERROR getting proc addr of eglCreateImageKHR
nvbuf_utils: ERROR getting proc addr of eglDestroyImageKHR
Using SVO file: /NVME/SVO_RECORDINGS/20210526_182313.svo
Opening in BLOCKING MODE
Opening in BLOCKING MODE
NvMMLiteOpen : Block : BlockType = 261
NVMEDIA: Reading vendor.tegra.display-size : status: 6
NvMMLiteBlockCreate : Block : BlockType = 261
Opening in BLOCKING MODE
libv4l2_nvvidconv (0):(802) (INFO) : Allocating (8) OUTPUT PLANE BUFFERS Layout=1
libv4l2_nvvidconv (0):(818) (INFO) : Allocating (8) CAPTURE PLANE BUFFERS Layout=0
[ZED] [Object Detection] SL_AI_NOT_FOUND
libGL: screen 0 does not appear to be DRI2 capable
libGL: MESA-LOADER: failed to open /usr/lib/aarch64-linux-gnu/dri/swrast_dri.so: /usr/lib/aarch64-linux-gnu/libdrm_amdgpu.so.1: undefined symbol: drmSyncobjTimelineSignal
libGL: MESA-LOADER: failed to open $${ORIGIN}/dri/swrast_dri.so: $${ORIGIN}/dri/swrast_dri.so: cannot open shared object file: No such file or directory
libGL: MESA-LOADER: failed to open /usr/lib/dri/swrast_dri.so: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory
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
Is there a method to force hardware usage?
thanks very much to all for any directions/advice,
-t
The glxinfo shows you have EGL 3.2. However, where did you run the glxinfo from? By “from” I mean was it running natively on an X desktop on the Jetson? I saw you mention NoMachine, and the “glxinfo” of the native X server would differ from that of NoMachine. If you are actually running inside the native server, and run “echo $DISPLAY”, the result would differ from running under NoMachine. You have to be very careful that every command runs inside the same context (the same “$DISPLAY”).
You might want to consider running “echo $DISPLAY” in each environment, and if this ever differs, then this is probably why there is a conflict.
Also, as mentioned, some of this is trying to use Mesa…which could be a result of running in the wrong “$DISPLAY”. Take a look at this specific error:
…this is looking for a desktop PC using an AMD video card, although it is correctly looking for aarch64 architecture. I don’t know what your application is doing to want an AMD video card, but it might be as simple as running more than one environment and one of them is just set up wrong (especially likely if running in some sort of container).