2023-02-06
February 6th, 2023
Host: Carol Payne
Secretary: Carol Payne
Attendees:
Apologies:
Mei Chu
OCIO TSC Meeting Notes
CI Build Matrix
Remi: there are some breaking changes in the spreadsheet. Please take a look if you get a chance
https://docs.google.com/spreadsheets/d/12fS8A3rcAHz5X05NVM11CeeD2N8EG6l1dRbuOqnHL7U/edit#gid=0
Red: delete
Green: add
Blue: in-line changes
Should work start on these changes before the 2023 docker is available?
Not planning on changing the nightly, changes to CI only
Michael: should we leave latest in the nightly though? To catch upcoming breakage quickly?
Kevin: floating versions should be for notification purposes, not for code quality release support purposes.
Remi: the nightly builds have been failing for months now, so it's hard to use/depend on
Remi: optional jobs in the CI would be more visible
Doug: hopefully we'll be able to get resources to fix at least the analysis nightly builds soon
Michael: we could split up the analysis workflows and be more intentional about what we want to get out of them.
We should update the yaml files with new workflows before we attempt to make the changes proposed by Remi. Michael: should be pretty simple, can take a look.
Managing 3rd party security updates
Doug: Cedric is working on a PR for that as discussed in prior meetings - adding min/max/recommended
PR #1762
1D/2D Texture LUT - PR to let users disable the 1D LUT simplification as 1D is not supported in Unreal and other apps
Default would stay the same, user/app would have to explicitly disallow to generate 2D only
Remi: not sure there is a way to implement this without breaking ABI
Mark: is there a huge performance hit to just remove the optimization to 1D lookup?
Eric: probably not, but it would be breaking still as the client would need to be updated - as the height of the lookup would remain "1"
API should have been based on the enum type and not the texture height
Michael: can we overload the function to pass an enum on a patch release?
Does this need fixed in 2.2 or can it wait for 2.3?
Eric: Epic prefers waiting for an official release, will mitigate on their side until that is available
Group: decision to do this "right" an add more of an enum to the methods which will break ABI & API so would target 2.3
GradingPrimaryTransform fixes
Remi: is anyone currently looking at a fix for this (clamping, saturation behavior differences)? If not, going to take a look
Doug - on the list but not in progress, reach out for help as needed
NaN/Inf handling:
Doug: Cedric is looking at adding NEON support. Difficult to get the same behavior between the different cpu/gpu paths. Even can be different per graphic card. Right now, OCIO prioritizes efficiency and speed vs. 100% accuracy between paths. Wanted to check with the TSC - is the current approach satisfactory? Are the differences an issue?
Michael: would prioritize parity over performance
Remi: could we do both? CMAKE or runtime?
Carol: what is the performance difference? Can we decide on a threshold that is okay?
Doug: early days, no real benchmarking yet. But we're working on a PR and can discuss more as we go.