GPU Improvement availability before the OCIO v2 Project completion?

[hodoulp]

Following the last TAC meeting, the GPU improvements received a positive feedback from the community so the question about its official availability is now open. Some would like to benefit from the GPU improvements without waiting for the OCIO v2 Project completion.

Please let us know your comments on the subject.

Other pros & cons were discussed at the last TSC meeting, refer to #664

Below is copy & paste from an exchange in Slack #general:

Larry Gritz [Feb 9th at 14:26] Questions from the group after Mike & Doug's update at yesterday's ASWF summit basically boiled down to "wow, that's an impressive list of improvements" and "do we really have to wait until next year to get a release wth the portion of v2 features that have already been implemented, can't you do a release now?"

Patrick Hodoul [Feb 9th at 19:13] Preserving the great impression we produced to the industry requires to carefully prepare the first official OCIO 2.x release. We already are in the middle of major enhancements without planning any intermediate release to keep the focus on the library, and not on the integration. And the decision to create a release is always a challenging and tough decision and must be balanced with the extra cost added to the development. Delivering an official release means to integrate it in various tools (i.e. Autodesk Maya, Arnold, Flame…) and requires last minutes changes/fixes to help the community, which will both drain Autodesk resources outside the development. Even if we started the OCIO v2 project on a solid code base, and put lot of attention to the code quality, we must understand the exact stability/robustness of the current code before thinking about producing a release. So, several aspects must be investigated. One is to find the right time to do it (without badly impacting the development) to avoid partial features, but we are currently in the middle of the ‘Autodesk CTF support’, and actively working of the ‘integer pixel format support’. These two features are deeply changing the code with impacts on the public API. Another one is the overall stability / robustness of the code knowing that successful CI builds (unfortunately, without the GPU tests) only partially capture it, and the public API is still planning to change as well as the config file content. Finally, a ‘production ready’ code could only be validated by intensive testing ideally with real life scenarios. Even if some successful experiments were done the status is still unclear for now. To preserve the positive impression we made, here are some thoughts to keep in mind when thinking of an ‘intermediate’ OCIO 2.x release. (edited)

Larry Gritz [Feb 9th at 20:52] Agreed. I was mostly just trying to convey the level of enthusiasm for what you're working on. Another possibility is, without the fanfare and preparation of a true release, to tag, in master, a "development" release to signify a point that you think is fairly stable, has a bunch of features that are ready to test for those who need them and don't want to wait for next year -- but with everybody understanding that while you think it's fine, it has certainly not undergone the usual level of scrutiny of a public release, nor are you guaranteeing API stability of the new features compared to how it will be in a final v2.0. (edited) I do, however, still recommend a formal 1.1.1 release that is bug-fix only, including the patch that lets it build against the current OIIO release.

Patrick Hodoul [Feb 9th at 11:32] @lgritz A tag approach could be a solution (i.e. indicates a 'point' containing a set of interesting features ready for testing) but with all the warnings you mentioned. Even if finding the right timing is complex, early feedbacks are valuable for the long-term success of the project. I think that the next TSC meeting is the forum to continue the discussion. (edited)

Troy Sobotka [2 days ago] Perhaps a floating tag too, so it could move along with fixes?

Larry Gritz [1 day ago] Tags should be forever, but it could be a floating branch marker.

[hodoulp]

Here is the final version of the TSC meeting minute report Here

[hodoulp]

Any new idea? Tabled idea?

[michdolan]

I am personally in favor of a tag pointing to a relatively stable point in the history from which a person or organization can choose to try out the new GPU renderer. I absolutely agree though that it should be loudly labeled as unsupported, as to not stall development or make any promises of any kind.

At Imageworks, we have already implemented the new GPU renderer into our internal review tool, as previously shared at SIGGRAPH. It's there, but we're not using it in production yet because the revision at which we built it had some incomplete functionality (that has since been "completed"). I would like to revisit it though, and do some limited testing on some productions, and having a tag at the point which Doug and Patrick deem the functionality "complete" (note the quotes) would be helpful for navigating the many recent changes.

I think others could benefit in the same way, and as @hodoulp suggested, get some much needed testing so that when we do near an actual release, we can have that much more confidence in the work. My two cents...

[KevinJW]

We are in a similar position we'd like to integrate into some of our tools, but which random commit id should we pick...

I'd argue in favour of a tag because - it increases the likely hood that questions and queries will all focus on that commit, otherwise each interested party could just pick whatever HEAD is at the time they clone the repo, resulting in all kinds of reports, which I'd guess is more support effort than a tag.

Kevin

[hodoulp]

Following Mark's comments mentioning that the tag will be used as a version, I now disagree to have any 'special' tag.

[hodoulp]

Discussion closed.