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/_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
