...
- TSC Leadership 2022:
- Chair: Carol Payne
- Chief Architect: Doug Walker
- ACES TAC Rep role:
- Michael: Discussed better defining this role last year. Was thinking one task could be leading the ACES config initiative, since it's directly connected to OCIO and ACES and is user facing.
- Carol: What are the big things we're collaborating on, and what else do we want to collaborate on? AMF, configs. Those require attention, whether by a person or group.
- Doug: Already a lot of collaboration between projects. Even though no official documented role, a lot of cross communication between projects.
- Carol: Sort of intended that person be OCIO rep on ACES TAC. Doug, Sean, and Kevin are on ACES TAC. Could just be that we have someone there each time, and multiple people.
- Doug: Up to ACES leadership if they want an official OCIO rep. Don't think ACES has that now, but something to bring up. We could also have a reserve ACES TAC member on TSC. Part of role of communication is to surface problem areas at the TAC meetings. There is architecture and implementation TACs. That's where to get attention of ACES leadership. We email leaders now, but if need discussion, no other place to do that other than the TAC meetings. Good to have someone to report on both sides.
- Kevin: They may say counter to that: OCIO is a vendor, so may have concern of explicit representation. Open meetings, so open to talk as long as on agenda.
- Carol: Agree. Difference with OCIO is we're both open source. Good point to get time on TAC agenda to see how we want to work together. After the configs are done would be a good time to do that.
- TSC absentee policy:
- Michael: Possible topic for TAC. If TSC member absent for year or more, what's our policy to move forward?
- Doug: Connected point to that is our governing documents are strict in terms of quorum. Not allowed to make decision without quorum. We've been able to do that, but if we're strictly following our docs, could become issue.
- Carol: We've done a good job about adding TSC members each year, but good to have something in there to prevent opinions from getting stale. Good to have new people to share opinions, and not make people feel that they need to stay on forever.
- Doug: Could turn it into annual thing for everyone; do you want to continue or not? Give people easy way to step down if they want. Right now, if someone is struggling to participate, there's no motivation to contact us and say they don't have time.
- Carol: ASWF is having tenure conversations for board/TAC members. Could pull from some of that. ASWF policy overall, and can be looked at on project levels after that. D&I initiative.
- Michael: Have also been conversations about project lifespan at TAC. Proposal to pursue higher levels of CII badge and have check-ins on project health. Also could be case where a project is moved into archive status if it's been inactive for a long time, etc.
- GSoC:
- Carol: I'm currently getting ready to fill out GSoC paperwork for ASWF. Do we want to commit the time to participate? Don't need to be a student anymore. Anyone over 18 is able to participate. Also allowing smaller and full summer size projects. Are we still interested in participating?
- Michael: Can mentorship be shared?
- Carol: Yes, they recommend it. Need a dedicated mentor to work through code.
- Michael: FFmpeg OCIO project would be cool. We almost had that two years back.
- Carol: Kevin brought up OCIO in WebAssembly.
- Michael: That would be huge. Will have to tackle it eventually with so much production in the cloud.
- Carol: Could also be a POC for further work.
- Kevin: Topic coming from perspective of review and approval group.
- Carol: Other topic was about more support for ICC. Tough subject to get interest in.
- Michael will to be mentor and Mark B willing to help.
- Doug: More interested in ASWF internship program.
- Carol: Don't think we can do both. Going to apply for GSoC. If we can't get in, will host internship program. If we do get into GSoC, will push internship to next year.
- Michael: Would prefer WebAssembly if there's a choice.
- Doug: One side is getting OCIO running in browser, the other is turning off existing stuff in browser.
- Michael: Do we just want to have that project, or that and ffmpeg?
- Carol: Both would be cool.
- ffmpeg project:
- Doug: If you're outputting EXRs, would save you a step of having to generate intermedia files.
- Kevin: It's interesting to figure out use cases. Potentially useful, but we wouldn't use it. Some would find use case for it.
- Carol: Many other pieces to puzzle, but one piece of that, which might make other things more available, like AMF and framing decision list.
- Mark B: Would also be hard to merge upstream, but think it's a good feature. I would use it a lot.
- Carol: More possible now since EXR is supported.
- J: Let's keep it.
- OpenFX plugin feedback:
- Mark B: OFX plugins build, but performance is not great
- Michael: Yes, performance not as good as we hoped. Part of goal was as reference plugin implementation, so didn't focus on that.
- J: Would be good to improve performance.
- Rémi: Any DCC in mind for OFX OCIO plugin? Different ways to accelerate plugins.
- J: Want to be able to provide that as useful tool for others we work with.
- Michael: Resolve has GPU accelerated path, but not available to other OFX clients.
- J: Worth exploring. Resolve is main use case.
- Michael: Pixel processing is in one place, so could fix it in one place.
- Correction: In meeting I mentioned remembering our OpenFX plugins were single threaded. I double checked after meeting and they are multi-threading using an interface provided by the OpenFX Support lib (C++ wrapper). CPU only implementation, but should be threaded. It's possible there could be a host implementation issue, or something we're doing wrong. Will need investigation.
- J: We can spend time to get that up and running.
- Michael: Can add CMake options for custom build if we need to support different compile options.
- GPU caching discussion:
- Doug: Thread on Slack about caching for GPU. Did Patrick see it?
- Patrick: Don't have time to investigate right now, but will think through it.
- Doug: Is it needed?
- Patrick: Only needed if two processors can use the same LUT.
- Rémi: that was the idea. If you create multiple GPU processors that share a LUT, currently will upload texture for each, even though they are already available on GPU. For now have to compute yourself the hash, but OCIO is already hashing LUTs for processor, so wondering if it could be reused.
- Patrick: If you have two different processors, can we share LUTs? If they are the same. We are building cache for processor that contains ID for LUT, but don't remember how to access it. Have to double check.
- Rémi: If you have multiple shots, and per shot CDL, your processor could be different, so lot of duplication.
- Doug: Had talked about trying to split things up for the cache, but requires some extra work.
- Mark B: Does it cache if multiple config objects referencing the same LUT?
- Patrick: No. Cache is attached to config instance. File cache is global though, so read LUT would be reused.
- Rémi: If you have a single processor and reuse LUTs in that. will it reuse that on GPU?
- Patrick: Not sure it makes sense, but think it will create it again. Not clear if it's an edge case.
- Rémi: Yes, probably an edge case, but could have a processor which goes to and from a log space multiple times
- Mark B: We do that too. Have other transforms between, so doesn't optimize that out. Noticed optimization pipeline doesn't consider matrix transform reversible. Works with identity or offset only.
- Kevin: Last I checked it concatenated the matrices, Reduced them to fewer matrices, but not sure if it recognized inverses.
- Doug: Optimizer runs when finalizing processor, so maybe wasn't run at that point. Can get back an optimized processor from the API.