ASWF TAC Meeting - October 05, 2021

Video Conference Link

Voting member attendance

Other Attendees

John Mertic, Linux Foundation
Andrew Grimberg, LF Release Engineering
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Scott Wilson, Rust WG
Nick Porcino, Pixar
Matthew Low, DreamWorks Animation
Sergio Rojas, Arena World
Trevor Thomson, Intel
Ashley Whetter, Python 3 WG
Arun Ramachandran

Apologies

Kimball Thurston - Chairperson, Weta Digital Limited
Michael B. Johnson, Apple
Cary Phillips, OpenEXR Representative
Sean Looper, Amazon Web Services

Agenda

Welcome Roy
- Global head of research at DNEG, has been 7 months, background in Real Time Graphics, and commercial VR and themed entertainment applications. Worked on rides and solutions for Disney, Universal, and custom turnkey solutions for automakers.
Python3 WG
- Ashley: group hasn’t met for some time, number of attendees was dwindling, as members weren’t getting value from the meetings. Created some of the initial deliverables:
  - Skeleton 2 to 3 transition guide for studios
- Communication between studios and with vendors, the studios seemed to be mostly saying “we haven’t done anything yet”, being aware of the progres from the studios would have been useful, but not enough to justify monthly meetings.
- Larry: what do we need to do going forward? John: looking at the WG lifecycle and processes, if the WG says they are done, they are done, the TAC can shut it down. The TAC can vote to accept that. Ashley: there was a discussion about the shutdown process for a group, which is why the WG hasn’t shutdown yet since there was no process yet? John: it’s a decision of the TAC as to whether it’s complete is not. Larry: there isn’t really much alternative to “force” more work. Ashley: could decide there are things the group hasn’t covered. There should be ongoing communication with vendors for Python 3 support. Gordon: the TAC decided to start this process, we can do a recap as to what was achieved, maybe the WG isn’t the right vehicle, or not the right set of members, or maybe we decide it’s done. Would be good to have some kind of process to review what was done and see if anything can be learned from it. Michael: might want to keep alive things like Slack channels for archival purposes? John: not a lot of guidelines, the group can decide what it feels is appropriate. Eric: could a short document be part of this? Larry: would be nice to get a summary of where the major players are, and a recap of what got done. What’s the current state of the world in the Python 3 transition. Ashley: yes, can present what got done, what are the loose ends. Larry: are there ASWF or close projects that still don’t support Python 3 / blockers that need resources / attention, or is it just at the studio level to continue fixing up their code? Ashley: no known blockers in terms of OSS projects, lots of vendor provided software that wasn’t Python 3 compatible yet. But since studios are so far behind in the process, so it’s hard to tell that the Python 3 support in OSS projects is working since there may not be enough users yet to find any outstanding issues.
- Larry: we’ll table for now, since we’ve decided there should be some kind of final report.
Rust
- Larry: Rust WG close to having a first deliverable, next project of what to “rustify”. Discussions about short vs long term goals.
- Scott: looking at USD as next target, which is a large project. Also looking in the short / medium term would be OIIO and Ptex. Still working on wrapping up OpenEXR, getting ready to announce what has been accomplished publicly, would like to thank Shannon for writing the blog post. Draft in Slack channel, comments are welcome. Should have a final version on Friday, so should go out sometime this weekend.
- LG: some projects have complicated C++ interfaces that don’t necessarily map to a Rust-style interface? Scott: planning on “unsafe Plus” APIs, some APIs in C++ are hard to get the Rust compiler to agree that memory usage is safe, there are ways to do this, but will require lots of time / energy / research, will need more people to support the project, Rust developers + project members to help create safer APIs, but without dropping important use cases.
- Larry: canonical example in OpenEXR for a difficult to make safe interface is one that has been a “thorn in our side” which is scheduled to be replaced and causes issues with multi-threading. So things that the Rust group has issues with may be good feedback to the project since it may help C++ users as well. So think about where problematic C++ APIs may be improved. Scott: yes, that’s also a long term goal, working with C++ side to make sure “everyone wins”
- Gordon: where are we at in terms of Rust in the industry? Still in the “early part of the hockey stick”, are there good references? Scott: still early on in our industry, people are interested in memory safe languages in our industry, but missing some of the basic packages. So hoping to be a spark. Outside M&E, starting to be used a lot, Amazon / Google / Microsoft are all looking at Rust. Gordon: does the project understand where there is the most value for it? Scott: anywhere C++ is appropriate, Rust could be applicable. Larry: hard to know where this is going, there’s a “chicken and egg” problem, individual studio developers are very interested / intrigued, but so little things can be done in Rust without the core libraries, will the efforts of the Rust group help to kick start / enable the process, allowing us to seriously look at it. JT: younger / up and coming developers are using Rust, so can be important to help attract young talent.
- Gordon: trying to understand what the real shape of the integration of an existing C/C++ library, we used SWIG for Python integration, but how Pythonic was that? What are the big hurdles, where are there code inefficiencies due to automation. Scott: happy to talk one on one, via #rust Slack channel, or can set up Zoom meeting.
Packaging talk? (LG)
- Someone who helps package OIIO / ASWF for Fedora was “venting” a bit due to issues with cross package dependencies, and how distro packages view these projects, what we do that makes their lives difficult, and what could we do to make life easier. Could we invite someone like that to present? What are the patches they need to apply? There’s definitely some education that could help on our part. Is that something generally desirable? Should it be here or in the CI group? Can we get project representation at the CI group? Christina: better to have it in this group to get better attendance. Larry: will reach back to this person, and we’ll see where we get.
Project/WG updates as needed
- OpenVDB/OpenEXR status
  - Required release for VFX Platform
  - Ken: going well, convinced will make the deadline. Still polishing a version ready to go out, allows to build against OpenEXR 3, also a version of Half included in the library.
  - Making good progress on NanoVDB integration, should make it into V9.
  - V9 will definitely make it with OpenEXR 3, 99% sure it will have NanoVDB.
  - Looking at improving build times, some uncertainty as to whether it will make it in time (explicit template instantiation). Some optimizations for offsetting nodes.
- Assets (Eric): moving forward on a number of possible assets
- OpenCue (Brian):
  - Discussions on tweaks to scheduler performance, when the scheduler is under high load, some PRs outstanding that solve the problem in different ways with some overlap, trying to figure out best way to go forward. Also mindful of planned scheduler rebuild.
  - Response to user feedback, want to plan out new user and permission system, most popular request, similar to scheduler rebuild, moving discussion and gathering requirements.
- OTIO (Johsb):
  - Release planning, contributions that haven’t made it into an official release.
  - Nice write up in integrating OTIO into Blender for sound integration. Nice to see community using OTIO
  - A TSC member is out right now so haven’t moved on admin items
- OpenEXR (Larry):
  - Bugfix release 3.1.2
  - Cary working on helping OpenVDB with OpenEXR 3 integration
  - How to keep from breaking ABI on yearly releases, is there a way to do better at long term ABI compatibility, Kimball has made a few proposals along those lines. One the verge of trying to tackle.
  - Eric: what about the CLA document issue? Nick: README refers to the 2.1 document, but still carrying the 2.0 document, and there may be inconsistencies between those two. Larry: thought we were now in sync with the other projects? Christina: also thought we were on 2.1? Nick: all organizations seemed to be OK with the 2.1 document, but one organization may not have signed off yet. Larry: we’ll wait for Cary to be back and coordinate.
Question about MaterialX + USD (mmin)
- Michael: this has come up in USD wg, looking for some guidance as to guidance from MaterialX, is there someone from this project they can reach out to and discuss these issues? If anyone from MaterialX can reach out, that would be great. Gordon: someone reached out to Jonathan Stone, would be great to have a good round trip support between USD and MateriaX that would be great, and Autodesk would be happy to help. Is there a more formal way that could be supported, maybe through a joint WG.