Commit fb67a7e1 authored by Laszlo Agocs's avatar Laszlo Agocs

Move some docs from .qdoc into .cpp

As we may not have the doc landing page once integrating into
some other Qt module.
parent 8599a2b5
......@@ -38,61 +38,12 @@ graphics APIs, such as, \l{https://www.khronos.org/opengl/}{OpenGL},
\l{https://developer.apple.com/metal/}{Metal}, and
\l{https://www.khronos.org/vulkan/}{Vulkan}.
Some of the main design goals are:
\list
\li Simple, minimal, understandable, extensible. Follow the proven path of the
Qt Quick scenegraph.
\li Aim to be a product - and in the bigger picture, part of a product (Qt) -
that is usable out of the box both by internal (such as, Qt Quick) and,
eventually, external users.
\li Not a complete 1:1 wrapper for any of the underlying APIs. The feature set
is tuned towards the needs of Qt's 2D and 3D offering (QPainter, Qt Quick, Qt
3D Studio). Iterate and evolve in a sustainable manner.
\li Intrinsically cross-platform, without reinventing: abstracting
cross-platform aspects of certain APIs (such as, OpenGL context creation and
windowing system interfaces, Vulkan instance and surface management) is not in
scope here. These are delegated to the existing QtGui facilities (QWindow,
QOpenGLContext, QVulkanInstance) and its backing QPA architecture.
\endlist
The main class in the module is QRhi. Each QRhi instance is backed by a backend
for a specific graphics API. The selection of the backend is a run time choice
and is up to the application or library that creates the QRhi instance. Some
backends are available on multiple platforms (OpenGL, Vulkan, Null), while APIs
specific to a given platform are only available when running on the platform in
question.
The available backends currently are:
\list
\li OpenGL 2.1 or OpenGL ES 2.0 or newer. Some extensions are utilized when
present, for example to enable multisample framebuffers.
\li Direct3D 11.1
\li Metal
\li Vulkan 1.0, optionally with some extensions that are part of Vulkan 1.1
\li Null - A "dummy" backend that issues no graphics calls at all.
\endlist
In order to allow shader code to be written once in Qt applications and
libraries, all shaders are expected to be written in a single language which is
then compiled into SPIR-V. Versions for various shading language are then
generated from that, together with reflection information (inputs, outputs,
shader resources). This is then packed into easily and efficiently serializable
QRhiShader instances. The compilers and tools to generate such shaders are not
part of the Rhi module, but the core classes for using such shaders,
QRhiShader and QRhiShaderDescription, are.
specific to a given platform (Direct3D, Metal) are only available when running
on the platform in question.
\section1 Table of Contents
......
......@@ -59,13 +59,36 @@ QT_BEGIN_NAMESPACE
\brief Accelerated 2D/3D graphics API abstraction.
QRhi is an abstraction for hardware accelerated graphics APIs, such as,
\l{https://www.khronos.org/opengl/}{OpenGL},
The Qt Rendering Hardware Interface is an abstraction for hardware accelerated
graphics APIs, such as, \l{https://www.khronos.org/opengl/}{OpenGL},
\l{https://www.khronos.org/opengles/}{OpenGL ES},
\l{https://docs.microsoft.com/en-us/windows/desktop/direct3d}{Direct3D},
\l{https://developer.apple.com/metal/}{Metal}, and
\l{https://www.khronos.org/vulkan/}{Vulkan}.
Some of the main design goals are:
\list
\li Simple, minimal, understandable, extensible. Follow the proven path of the
Qt Quick scenegraph.
\li Aim to be a product - and in the bigger picture, part of a product (Qt) -
that is usable out of the box both by internal (such as, Qt Quick) and,
eventually, external users.
\li Not a complete 1:1 wrapper for any of the underlying APIs. The feature set
is tuned towards the needs of Qt's 2D and 3D offering (QPainter, Qt Quick, Qt
3D Studio). Iterate and evolve in a sustainable manner.
\li Intrinsically cross-platform, without reinventing: abstracting
cross-platform aspects of certain APIs (such as, OpenGL context creation and
windowing system interfaces, Vulkan instance and surface management) is not in
scope here. These are delegated to the existing QtGui facilities (QWindow,
QOpenGLContext, QVulkanInstance) and its backing QPA architecture.
\endlist
Each QRhi instance is backed by a backend for a specific graphics API. The
selection of the backend is a run time choice and is up to the application
or library that creates the QRhi instance. Some backends are available on
......@@ -73,6 +96,32 @@ QT_BEGIN_NAMESPACE
platform are only available when running on the platform in question (Metal
on macOS/iOS/tvOS, Direct3D on Windows).
The available backends currently are:
\list
\li OpenGL 2.1 or OpenGL ES 2.0 or newer. Some extensions are utilized when
present, for example to enable multisample framebuffers.
\li Direct3D 11.1
\li Metal
\li Vulkan 1.0, optionally with some extensions that are part of Vulkan 1.1
\li Null - A "dummy" backend that issues no graphics calls at all.
\endlist
In order to allow shader code to be written once in Qt applications and
libraries, all shaders are expected to be written in a single language
which is then compiled into SPIR-V. Versions for various shading language
are then generated from that, together with reflection information (inputs,
outputs, shader resources). This is then packed into easily and efficiently
serializable QRhiShader instances. The compilers and tools to generate such
shaders are not part of QRhi, but the core classes for using such shaders,
QRhiShader and QRhiShaderDescription, are.
\section2 Design Fundamentals
A QRhi cannot be instantiated directly. Instead, use the create()
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment