Cuda simulaton oceanFFT failed with code=999(cudaErrorUnknown)

[stuart.xu]

I try to run a CUDA simulation sample oceanFFT and encountered the following error:

$ ./oceanFFT
NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled.

[CUDA FFT Ocean Simulation]

Left mouse button - rotate
Middle mouse button - pan
Right mouse button - zoom
‘w’ key - toggle wireframe
[CUDA FFT Ocean Simulation]
GPU Device 0: “Xavier” with compute capability 7.2

CUDA error at oceanFFT.cpp:296 code=999(cudaErrorUnknown) “cudaGraphicsGLRegisterBuffer(&cuda_heightVB_resource, heightVertexBuffer, cudaGraphicsMapFlagsWriteDiscard)”
corrupted size vs. prev_size
Aborted (core dumped)

A graphic window opened and closed briefly.

My work environment settings are:

1. target: NX production module on CTI Quark board, headless, JetPack 4.5, L4T 32.5.
2. host PC: laptop with Linux 18.04.
3. Since the target is headless, I installed NoMachine to open the desktop of the NX. Xfce4 is installed on NX as a desktop.

When I first run Cuda sample oceanFFT, I hit a libGL error as stated in this thread:

JetPack 4.3: MESA-LOADER: failed to open swrast while in xrdp session

Hi there, after initially struggeling to get the combination of xrdp and gnome to work on the Jetson Nano (I eventually gave up and switched to the Mate desktop. BTW that problems seems to be also swras_dri related), I am now trying to solve the next problem, again it seems to be related to the swrast driver / libgl environent on the Nano. If I try to run glxinfo in a Mate terminal window while being in a xrdp session, I am getting the following error message(s): $ glxinfo name of display: :…

I fixed it with re-link the libdrm.so to libdrm.so.2.4.0.

Other simulation sample programs also hit the sample error on my system. A Nvidia bug report log is attached. I collected this log after the oceanFFT failed.

Anyone has seen this problem and has known solution? Or any hint leading to a fix?
Thanks for your help.

nvidia-bug-report-tegra.log (375.0 KB)

Thanks.

[njuffa]

For embedded platforms, you are likely to receive faster / more numerous answers in the forums dedicated to these platforms:

Jetson & Embedded Systems

[Robert_Crovella]

^agreed

@stuart.xu

Since the target is headless, I installed NoMachine to open the desktop of the NX.

Running a gpu-accelerated OpenGL sample code remotely requires a variety of plumbing, and in my experience its not enough simply to use a remoting tool like nomachine.

To start the debug here, my suggestion would be to first make sure you can run it on the Jetson device when the Jetson device is not headless, and when you can test and confirm OGL acceleration via GPU hardware in that setting. Then, to run remotely, I would make sure to use a proper OGL GPU accelerated remoting solution.

The writeup here may be useful, although it has no connection to Jetson and I have no idea if any of it works on Jetson, as I have not tried it or anything like it in a Jetson setting.

(Yes, I’m aware in that writeup I first direct users to try NoMachine. The rationale is that anyone may find that post with any range of needs, not all of which have to do with GPU-accelerated OGL in a remote setting. For those users that don’t actually need remote GPU accelerated OGL, in my experience Nomachine is a useful tool. However, if you actually need what is described in that posting, in my experience NoMachine doesn’t provide all the needed pieces. Things may have changed and YMMV.)

[stuart.xu]

@Robert_Crovella, Thanks for the advice. The simulation program (oceanFFT) can run on the NX DevKit, which has a HDMI port. It can also run from a NoMachine client connected to the NX DevKit. I will follow the provided link to see if I can make it remotely displayed from the headless module.
Thanks again.