Remove D3D12 scenegraph backend

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

1 files changed, 15 insertions, 224 deletions

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
 */