Details
-
Sub-task
-
Resolution: Unresolved
-
P2: Important
-
None
Description
Starting with https://codereview.qt-project.org/c/qt/qtbase/+/486503 (Qt 6.7) the D3D12 backend of QRhi will be automatically unavailable when Qt is built with an environment where the Windows headers are not new enough.
If the d3d12.h does not contain the types introduced in 2017, with the SDK corresponding to Windows 10 version 1703, the whole backend code will get automatically ifdefed out and QRhi::create() will fail with an appropriate warning message when D3D12 is requested.
Note that Qt 6.5 LTS's minimum supported Windows version (at run time) is already Windows 10 1809, from late 2018. Therefore, the expectation of a build environment suitable for 1703 (or 1809, even) features in Qt 6.7 is likely not unreasonable.
Ideally Qt should always be built with an official Windows SDK (i.e. headers and libraries) corresponding to the minimum supported Windows version, not outdated/unofficial/reengineered headers collected from random places; granted, I realize this may not be that simple with third-party toolchains not supported by the platform vendor that cannot use the official SDK and have the create their own SDK in practice. (see e.g. this thread https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/89131299-f97b-df98-32c6-66fa02be0dc%40martin.st/ )
For MSVC this is not an issue, a typical installation of MSVC 2019 or 2022 is fine with this since it usually ends up installing a somewhat up-to-date set of headers/libraries (the official Windows SDK) out of the box.
However, MinGW/gcc and MinGW/LLVM seem to have headers lacking newer APIs. (e.g. in case of d3d12.h, lacking everything post-2015 or so)
There is an additional problem: dxcapi.h is not present at all. (this is the header for the modern D3D shader compiler https://github.com/microsoft/DirectXShaderCompiler;the header is bundled with the Windows SDK too these days) The lack of this header is also handled gracefully in 6.7, but that means runtime HLSL->DXIL (intermediate bytecode) compilation in such builds will get disabled, which may cripple some applications, although for the time being this code path is rarely hit, unless one uses multiview or something else that implies using HLSL >= 6.0.
While many users can use the D3D11 backend (which is the default anyway), new features will not be available with that one. (e.g. this would mean multiview support, and by extension VR/AR support in the future, is just not going to be available with MinGW; with D3D at least, of course one can still force using Vulkan or OpenGL instead, but in any case the parity to MSVC is gone)
It would be nice if we could support MinGW properly, but it is not clear what we can do within Qt to support this.
For now, in practice this will manifest like this from Qt 6.7 on, here as an example a snippet from a random qtbase CI run with MinGW/LLVM. All D3D12 stuff is skipped as QRhi::create() gracefully fails with a helpful warning and that's that.
PASS : tst_QRhi::stats(OpenGL)
PASS : tst_QRhi::stats(Direct3D 11)
QWARN : tst_QRhi::stats(Direct3D 12) Qt was built without Direct3D 12 support. This is likely due to having ancient SDK headers (such as d3d12.h) in the Qt build environment. Rebuild Qt with an SDK supporting D3D12 features introduced in Windows 10 version 1703, or use an MSVC build as those typically are built with more up-to-date SDKs.
SKIP : tst_QRhi::stats(Direct3D 12) QRhi could not be created, skipping testing statistics getter
C:/Users/qt/work/qt/qtbase/tests/auto/gui/rhi/qrhi/tst_qrhi.cpp(444) : failure location
PASS : tst_QRhi::nativeHandles(OpenGL)
PASS : tst_QRhi::nativeHandles(Direct3D 11)
QWARN : tst_QRhi::nativeHandles(Direct3D 12) Qt was built without Direct3D 12 support. This is likely due to having ancient SDK headers (such as d3d12.h) in the Qt build environment. Rebuild Qt with an SDK supporting D3D12 features introduced in Windows 10 version 1703, or use an MSVC build as those typically are built with more up-to-date SDKs.
SKIP : tst_QRhi::nativeHandles(Direct3D 12) QRhi could not be created, skipping testing native handles
...
Perhaps this is going to solve itself with time (e.g. when mingw-w64 gets newer headers generated somehow), so it is not certain if there is any action Qt can/should take here.
Attachments
Issue Links
- depends on
-
QTBUG-107516 Migrate from GCC MinGW to LLVM-MinGW
-
- Reported
-