November 29, 2021

Host: Michael Dolan

Attendees:

  • Rémi Achard (TSC) - DNEG

  • Mark Boorer (TSC) - Industrial Light & Magic

  • Mei Chu (TSC) - Sony Pictures Imageworks

  • Sean Cooper (TSC ACES TAC Rep) - ARRI

  • Michael Dolan (TSC Chair) - Epic Games

  • Patrick Hodoul (TSC) - Autodesk

  • John Mertic - Academy Software Foundation / Linux Foundation

  • Carol Payne (TSC) - Netflix

  • Mark Titchener (TSC) - Foundry

  • Carl Rand (TSC) - Weta Digital

  • Doug Walker (TSC Chief Architect) - Autodesk

  • Kevin Wheatley (TSC) - Framestore

  • Thomas Mansencal - Weta Digital
  • Sergio Rojas

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.
  • No labels