OpenCL image vs buffer for raytracer?

Started by
3 comments, last by BadEggGames 7 years, 7 months ago

Hi

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?

Thanks

Advertisement

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.

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?

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.

Thanks Joe.

I guess I will figure out how to share a texture between cl and gl to speed things up.

Cheers

This topic is closed to new replies.

Advertisement