VFX Reference
Platform
The VFX Reference Platform defines a set of tool and library versions to establish a consistent build target for software providers. Its purpose is to minimise incompatibilities between different software packages, ease the support burden for integrated pipelines and encourage further adoption of Linux.
Current Status
The Calendar Year 2027 (CY2027) Reference Platform is the target for all major software releases in 2027.
CY2027 is now Final and will be effective from January 1st. Confirmation of versions for OpenColorIO, Opensubdiv, and OpenEXR will follow by early October, and OpenVDB by early November pending the timely release of new versions. As always, if any major issues are discovered with CY2027 then they will be shared with the community to decide whether a late change is required.
CY2027 Draft published. The major change is Linux moving to glibc 2.34, which effectively mandates that everyone should be on an EL9 Linux OS (or equivalent). Most other components are unchanged, given that there were major updates the previous year with C++ and Qt. We are currently soliciting feedback on this Draft so please either send to feedback@vfxplatform.com or share on vfx-platform-discuss.
CY2026 is now Final and will be effective from January 1st. All package versions called out by the platform are now released. In 2021, the Imath library was split off from the OpenEXR 3 release into its own separately released package. Since Imath types are part of the OpenEXR API/ABI (as well other libraries such as Alembic), the OpenEXR / Imath maintainers have requested that the VFX Platform call out a specific, compatible version of Imath to avoid ambiguity.
CY2026 Draft published, with a number of significant changes to gcc, glibc, and Qt. We are currently soliciting feedback on this Draft so please either send to feedback@vfxplatform.com or share on vfx-platform-discuss.
Reference Platform
Each annual reference platform is designated by the calendar year in which major product releases should be targeting that particular reference.
All versions should be considered exact required versions, except for those components where ↓↑ indicates that:
- For systems (or software) providing the library at runtime, versions should be considered minimum version required.
- Otherwise, for software building against the library, versions should be considered highest version allowed.
| Component | CY2027 | CY2026 | CY2025 | CY2024 |
|---|---|---|---|---|
| ▾ Linux | ||||
| gcc ↓↑ | 14.2 | 14.2 |
11.2.1
(New libstdc++ ABI) (see notes) |
11.2.1
(New libstdc++ ABI) (see notes) |
| glibc ↓↑ | 2.34 | 2.28 | 2.28 | 2.28 |
| ▾ macOS | ||||
| Minimum Deployment Target |
14.0
(see notes) |
14.0
(see notes) |
12.0
(see notes) |
11.0
(see notes) |
| ▾ Windows | ||||
| Minimum Platform Toolset |
Visual Studio build tools v14.44 or later
(see notes) |
Visual Studio 2022 v17.6 or later | Visual Studio 2022 v17.6 or later | Visual Studio 2022 v17.4 or later |
| Windows SDK | 10.0.22621 or later | 10.0.22621 or later | 10.0.20348 or later | 10.0.20348 or later |
| ▾ Common Components | ||||
| C++ API/SDK | C++20 | C++20 | C++17 | C++17 |
| Python | 3.13.x | 3.13.x | 3.11.x | 3.11.x |
| PyQt | 6.8.x | 6.8.x | 6.5.x | 6.5.x |
| Qt for Python (PySide) | 6.8.x | 6.8.x | 6.5.x | 6.5.x |
| Qt | 6.8.x | 6.8.x |
6.5.x
(6.8 planned for CY2026) |
6.5.x |
| ACES | 2.0 | 2.0 | 2.0 | 1.3 |
| Alembic | 1.8.x | 1.8.x | 1.8.x | 1.8.x |
| Boost | 1.91 | 1.88 | 1.85 | 1.82 |
| FBX | 2020.2 - 2020.latest | 2020.2 - 2020.latest | 2020.2 - 2020.latest | 2020.2 - 2020.latest |
| Imath | 3.2.x | 3.2.x | 3.1.x | 3.1.x |
| NumPy | 2.4.x | 2.3.x | 1.26.x | 1.24.x |
| oneMKL/MKL | 2025 | 2025 |
2024
(Move to oneMKL) |
2020
(Move to oneMKL deferred to CY2025) |
| oneTBB/TBB ↓↑ | 2023.x | 2022.x |
2021.x
(Move to oneTBB) (see notes) |
2020 Update 3
(Move to oneTBB deferred to CY2025) (see notes) |
| OpenColorIO |
2.6.x
(Release expected by Oct 1st) |
2.5.x | 2.4.x | 2.3.x |
| OpenEXR |
3.5.x
(Release expected by Oct 1st) |
3.4.x | 3.3.x | 3.2.x |
| OpenSubdiv |
3.8.x
(Release expected by Oct 1st) |
3.7.x | 3.6.x | 3.6.x |
| OpenVDB |
14.x
(Release expected by Nov 1st) |
13.x | 12.x | 11.x |
| Ptex | 2.5.x | 2.4.x | 2.4.x | 2.4.x |
Support Guidance
Support Window
Providers of open source software libraries focused on VFX and animation content creation should aim to support their releases for the current calendar year and the three preceding years with compatible updates. Studios and end users should have no expectation of support for older libraries.
Best Practices
The VFX Reference Platform strongly recommends open source project maintainers provide a level of support described by the FLOSS Best Practices Criteria, which is already a requirement for all Academy Software Foundation projects.
Useful Links
2021 Studio Platform Survey Report
Results from the 2021 survey of VFX studio platform configurations and requirements.
VFXpy Python 3 Compatibility Tracker
Track Python 3 compatibility for common VFX and animation software packages.
ASWF Docker Containers
Ready-to-build containers implementing VFX Reference Platform compliant build environments.
VFX Industry Build Matrix
Cross-reference of build configurations used across the VFX industry.
Notes - macOS
Minimum Deployment Target in Xcode
Xcode’s “Deployment Target” identifies the earliest OS version on which your software can run.
To set the Deployment Target for the compiler, use the option -mmacosx-version-min=10.13 to specify the APIs marked as available. For the linker, use the option -macosx_version_min 10.13 to instruct the linker to create a key in the Info.plist file which marks the executable as being able to run or not for a given OS version.
The MACOSX_DEPLOYMENT_TARGET environment variable also sets the minimum deployment target and is used if the compiler option is not specified. The environment variable is also recognized by CMake.
Note: Despite the backward compatibility, it is still possible for runtime behavior to be affected by SDK and OS version, hardware etc.
More information about configuring developer tools is available in the SDK documentation.
Frameworks vs Shared Libraries
In general, the Frameworks approach is recommended over shared libraries for building and deploying components like Qt and Python on macOS.
UPDATE: May 22nd 2021 - CY2022 dropping 32-bit support
The move to 10.15 requires all apps to be 64-bit, with 32-bit releases no longer supported.
UPDATE: April 4th 2021 - Building Qt for macOS
Building Qt against C++17 requires a minimum macOS version of 10.14 otherwise Qt fails during configuration. If 10.13 support is needed then a known workaround is to build Qt against C++14.
UPDATE: August 2026 - Qt 6.8 on macOS
Qt 6.8 source code sets a limit for the minimum macOS version to 14, since it uses APIs that were removed in 15. Until a future Qt version unblocks this, the minimum macOS version has been held.
Note - gcc 9 and 11
For users of Red Hat Enterprise Linux and RHEL-derived Linux distributions (such as CentOS Linux and Rocky Linux), the Redhat Developer Toolset (DTS) offers gcc and other build tooling that provide increased compatibility and it is used by many software vendors and studios. DTS 9.1 provides gcc 9.3.1 for compatibility with CY2021, and DTS 11.0 provides gcc 11.2.1 for compatibility with CY2023.
For those who want or need to use llvm, some studios have been successful building clang with DTS and using that to build software that is compatible with vendor-provided libraries.
Since gcc 5.1, libstdc++ introduced a new library ABI that includes new implementations of std::string and std::list. In order to maintain backwards compatibility the old implementations are still supported in parallel with the new ones. The choice of implementation is made using the _GLIBCXX_USE_CXX11_ABI macro, and the VFX Reference Platform up to CY2022 used the older option so the compiler setting for those Platforms should be _GLIBCXX_USE_CXX11_ABI=0, although that setting may not be supported by some older Linux distros.
From CY2023, the Platform has moved to the newer implementation since all the major Linux distributions have made the transition. This is a major change for CY2023 that may require a rebuild of all software against the new ABI for those moving from earlier Platforms.
Note - gcc 6
UPDATE: May 10th 2020 - Redhat DTS 6.1 is no longer actively supported so availability may be limited. More information available on this vfx-platform-discuss thread.
UPDATE: November 26th 2017 - CY2018 changed from gcc 5 to gcc 6 due to integration issues discovered with the older version.
Redhat/CentOS systems can obtain gcc 6.3.1 by installing Redhat DTS 6.1. To install Red Hat Developer Toolset 6.1 on CentOS 7:
sudo yum -y install centos-release-scl
sudo yum -y install devtoolset-6
If you are looking for gcc 6.3.1 source code then a copy can be found in the CentOS Vault.
Since gcc 5.1, libstdc++ introduced a new library ABI that includes new implementations of std::string and std::list. In order to maintain backwards compatibility the old implementations are still supported in parallel with the new ones. The choice of implementation is made using the _GLIBCXX_USE_CXX11_ABI macro, and the VFX Reference Platform is still using the older option so the compiler setting should be _GLIBCXX_USE_CXX11_ABI=0. The Platform will move to the newer implementations in a future year once the major Linux distributions have made the transition. RHEL/CentOS 7 and Redhat DTS still use the original implementations by default.
Note - gcc 4
The vanilla gcc 4.8.2 has a serious bug that was fixed in 4.8.3 and some Linux distribution vendors actually ship a patched version as 4.8.2. The reason the Platform gave 4.8.2 as an option for CY2016 is that this gcc version is what ships with Redhat Developer Toolset 2.1 that some software vendors were committed to using through 2016.
The following are the known distributions that ship with a fixed 4.8.2: Redhat DTS 2.1, RHEL/CentOS 6.
Note - Python 3
The move to Python 3 was delayed from CY2019 to CY2020 due to:
- No supported combination of Qt 5.6, Python 3 and PySide 2 so Qt first needed to be upgraded.
- Upgrade of both Qt and Python in the same year was too large a commitment for software vendors and large studios.
Python 3 in CY2020 is a required upgrade as Python 2 will no longer be supported beyond 2020.
Note - Qt modifications
The major change for CY2016 was a move to Qt 5 which required a port of PySide and modifications to vanilla Qt. In November 2015 CY2016 version of Qt was upped from 5.5.x to 5.6.x with agreement from the community that it was preferable to align with a Long Term Support release. In May 2016 it was updated again to 5.6.1 to incorporate some critical bug fixes.
These modifications are required to avoid the introduction of functional UI regressions impacting DCC tools and consist only of backported bug fixes and critical changes that have not yet been accepted into the mainline Qt distribution. The need for these modifications is not new, currently some software vendors ship their own differently modified Qt so CY2016 represented a significant step forward with the goal of all software vendors sharing an identically modified Qt. We are working with the Qt Company to eliminate the need for these modifications entirely in a future release, potentially as soon as CY2019.
These Qt 5.6 modifications are available on Github from these forks of qtbase, qtx11extras and qtdeclarative. These modifications to Qt 5.6.1 should be used by anyone who wishes to build Qt applications against the Platforms from CY2016 through to CY2018.
Note - Intel TBB
There is a known issue compiling TBB 2020 with MSVC 2017 that can be resolved with this workaround.
Please plan to migrate to oneTBB and have compatible releases published by September 1st 2024 to enable DCC providers to complete a planned move in CY2025. The original plan was to move to the oneAPI in CY2024 but more time was needed to migrate critical dependencies without impacting performance or introducing multiple conflicting thread pools.
Note - MSVC build tool versons
There are many different version numbers that Microsoft use in the VisualStudio ecosystem. Build tool versions can be found here.
14.44 is the latest VS2022 build tools, supported until January 2032. VS2026 build tools start from 14.50. VisualStudio products can generally install current and older build tool versions side-by-side.
We will lean on Microsoft’s binary compatibility guarantee.