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 Linux-based pipelines and encourage further adoption of Linux by 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 2020 (CY2020) Reference Platform is the target for all major software releases in 2020.
12th September 2020 - CY2021 is now Final. Further changes are not anticipated unless a major issue is discovered and the community supports a late change.
20th August 2020 - From CY2021 the VFX Reference Platform will support Windows and macOS in addition to Linux. Details added below, and feedback welcome. CY2021 will be finalized within the next 4 weeks.
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:
|4.8.2 with bugfix or 4.8.3|| Earlier
|macOS||Minimum Deployment Target||10.13
|Windows||Minimum Platform Toolset||Visual Studio 2017|
(built with ucs4)
|2.7.9 - 2.7.latest
(Python 3 tech preview release)
|2.7.5 - 2.7.latest||2.7.5 - 2.7.latest|
|Qt||5.15.x||5.12.x||5.12.x||5.6.1 - 5.6.latest (modified)||5.6.1 (modified)|
|Qt for Python
|5.15||5.12 (with patch)
(v2 in CY2021)
|ACES||1.2||1.1||1.1||1.0.3 - 1.0.latest||1.0.x|
|Intel TBB||2020 Update 2||2019 Update 6||2018||2017 Update 6||4.4|
|Intel MKL||2020||2019||2018||2017 Update 2||11.3|
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.
The move to Python 3 was delayed from CY2019 to CY2020 due to:
Python 3 in CY2020 is a required upgrade as Python 2 will no longer be supported beyond 2020.
For users of RHEL-derived Linux distributions, 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.
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 is still using the older option so the compiler setting should be _GLIBCXX_USE_CXX11_ABI=0, although that setting may not be supported by some distros yet. The Platform will move to the newer implementations in a future year once the major Linux distributions have made the transition.
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.
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 werw 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.
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.
17th July 2020 - Added gcc notes to CY2021 Draft with details on Redhat Developer Toolset and clang compatibility.
7th March 2020 - CY2020 updated - Added required patch for Qt for Python (PySide) and an alternative option of using 5.13.
2nd November 2019 - Late change approved to CY2020 - OpenEXR updated to 2.4.x.
19th October 2019 - Late change to CY2020 under review to accomodate an updated OpenEXR release. Proposed change is limited to OpenEXR moving to 2.4.x. Please send feedback on this change by 31st October.
3rd August 2019 - The CY2020 Platform is now Final with no further changes planned.
1st May 2019 - CY2020 Draft published which includes the long-awaited move to Python 3. We are currently soliciting feedback on this Draft so please either send to firstname.lastname@example.org or share on vfx-platform-discuss. Software vendors are encouraged to provide a Python 3 tech preview release this year to help studios with testing during migration efforts.
12th September 2018 - CY2019 Final now published with OpenVDB updated to 6.x and ACES to 1.1 to reflect recent or imminent major releases of these important industry packages.
22nd July 2018 - CY2019 Draft updated - OpenEXR upped to 2.3.x.
22nd July 2018 - CY2019 Draft updated - minimum version of Python is now 2.7.9 to ensure support of PIP via PyPI.
20th May 2018 - CY2019 Draft published. The move to Python 3 has been pushed to CY2020 due to the need to focus on upgrading to the latest Qt Long Term Support release. Software vendors are requested to provide a Python 3 tech preview release in 2019 to help studios with testing during migration efforts. We are currently soliciting feedback on this Draft so please either send to email@example.com or share on vfx-platform-discuss.
26th November 2017 - CY2018 has had a late change to the compiler version which is now gcc 6.3.1. This successfully resolves issues that were discovered with gcc 5.3.1.
28th August 2017 - Added a note for gcc 5 and updated the Qt note to include a link to the qtdeclarative modifications.
3rd August 2017 - The CY2018 Platform was ratified as Final at the annual SIGGRAPH VFX Reference Platform Birds of a Feather with no further planned changes.
2nd July 2017 - Minor updates to CY2018 Draft for Qt and ACES.
29th April 2017 - CY2018 Draft published with significant upgrades to gcc and glibc. This also comes with notice of our intention to move to Python 3 for CY2019 in advance of Python 2 support ending in 2020. We are currently soliciting feedback on this Draft so please either send to firstname.lastname@example.org or share on vfx-platform-discuss. We expect to publish CY2018 Final around SIGGRAPH in July.
1st August 2016 - CY2017 Final now published with OpenSubdiv and OpenVDB being updated in addition to Boost, Ptex, Alembic and TBB as result of feedback to the Draft.
20th June 2016 - CY2017 Draft published for comment from the community. The theme for CY2017 is to minmize code changes in the year following the transition to Qt 5.
27th October 2015 - A late change has been proposed to CY2016 to move from Qt 5.5.x to Qt 5.6.x due to that version now being targetted as a Long Term Support release. Please see here for further details.
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.