Re: State of OCIO development re: CPU/GPU mismatches
toggle quoted messageShow quoted text
This issue not just tetrahedral interpolation, it is the fact that the existing OCIO OpenGL GPU path folds all LUTs into a single 3D LUT, and this is not sufficient for many transformations (especially ACES when both 2D and 3D LUTs are being used).
We fixed this for our GPU processing pipeline and we were working on contributing it back to OCIO, but that effort got stalled (and it doesn't seem like there is anyone to take the pull request anyway). I'd like to gauge interest in what we did so we can determine if we should restart that effort. We added the ability to generate OpenCL 1.1 kernels which have the same processing steps as the CPU path and therefore produce very similar results (within numerical and math function accuracy). Benchmarked across a set of sample transformations it is, on average, 100x faster than the CPU path (ranging from 19x to 636x for the two dozen ACES transformations tested). However, our implementation is only beneficial to those using OpenCL, which is why I'm asking about interest. Notably, the technique we created could be for an accurate OpenGL path by someone needing OpenGL shaders instead of OpenCL kernels, and is only slightly more complicated for the caller than the existing GPU path, so even if you're not using OpenCL but are interested in an accurate OpenGL path, it would be a good starting point.
Sony Creative Software
On Wed, Sep 7, 2016 at 11:02 AM, Deke Kincaid <dekek...@...> wrote:
Without tetrahedral interpolation you can get better results by creating 65x cubes instead of the default of 32x that the example OCIO configs use (very easy to create with Hp's python script included with the ACES configs). It's still not as good as tetrahedral interpolation but it is close enough for gpu playback. Kevin Wheatley had some good slides & charts on this from his ACES presentation at Digipro if you have an ACM account.