Feedback request - updating CY2023 for OpenSubdiv 3.5

90 views
Skip to first unread message

Nick Cannon

unread,
Oct 2, 2022, 6:23:08 PM10/2/22
to vfx-platform-discuss
OpenSubdiv 3.5 has just been released:

CY2023 specifies OpenSubdiv 3.4 and the request has been made to change it to 3.5. The Working Group is supportive of this change so the next step is to see whether there are any objections from the community.

Please reply to this thread in the next 7 days, or respond privately to feed...@vfxplatform.com, if you have any concerns or objections to changing OpenSubdiv for CY2023 from 3.4 to 3.5.

Thank you,

Nick

Neal Gompa

unread,
Oct 2, 2022, 8:40:20 PM10/2/22
to nick....@gmail.com, vfx-platform-discuss
What's the ABI situation with OpenSubdiv for minor releases? Looking
at the CMake script, it looks like the soname changes with every
release[1].

From my perspective, if the upgrade was ABI-safe, then it's reasonable
to upgrade it. Otherwise, it violates the planning promise to do this
when CY2023 planning by ISVs is already happening now. You didn't even
have a note about bumping the version if the new version series was
going to be available by a certain date.

It might seem counterintuitive, but I'm arguing against the OpenSubdiv
upgrade on the basis that you gave no notice you'd consider it before
and the library is built in a way where it implies that there's no
symbol or interface stability. If the latter is not true, then someone
should look into adjusting how the libraries are built to reflect
that, and add some ABI testing (maybe using something like
abigail[2]?) to ensure it follows OpenSubdiv's promises.

[1]: https://github.com/PixarAnimationStudios/OpenSubdiv/blob/8ffa2b6566be10209529d7a0d1db02a0796b160c/CMakeLists.txt#L42-L52
[2]: https://developers.redhat.com/articles/2022/01/06/whats-new-libabigail-20



--
真実はいつも一つ!/ Always, there's only one truth!

Brecht Van Lommel

unread,
Oct 3, 2022, 3:49:38 PM10/3/22
to vfx-platform-discuss
There appear to be no API breaking changes in OpenSubdiv 3.5, and we don't know the version of 4 other libraries until October 31st.

I don't expect an ISV to have things locked in to the point where an ABI change like this is much of an inconvenience, if at all.

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAEg-Je8e9Oby7wEWzCBQ3Fe61Q48K7VYrzcSAHw772ACysDqLQ%40mail.gmail.com.

Edward Lam

unread,
Oct 3, 2022, 4:02:03 PM10/3/22
to vfx-platform-discuss
On Mon, Oct 3, 2022 at 2:40 AM Neal Gompa wrote:
From my perspective, if the upgrade was ABI-safe, then it's reasonable
to upgrade it. Otherwise, it violates the planning promise to do this
when CY2023 planning by ISVs is already happening now. You didn't even
have a note about bumping the version if the new version series was
going to be available by a certain date.
...
On Mon, Oct 3, 2022 at 3:49 PM Brecht Van Lommel wrote:
There appear to be no API breaking changes in OpenSubdiv 3.5, and we don't know the version of 4 other libraries until October 31st.

I don't expect an ISV to have things locked in to the point where an ABI change like this is much of an inconvenience, if at all.

Exactly. The reason why the next year's platform is settled so early is precisely because ISVs don't expect the ABI to be locked in until it's finalized. For projects on the platform, if they miss this window, it will be difficult to get the latest changes that require ABI changes to be used on shows that standardize on the platform.

Best regards,
-Edward

David Yu

unread,
Oct 3, 2022, 4:45:42 PM10/3/22
to vfx-platform-discuss
Hi Neal,

Thank you for your reply!

We do regret not engaging earlier with the CY2023 process, but we did want to use this window of opportunity to help with the successful adoption of CY2023 (more below).

I agree with your good points about ABI compatibility. Moving to 3.5.x leaves this behavior unchanged, though we do look forward to improving this in the future.

As for other benefits of moving to 3.5.x:
- We've done additional work to address compiler warnings and errors with GCC 11 and VS2022 and recent Apple platforms.
- We've addressed build compatibility issues with CMake 3.x and Python 3.
- Last but not least, we think the additional subdivision surface evaluation methods in this release will be important and helpful to studios and VFX application developers going forward.

Happy to answer any questions!

Thanks!
-David

Neal Gompa

unread,
Oct 3, 2022, 5:52:01 PM10/3/22
to David Yu, vfx-platform-discuss
On Mon, Oct 3, 2022 at 10:45 PM David Yu <davi...@gmail.com> wrote:
>
> Hi Neal,
>
> Thank you for your reply!
>
> We do regret not engaging earlier with the CY2023 process, but we did want to use this window of opportunity to help with the successful adoption of CY2023 (more below).
>
> I agree with your good points about ABI compatibility. Moving to 3.5.x leaves this behavior unchanged, though we do look forward to improving this in the future.
>
> As for other benefits of moving to 3.5.x:
> - We've done additional work to address compiler warnings and errors with GCC 11 and VS2022 and recent Apple platforms.
> - We've addressed build compatibility issues with CMake 3.x and Python 3.
> - Last but not least, we think the additional subdivision surface evaluation methods in this release will be important and helpful to studios and VFX application developers going forward.
>
> Happy to answer any questions!
>

That sounds great! Would it be possible to fix the soname for
OpenSubdiv so that newer 3.5.x releases don't require rebuilding
everything to use it? Right now, we ship OpenSubdiv in Fedora, and
every library upgrade requires rebuilding its reverse dependencies
because the user-facing version is encoded as the shared object
version too. That is. OpenSubdiv 3.5.0 produces libosdCPU.so.3.5.0 and
libosdGPU.so.3.5.0, and 3.5.1 bumps the soversion to 3.5.1, and so on.
This is unnecessarily punishing for consumers of the library.

If OpenSubdiv is major version compatible, then the soversion should
just be 3, if it's major+minor compatible, then it should be 3.5, and
this should not change as new versions that don't break API+ABI are
made. Once an API and/or ABI break occurs, then the library version
should bump.

David Yu

unread,
Oct 4, 2022, 2:43:48 AM10/4/22
to vfx-platform-discuss
Yes, that sounds exactly right.

OpenSubdiv releases are typically major+minor version compatible and we can drop the patch release number from API symbols and from the SOVERSION for compatible releases going forward.

Thanks!
-David

Neal Gompa

unread,
Oct 4, 2022, 2:59:49 AM10/4/22
to David Yu, vfx-platform-discuss
Note that API+ABI breaks are mostly around changing existing function
signatures or removing them. Adding new ones does not lead to an ABI breakage.

If you only remove functions at new major versions, then your
soversion is should only use the major version, though if you'd rather
to lock the "full" ABI with major+minor, that's still an improvement
over the current situation.
> --
> You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/2db5e96c-dcd3-40a4-bc2d-2cb1a9271437n%40googlegroups.com.

David Yu

unread,
Oct 4, 2022, 11:41:47 AM10/4/22
to vfx-platform-discuss
Since 3.0.0 we've been careful to bump the minor version whenever exposing API changes.

Bumping the ABI major+minor whenever we change the major or minor release would match our API policy, and would be a simple and clear contract. Agree there are some cases where that might be more restrictive than necessary, but also agree that removing the patch release number from the ABI would be the most beneficial improvement for maintainers.

Thanks!
-David

Richard Addison-Wood

unread,
Oct 4, 2022, 5:39:57 PM10/4/22
to Neal Gompa, David Yu, vfx-platform-discuss
Of course, remember that there are additional compatibility considerations for classes with virtual functions (such as changing the order of declaration or adding additional functions will break compatibility).

From: vfx-platfo...@googlegroups.com <vfx-platfo...@googlegroups.com> on behalf of Neal Gompa <ngom...@gmail.com>
Sent: October 4, 2022 19:59
To: David Yu <davi...@gmail.com>
Cc: vfx-platform-discuss <vfx-platfo...@googlegroups.com>
Subject: Re: [vfx-platform-discuss] Feedback request - updating CY2023 for OpenSubdiv 3.5
 
*Originates outside of Wētā FX

David Yu

unread,
Oct 6, 2022, 3:46:43 PM10/6/22
to vfx-platform-discuss
Indeed. Binary compatibility for C++ has numerous concerns for exposed classes.
We plan to continue to document, test and verify API and ABI compatibility claims of releases.

Thanks!
-David

Nick Cannon

unread,
Oct 9, 2022, 2:01:01 PM10/9/22
to vfx-platform-discuss
Thank you for all the feedback here and directly to the working group. Thanks also to David for the prompt responses.

As there are no API or ABI compatibility issues with this new release, OpenSubdiv for CY2023 will be updated to 3.5.x but only if a compatible USD release is published by October 31st. DCC software providers require this to make sure they have enough time for integration and testing with both the new OSD and USD before their major 2023 releases.

The web site at vfxplatform.com has been updated.

Expect more CY2023 updates around the first week of November when we assess which of the industry-specific OSS projects published their new releases before the extended October 31st cut-off.

Nick
Reply all
Reply to author
Forward
0 new messages