<p>In short: All of it can benefit from OpenCL.</p>

<p>Path tracing is done by taking many individual ray samples from a scene and combining them into a final image.  As the number of samples increase, so does the quality of the resulting image.</p>

<p>If you are doing regular path tracing (not photon mapping or bidirectional path tracing or anything like that), each sample needs just READ ONLY access to the scene so can work completely independently of the other samples.</p>

<p>That fact makes path tracing astonishing parallelizable.  If you had an output image resolution of 1000x1000, for a total of 1,000,000 pixels, and took 10,000 samples that would mean you needed to take 10,000,000,000 (10 billion) samples.</p>

<p>Each one of those samples is parallelizable, so if you had 10 billion cores, you could make use of all of them.</p>

<p>There are pragmatic concerns when doing this including cache coherency, but the costs of getting that wrong with the naive implementation are much smaller than the benefits of going massively threaded in the first place.</p>

<p>Here is some more information about the details of naive path tracing if you are interested:
<a href="http://blog.demofox.org/2016/09/21/path-tracing-getting-started-with-diffuse-and-emissive/" rel="nofollow noreferrer">http://blog.demofox.org/2016/09/21/path-tracing-getting-started-with-diffuse-and-emissive/</a></p>

CC BY-SA 3.0
2016-11-30T23:34:36.953Z
It's funny, I joined this stack site because of you :) (i read your tags after you answered my UDP question on gamedev). Cheers!
Mr. Developerdude
CC BY-SA 3.0
2016-11-30T23:36:25.700Z
Small world!  There's a great graphics community on twitter too.  Check out who i'm following (@Atrix256) if you want to get into that.  BTW, now I'm wondering what sort of remote control robot application needs to do OpenCL path tracing.  It sounds like you run an interesting business (:
Alan Wolfe
CC BY-SA 3.0
2016-11-30T23:39:35.780Z
That is just the tip of the iceberg... I am writing the path tracer to render images for training a machine learning algo to make a SLAM for robots. Project is not officially launched yet, but site is online to cath some early SEO: http://www.octomy.org/
Mr. Developerdude
CC BY-SA 3.0
2016-11-30T23:14:44.050Z
2016-11-30T23:14:44.050Z
Alan Wolfe
<p>After looking at a lot of existing implementations, I am currently implementing a path tracer in OpenCL. However there seems to be divergence to what parts of the pipeline can actually benefit from OpenCL acceleration.</p>

<p>So is it possible to construct a complete path tracer in OpenCL? What parts of the pipeline will benefit the most? Which will benefit the least? Are there any parts that is recommended to keep out of OpenCL?</p>

<pathtracing><opencl>
What parts of unbiased path tracing pipeline can benefit from OpenCL?
Mr. Developerdude
# What parts of unbiased path tracing pipeline can benefit from OpenCL?

(Asked by: username_0 on 2016-11-30)

After looking at a lot of existing implementations, I am currently implementing a path tracer in OpenCL. However there seems to be divergence to what parts of the pipeline can actually benefit from OpenCL acceleration.

So is it possible to construct a complete path tracer in OpenCL? What parts of the pipeline will benefit the most? Which will benefit the least? Are there any parts that is recommended to keep out of OpenCL?

**Tags:** pathtracing, opencl


---

## 1 answers

### Answer by username_1 on 2016-11-30. Score: 2 | Accepted answer

In short: All of it can benefit from OpenCL.

Path tracing is done by taking many individual ray samples from a scene and combining them into a final image. As the number of samples increase, so does the quality of the resulting image.

If you are doing regular path tracing (not photon mapping or bidirectional path tracing or anything like that), each sample needs just READ ONLY access to the scene so can work completely independently of the other samples.

That fact makes path tracing astonishing parallelizable. If you had an output image resolution of 1000x1000, for a total of 1,000,000 pixels, and took 10,000 samples that would mean you needed to take 10,000,000,000 (10 billion) samples.

Each one of those samples is parallelizable, so if you had 10 billion cores, you could make use of all of them.

There are pragmatic concerns when doing this including cache coherency, but the costs of getting that wrong with the naive implementation are much smaller than the benefits of going massively threaded in the first place.

Here is some more information about the details of naive path tracing if you are interested:
<http://blog.demofox.org/2016/09/21/path-tracing-getting-started-with-diffuse-and-emissive/>

> **Comments:**
> **username_0**: It's funny, I joined this stack site because of you :) (i read your tags after you answered my UDP question on gamedev). Cheers!  
> **username_1**: Small world!  There's a great graphics community on twitter too.  Check out who i'm following (@Atrix256) if you want to get into that.  BTW, now I'm wondering what sort of remote control robot application needs to do OpenCL path tracing.  It sounds like you run an interesting business (:  
> **username_0**: That is just the tip of the iceberg... I am writing the path tracer to render images for training a machine learning algo to make a SLAM for robots. Project is not officially launched yet, but site is online to cath some early SEO: http://www.octomy.org/  

---

