CY2026 Draft Published

[Francois Chardavoine]

Hello VFX Platform friends & family!

The Draft CY2026 VFX Reference Platform has been published at https://vfxplatform.com.

There are quite a few changes here, and we'd love to hear your feedback on it, but there's a number of areas where we need to catch-up:

• gcc 14: gcc 12 is out of support, and gcc 13 will also be in November of this year.

• glibc 2.34: note that this does mark the transition to requiring RHEL9-compatible distros, which has been the guidance for studios for the past couple years.

• Python 3.13: python 3.11 will be over 3 years old at that point.

• Qt 6.8: Qt 6.5 will be almost 3 years old in CY26, and the bump to 6.8 is required regardless if moving to Python 3.13.

• MacOS 14.0 (Sonoma): both MacOS 12 and 13 will be out of support.

• WindowsSDK 10.0.22621: This effectively forces Windows 11, and is a requirement for QtWebEngine in QT 6.8. This in particular is something we'd love to get your thoughts on.

We've also bumped up all of the industry-specific open source packages to the newest version the DCC vendors expect to be able to support.

The topic of USD was also discussed, but the consensus so far seems similar to previous years, which is to not lock it down as part of the VFX Platform this year: there remains appetite to lean forward and provide some flexibility here, with the benefits outweighing the downsides.

Two additional requests to the community

• Are there any libraries currently in the platform that haven't caused versionitis-related issues in a while and could be removed? Examples of this could be Ptex, NumPy, or FBX.

• Are there new libraries that have been problematic and should be considered to add to the platform to minimize version-related issues?

To provide feedback on this Draft Platform, you can reply to this thread or respond privately to the Working Group by emailing feedback at vfxplatform.com.

As usual, we are looking to lock down the Final version at the start of September. Like in previous years, we intend to provide additional forums to discuss and provide feedback by hosting an in-person Birds of a Feather event at SIGGRAPH, as well as a public user group meeting via Zoom shortly after.

Francois

on behalf of the VFX Reference Platform Working Group

[Mikki Wells]

Does use of Windows SDK 10.0.22621 really force Windows 11?
From what I can tell without actually trying it, this is not the case.
Is it actually QtWebEngine 6.8 which requires Windows 11 for full functionality? (https://doc.qt.io/qt-6.8/qtwebengine-platform-notes.html#windows)

Mikki

[Brecht Van Lommel]

Could Numpy be upgraded to 2.x? Version 2.0 was released slightly before Python 3.13, and it is the default version installed through pip. To me it seems natural to match these. For Blender we've already seen some compatibility issues between Numpy 1.x and 2.x now.

Dropping Windows 10 support seems a bit soon, it is only end-of-life in October 2025. For Blender we usually support another 2 years because of user demand. Though probably we can stick to the older Windows SDK as we don't ship QtWebEngine.

--
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 visit https://groups.google.com/d/msgid/vfx-platform-discuss/CADBZUEinLRJXNpYHR1odvtkJ%2BCufY9PUWpj%3D%3DKYi4OaWHq27wA%40mail.gmail.com.

[Kevin Wheatley]

Just a thought, what consideration for the long term stability of the
C++ 20 ABI/API was made when bumping to C++ 20?

From my understanding the GCC support for it is still considered
'experimental' which I read as meaning there is no 100% guarantee
about backwards compatibility in future releases
https://gcc.gnu.org/projects/cxx-status.html#cxx20

I'm not thinking the GCC developers are likely to make a breaking
change, but ...

(to save people the efforts of searching...)

Clang status is https://clang.llvm.org/cxx_status.html#cxx20
Visual Studio https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?view=msvc-170

Kevin

[Mark Final]

Regarding the choice of C++20, I did some research last year, posted here https://groups.google.com/g/vfx-platform-discuss/c/XUznp633U1s/m/Yuf_BXEfAwAJ, considering whether those consumers of the libraries built against an RP could use a newer compiler and/or C++ standard.

Although there are toolchain specifics, it seemed like the best path forward was to recommend only using the supported features of the standard in the toolchain. This was particularly for library authors to be mindful of, to maximise portability. Those leaf-node consuming applications might get away with some experimental features, but still not recommended.

Also in that document is consideration of deprecated or removed C++ features and how toolchain behaviour can change. In current testing, I've observed GCC14 being more strict about this than GCC11. Even compiling code we have today, against C++17, GCC11 was more relaxed about deprecations, while GCC14 was shouting loudly. I can appreciate that, as it is more closely following what the standard says.

I agree there are some incomplete features in GCC14 for C++20. If we avoid them, then we should be in a better position. On the plus side, there are some nice features in C++20 that can be used.

I personally wouldn't recommend even thinking about C++ modules on any toolchain yet.

I also use this site to check for what's supported: https://en.cppreference.com/w/cpp/compiler_support#cpp20.
Having looked just now, there are, for example, some C++17 features that weren't supported in GCC11.2 in https://en.cppreference.com/w/cpp/compiler_support/17. So having a little incomplete support has been around already.

Perhaps the wording of the RP can be to recommend only using features of the language standard that are fully supported across toolchains for all platforms.

Thanks,
Mark

[Larry Gritz]

That report is really helpful, but I think there is an interesting case that it doesn't address:

* vendor has a C++XX compatible public API, but builds itself with and uses C++YY features strictly internally (where XX < YY, and assuming that YY doesn't break ABI compatibility even when using XX features).

Also, I understand that some of the caution about staying close to the C++ forefront is this issue that it takes a while for any given compiler to truly be 100% compliant (if they ever are), and so there is danger of using a feature that isn't yet working on all platforms and compilers, even those that nominally advertise themselves as (mostly) adhering to the standard. So this causes us to wait until all known compilers are within some small epsilon of full compliance with a standard before VFX Platform recommends that standard.

But I think that it would not be nearly as risky in practice as it sounds in theory... for any library or application that is cross-platform, has rigorous CI on all the platforms and compiler combinations, and has well designed tests of its full API. Saying "use C++20, but only the subset that works now on all major compilers" sounds really squirrelly, but if you have a good CI setup, you can't help but do it, because your tests will fail on some platform that doesn't yet support the feature you're trying to use.

-- 
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 visit https://groups.google.com/d/msgid/vfx-platform-discuss/845a5f86-28da-429a-af61-a57d49ee7a02n%40googlegroups.com.

--

Larry Gritz

l...@larrygritz.com

[Jean-Francois Panisset]

Anecdotally I'm starting to play with a VFX 2026 version of the aswf-docker containers (even though versions of ASWF projects called for aren't released yet), and gcc14 does seem to emit a lot more warnings, including from its own STL headers. But also flagging what seems like pretty scary stuff just building LLVM 20 for instance:

#24 580.5     inlined from 'bool checkOMPArraySectionConstantForReduction(clang::ASTContext&, const clang::ArraySectionExpr*, bool&, llvm::SmallVectorImpl<llvm::APSInt>&)' at /opt/conan_home/d/b/clangbe09c4043542a/b/src/clang/lib/Sema/SemaOpenMP.cpp:18330:43:
#24 580.5 /opt/conan_home/d/b/clangbe09c4043542a/b/src/llvm/include/llvm/ADT/APInt.h:192:18: warning: 'void operator delete [](void*)' called on a pointer to an unallocated object '1' [-Wfree-nonheap-object]                                                                                                                                                                       #24 580.5   192 |       delete[] U.pVal;
#24 580.5       |                  ^~~~

Projects which turn on "treat warnings as errors" by default may need some work, but stricter compilers are overall a good thing moving forward.

Otherwise so far no major issues building with gcc14.

JF

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/3A57703E-73C0-432C-9DFC-9F82604E3ABA%40larrygritz.com.

[Larry Gritz]

Surely all the important projects are routinely doing CI testing against "modern" versions of dependencies ahead of VFX Platform and so have long since worked out the kinks for gcc14. Right? Right?

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/CALiMbRVscoPvCsj_0uLUauMucOsrcL6JUzw003uzF83w8sfiHQ%40mail.gmail.com.

--

Larry Gritz

l...@larrygritz.com

[Robert Fanner]

Hi,

Late to reply to the below, but I wanted to chip in with my possibly flawed understanding on the below:

 * vendor has a C++XX compatible public API, but builds itself with and uses C++YY features strictly internally (where XX < YY, and assuming that YY doesn't break ABI compatibility even when using XX features).

In the references in Mark's document, there's a note on GCC/linux nitty gritty that I think may mean the above use case may not always work out nicely, because assuming dynamic linking of libstdc++ & co. we might not be able to hide away C++YY internal use. (Or alternatively framed: everyone that wants experimental bits from C++YY will need to use the exact same compiler version at build time for common dependencies, the DCC and DCC extensions/plugins).

 

https://stackoverflow.com/questions/46746878/is-it-safe-to-link-c17-c14-and-c11-objects/49119902#49119902

 

"Where you have problems is if you link together objects compiled with different versions of GCC and you have used unstable features from a new C++ standard before GCC's support for that standard is complete. For example, if you compile an object using GCC 4.9 and -std=c++11 and another object with GCC 5 and -std=c++11 you will have problems. The C++11 support was experimental in GCC 4.x, and so there were incompatible changes between the GCC 4.9 and 5 versions of C++11 features. Similarly, if you compile one object with GCC 7 and -std=c++17 and another object with GCC 8 and -std=c++17 you will have problems, because C++17 support in GCC 7 and 8 is still experimental and evolving."

 

My (possibly flawed) understanding is that the above applies whether you're trying to link things in the same static or dynamic library, or at runtime over different dynamic libraries. Assuming that's on the mark, then you may not be able to hide away this ABI niggle even if the experimental feature use is "internal" to your `.so`.

To make these ABI bits play nicely, I think this implies that everyone uses the exact same GCC and libstdc++ versions to access experimental features?

By way of example, if an ASWF library requires a certain experimental features internally, then a DCC pulling in that dependency would need to build vs a compiler and stdlib version new enough to support those. Once built, that hard-wires what downstream users can choose compiler-wise if they also want to use those experimental features.

Whether pinning down the compiler and stdlib versions that closely is an easy thing to agree all round will need some discussion, as it may narrow the compatibility margins a fair bit.

The other OSs & compilers will also need to be sussed. Mark's document might serve as a handy starting point.

If my assumptions here are wrong, then perhaps this is an easier thing to get comfortable with, but I did want to call out this potential issue.

Best regards,

Rob

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/AFE119BB-72A0-4CBB-963E-897A473740DC%40larrygritz.com.

--

Rob Fanner

Senior Director of Engineering

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

[Larry Gritz]

On Jun 2, 2025, at 5:06 AM, Robert Fanner <robert...@foundry.com> wrote:

In the references in Mark's document, there's a note on GCC/linux nitty gritty that I think may mean the above use case may not always work out nicely, because assuming dynamic linking of libstdc++ & co. we might not be able to hide away C++YY internal use. (Or alternatively framed: everyone that wants experimental bits from C++YY will need to use the exact same compiler version at build time for common dependencies, the DCC and DCC extensions/plugins).

Yeah, you're quite right about that, I hadn't really thought about the problem of different libstdc++ for any components that weren't header-only. That does seem like there is a real risk.

ON THE OTHER HAND... I will just observe that we all build our projects against a lot of C++ dependencies without any knowledge of exactly which compiler, version, or C++ standard was used to build the dependency, other than ensuring that we are on at least the minimum C++ standard that their public APIs seem to require.

As a specific example, OIIO's CI has individual tests for C++17, 20, until recently 14, and soon probably 23, and a mixture of clang and gcc, and multiple compiler versions thereof. But they all consume the very same pre-built OpenEXR headers and libraries from the ASWF containers. So the circumstantial evidence is that the compiler version and C++ standard generally do not need to match for library provider and consumer, as long as the public API of the library is not using any cutting edge features, and as long as we're not straddling a known ABI-breaking boundary, as happened with gcc a few years back with the std::string ABI in particular.

Maybe this only works if the library's public API stays on an old version and the internals are compiled with that same C++ standard (when compiled for binary library distribution, that is)?

--

Larry Gritz

l...@larrygritz.com

[Edward Lam]

On Mon, Jun 2, 2025 at 8:07 AM 'Robert Fanner' via vfx-platform-discuss <vfx-platfo...@googlegroups.com> wrote:

By way of example, if an ASWF library requires a certain experimental features internally, then a DCC pulling in that dependency would need to build vs a compiler and stdlib version new enough to support those. Once built, that hard-wires what downstream users can choose compiler-wise if they also want to use those experimental features.

While that is true in general, any practical usage of new features within a library that aims to target a lower C++ standard in their interface will naturally be constrained so that they do not use the new features on their public interface. By far, the most useful features of say using C++20 in a C++17 public interface would be syntactic niceties in cpp files like designated initializers as one example.

For a VFX Platform abiding project, if something is added that breaks ABI with the recommended gcc target version, then it should just be removed. Given this constraint, I believe there are still good uses of new features. Having said that, whether a VFX Platform project feels that this is worth the added complexity, that is a separate question. As a data point, Houdini used C++17 internally but C++14 as the public interface back in the day [1].

 Best regards,

-Edward

1. We have since stopped doing split C++ standards just because it hasn't been compelling enough with the features that we want to use.

[Robert Fanner]

"They mostly come at night. Mostly."

@Larry : I'd agree that mostly this stuff does just work out. It always boggles the mind how compatible the libstdc++ & other maintainers manage to make these things. Testing OIIO against a wide range of toolchains sounds like good practice to me.

@edward : I think Rob V also mentioned using C++17 and only having C++14 on the public Houdini APIs at an earlier juncture. I agree that "breaks ABI with the recommended gcc target version" is sensible. I think this is basically in line with what the SO post outlines, so you need to use either the safe subset of C++17 features on those toolchains, or pin to the recommended gcc target version?

I'd still argue for caution on diving too deeply into the more experimentally supported features unless we're able to get a closer bead on which scenarios break things, though I'd take Larry & Edward's input as votes for being a bit more adventurous on internal language version use, and pinning the compiler version to ensure the critters only come at nighttime? 

Do these linux-y intuitions also work on the other platforms based on community experience?

All the best,

Rob

[Larry Gritz]

I think calling my observations as a "vote" might be taking it one step too far. I'm just saying that while in principle, mixing compiler versions and C++ standards seems unsafe, in practice we are all disregarding that caution every time we build against a C++ library that comes pre-built from a package manager and we have no idea which flags it was compiled with. Equally so when we build that dependency from source and just trust its build system's defaults. I'm not fully sure what we should do with that observation.

-- 
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 visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAEGe5KBffPnzi9%3DGwhQ%3Drgppu9Dj4zmTEWxC2bdRjDQor6%3DF8w%40mail.gmail.com.

--

Larry Gritz

l...@larrygritz.com

[Richard Addison-Wood]

For what it is worth, just mixing builds where some libraries are built as C++14 and some are build as C++17 have lead to misalignment problems, including cases with interfaces that come from header-only packages.

Also, libstdc++.so.6 (and related runtime libraries) have dropped or changed support for things that were experimental at the time they were first available. So, even if some software's internal implementation hides the use of things from a newer C++ standard, if it uses experimental features there could be failures at linktime or runtime.

---

From: vfx-platfo...@googlegroups.com <vfx-platfo...@googlegroups.com> on behalf of Larry Gritz <l...@larrygritz.com>
Sent: June 4, 2025 04:49
To: Robert Fanner <robert...@foundry.com>
Cc: Edward Lam <triplequ...@gmail.com>; vfx-platform-discuss <vfx-platfo...@googlegroups.com>; Jean-Francois Panisset <pani...@gmail.com>
Subject: Re: [vfx-platform-discuss] CY2026 Draft Published

 

*WARNING External email, think before you click. Please report suspicious emails using the REPORT button on your Outlook email toolbar.

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/20BC1036-D94D-4579-9FF0-F86B5E960C5E%40larrygritz.com.

[Robert Fanner]

Apologies for framing it as a "vote", Larry - I know that's not what you meant. I do think you've raised a few interesting points here, and I'm trying to get a sense of value and risk on carving out more wiggle room for modernisation :) .

Richard - 100%. The SO post linked earlier also hints at libstdc++.so.6 dropping or changing support for experimental things, and the additional requirements around any experimentally used features creating a harder dependency on the exact libstdc++.so used at runtime. The point on header-only things also creating the potential for things being mismatched is also good to call out.

Best regards,

Rob

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/SYCP282MB06079CB64EFAEE9BC890ACC79C6DA%40SYCP282MB0607.AUSP282.PROD.OUTLOOK.COM.

[Robert Fanner]

Apologies for framing it as a "vote", Larry - I know that's not what you meant. I do think you've raised a few interesting points here, and I'm trying to get a sense of value and risk on carving out more wiggle room for modernisation :) .

Hit send too soon! A better way to say the above might have been to ask if the perceived value to use more modern C++ internally (and safely), and the perceptions of likely risk low enough to warrant deeper research to pin things down more closely. And also who can help with such research. 

[Larry Gritz]

From my point of view, intentionally using a higher C++ standard for internals than for API is a poor substitute for the VFX Platform actually being closer to modern C++. The talk of splitting internals is merely a sign of desperation over the fact that we're still stuck on C++17 in 2025. I don't think we should be jumping on a standard the second it's published, but being two full 3-year standards cycles behind seems too conservative to me.

Counter point: the farther ahead our compiler requirements get from what's in the distros everybody is using, the more friction and chance for problems. So I am mindful of choosing compiler version based on a number of considerations. But I wish we were more eager to embrace the highest C++ standard supported by our compiler version of choice.

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAEGe5KCR5Tgp9GoxZNtWquj61LFh2WzX6vSwY-6cbSFR6Uj07w%40mail.gmail.com.

--

Larry Gritz

l...@larrygritz.com

[Richard Addison-Wood]

I think it would be useful to have a concise summary of which features in newer C++ standards still have incomplete experimental implementations on any of the compilers we might end up using in the VFX industry.

Of course, developers can look up the status of feature completeness for the compiler they use, but they might not bother looking at what features are stable for compilers they do not regularly use.

For example, I don't think the implementations for C++20 modules is at a stable point yet, and I don't think there is enough practical experience to reasonably guide best practice. (On the other hand, some open source software might push us to using it is some places.)

I am glad to see that gcc 14.2 is specified for VFX Platform 2026, but I should note that we have encountered upstream things that were rather picky about which gcc versions they were ready to support.

---

From: Larry Gritz <l...@larrygritz.com>
Sent: June 5, 2025 06:58
To: Robert Fanner <robert...@foundry.com>
Cc: Richard Addison-Wood <ric...@wetafx.co.nz>; vfx-platform-discuss <vfx-platfo...@googlegroups.com>

[Jean-Francois Panisset]

A slightly interesting issue I just ran into with my prototype 2026 implementation is that in EL 9 the standard binutils package now installs a /usr/lib64/libctf.so.0.0.0 (which it didn't in EL8) but the ld from gcc-toolset-14 wants to see the newer, incompatible version of libctf.so.0.0.0 from gcc-toolset-14. So if your LD_LIBRARY_PATH ends up with /usr/lib64 before the gcc-toolset lib64, this breaks the compiler as ld can't start due to a libctf version mismatch.

In my specific case this was due to Conan mistakenly pre-pending /usr/lib64 to LD_LIBRARY_PATH due to some incorrect recipes, but this wasn't a problem in EL8 / gcc-toolset-11 as there didn't seem to be any such potential DSO conflicts and you could get away with having /usr/lib64 first in your LD_LIBRARY_PATH.

JF

To view this discussion visit https://groups.google.com/d/msgid/vfx-platform-discuss/ME2P282MB05967E0F5F3F6B7891CAD9EA9C6CA%40ME2P282MB0596.AUSP282.PROD.OUTLOOK.COM.

[Joe Hura]

Hiya,

> Windows SDK 10.0.22621: This effectively forces Windows 11, and is a requirement for QtWebEngine in Qt 6.8. This in particular is something we'd love to get your thoughts on.

I'm happy to share a suggestion regarding the Windows SDK version, especially if we're aiming to align with the QtWebEngine requirements.

I'd like to propose we consider moving to Windows SDK 10.0.26100.0. From an ISV perspective, it's generally preferable to align with an SDK version that remains supported by the OS vendor throughout the 2026 calendar year.

The currently proposed 10.0.22621.0 SDK (Windows 11, version 22H2) reaches Microsoft's end of support on 10/14/2025.
Looking ahead, it may be more future-proof to target 10.0.26100.0 SDK (Windows 11, version 24H2), which reaches end of support on 10/12/2027.
The intermediate option, 10.0.22631.0 SDK (Windows 11, version 23H2), reaches end of support on 11/10/2026, and may not be ideal since its support window ends before the close of CY2026.

Importantly, 10.0.26100.0 SDK fully satisfies QtWebEngine's requirement of using Windows 11 SDK version 10.0.22621.0 or later.

On a related note.. Windows 10. Only the Enterprise LTSC edition will continue to receive support through 1/12/2027. For all other variants (home/pro, enterprise/education), support ends 10/14/2025 (unless extended via ESU), which could pose challenges for some IT environments. I'd be really interested to hear thoughts from the group on this, particularly around support strategy and forward compatibility.

Looking forward to hearing your thoughts.

All the best,
pheonix