Anyone know how to update a buffer in the OptiX API using atomic operations or where I find the information? Thanks.
Hi, and congrats on being the first OptiX post on the new forums!
The “zoneplate” SDK sample uses atomic operations to update buffers, so you might take a look at that. It just uses the standard atomicAdd CUDA operations to update buffer elements; nothing special is required because it’s OptiX-created memory.
One thing to keep in mind is that atomic operations will not work in multi-GPU situations unless you specify RT_BUFFER_GPU_LOCAL. In that case the data stays resident on the device and can only be read by the device that wrote it.
Thanks guys. It was a little disturbing hitting a forum for answers and finding that I’d be the first post.
It appears the atomic function fixed a race condition where multiple rays with equivalent path lengths were trying to add there contribution to an output buffer at the same time. For very small objects, I think I’m seeing what I expect in the output buffer from the host side. However, as the scene becomes more complex, that buffer looks fishy. Kernel launches are asynchronous right? Does that hold true for Optix context launches as well? If so, do I need to issue a command to ensure the launch is finished and the buffer is stable before I copy it for CPU computation? I haven’t found where it explicitly states that in Optix docs, but maybe I just haven’t located it. Thanks.
rtContextLaunch will not return until all devices have finished rendering. Once it comes back, all buffers should be safe to read.
It is possible to use the context callback mechanism to allow your application to be periodically poked by OptiX during a very long render (e.g., to update a GUI); you should not try to read buffers during those callbacks.