OptiX 5 + cuda 9 + titan V causing 'gl buff objects must be same size as optix buff objs'

This is on a multi-gpu system (the other is a P6000). I had some interaction with Nvidia driver support to be sure there wasn’t a driver problem, as Quadro and GeForce combos are frowned on.

Anyway, when I modify one of the optix 5 SDK samples, like optixWhitted, to use only the Titan V, this error is raised:

OptiX Error: 'Invalid value (Details: Function "RTresult _rtContextLaunch2D(RTcontext, unsigned int, RTsize, RTsize)" caught exception: OpenGL buffer objects must be the same size as OptiX buffer objects)'

Any idea what would cause this? I’m also using driver 387.34

Thank you

How did you force the OptiX application to run only on the Titan V?

Is that board running in WDDM mode or just as compute board? Means is no NVIDIA OpenGL implementation running on that board? In that case the OptiX example would need to be changed to not use OpenGL interop.

Please test if the optixConsole example runs, which is not using any raster graphics API.

Hi Detlef,

Correct, that board (Titan V) is not driving a display.

I am simply limiting the OptiX context to that device (e.g. ‘setDevice’). It uses the other GPU for display (GL).

I love the ASCII rasterization in that demo. Yes, it works, and nv-smi shows C on both devices.

I have not had this problem before. I’ve built an application that explicitly selects GPUs for OptiX contexts (and works on other machines).

any thoughts?

Ok, if that would be due to OpenGL interop, I would have expected that the createBufferFromGLBO() would have already failed. I hadn’t seen your error output before. There is one size related error which I know of which is that interop buffers must not be zero size on OpenGL side before calling createBufferFromGLBO().

In any case, if there is an OpenGL implementation from NVIDIA running on that system and it’s from the Quadro P6000, forcing the programs onto that device should just work.
If the Titan is not running in WDDM mode there cannot be any OpenGL-OptiX interop with that.

Most OptiX samples normally use OpenGL interop by default for the display of the output image.
They are rendering to a pixel buffer object and copy that into an OpenGL texture, all on the device.
That isn’t possible when rendering on a device in Tesla Compute Cluster (TCC) driver mode or in any OptiX multi-GPU context when the output buffer resides in pinned memory on the host.

Some examples offer a switch –nopbo to disable that OpenGL interop, map the output buffer, and copy the data through the host to the OpenGL texture before final display. That should always work.

Please check if the examples you changed to run only on the Titan V device offer that option (–help prints the command line option) and work when setting --nopobo. If yes, that’s your solution.

Before using a Titan V? (Trying to isolate if this is Volta specific.)

I’m not at a place I can check your suggestions right now, but I can tell you that I was able, with the same GPUs, to run the examples with my GPU selection mechanism. This is what changed:

  1. I installed the new driver, 387.34
  2. I swapped slots for the GPUs: I started driving the display from the P6000 instead of the Titan V

E.g I could run from both GPUs individually, but now the Titan produces the described failure

Thank you, Detlef

Means you’re running a Linux OS? Because that 387.34 driver is not on the list of Windows drivers for the Titan V.
http://www.nvidia.com/Download/Find.aspx?lang=en-us

Which driver did you use before?
Maybe try the newer available ones which support both boards.

I need to pass on Linux driver issues. I’m working under Windows OSes.

Was it too soon?

Yes, it is Linux

No, I just looked under Windows drivers first and the oldest released driver for Titan V was 388.59 there.
OptiX 5 requires a CUDA 9 capable display driver and according to its release notes all of these should work.
Windows: driver version 386.01 or later is required
Linux: driver version 384.98 or later is required.

I’m gla that according to this, the driver should work.

I was joking that I told you too soon that I’m a Linux user :D

Detlef, do you know anyone else that may be able to help?

This problem began when I changed drivers.

Let me ask around internally.

Could you provide the driver version number which worked before?

Thanks Detlef, I appreciate your effort.

The previous driver was 384.111