Thank you very much for answering this question last week. I’m only now able to get to read your responses - sorry for this delayed acknowledgement and words of thanks.
Matt, in regards to lobbying AMD by the Blender Community to move further in its OpenCL development, what can I do to help? Is there a specific point of contact at AMD or has the “bugging” been done ad hoc?
Similarly, is AMD’s OpenCL development hindering other software; i.e., Autodesk products, etc. in their respective rendering performances?
As far as I know the only other software using GPU OpenCL for path tracing is SmallLuxGPU, nothing from Autodesk. And even that isn’t a fully featured production engine (no material mixing, motion blur, etc.) so there’s really nothing to compare against. Maxwell and Indigo might use OpenCL on the GPU for previewing, but as far as I know no one has gotten the more complex features of a path tracer running solely on the GPU using OpenCL. The standard itself is young and still-growing, which is why Cycles and Octane have chosen to stick with CUDA for the time being. The truth is that there isn’t much demand for GPU path tracing outside of preview functionalities due to the inherent limits of the architecture (kernel size limits, memory limits, no speed increases with highly differentiated kernels), so it will likely be a while before anyone truly finds the best way to do everything and before we’ll see the big guns hunker down and get their R&D teams cracking on it. Production path tracing is still in its infancy, with Arnold leading the pack. Cycles has taken a generally Arnold-like development path so far, and I expect it to continue, which likely means more and more features aren’t going to be GPU compatible. My assumption is that GPU rendering will be relegated to material previewing and lighting/shot setup in the near future until the pertinent technologies mature, but we’ll see.