[osg-users] [osgCompute] Persistant texture modification using osgCompute / CUDA

Asmar Arsala asmararsala at hotmail.com
Mon Nov 16 04:46:30 PST 2009


Hey Jens,
 
Thanks for you quick reply. As I have been away from the project for a while due to illness I hadn’t been able to really act upon your comments until now.
 
It had also been a while since I worked with Cuda and I had forgotten that Cuda actually makes a crucial distinction between memory allocated through cudaMalloc() versus memory allocated by cudaMallocArray(). In my previous attempts I made the erroneous assumption that a one-dimensional array through osgCuda::Array would lead to cuda-writable memory. 
 
After perusing the osgCuda and osgCompute code I now gather that osgCuda::Array allocates with cudaMallocArray(), osgCuda::Buffer allocates with cudaMalloc() and osgCuda::Texture allocates via OpenGL Buffer Objects. Which would indeed suggest that osgCuda::Arrays are read only, osgCuda::Buffers are read-write, and osgCuda::Textures are read-write (depending on the current OpenGL mapping and binding states). I should point out here that my background is DirectX and that I am not yet all that wise in the ways of OpenGL in general.
 
I had originally tried using osgCuda::Buffers, but then realised that the cudaBindTextureToArray() was failing (for obvious reasons). I then changed to one dimensional osgCuda::Arrays under the aforementioned assumption. In retrospect after having the source data be linear, there wasn’t really any need to map to texture memory, so I could have just as easily stayed with the osgCuda::Buffers and passed both source and destination data pointers to the kernel. This indeed, works fine, however the whole setup has now kind of strayed from the initial intent.
 
The idea is to be able to persistently update textures containing height related data on numerous LOD levels. Hence I want to avoid memory copies as much as possible; especially from host to device, and vice verse.
Now I also gather that the both osgCuda::Arrays and osgCuda::Buffers, due to their nature should be used as very temporary buffers; for cuda computations and not as persistent (texture-related) memory. Hence osgCuda::Textures are in fact the logical choice here. OpenGL can take care of the (device) memory management, Cuda can have read and write access, and changes can remain persistent. I imagine one of the most efficient ways to update a texture would then be to first map to a cudaArray for reading and then writing the result back to the osgCuda::Texture PBO.
 
To test this out I have now changed all osgCuda::Buffers/Arrays to osgCuda::Textures,  however this almost always throws a number of exceptions; sometimes when I debug it (without changing the code) is does not throw these exceptions. When that happens it will actually run perfectly. Otherwise it just doesn’t work. The exceptions thrown are:
 
osgCuda::Context::registerBufferObject() for Context "0": something goes wrong within cudaGLRegisterBufferObject().
unspecified launch failure.
osgCuda::Texture2D::allocPBO() for Buffer "TempBuffer": Could not generate buffer object (glGenBuffers()) for context "0".
osgCuda::Texture::mapStream() for texture "TempBuffer": error during cudaGLMapBufferObject() for context "0". 
unspecified launch failure.
osgCuda::Context::registerBufferObject() for Context "0": something goes wrong within cudaGLRegisterBufferObject().
unspecified launch failure.
osgCuda::Texture2D::allocPBO() for Buffer "DestBuffer": Could not generate buffer object (glGenBuffers()) for context "0".
osgCuda::Texture::mapStream() for texture "DestBuffer": error during cudaGLMapBufferObject() for context "0". 
unspecified launch failure.
 
That is, something goes wrong in Context::mallocBufferObject().
 
Now I’m starting to suspect that the way osgCompute is set up might not be ideal for what I intend to do here, but I would also not be the least bit surprised if I am totally misusing something again.
As before, any suggestions are greatly appreciated.
 
Sincerely,
          Asmar B. Arsala 		 	   		  
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20091116/fc017b6e/attachment.htm>


More information about the osg-users mailing list