The VFX Reference Platform is a set of tool and library versions to be used as a common target platform for building software for the VFX industry. Its purpose is to minimise incompatibilities between different software packages, ease the support burden for integrated pipelines and encourage further adoption of Linux by both studios and software vendors. The Reference Platform is updated annually by a group of software vendors in collaboration with the Visual Effects Society Technology Committee.
The Calendar Year 2023 (CY2023) Reference Platform is the target for all major software releases in 2023.
5th September 2023 - The recording of the 2023 User Group meeting is now available. Please note that the recommendation from the VFX Linux Distribution Recommendation Report published last year is still as valid today as it was a year ago.
4th September 2023 - CY2024 is now Final. Confirmation of versions for OpenSubdiv and OpenVDB will follow by early November pending the timely release of new versions. As always, if any major issues are discovered with CY2024 then they will be shared with the community to decide whether a late change is required.
24th July 2023 - The annual VFX Reference Platform User Group will be held on August 1st at 1pm PDT. This is a free online meeting for the whole community, no registration required. See here for details.
16th May 2023 - CY2024 Draft published, with the main change being a move to Qt 6. Due to ongoing work required to migrate critical dependencies, the planned move to Intel's oneAPI has been deferred until CY2025. We are currently soliciting feedback on this Draft so please either send to firstname.lastname@example.org or share on vfx-platform-discuss.
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:
(New libstdc++ ABI)
(Switch to new libstdc++ ABI)
|macOS||Minimum Deployment Target||11.0
|Windows||Minimum Platform Toolset||Visual Studio 2022
v17.4 or later
|Visual Studio 2022||Visual Studio 2019
v16.9 or later
|Visual Studio 2017|
|Windows SDK||10.0.19041 or later||10.0.19041 or later||10.0.19041 or later||v10|
(built with ucs4)
|3.11.x||3.10.x||3.9.1 - 3.9.latest||3.7.x
(6.5 planned for CY2024)
|Qt for Python
|6.5.x||5.15||5.15||5.15||5.12 (with patch)
(if released by Nov 1st)
|FBX||2020.2 - 2020.latest||2020.2 - 2020.latest||2020.x||2020.x||2020.x|
(v2 in CY2021)
|Intel TBB||2020 Update 3
(Move to oneTBB
deferred to CY2025)
|2020 Update 3
(Plan to move to
oneTBB in CY2024)
|2020 Update 3||2020 Update 2
|2019 Update 6|
(Move to oneMKL
deferred to CY2025)
(Plan to move to
oneMKL in CY2024)
Providers of 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.
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.
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 on 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.
Python 3 is a required upgrade for software providers from CY2020 onwards as Python 2 is no longer supported beyond 2020.
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.
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 used the older option until CY2022 so the compiler setting should be _GLIBCXX_USE_CXX11_ABI=0 unless using CY2023 or newer. The Platform will moved to the newer implementation for CY2023, once the major Linux distributions had made the transition. RHEL/CentOS 7 and Redhat DTS use the original implementations by default.
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.
Any reference made in the VFX Reference Platform to any company or any other entity, or to their services or products, is not an endorsement or recommendation nor should it imply any such endorsement or recommendation of the quality or fitness of purpose of that company or entity, or its services or products. In no event shall the Visual Effects Society be responsible or liable, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any such content, goods, or services identified in the VFX Reference Platform or the Visual Effects Society website.