2021-03-22

Owned by Michael Dolan
Mar 22, 2021
3 min read

March 22, 2021

Host: Michael Dolan

Attendees:

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
Sergio Rojas
Stela Espíndola
Rémi Achard - DNEG
Thomas Mansencal - Weta Digital

OCIO TSC Working Group Meeting Notes

  • Several pull requests waiting for feedback i.e. some really small changes:

    • Patrick: A lot of PRs pending for review/approval. Would like to merge these to prevent PR overlap.

      • Several PRs from new contributors. Want to demonstrate active participation in reviews if we want to keep people involved in the project.

    • Doug: Patrick just posted fix for LegacyGPUShaderDesc issue (issue #1294, PR #1352):

      • Patrick: Found no way to make this change without changing API. Required new method.

      • Doug: API change is ABI compatible.

      • Patrick: Bug in 2.0.0 release. Important how to handle this. Only for Legacy GPU code path.

      • Michael: So patch instead of minor version bump to keep with CY2021 VFX ref platform.

      • Summary of further discussion and conclusion:

        • Initial PR made current method with bug raise an exception at runtime, and new method which fixes the bug succeeds. This would force integrators to switch to the correct method. Concerns were raise though that introducing an exception where one wasn't before would be a breaking change for some implementations. Group agrees that instead, both paths will work. The current method with the bug will continue to function, but will result in logging a (ideally compile-time) warning that the other method should be used. The new method will work as presented in PR. When OCIO 2.1 releases the bad method will be removed from the API. In the meantime we should put a clear note (in red box, etc) in docs that the new method should be used in all implementations.

      • Mark B: What's the different between old and new method?

        • Patrick: New method on another class. A little different. The  old method is used too late to make GPU code path. Bug that can't be used. New method somewhere else in API. Completely different design.

  • VFX Reference Platform: CY2021 is now C++17, should we move OCIO default standard to C++14? C++17?:

    • Summary of discussion and conclusion:

      • OCIO will continue to support C++ 11, 14, and 17. Even though VFX ref platform recommends 17, many studios are still on 11 moving to 14. OCIO should default to the lowest supported/commonly used version, which is 11. Builders can opt into building for 14 and 17, but shouldn't have to opt into the lower supported versions from a higher default. It was noted that MSVC support of C++ standards is a bit different. See this page for more info: https://docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?view=msvc-160

      • Mark B mentioned that #ifdef could be used to support newer features if needed, which could later become the default implementation when the default C++ standard increases. OCIO's design is insulated enough to do this where needed.

      • Patrick cautioned that if we don't need new features offered by the newer standards, than there's no need to implement them for now. That there are some interesting performance improvements available though.

      • Michael mentioned that CI job count will need to be an ongoing consideration when supporting more C++ standards. GH Actions supports 20 concurrent jobs, and beyond that we will see longer CI runtimes. When GH supports conditional required checks based on the file types being modified in a PR we can reduce noise by not requiring CI for text-only file changes, but this is not supported yet.

  • Should we move ‘master’ branch to have cmake project version set to 2.1.0-dev? or 2.X.0-dev?

    • Patrick: Have RB-2.0 branch. Need to say something in master branch so they know it's not specific to a release. Could be different later. Propose to change version to have "-dev" suffix. Only will change the binary name that's in cmake. Will use "2.1.0-dev" to differentiate work.

    • Group agrees. This is intended to avoid confusion when developers pull from a non-RB branch, to know it is code in development.

  • ASWF 2.1 CCLA migration

    • Group agrees to try and switch to the new CLA by May, but ultimately will wait for Autodesk to sign it so that Doug, Patrick, and Bernard are not blocked. We will communicate to the wider community once a plan is in place. All current contributors will need to sign the new CLA once we switch over.

    • TODO: Michael will work with John Mertic to establish a change over plan.

  • Other topics:

    • Mei: Any Python PRs I can assist with reviewing?

      • Michael: PR #1342 may need guidance on updating a LegacyViewingPipeline example if you have time. Was glad to see a PR adding much needed code examples. Any other code examples for the docs would be welcome too. The Python binding docstrings could also use some updates where the C++ docs didn't translate well.

    • Carol: We didn't get accepted into GSoC unfortunately.

      • Michael: What's timeline for D&I internships?

      • Carol: Summer timeframe. Will come back with answer in couple weeks. Does it being summer make a difference?

      • Patrick: any time of year is fine for me. Summer will have some vacation, but if we have someone interested that's the most important.