Computer Graphics Stack Exchange is a question and answer site for computer graphics researchers and programmers. It only takes a minute to sign up.
Sign up to join this community
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?
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/
