[Development] Shadertools repo request and some words about state of graphics

Wed Apr 3 19:42:59 CEST 2019

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?

Cheers,
Lars

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 import https://git.qt.io/laagocs/qtshadertools here. 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 destination.

- Qt Quick is just one piece in the puzzle. More about the others at some other time.

Long version:

As discussed at https://wiki.qt.io/QtCS2018_Graphics_Vision_2020 Qt 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) picture: https://git.qt.io/laagocs/qtrhi/blob/1dd15d715399000707552b030357a74782d50f38/rhi2.png

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 what https://codereview.qt-project.org/#/c/256713/ is. (basically a private-ized version of https://git.qt.io/laagocs/qtrhi with 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 at https://alpqr.github.io/qtrhi/qtrhi-index.html# andhttps://alpqr.github.io/qtshadertools/qtshadertools-index.html#

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,
Laszlo

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190403/340c0197/attachment.html>