Remove D3D12 scenegraph backend

Task-number: QTBUG-79925
Change-Id: Id3f0a688f47efaf1653c85d23ef49618ed09c931
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>

10 files changed, 28 insertions, 506 deletions

diff --git a/src/quick/configure.json b/src/quick/configure.json
index 0cb1e7470b..84b9188605 100644
--- a/src/quick/configure.json
+++ b/src/quick/configure.json
@@ -10,7 +10,6 @@
 
     "commandline": {
         "options": {
-            "d3d12": "boolean",
             "quick-animatedimage": "boolean",
             "quick-canvas": "boolean",
             "quick-designer": "boolean",
@@ -26,24 +25,7 @@
         }
     },
 
-    "tests": {
-        "d3d12": {
-            "label": "Direct3D 12",
-            "type": "compile",
-            "test": "d3d12"
-        }
-    },
-
     "features": {
-        "d3d12": {
-            "label": "Direct3D 12",
-            "purpose": "Provides a Direct3D 12 backend for the scenegraph.",
-            "section": "Qt Quick",
-            "condition": "tests.d3d12",
-            "output": [
-                "publicFeature"
-            ]
-        },
         "quick-animatedimage": {
             "label": "AnimatedImage item",
             "purpose": "Provides the AnimatedImage item.",
@@ -200,7 +182,6 @@
         {
             "section": "Qt Quick",
             "entries": [
-                "d3d12",
                 "quick-animatedimage",
                 "quick-canvas",
                 "quick-designer",
diff --git a/src/quick/doc/src/concepts/visualcanvas/adaptations.qdoc b/src/quick/doc/src/concepts/visualcanvas/adaptations.qdoc
index 88003b68d3..86292921a6 100644
--- a/src/quick/doc/src/concepts/visualcanvas/adaptations.qdoc
+++ b/src/quick/doc/src/concepts/visualcanvas/adaptations.qdoc
@@ -34,11 +34,10 @@
 Originally, Qt Quick always relied on OpenGL (OpenGL ES 2.0 or OpenGL 2.0) to
 parse the scene graph and render the results to a render target
 
-From Qt 5.8 onwards, Qt Quick also supports rendering in software, with OpenVG,
-and with Direct3D 12. This is realized by having additional scene graph
-adaptations, either in form of plugins (d3d12, openvg) or built-in to the Qt
-Quick library (software). The default adaptation continues to rely directly on
-OpenGL.
+From Qt 5.8 onwards, Qt Quick also supports rendering in software, and with
+OpenVG.  This is realized by having additional scene graph adaptations, either
+in form of plugins (openvg) or built-in to the Qt Quick library
+(software). The default adaptation continues to rely directly on OpenGL.
 
 From Qt 5.14 onwards, the default adaptation gains the option of rendering via
 a graphics abstraction layer, the Qt Rendering Hardware Interface (RHI),
@@ -52,7 +51,7 @@ appropriate for the various graphics APIs.
 \target Switching Between the Adaptation Used by the Application
 \section1 Switch Between Adaptations in Your Application
 
-Unlike \c software or \c d3d12, the RHI-based renderer is not an additional
+Unlike \c software, the RHI-based renderer is not an additional
 adaptation, and is always built-in. As of Qt 5.14 it can be enabled by setting
 the environment variable \c{QSG_RHI} to a non-zero value before starting the
 application, or via \l QQuickWindow::setSceneGraphBackend() in combination with
@@ -75,8 +74,6 @@ The following backends are supported:
         different than the ones listed below.
     \li Software - Request with the \c{"software"} string or the QSGRendererInterface::Software
         enum value.
-    \li Direct3D 12 - Request with the \c{"d3d12"} string or the QSGRendererInterface::Direct3D12
-        enum value.
     \li OpenVG - Request with the \c{"openvg"} string or the QSGRendererInterface::OpenVG enum
         value.
 \endlist
@@ -111,12 +108,6 @@ The Software adaptation is an alternative renderer for \l{Qt Quick} 2 that uses
 engine to render the contents of the scene graph. For more details, see
 \l{qtquick-visualcanvas-adaptations-software.html}{Software Adaptation}.
 
-\section1 Direct3D 12 (experimental)
-
-The Direct3D 12 adaptation is an alternative renderer for \l{Qt Quick} 2 when running on Windows
-10, both for Win32 and UWP applications. For more details, see
-\l{qtquick-visualcanvas-adaptations-d3d12.html}{Direct3D 12 Adaptation}.
-
 \section1 OpenVG
 
 The OpenVG adaptation is an alternative renderer for \l{Qt Quick} 2 that renders the contents of
@@ -172,235 +163,6 @@ behavior, which is only present in the default OpenGL adaptation.
 
 
 /*!
-\title Qt Quick Direct3D 12 Adaptation
-\page qtquick-visualcanvas-adaptations-d3d12.html
-
-The Direct3D 12 adaptation for Windows 10, both in Win32 (\c windows platform plugin) and in UWP
-(\c winrt platform plugin), is shipped as a dynamically loaded plugin. This adaptation doesn't work
-on earlier Windows versions. Building this plugin is enabled automatically, whenever the necessary
-D3D and DXGI develpoment files are present. In practice, this currently means Visual Studio 2015
-and newer.
-
-The adaptation is available both in normal, OpenGL-enabled Qt builds, and also when Qt is
-configured with \c{-no-opengl}. However, it's never the default, meaning that the user or the
-application has to explicitly request it by setting the \c{QT_QUICK_BACKEND} environment variable
-to \c{d3d12} or by calling QQuickWindow::setSceneGraphBackend().
-
-\section2 Motivation
-
-This experimental adaptation is the first Qt Quick backend that focuses on a modern, lower-level
-graphics API in combination with a windowing system interface that's different from the traditional
-approaches used in combination with OpenGL.
-
-This adaptation also allows better integration with Windows, as Direct3D is the primary
-vendor-supported solution. Consequently, there are fewer problems anticipated with drivers,
-operations like window resizes, and special events like graphics device loss caused by device
-resets or graphics driver updates.
-
-Performance-wise, the general expectation is a somewhat lower CPU usage compared to OpenGL, due to
-lower driver overhead, and a higher GPU utilization with less idle time wastage. The backend
-doesn't heavily utilize threads yet, which means there are opportunities for further improvements
-in the future, for example to further optimize image loading.
-
-The D3D12 backend also introduces support for pre-compiled shaders. All the backend's own shaders
-(used by the built-in materials on which the Rectangle, Image, Text, and other QML types are built
-with) are compiled to D3D shader bytecode when you compile Qt. Applications using ShaderEffect
-items can choose to ship bytecode either in regular files, via the Qt resource system, or use
-High Level Shading Language for DirectX (HLSL) source strings. Unlike OpenGL, the compilation for
-HLSL is properly threaded, meaning shader compilation won't block the application and its user
-interface.
-
-\section2 Graphics Adapters
-
-The plugin does not necessarily require hardware acceleration. You can also use WARP, the Direct3D
-software rasterizer. By default, the first adapter providing hardware acceleration is chosen. To
-override this and use another graphics adapter or to force the use of the software rasterizer, set
-the \c{QT_D3D_ADAPTER_INDEX} environment variable to the index of the adapter. The adapters
-discovered are printed at startup when \c{QSG_INFO} or the \c{qt.scenegraph.general} logging
-category is enabled.
-
-\section2 Troubleshooting
-
-If you encounter issues, always set the \c{QSG_INFO} and \c{QT_D3D_DEBUG} environment variables
-to \c 1, to get debug and warning messages printed on the debug output. \c{QT_D3D_DEBUG} enables
-the Direct3D debug layer.
-
-\note The debug layer shouldn't be enabled in production use, since it can significantly impact
-performance (CPU load) due to increased API overhead.
-
-\section2 Render Loops
-
-By default, the D3D12 adaptation uses a single-threaded render loop similar to OpenGL's \c windows
-render loop. A threaded variant is also available, that you can request by setting the
-\c{QSG_RENDER_LOOP} environment variable to \c threaded. However, due to conceptual limitations in
-DXGI, the windowing system interface, the threaded loop is prone to deadlocks when multiple
-QQuickWindow or QQuickView instances are shown. Consequently, for the time being, the default is
-the single-threaded loop. This means that with the D3D12 backend, applications are expected to move
-their work from the main (GUI) thread out to worker threads, instead of expecting Qt to keep the
-GUI thread responsive and suitable for heavy, blocking operations.
-
-For more information see \l{qtquick-visualcanvas-scenegraph.html}{Qt Quick Scene Graph} for
-details on render loops and
-\l{https://docs.microsoft.com/en-us/windows/desktop/direct3darticles/dxgi-best-practices#multithreading-and-dxgi}{Multithreading and DXGI}
-regarding the issues with multithreading.
-
-\section2 Renderer
-
-The scene graph renderer in the D3D12 adaptation currently doesn't perform any batching. This is
-less of an issue, unlike OpenGL, because state changes don't present any problems in the first
-place. The simpler renderer logic can also lead to lower CPU overhead in some cases. The trade-offs
-between the various approaches are currently under research.
-
-\section2 Shader Effects
-
-The ShaderEffect QML type is fully functional with the D3D12 adaptation as well. However, the
-interpretation of the fragmentShader and vertexShader properties is different than with OpenGL.
-
-With D3D12, these strings can either be a URL for a local file, a file in the resource system,
-or an HLSL source string. Using a URL for a local file or a file in the resource system
-indicates that the file in question contains pre-compiled D3D shader bytecode generated by the
-\c fxc tool, or, alternatively, HLSL source code. The type of file is detected automatically.
-This means that the D3D12 backend supports all options from GraphicsInfo.shaderCompilationType
-and GraphicsInfo.shaderSourceType.
-
-Unlike OpenGL, whenever you open a file, there is a QFileSelector with the extra \c hlsl selector
-used. This provides easy creation of ShaderEffect items that are functional across both backends,
-for example by placing the GLSL source code into \c{shaders/effect.frag}, the HLSL source code or
-- preferably - pre-compiled bytecode into \c{shaders/+hlsl/effect.frag}, while simply writing
-\c{fragmentShader: "qrc:shaders/effect.frag"} in QML. For more details, see ShaderEffect.
-
-\section2 Multisample Render Targets
-
-The Direct3D 12 adaptation ignores the QSurfaceFormat set on the QQuickWindow or QQuickView, or
-set via QSurfaceFormat::setDefaultFormat(), with two exceptions: QSurfaceFormat::samples() and
-QSurfaceFormat::alphaBufferSize() are still taken into account. When the sample value is greater
-than 1, multisample offscreen render targets will be created with the specified sample count at
-the maximum supported quality level. The backend automatically performs resolving into the
-non-multisample swapchain buffers after each frame.
-
-\section2 Semi-transparent Windows
-
-When the alpha channel is enabled either via QQuickWindow::setDefaultAlphaBuffer() or by setting
-alphaBufferSize to a non-zero value in the window's QSurfaceFormat or in the global format managed
-by QSurfaceFormat::setDefaultFormat(), the D3D12 backend will create a swapchain for composition
-and go through DirectComposition. This is necessary, because the mandatory flip model swapchain
-wouldn't support transparency otherwise.
-
-Therefore, it's important not to unneccessarily request an alpha channel. When the alphaBufferSize
-is 0 or the default -1, all these extra steps can be avoided and the traditional window-based
-swapchain is sufficient.
-
-On WinRT, this isn't relevant because the backend there always uses a composition swapchain which
-is associated with the ISwapChainPanel that backs QWindow on that platform.
-
-\section2 Mipmaps
-
-Mipmap generation is supported and handled transparently to the applications via a built-in compute
-shader. However, at the moment, this feature is experimental and only supports power-of-two images.
-Textures of other size will work too, but this involves a QImage-based scaling on the CPU first.
-Therefore, avoid enabling mipmapping for Non-Power-Of-Two (NPOT) images whenever possible.
-
-\section2 Image Formats
-
-When creating textures via C++ scene graph APIs like QQuickWindow::createTextureFromImage(), 32-bit
-formats won't involve any conversion, they'll map directly to the corresponding \c{R8G8B8A8_UNORM}
-or \c{B8G8R8A8_UNORM} format. Everything else will trigger a QImage-based format conversion on the
-CPU first.
-
-\section2 Unsupported Features
-
-Particles and some other OpenGL-dependent utilities, like QQuickFramebufferObject, are currently
-not supported.
-
-Like with \l{qtquick-visualcanvas-adaptations-software.html}{Software adaptation}, text is always
-rendered using the native method. Distance field-based text rendering is currently not implemented.
-
-The shader sources in the \l {Qt Graphical Effects} module have not been ported to any format other
-than the OpenGL 2.0 compatible one, meaning that the QML types provided by that module are currently
-not functional with the D3D12 backend.
-
-Texture atlases are currently not in use.
-
-The renderer may lack support for certain minor features, such as drawing points and lines with a
-width other than 1.
-
-Custom Qt Quick items using custom scene graph nodes can be problematic because materials are
-inherently tied to the graphics API. Therefore, only items that use the utility rectangle and image
-nodes are functional across all adaptations.
-
-QQuickWidget and its underlying OpenGL-based compositing architecture is not supported. If you need
-to mix with QWidget-based user interfaces, use QWidget::createWindowContainer() to embed the native
-window of the QQuickWindow or QQuickView.
-
-Finally, rendering via QSGEngine and QSGAbstractRenderer is not feasible with the D3D12 adaptation
-at the moment.
-
-\section2 Related APIs
-
-To integrate custom Direct3D 12 rendering, use QSGRenderNode in combination with
-QSGRendererInterface. This approach doesn't rely on OpenGL contexts or API specifics like
-framebuffers, and allows exposing the graphics device and command buffer from the adaptation. It's
-not necessarily suitable for easy integration of all types of content, in particular true 3D, so
-it'll likely get complemented by an alternative to QQuickFramebufferObject in future releases.
-
-To perform runtime decisions based on the adaptation, use QSGRendererInterface from C++ and
-GraphicsInfo from QML. They can also be used to check the level of shader support: shading
-language, compilation approach, and so on.
-
-When creating custom items, use the new QSGRectangleNode and QSGImageNode classes. These replace
-the now deprecated QSGSimpleRectNode and QSGSimpleTextureNode. Unlike their predecessors, these new
-classes are interfaces, and implementations are created via the QQuickWindow::createRectangleNode()
-and QQuickWindow::createImageNode() factory functions.
-
-\section2 Advanced Configuration
-
-The D3D12 adaptation can keep multiple frames in flight, similar to modern game engines. This is
-somewhat different from the traditional "render - swap - wait for vsync" model and allows for
-better GPU utilization at the expense of higher resource use. This means that the renderer will
-be a number of frames ahead of what is displayed on the screen.
-
-For a discussion of flip model swap chains and the typical configuration parameters, refer to
-\l{https://software.intel.com/en-us/articles/sample-application-for-direct3d-12-flip-model-swap-chains}
-{Sample Application for Direct3D 12 Flip Model Swap Chains}.
-
-Vertical synchronization is always enabled, meaning Present() is invoked with an interval of 1.
-
-The configuration can be changed by setting the following environment variables:
-
-\table
-    \header
-        \li Environment variable
-        \li Description
-    \row
-        \li \c{QT_D3D_BUFFER_COUNT}
-        \li The number of swap chain buffers in range 2 - 4. The default value is 3.
-    \row
-        \li \c{QT_D3D_FRAME_COUNT}
-        \li The number of frames prepared without blocking in range 1 - 4. The default value is 2.
-            Present() starts blocking after queuing 3 frames (regardless of
-            \c{QT_D3D_BUFFER_COUNT}), unless the waitable object is in use. Every additional frame
-            increases GPU resource usage since geometry and constant buffer data needs to be
-            duplicated, and involves more bookkeeping on the CPU side.
-    \row
-        \li \c{QT_D3D_WAITABLE_SWAP_CHAIN_MAX_LATENCY}
-        \li The frame latency in range 1 - 16. The default value is 0 (disabled).
-            Changes the limit for Present() and triggers a wait for an available swap chain buffer
-            when beginning each frame. For a detailed discussion, see the article linked above.
-            \note Currently, this behavior is experimental.
-    \row
-        \li \c{QT_D3D_BLOCKING_PRESENT}
-        \li The time the CPU should wait, a non-zero value, for the GPU to finish its work after
-            each call to Present(). The default value is 0 (disabled). This behavior effectively
-            kills all parallelism but makes the behavior resemble the traditional
-            swap-blocks-for-vsync model, which can be useful in some special cases. However, this
-            behavior is not the same as setting the frame count to 1 because that still avoids
-            blocking after Present(), and may only block when starting to prepare the next frame
-            (or may not block at all depending on the time gap between the frames).
-\endtable
-
-*/
-
-/*!
 \title Qt Quick OpenVG Adaptation
 \page qtquick-visualcanvas-adaptations-openvg.html
 
diff --git a/src/quick/items/qquickgraphicsinfo.cpp b/src/quick/items/qquickgraphicsinfo.cpp
index 8f6f4386fb..adf620b256 100644
--- a/src/quick/items/qquickgraphicsinfo.cpp
+++ b/src/quick/items/qquickgraphicsinfo.cpp
@@ -95,7 +95,6 @@ QQuickGraphicsInfo *QQuickGraphicsInfo::qmlAttachedProperties(QObject *object)
     \li GraphicsInfo.Unknown - the default value when no active scenegraph is associated with the item
     \li GraphicsInfo.Software - Qt Quick's software renderer based on QPainter with the raster paint engine
     \li GraphicsInfo.OpenGL - OpenGL or OpenGL ES
-    \li GraphicsInfo.Direct3D12 - Direct3D 12
     \li GraphicsInfo.OpenVG - OpenVG
     \li GraphicsInfo.OpenGLRhi - OpenGL on top of QRhi, a graphics abstraction layer
     \li GraphicsInfo.Direct3D11Rhi - Direct3D 11 on top of QRhi, a graphics abstraction layer
diff --git a/src/quick/items/qquickgraphicsinfo_p.h b/src/quick/items/qquickgraphicsinfo_p.h
index 066a419c37..aa7d15f72d 100644
--- a/src/quick/items/qquickgraphicsinfo_p.h
+++ b/src/quick/items/qquickgraphicsinfo_p.h
@@ -85,7 +85,6 @@ public:
         Unknown = QSGRendererInterface::Unknown,
         Software = QSGRendererInterface::Software,
         OpenGL = QSGRendererInterface::OpenGL,
-        Direct3D12 = QSGRendererInterface::Direct3D12,
         OpenVG = QSGRendererInterface::OpenVG,
         OpenGLRhi = QSGRendererInterface::OpenGLRhi,
         Direct3D11Rhi = QSGRendererInterface::Direct3D11Rhi,
diff --git a/src/quick/items/qquickshadereffect.cpp b/src/quick/items/qquickshadereffect.cpp
index b3c8386fd9..e71e6dc698 100644
--- a/src/quick/items/qquickshadereffect.cpp
+++ b/src/quick/items/qquickshadereffect.cpp
@@ -179,201 +179,11 @@ QT_BEGIN_NAMESPACE
     is a URL with the \c file or \c qrc schema, it is treated as a file
     reference and the source code is read from the specified file.
 
-    \section1 Direct3D and HLSL
-
-    Direct3D backends provide ShaderEffect support with HLSL. The Direct3D 12
-    backend requires using at least Shader Model 5.0 both for vertex and pixel
-    shaders. When necessary, GraphicsInfo.shaderType can be used to decide
-    at runtime what kind of value to assign to \l fragmentShader or
-    \l vertexShader.
-
-    All concepts described above for OpenGL and GLSL apply to Direct3D and HLSL
-    as well. There are however a number of notable practical differences, which
-    are the following:
-
-    Instead of uniforms, HLSL shaders are expected to use a single constant
-    buffer, assigned to register \c b0. The special names \c qt_Matrix,
-    \c qt_Opacity, and \c qt_SubRect_<name> function the same way as with GLSL.
-    All other members of the buffer are expected to map to properties in the
-    ShaderEffect item.
-
-    \note The buffer layout must be compatible for both shaders. This means
-    that application-provided shaders must make sure \c qt_Matrix and
-    \c qt_Opacity are included in the buffer, starting at offset 0, when custom
-    code is provided for one type of shader only, leading to ShaderEffect
-    providing the other shader. This is due to ShaderEffect's built-in shader code
-    declaring a constant buffer containing \c{float4x4 qt_Matrix; float qt_Opacity;}.
-
-    Unlike GLSL's attributes, no names are used for vertex input elements.
-    Therefore qt_Vertex and qt_MultiTexCoord0 are not relevant. Instead, the
-    standard Direct3D semantics, \c POSITION and \c TEXCOORD (or \c TEXCOORD0)
-    are used for identifying the correct input layout.
-
-    Unlike GLSL's samplers, texture and sampler objects are separate in HLSL.
-    Shaders are expected to expect 2D, non-array, non-multisample textures.
-    Both the texture and sampler binding points are expected to be sequential
-    and start from 0 (meaning registers \c{t0, t1, ...}, and \c{s0, s1, ...},
-    respectively). Unlike with OpenGL, samplers are not mapped to Qt Quick item
-    properties and therefore the name of the sampler is not relevant. Instead,
-    it is the textures that map to properties referencing \l Image or
-    \l ShaderEffectSource items.
-
-    Unlike OpenGL, backends for modern APIs will typically prefer offline
-    compilation and shipping pre-compiled bytecode with applications instead of
-    inlined shader source strings. In this case the string properties for
-    vertex and fragment shaders are treated as URLs referring to local files or
-    files shipped via the Qt resource system.
-
-    To check at runtime what is supported, use the
-    GraphicsInfo.shaderSourceType and GraphicsInfo.shaderCompilationType
-    properties. Note that these are bitmasks, because some backends may support
-    multiple approaches.
-
-    In case of Direct3D 12, all combinations are supported. If the vertexShader
-    and fragmentShader properties form a valid URL with the \c file or \c qrc
-    schema, the bytecode or HLSL source code is read from the specified file.
-    The type of the file contents is detected automatically. Otherwise, the
-    string is treated as HLSL source code and is compiled at runtime, assuming
-    Shader Model 5.0 and an entry point of \c{"main"}. This allows dynamically
-    constructing shader strings. However, whenever the shader source code is
-    static, it is strongly recommended to pre-compile to bytecode using the
-    \c fxc tool and refer to these files from QML. This will be a lot more
-    efficient at runtime and allows catching syntax errors in the shaders at
-    compile time.
-
-    Unlike OpenGL, the Direct3D backend is able to perform runtime shader
-    compilation on dedicated threads. This is managed transparently to the
-    applications, and means that ShaderEffect items that contain HLSL source
-    strings do not block the rendering or other parts of the application until
-    the bytecode is ready.
-
-    Using files with bytecode is more flexible also when it comes to the entry
-    point name (it can be anything, not limited to \c main) and the shader
-    model (it can be something newer than 5.0, for instance 5.1).
-
-    \table 70%
-    \row
-    \li \qml
-        import QtQuick 2.0
-
-        Rectangle {
-            width: 200; height: 100
-            Row {
-                Image { id: img;
-                        sourceSize { width: 100; height: 100 } source: "qt-logo.png" }
-                ShaderEffect {
-                    width: 100; height: 100
-                    property variant src: img
-                    fragmentShader: "qrc:/effect_ps.cso"
-                }
-            }
-        }
-        \endqml
-    \row
-    \li where \c effect_ps.cso is the compiled bytecode for the following HLSL shader:
-        \code
-        cbuffer ConstantBuffer : register(b0)
-        {
-            float4x4 qt_Matrix;
-            float qt_Opacity;
-        };
-        Texture2D src : register(t0);
-        SamplerState srcSampler : register(s0);
-        float4 ExamplePixelShader(float4 position : SV_POSITION, float2 coord : TEXCOORD0) : SV_TARGET
-        {
-            float4 tex = src.Sample(srcSampler, coord);
-            float3 col = dot(tex.rgb, float3(0.344, 0.5, 0.156));
-            return float4(col, tex.a) * qt_Opacity;
-        }
-        \endcode
-    \endtable
-
-    The above is equivalent to the OpenGL example presented earlier. The vertex
-    shader is provided implicitly by ShaderEffect. Note that the output of the
-    pixel shader is using premultiplied alpha and that \c qt_Matrix is present
-    in the constant buffer at offset 0, even though the pixel shader does not
-    use the value.
-
-    If desired, the HLSL source code can be placed directly into the QML
-    source, similarly to how its done with GLSL. The only difference in this
-    case is the entry point name, which must be \c main when using inline
-    source strings.
-
-    Alternatively, we could also have referred to a file containing the source
-    of the effect instead of the compiled bytecode version.
-
-    Some effects will want to provide a vertex shader as well. Below is a
-    similar effect with both the vertex and fragment shader provided by the
-    application. This time the colorization factor is provided by the QML item
-    instead of hardcoding it in the shader. This can allow, among others,
-    animating the value using QML's and Qt Quick's standard facilities.
-
-    \table 70%
-    \row
-    \li \qml
-        import QtQuick 2.0
-
-        Rectangle {
-            width: 200; height: 100
-            Row {
-                Image { id: img;
-                        sourceSize { width: 100; height: 100 } source: "qt-logo.png" }
-                ShaderEffect {
-                    width: 100; height: 100
-                    property variant src: img
-                    property variant color: Qt.vector3d(0.344, 0.5, 0.156)
-                    vertexShader: "qrc:/effect_vs.cso"
-                    fragmentShader: "qrc:/effect_ps.cso"
-                }
-            }
-        }
-        \endqml
-    \row
-    \li where \c effect_vs.cso and \c effect_ps.cso are the compiled bytecode
-    for \c ExampleVertexShader and \c ExamplePixelShader. The source code is
-    presented as one snippet here, the shaders can however be placed in
-    separate source files as well.
-        \code
-        cbuffer ConstantBuffer : register(b0)
-        {
-            float4x4 qt_Matrix;
-            float qt_Opacity;
-            float3 color;
-        };
-        Texture2D src : register(t0);
-        SamplerState srcSampler : register(s0);
-        struct PSInput
-        {
-            float4 position : SV_POSITION;
-            float2 coord : TEXCOORD0;
-        };
-        PSInput ExampleVertexShader(float4 position : POSITION, float2 coord : TEXCOORD0)
-        {
-            PSInput result;
-            result.position = mul(qt_Matrix, position);
-            result.coord = coord;
-            return result;
-        }
-        float4 ExamplePixelShader(PSInput input) : SV_TARGET
-        {
-            float4 tex = src.Sample(srcSampler, coord);
-            float3 col = dot(tex.rgb, color);
-            return float4(col, tex.a) * qt_Opacity;
-        }
-        \endcode
-    \endtable
-
-    \note With OpenGL the \c y coordinate runs from bottom to top whereas with
-    Direct 3D it goes top to bottom. For shader effect sources Qt Quick hides
-    the difference by treating QtQuick::ShaderEffectSource::textureMirroring as
-    appropriate, meaning texture coordinates in HLSL version of the shaders
-    will not need any adjustments compared to the equivalent GLSL code.
-
     \section1 Cross-platform, Cross-API ShaderEffect Items
 
-    Some applications will want to be functional with multiple accelerated
-    graphics backends. This has consequences for ShaderEffect items because the
-    supported shading languages may vary from backend to backend.
+    Some applications will want to be functional with multiple graphics
+    APIs. This has consequences for ShaderEffect items because the supported
+    shading languages may vary from backend to backend.
 
     There are two approaches to handle this: either write conditional property
     values based on GraphicsInfo.shaderType, or use file selectors. In practice
@@ -404,20 +214,8 @@ QT_BEGIN_NAMESPACE
                             gl_FragColor = vec4(vec3(dot(tex.rgb,
                                                 vec3(0.344, 0.5, 0.156))),
                                                      tex.a) * qt_Opacity;"
-                    : GraphicsInfo.shaderType === GraphicsInfo.HLSL ?
-                        "cbuffer ConstantBuffer : register(b0)
-                        {
-                            float4x4 qt_Matrix;
-                            float qt_Opacity;
-                        };
-                        Texture2D src : register(t0);
-                        SamplerState srcSampler : register(s0);
-                        float4 ExamplePixelShader(float4 position : SV_POSITION, float2 coord : TEXCOORD0) : SV_TARGET
-                        {
-                            float4 tex = src.Sample(srcSampler, coord);
-                            float3 col = dot(tex.rgb, float3(0.344, 0.5, 0.156));
-                            return float4(col, tex.a) * qt_Opacity;
-                        }"
+                    : GraphicsInfo.shaderType === GraphicsInfo.RhiShader ?
+                        "qrc:/shader.frag.qsb"
                     : ""
                 }
             }
@@ -429,15 +227,14 @@ QT_BEGIN_NAMESPACE
     reported by GraphicsInfo is not up-to-date until the ShaderEffect item gets
     associated with a QQuickWindow. Before that, the reported value is
     GraphicsInfo.UnknownShadingLanguage. The alternative is to place the GLSL
-    source code and the compiled D3D bytecode into the files
-    \c{shaders/effect.frag} and \c{shaders/+hlsl/effect.frag}, include them in
-    the Qt resource system, and let the ShaderEffect's internal QFileSelector
-    do its job. The selector-less version is the GLSL source, while the \c hlsl
-    selector is used when running on the D3D12 backend. The file under
-    \c{+hlsl} can then contain either HLSL source code or compiled bytecode
-    from the \c fxc tool. Additionally, when using a version 3.2 or newer core
-    profile context with OpenGL, GLSL sources with a core profile compatible
-    syntax can be placed under \c{+glslcore}.
+    source code and the RHI-compatible shader pack into the files
+    \c{shaders/effect.frag} and \c{shaders/+qsb/effect.frag}, include them in
+    the Qt resource system, and let the ShaderEffect's internal QFileSelector do
+    its job. The selector-less version is the GLSL source, while the \c qsb
+    selector is used when running with the Qt graphics abstraction (RHI).
+    Additionally, when using a version 3.2 or newer core profile context with
+    OpenGL, GLSL sources with a core profile compatible syntax can be placed
+    under \c{+glslcore}.
         \qml
         import QtQuick 2.8 // for GraphicsInfo
 
@@ -552,11 +349,7 @@ QQuickShaderEffect::~QQuickShaderEffect()
 
     With GLSL the default shader expects the texture coordinate to be passed
     from the vertex shader as \c{varying highp vec2 qt_TexCoord0}, and it
-    samples from a sampler2D named \c source. With HLSL the texture is named
-    \c source, while the vertex shader is expected to provide
-    \c{float2 coord : TEXCOORD0} in its output in addition to
-    \c{float4 position : SV_POSITION} (names can differ since linking is done
-    based on the semantics).
+    samples from a sampler2D named \c source.
 
     \sa vertexShader, GraphicsInfo
 */
@@ -593,9 +386,7 @@ void QQuickShaderEffect::setFragmentShader(const QByteArray &code)
     filesystem or bundled with the executable via Qt's resource system.
 
     With GLSL the default shader passes the texture coordinate along to the
-    fragment shader as \c{varying highp vec2 qt_TexCoord0}. With HLSL it is
-    enough to use the standard \c TEXCOORD0 semantic, for example
-    \c{float2 coord : TEXCOORD0}.
+    fragment shader as \c{varying highp vec2 qt_TexCoord0}.
 
     \sa fragmentShader, GraphicsInfo
 */
diff --git a/src/quick/items/qquickwindow.cpp b/src/quick/items/qquickwindow.cpp
index 3dd7862c72..f674962a52 100644
--- a/src/quick/items/qquickwindow.cpp
+++ b/src/quick/items/qquickwindow.cpp
@@ -4045,7 +4045,7 @@ QImage QQuickWindow::grabWindow()
     Q_D(QQuickWindow);
 
     if (!isVisible() && !d->renderControl) {
-        // backends like software and d3d12 can grab regardless of the window state
+        // backends like software can grab regardless of the window state
         if (d->windowManager && (d->windowManager->flags() & QSGRenderLoop::SupportsGrabWithoutExpose))
             return d->windowManager->grab(this);
     }
@@ -5514,9 +5514,6 @@ void QQuickWindow::setSceneGraphBackend(QSGRendererInterface::GraphicsApi api)
     case QSGRendererInterface::Software:
         setSceneGraphBackend(QStringLiteral("software"));
         break;
-    case QSGRendererInterface::Direct3D12:
-        setSceneGraphBackend(QStringLiteral("d3d12"));
-        break;
     default:
         break;
     }
diff --git a/src/quick/scenegraph/adaptations/software/qsgsoftwarethreadedrenderloop.cpp b/src/quick/scenegraph/adaptations/software/qsgsoftwarethreadedrenderloop.cpp
index f07cc28827..1de9415dd0 100644
--- a/src/quick/scenegraph/adaptations/software/qsgsoftwarethreadedrenderloop.cpp
+++ b/src/quick/scenegraph/adaptations/software/qsgsoftwarethreadedrenderloop.cpp
@@ -423,7 +423,7 @@ void QSGSoftwareRenderThread::sync(bool inExpose)
     qCDebug(QSG_RASTER_LOG_RENDERLOOP, "RT - sync");
 
     mutex.lock();
-    Q_ASSERT_X(renderLoop->lockedForSync, "QSGD3D12RenderThread::sync()", "sync triggered with gui not locked");
+    Q_ASSERT_X(renderLoop->lockedForSync, "QSGSoftwareRenderThread::sync()", "sync triggered with gui not locked");
 
     if (exposedWindow) {
         QQuickWindowPrivate *wd = QQuickWindowPrivate::get(exposedWindow);
diff --git a/src/quick/scenegraph/coreapi/qsgrendererinterface.cpp b/src/quick/scenegraph/coreapi/qsgrendererinterface.cpp
index 0fee1486cf..9b5701df5a 100644
--- a/src/quick/scenegraph/coreapi/qsgrendererinterface.cpp
+++ b/src/quick/scenegraph/coreapi/qsgrendererinterface.cpp
@@ -76,7 +76,6 @@ QT_BEGIN_NAMESPACE
     \value Unknown An unknown graphics API is in use
     \value Software The Qt Quick 2D Renderer is in use
     \value OpenGL OpenGL ES 2.0 or higher
-    \value Direct3D12 Direct3D 12
     \value OpenVG OpenVG via EGL
     \value OpenGLRhi OpenGL ES 2.0 or higher via a graphics abstraction layer. This value was introduced in Qt 5.14.
     \value Direct3D11Rhi Direct3D 11 via a graphics abstraction layer. This value was introduced in Qt 5.14.
@@ -189,10 +188,10 @@ QSGRendererInterface::~QSGRendererInterface()
     not supported or not available.
 
     When successful, the returned pointer is either a direct pointer to an
-    interface (and can be cast, for example, to \c{ID3D12Device *}) or a
-    pointer to an opaque handle that needs to be dereferenced first (for
-    example, \c{VkDevice dev = *static_cast<VkDevice *>(result)}). The latter
-    is necessary since such handles may have sizes different from a pointer.
+    interface, or a pointer to an opaque handle that needs to be dereferenced
+    first (for example, \c{VkDevice dev = *static_cast<VkDevice
+    *>(result)}). The latter is necessary since such handles may have sizes
+    different from a pointer.
 
     \note The ownership of the returned pointer is never transferred to the caller.
 
diff --git a/src/quick/scenegraph/coreapi/qsgrendererinterface.h b/src/quick/scenegraph/coreapi/qsgrendererinterface.h
index 7aa7d0e769..6224e08e84 100644
--- a/src/quick/scenegraph/coreapi/qsgrendererinterface.h
+++ b/src/quick/scenegraph/coreapi/qsgrendererinterface.h
@@ -53,7 +53,6 @@ public:
         Unknown,
         Software,
         OpenGL,
-        Direct3D12,
         OpenVG,
         OpenGLRhi,
         Direct3D11Rhi,
diff --git a/src/quick/scenegraph/coreapi/qsgrendernode.cpp b/src/quick/scenegraph/coreapi/qsgrendernode.cpp
index 63878954bf..519e3cd017 100644
--- a/src/quick/scenegraph/coreapi/qsgrendernode.cpp
+++ b/src/quick/scenegraph/coreapi/qsgrendernode.cpp
@@ -99,8 +99,8 @@ QSGRenderNodePrivate::QSGRenderNodePrivate()
 
     With APIs other than OpenGL, the only relevant values are the ones that
     correspond to dynamic state changes recorded on the command list/buffer.
-    For example, RSSetViewports, RSSetScissorRects, OMSetBlendFactor,
-    OMSetStencilRef in case of D3D12, or vkCmdSetViewport, vkCmdSetScissor,
+    For example, RSSetViewports, RSSetScissorRects, OMSetBlendState,
+    OMSetDepthStencilState in case of D3D11, or vkCmdSetViewport, vkCmdSetScissor,
     vkCmdSetBlendConstants, vkCmdSetStencilRef in case of Vulkan, and only when
     such commands were added to the scenegraph's command list queried via the
     QSGRendererInterface::CommandList resource enum. States set in pipeline
@@ -381,11 +381,6 @@ QSGRenderNode::RenderState::~RenderState()
 
     \return the current scissor rectangle when clipping is active. x and y are
     the bottom left coordinates.
-
-    \note Be aware of the differences between graphics APIs: for some the
-    scissor rect is only active when scissoring is enabled (for example,
-    OpenGL), while for others the scissor rect is equal to the viewport rect
-    when there is no need to scissor away anything (for example, Direct3D 12).
  */
 
 /*!