[osg-users] osgCuda: Using CUDA in osg - Problem with Threading

Mick mick.svt at googlemail.com
Wed Mar 11 14:24:25 PDT 2009

Hi Robert,

thanks for your quick reply. We are really looking forward to
opening osgCuda to the public. We stay also in close contact with Art Tevs.

Robert Osfield wrote:
> A few general notes, the osg::GraphicsContext currently does
> clean up of OpenGL objects during the GraphicsContext::close()
> method, ... so that the GraphicsContext::close() method can safely
> do a makeCurrent() and then do the clean up.

Yes - that was also our first try. The Viewer calls stopThreading()
of ViewerBase which sets GraphicsContext::setGraphicsThread(0) and which then
calls cancel(). When all methods have returned then GraphicsContext::close()
is called to do the clean up.

Unfortunately these calls are all done by the main thread. All the allocated
memory (by cudaMalloc) is bound to the thread which allocated it (in a
multithreaded application this is the GraphicsThread). The CUDA API says
explicitly that these resources cannot be used by another thread by the
runtime API (which we use). Thus, we can only destruct the resources (by
calling cudaFree) in the thread which created the resources. 

Robert Osfield wrote:
> Is there any equivilant to makeCurrent() in Cuda?  I.e can we make the
> Cuda data available to other threads in someway?

We are only familiar with the Runtime API of CUDA. This API does not allow
any context management. We chose this API because it is very comfortable and
allows us also to debug the graphics kernels.
The second API, the Driver API, can do some kind of context handling. But it
can only process precompiled kernels and it does not allow any debugging. 

Robert Osfield wrote:
> ...clean up operations in GraphicsThread, or
> release operations mechanism as you suggest might well be viable or
> not too an intrusive change.

This would be perfect for our needs.

Best regards,

SVT Group

Read this topic online here:

More information about the osg-users mailing list