Hi Mick,
Interesting news about osgCuda :-)
I'm open to merging changes to the core OSG to facilitate third party
NodeKit's like osgCuda. I'm not familiar with implementation/usage of
Cuda so I can't comment on specifics.
A few general notes, the osg::GraphicsContext currently does clean up
of OpenGL objects during the GraphicsContext::close() method, this
doesn't require the same thread that the OpenGL objects were created
from, only that that any GraphicsThread associated with it does a
releasContext() prior to exit of the thread, so that the
GraphicsContext::close() method can safely do a makeCurrent() and then
do the clean up.
Is there any equivilant to makeCurrent() in Cuda? I.e can we make the
Cuda data available to other threads in someway? This could be used
to avoid this issue for Cuda in the same way we tackle it in OpenGL.
Failing this a callback/clean up operations in GraphicsThread, or
release operations mechanism as you suggest might well be viable or
not too an intrusive change.
Robert.
On Wed, Mar 11, 2009 at 4:43 PM, Mick <mick....@googlemail.com> wrote:
> Hi,
>
> my name is Mick an I'm currently involved in a project we call osgCuda.
> osgCuda is based on osgPipe which can be added as a leaf node
> anywhere into the osg-scenegraph and which enables you to jump to the
> GPU for any kind of calculations using Nvidia's CUDA. The data
> manipulated by CUDA is then afterwards available to the scenegraph for
> further processing (e.g. rendering).
>
> We plan to make this nodekit available to the public very soon so
> everybody who might be interested in connecting osg and cuda is
> welcome to test/use it.
>
> At the moment we still have one problem to be solved:
> In a single threaded application (i.e. osgViewer::Viewer::SingleThreaded)
> everything works fine. In a multithreaded environment (e.g.
> DrawThreadPerContext/
> CullDrawThreadPerContex/CullThreadPerCameraDrawThreadPerContext) we have
> problems
> to clean up the memory allocated by CUDA at the end of the application.
>
> The reason for this is obvious: any CUDA resources created through the runtime
> in one host thread cannot be used by the runtime from another host thread.
>
> In our case:
> We allocate memory within a GraphicsThread. When the application closes the
> main
> thread which also runs ViewerBase::stopThreading() then prevents CUDA from
> releasing its resources because the GraphicsThread associated with CUDA
> doesn't exist
> anymore. That is why we are not able to clean up the CUDA resources and why
> the application
> crashes at the end while running the osg application multithreaded.
>
> One solution we have verified would be to release the resources at the end of
> GraphicsThread::run() by adding
> OperationThread::_operationQueue->releaseAllOperations().
> This would work because we ensure that we have added one osg::Operation per
> GraphicsThread
> which takes care of releasing the resources in its release-method.
>
> But this would require a change of the osg core library within the
> GraphicsThread.cpp file.
>
>
> Code:
> void GraphicsThread::run()
> {
> // make the graphics context current.
> GraphicsContext* graphicsContext =
> dynamic_cast<GraphicsContext*>(_parent.get());
> if (graphicsContext)
> {
> graphicsContext->makeCurrent();
>
> graphicsContext->getState()->initializeExtensionProcs();
> }
>
> OperationThread::run();
>
> OperationThread::_operationQueue->releaseAllOperations();
>
> if (graphicsContext)
> {
> graphicsContext->releaseContext();
> }
>
> }
>
>
>
> Does anyone know another solution to our problem?
>
> Robert, we guess it would not be that easy to change the core in the way we
> did (just adding
> something like a "releaseAllOperations()" to the GraphicsThread's run()
> method to ensure that
> all osg::Operation's will be notified before thread-termination)?
>
> Thank you for your help.
>
> Best regards,
> Mick
>
> --
> SVT Group
>
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=8278#8278
>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
