Early I visualized Optix result by OpenGL using PBO and it worked fine for me.
Now I need visualization by OpenGL ES and it does not support PBO. Also Optix Programming Guide says that Optix can’t write to FBO, texture or render buffer.
Are there any ways to convert PBO to FBO or Another way to visualize Optix result via OpenGL ES?
I had a similar issue with DirectX9 where none of the interoperability functions provided by OptiX allowed me to capture the results.
What worked well for me was using CUDA for the interoperability instead of OptiX. There was a CUDA sample that showed how to write to texture memory. Basically, it created a copy of the texture in global memory. This global memory could be written into from a kernel. After the kernel had completed, it performed a memory copy from this global memory into the texture. Since memory copies that remain on the device are so fast, this extra copy is entirely negligible.
If you can figure out how to do this in CUDA then you’re set. All you need to do is pass the pointer to the global memory copy of the texture to OptiX and write to it that way.
If there’s no such CUDA interoperability for OpenGL ES then you may be stuck copying the results host-side. In my experience, it’s really not as bad for performance as one might expect. It was even faster than the CUDA interop method for small image sizes – the overhead of the CUDA-Graphics interoperability dominates the memory copy time in that case. As you might expect, it scales poorly to large images though.
What GL_Kyle said. ^^^
If it’s not about the performance, you can always use host buffers, upload them to a texture and continue from there as usual, that is, do a texture blit to the framebuffer you have bound.
That’s the standard method when no OpenGl interop is possible.
The OptiX example framework does this when setting SampleScene::m_use_vbo_buffer to false.
Look at SampleScene::createOutputBuffer() and SampleScene::resize() for the different handling.
(OpenGL sidenote: PBOs are something completely different than FBOs. Read that as Pixel-Bufferobject vs. Framebuffer-Object. Think of the first as real memory area, the second is just an object handle and it’s coincidence that is has “buffer” in its name.)