CY2021 updates

181 views
Skip to first unread message

Nick Cannon

unread,
Mar 15, 2021, 10:41:08 PM3/15/21
to vfx-platform-discuss
Hi all,

Although the year has already started, we are proposing a couple of changes to CY2021:
  • OpenEXR to be reverted from 3.0.x to 2.4.x - Although the next major release of OpenEXR is imminent, it's arriving too late for this year and vendors have already proceeded with releases based on the 2.4.x version specified for CY2020.
  • FBX to be reverted to from 2021.x to 2020.x since there has been no 2021 release.
If there are any concerns about the changes to CY2021 then please let us know by the end of this week, either by replying to this thread or emailing the working group directly at feed...@vfxplatform.com.

We will be changing the VFX Reference Platform policy from CY2022 onwards so that only released versions are added to the upcoming Platform, and we will no longer add unreleased versions in anticipation of a planned future release.

Nick

Larry Gritz

unread,
Mar 16, 2021, 1:05:39 AM3/16/21
to nick....@gmail.com, vfx-platform-discuss
Please at least bump OpenEXR to the current 2.5 (i.e. since 2.5 dates from last May). It should be source-compatible with 2.4, but it has a many important fixes including for security issues.
--
Larry Gritz




Francois Chardavoine

unread,
Mar 22, 2021, 1:50:17 AM3/22/21
to Larry Gritz, Nick Cannon, vfx-platform-discuss
A key factor in the choice of OpenEXR version for this update is what software vendors either have already released, or are planning to release, this year. It's important to ensure consistency in the runtime environments, so if most vendors are releasing with 2.4.x this year (and some already have), we would need 2.5 to be binary/ABI compatible in order to safely specify it in the ref platform. We realize the situation is a bit embarrassing in terms of coming at this much later than we should have, unfortunately. If vendors choose to release software using a custom-namespaced version of OpenEXR that isn't exposed in the API, then the concern is minimized as well of course.

Of course the VFX Platform isn't a guideline for Studios that may want to lean forward, it's only to ensure alignment among software vendors.

Francois.

--
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/182CE401-58A6-4082-A52B-A3D659EAA430%40larrygritz.com.

David Aguilar

unread,
Apr 13, 2021, 5:33:14 PM4/13/21
to Nick Cannon, vfx-platform-discuss
I have a question about CY2022. First some context. The vfx platform specifies:

CY2021 - C++17
CY2020 - C++14

But, both of these are assuming the old GLIBCXX ABI. "old ABI". The
vfxplatform footnotes mention the traditional approach of defining
_GLIBCXX_USE_CXX11_ABI=0 in builds to ensure ABI compatibility.

So, let's talk about RHEL8, which now comes with the New ABI enabled
by default in its default compilers and in all of the C++ libraries
provided by redhat.

https://developers.redhat.com/blog/2020/10/08/migrating-c-and-c-applications-from-red-hat-enterprise-linux-version-7-to-version-8/

https://bugzilla.redhat.com/show_bug.cgi?id=1546704#c2

I suspect that third party application vendors may not officially
support RHEL8 (just yet) because of the ABI change. Specifically,
building plugins against the existing "old ABI" releases are not going
to be compatible with compilers that emit the new ABI (eg. stock rhel8).

In addition to the "C++ API/SDK" specified by the platform, it
probably makes sense to have a separate "GLIBCXX CXX11 ABI 0/1" row to
call out this fundamental platform difference.

For vendors that traditionally used RHEL7 as their build base,
choosing to only support the New ABI alongside a change of their build
base to RHEL8 (or similar) might make the most sense.

Build scripts in third-party projects will likely need to be updated
to allow the ABI to be specified; some projects likely hard-code the
old ABI decision.

Are there any thoughts or plans on when the vfx platform will specify
the New ABI? Is this something that makes sense for a CY2022 request?

--
David

Robert Fanner

unread,
Apr 14, 2021, 7:47:40 AM4/14/21
to David Aguilar, Nick Cannon, vfx-platform-discuss
Hi David,

That's a very good point to flag.  We spent a bit of time pondering the issue earlier, and while I can't speak for the others on the committee I would venture the following.

It is worth mentioning that (by hook or by crook after navigating compiler environment variable/define quirks) people have managed to have vendor apps and plug-ins running on various distros that have different gcc defaults with the current old ABI=0 spec.

From a RHEL/CentOS perspective, keeping the old spec feels like a lowest-friction option for providing support for RHEL 7/CentOS 7 for apps that choose to do so (which I believe offers security patches till 2024) as well as potentially RHEL 8, without needing to recompile "everything".

The obvious caveat with the above (that you've already flagged via the excellent RHEL 7 / RHEL 8 compatibility link) is to avoid depending on certain distro-provided packages/libraries. If you have input on particularly problematic libraries from the unsupported "compatibility level 2" list from your perspective, then that would be very helpful.

All the best,
Rob



--
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.

David Aguilar

unread,
Apr 16, 2021, 1:44:09 AM4/16/21
to Robert Fanner, Nick Cannon, vfx-platform-discuss
On Wed, Apr 14, 2021 at 4:47 AM Robert Fanner <robert...@foundry.com> wrote:
>
> Hi David,
>
> That's a very good point to flag. We spent a bit of time pondering the issue earlier, and while I can't speak for the others on the committee I would venture the following.
>
> It is worth mentioning that (by hook or by crook after navigating compiler environment variable/define quirks) people have managed to have vendor apps and plug-ins running on various distros that have different gcc defaults with the current old ABI=0 spec.
>
> From a RHEL/CentOS perspective, keeping the old spec feels like a lowest-friction option for providing support for RHEL 7/CentOS 7 for apps that choose to do so (which I believe offers security patches till 2024) as well as potentially RHEL 8, without needing to recompile "everything".
>
> The obvious caveat with the above (that you've already flagged via the excellent RHEL 7 / RHEL 8 compatibility link) is to avoid depending on certain distro-provided packages/libraries. If you have input on particularly problematic libraries from the unsupported "compatibility level 2" list from your perspective, then that would be very helpful.
>
> All the best,
> Rob

Thanks Rob. Here's some more thoughts I've had on this topic beyond
the immediate compatibility level 2 libraries.

Right now specifying the old ABI provides the least friction for users
on centos/rhel7-ish distros. These distros have the most users in vfx
land today, and these are the versions that vendors officially
support, so the old ABI makes sense in the current old-ABI landscape.

An invisible benefit of using the old ABI is that blissfully ignorant
users, that won't know the finer details of compiler flags and the ABI
change, are able to use distro-provided C++ libraries inside
vendor-provided apps and things generally work. The rhel/centos7 user
base benefits from the old ABI because they retain access to all of
the pre-built C++ packages provided by the distro and third-party
repositories.

Changing the ABI level is a breaking change. RHEL made the breaking
change when they went from v7 to v8 ~ it required them to rebuild the
world so they saved it for a major release.

My opinion is that it'd be good to get this change out of the way
before something like Qt 6 since that is another big change that could
happen in a few years' time. We want to give vendors and studios
runway to transition to the new ABI landscape without other big
changes alongside them.

If we look forward and expect that studios and vendors have plans to
move to or support rhel/centos/rocky8, where distro-provided libraries
and compiler defaults are all using the new ABI, then it might be time
to make the change.

Another factor is that the vfxplatform is effectively forward-looking.
Studios lag in adopting the latest vfxplatform due to vendor-provided
apps that trail behind, so vfx CY2022 might translate to production
calendar year 2023 or even 2024 for some users. By then rhel7 will be
on its last legs of security patch support and we would probably want
to be prioritizing users in the new ABI landscape at that point in
time.

In the future (CY2022?) users should really be on a newer OS version
where the new ABI is the default, so it seems to make sense to make
the ABI change alongside them.

I guess it's really more of a question of when we expect to adopt the
new ABI. There's never really a good time for a breaking change, so it
is a tough one. Are there any vendor considerations around supporting
rhel8 that might be a factor? Is CY2022 too soon? Would Debian/Ubuntu
users say that CY2022 is already too late?

cheers,
--
David

Robert Fanner

unread,
Apr 16, 2021, 11:38:22 AM4/16/21
to David Aguilar, Nick Cannon, vfx-platform-discuss
Hi David,

Thanks for the additional context - certainly food for thought there.

All the best,
Rob

--

Rob Fanner

Engineering Manager - Platform

Web: www.foundry.com


The Foundry Visionmongers Ltd.  -  Registered in England and Wales No: 4642027  -  Address: 5 Golden Square, London, W1F 9HT  -  VAT No: 672742224


Reply all
Reply to author
Forward
0 new messages