[Development] [Gerrit-admin] Shadertools repo request and some words about state of graphics
kari.oikarinen at qt.io
Thu Apr 4 15:35:03 CEST 2019
qt-labs/qtshadertools has been created.
On 3.4.2019 20.42, Lars Knoll wrote:
> Thanks for the update Laszlo. This is really important work towards Qt 6, and I
> can recommend everybody that has an interest in the graphics stack for Qt to
> have a look.
> And I support the creation of the qtshadertools repo. Gerrit admins, could you
> please the qt-labs repo for Laszlo?
>> On 2 Apr 2019, at 15:14, Laszlo Agocs <laszlo.agocs at qt.io
>> <mailto:laszlo.agocs at qt.io>> wrote:
>> Hi all,
>> First, a qt-labs repository request:
>> Repo name: qtshadertools
>> Name: Qt Shader Tools
>> Responsible person: me
>> Purpose: will importhttps://git.qt.io/laagocs/qtshadertoolshere. This is an
>> experimental Qt module providing APIs and a host tool to perform graphics and
>> compute shader conditioning for the upcoming Qt graphics abstraction layer.
>> While it is expected to evolve into a proper Qt module in Qt 6, the intention
>> is to keep it as a qt-labs project for Qt 5.x, mainly in order to avoid
>> prematurely importing larger 3rd party dependencies.
>> Second, I believe the request above demands a few words about the current
>> status regarding the evolution of the accelerated graphics stack in Qt.
>> Short version:
>> - Graphics and shader stack evolution is on-going.
>> - A very early preview of Qt Quick for Vulkan, Metal, and D3D11 may come
>> already in Qt 5.14, then evolve in 5.15 and beyond, with 6.0 as its final
>> - Qt Quick is just one piece in the puzzle. More about the others at some
>> other time.
>> Long version:
>> As discussed athttps://wiki.qt.io/QtCS2018_Graphics_Vision_2020Qt 6 will do
>> away with the hard OpenGL dependency in most, if not all, of its modules. This
>> is achieved via a small abstraction layer, currently called the Qt Rendering
>> Hardware Interface, with backends for Vulkan, Metal, Direct 3D 11, and OpenGL
>> (ES) 2.x(+ some 3.x extensions) at the moment. Shader code needs additional
>> solutions: graphics shaders in Qt itself, and eventually also in applications
>> (custom Qt Quick materials, ShaderEffect, etc.), are expected to be written in
>> a single language regardless of the platform and graphics API the applications
>> will run on. Hence the above mentioned Shader Tools module.
>> In (a not fully up-to-date but conceptually correct)
>> Qt Quick, the OpenGL paint engine of QPainter, and various other components
>> are expected to migrate to this stack in Qt 6, removing direct OpenGL usage.
>> (to be clear, applications should still be able to do OpenGL/Vulkan/Metal/etc.
>> rendering directly in the future as well, just like they can resort to direct
>> OpenGL usage today via QSGRenderNode or QQuickFramebufferObject or the
>> QQuickWindow under/overlay signals, but then they get tied to running with a
>> given rhi backend, and so graphics API; therefore, this is not an option for
>> Qt itself, at least when it comes to the essential Qt modules)
>> This is a long journey, possibly with numerous road bumps (or blocks, even) on
>> the way. Therefore, the intention is to provide some of the components of the
>> new stack as tech previews already in the Qt 5.x time frame, in order to make
>> it easier to iterate, discover problems, and get feedback.
>> As a first step, it is likely that in Qt 5.14 we can already include the some
>> of the Qt Quick work as an early preview. In practice this would mean that
>> (suitable) Qt Quick applications could opt-in to the new RHI-based rendering
>> path (currently this is done by simply setting an environment variable), thus
>> switching from OpenGL to D3D11, Vulkan or Metal, transparently to the application.
>> This involves the following pieces:
>> 1. Most the RHI is to be imported (mostly) as private APIs. This is
>> whathttps://codereview.qt-project.org/#/c/256713/is. (basically a private-ized
>> version ofhttps://git.qt.io/laagocs/qtrhiwith a bunch of changes on top)
>> It is not unlikely that QRhi & co. becomes a public API at some point in Qt
>> 6.x, but we cannot yet commit to having them as public yet. While we believe
>> this already provides sufficient foundations for Qt Quick, QPainter, and Qt 3D
>> Studio, it will evolve and change over time as necessary so no API guarantees
>> can be given.
>> BTW, (slightly outdated) sets of the generated documentation of qtrhi and
>> qtshadertools are available
>> 2. The shader conditioning tools will not be taken into Qt 5.x, as explained
>> above. When it comes to the Qt Quick scenegraph's built-in materials
>> (QSGVertexColorMaterial and friends), they will come with the necessary
>> pre-processed shaders so this is not a problem for typical Quick items.
>> Developers wishing to experiment with ShaderEffects or custom QSGMaterials on
>> top of the RHI will need to check out and build this module themselves for now.
>> 3. The Qt Quick port will move to the wip/scenegraphng branch of qtdeclarative
>> soon, from there we can merge to dev eventually. For now this still lives
>> athttps://git.qt.io/laagocs/qtgreyhound(and is heavily work in progress).
>> Unlike earlier attempts, such as the D3D12 backend introduced in Qt 5.8, the
>> RHI port is not merely a new scenegraph backend (plugin) - rather, it is the
>> fully featured, default OpenGL rendering path that is getting extended and
>> massaged into being able to operate with QRhi instead of calling glWhatever()
>> directly (when the application opted in for this; changing or removing
>> anything on the gl* code path is Qt 6 material). This way all the scenegraph
>> goodies like the batching renderer, texture atlasing, distance field based
>> text rendering, and the ability to do custom materials will be available.
>> All this comes with the disclaimer that this, if materializes, is going to be
>> an early preview, and some Qt Quick features will most certainly not yet be
>> available. So not intended for production use.
>> Best regards,
>> Development mailing list
>> Development at qt-project.org <mailto:Development at qt-project.org>
> Gerrit-admin mailing list
> Gerrit-admin at qt-project.org
Senior Software Engineer
The Qt Company
90590, Oulu, Finland
kari.oikarinen at qt.io
+358 50 5281010
More information about the Development