OpenGL Interoperability - Multi CPU-Threading

Hi,

i have nothing found about this problem …

In my sample application i have created two CPU-threads … the first one will generate some texture-data inside OpenGL and register them with the cudaGraphicsGLRegisterImage function …

The second thread should do some work on this registered texture-data and will at first try to map the registered texture-data with the cudaGraphicsMapResources function. If i run the program single-threaded, so Cuda stuff and openGL stuff runs in a single CPU-thread, all will be fine. If i try to do the Cuda-Work inside a separte CPU-thread the cudaGraphicsMapResources function returns an cudaErrorInvalidDevice error.

So my questions are:

  1. Is it possible to register the texture-data and map/unmap this data in seperate CPU-threads?
  2. I’am not sure about that cuda-context stuff … i use the “CUDA Runtime API” and do not mixing up with the driver API! … so since Cuda 4.0 there should be one Cuda-Context for the whole process (all subsequent threads) which is bind to one cuda-device. Is this right? And if so … are the registered OpenGL resources acessable from any CPU-thread (and therefore same Cuda-context) inside this Process?

I’am using CUDA-SDK 5.0 with one cuda-device and my sample program runs well if CPU-single-threaded.

With best regards, Torsten

In your multi-threaded setup, are you modifying the texture data in OpenGL after it has been registered with CUDA? If so, that’ll produce undefined results. That is, “Accessing a resource through OpenGL or Direct3D while it is mapped to CUDA produces undefined results.” (from the programming guide).

It’s certainly possible to use the mapped OpenGL resource in multiple host threads, as long as they are sharing the same CUDA context. However, I’m not familiar with how this works with the Runtime API (since it does the context managment implicitly), sorry. I believe you can use Driver API calls alongside the Runtime API now though (it didn’t used to be this way).