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

[Mike Krus]

Hi Laszlo,

thanks for all this updated information.

> On 2 Apr 2019, at 14:14, Laszlo Agocs <laszlo.agocs at qt.io> wrote:
> 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.
looks like there's interesting things in your own repository. It would be a good addition to Qt6 tool set. It would also be nice to think of it in relation to the shader generator that was contributed to QtBase. While they are very different technologies, they do have some overlapping goals so might make sense to move them closer in qt6.

> 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.
While the effort being put in Qt Quick is important and strategic, do you have have an idea of how you want the rest qt’s rendering stacks to evolve? How does this impact QDeclarativeWidget for example? Or more importantly (although I may be partial), Qt 3D?

All the integrations of the various rendering tool chains currently rely on capturing the output of one stack in a buffer and using that in the other stack. Surely Qt6 can do better than that?

Since Qt 3D Studio now contains, for lack of a better word, a fork of much of Qt 3D, do you have ideas for that? And plans to integrate the work into main line Qt 3D?

Thanks again so sharing your ongoing work,


Mike


> 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# and https://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 at https://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
> https://lists.qt-project.org/listinfo/development

—
Mike Krus | mike.krus at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44 1625 809908   Mobile +44 7833 491941
KDAB - The Qt Experts, C++, OpenGL Experts