Most of the OptiX SDK examples use CUDA-OpenGL interoperability to directly write into an OpenGL pixel buffer object’s (PBO) memory on the GPU device inside the ray generation program. This speeds up the upload to the OpenGL texture object finally used to display the image on the screen with a textured rectangle in OpenGL.
The error indicates that CUDA was not able to register that OpenGL PBO resource inside the OptiX application host code, which in turn means that there is no valid output buffer for that case.
This will only work if the OpenGL implementation running at that time is the NVIDIA OpenGL driver, otherwise there is no CUDA-OpenGL interop possible.
Means your system doesn’t seem to have the NVIDIA OpenGL driver installed.
If that is not possible on that Linux server for some reason (I’m not a Linux user) then the only option is to not use CUDA-OpenGL interoperability.
Some of the SDK example applications have a command line option
--nopbo which disables the default display mechanism with the OpenGL PBO and uses device-to-host-to-OpenGL texture transfers of the raytraced output buffer. That path is obviously slower but should work with any OpenGL implementation running (and in some advanced examples supporting float4 textures.)
For example, the optixHello SDK application has a code path which is not displaying anything but only writes the raytraced image to a PPM file. That path is not using OpenGL interop and should always work.
Please also have a look at the additional OptiX 7 examples linked to inside the sticky posts of this sub-forum. My more advanced OptiX 7 examples support that host transfer and show two different CUDA-OpenGL interoperability mechanisms.