Advertisement Jump to content
Sign in to follow this  

OpenCL image vs buffer for raytracer?

This topic is 878 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts



I am wondering what would be the better data structure for a raytracer that computes each pixel in a separate kernel? Are there any performance gains choosing one or the other?

I noticed some people here use a 1d array then calculate the index from global id. Would an image not be faster by doing away with the index processing?


Share this post

Link to post
Share on other sites

Index processing still happens regardless. Images actually tend to have more complex indexing schemes, such as z-order curves, which provide increased performance due to cache coherency, assuming that you're frequently reading/writing the image.

For a ray-tracer where you do a shitload of work to compute each pixel (so: infrequently write pixel results compared to other work), then the buffer/image indexing scheme probably makes no real difference.

Share this post

Link to post
Share on other sites

Thanks Hodgman, good to know.


One last thing. I am not familiar with opengl and read that opencl can access opengl buffers . Is there any performance increase to be had by writing to an opengl buffer then blit? Or is that not possible?

Share this post

Link to post
Share on other sites

I've done some buffer vs. image performance comparisions, the difference was always close to zero for me.

Images have the advantage that hardware can subdivide them to smaller tiles internally, so vertical pixels are closer in memory.

But for raytracing you probably don't get anything from that.

(Oops, Hodgman already mentioned this)


I'd use data sharing with OpenGL to avoid the need for another copy, although it's cost should not matter much as long as data stays on GPU.

It would be very slow if you download CL data to CPU, and upload it as GL texture again (but it's ok to do so to get going and care for such boring details later).


I would recommend to do some OpenCL vs. OpenGL compute shader tests as well if you want best performance, for both NV and AMD.

I expect OpenCL is still faster, but i'm not up to date.


Also see if you can use GLSL -> SpirV -> OpenGL. Might be a big difference as well, and i think there are already extensions for this.

In Vulkan i get very good performace (tested on AMD only), first time beating OpenCL with compute shaders.


However - on the API side, setting things up is frustrating with compute shaders.

I still prefer to develop everything with OpenCL and port working kernels to compute shader later.

So there is nothing wrong with focusing on OpenCL only, and later do some experiments with alternatives.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!