2021-11-29
November 29, 2021
Host: Michael Dolan
Attendees:
OCIO TSC Meeting Notes
Review of PRs in progress:
fast-float (#1496):
Patrick: Reviewed this morning. Ready but want to do another performance test prior to approving.
Doug: Do we default to C++14 now?
Patrick: We impose C++11 features, but compile C++14 by default. Some libraries in our ecosystem have minimum C++14, no longer supporting 11, so becomes problematic to not default to the same. Can build with either though.
Kevin: Does fast-float leak symbols?
Patrick: Have not tested this. Will add comment in PR to check.
Optional fast-float discussion:
Patrick: Flag was added to allow user to use it or not.
Mark B: Problem if DCC ships with build with flag, but another doesn't. Two different behaviors for tools to conflict. Better to be always on or always off.
Patrick: Behavior is the same between the two.
Doug: One of the reasons was, you may not need fast-float, depending on compiler being used.
Patrick: Do we always want to have it?
Mark B: Should choose one or another. Bigger matrix to be built and tested, and more variants in the wild, making it harder to swap OCIO builds.
Patrick: Valid point.
Doug: Once we update the minimum C++ version to 17, will remove the dependency, but for now would keep it.
Patrick: Removing the flag would simplify everything. No objection if group agrees on that.
Michael: No objection.
Patrick: fast-float provides localization fix and improved performance.
Mark B: Even if we don't have fast-float, the new implementation will solve the problem other than performance?
Kevin: Yes, since this update, but not before it.
Michael: Speed benefit was particularly useful for shot-based grades, when loading LUTs frequently.
Rémi: I think the fallback implementation is already providing good improvement. fast-float not a huge gain.
Kevin: fast-float is 10-30% faster than re-implementation, which is ~3x faster than previous implementation.
Patrick: Interesting to test on Linux. Good point. For 10%, maybe not worth having the dependency. on mac test, we can challenge dependency. Less obvious on Windows.
Mark B: Are the numbers based on running unit tests?
Patrick: No, creating transforms. Used ocioperf.
Mark B: Seeing unit tests run completely will give better idea for overall performance improvement. More useful metric.
Patrick: I can do more tests, but best tests would be real life. That could be useful.
Doug: Sounds like we're coming to conclusion to get rid of fast-float and just use the new parser. Benefit without added dependency and no switch.
Patrick: Could put flag off by default.
Kevin: On Windows numbers, some are faster or slower, but not radically different. ~6-14%. Would be good to have linux numbers, to make sure there isn't a big difference. If numbers are similar to mac, could not use fast-float.
TODO: Remi will generate Linux numbers for relative comparison. Kevin will test if time.
TSC agreement: If numbers are similar enough to mac, don't use fast-float.
Analysis workflow (#1515):
Rémi: Goal to change the way we use nightly build for testing latest dependencies. Now testing for Linux, macOS, and Windows, and uses fixed version for non-ASWF/VFX dependencies. Changes mostly restricted to GitHub actions and CMake.
Patrick: Important for tracking changes with dependent libraries.
Bug fix (#1535):
Patrick: Fixed problem with search paths, where we would incorrectly fail on first unset context variable.
Release status:
Doug: One more PR in a day or so, fixing ACES implementation issue. Use b-spline in grading transform, same as CTL code. When extrapolating those splines, slopes are not zero, but with ACES output transforms, slopes are zero, which need to be clamped to b-spline domain when inverting.
Rémi: In Nuke if you use OCIO display with ACES output transform, and then invert, can produce NaNs
Doug: Could be related.
PR (#1538) with Metal test framework submitted today.
Michael: Can target release December 14th, final call on 13th.
Items for next meeting agenda:
Make final call on features for 2.1.1 and 2.0.2 releases.