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

Thu Apr 4 15:35:03 CEST 2019

qt-labs/qtshadertools has been created.

-- 
Kari

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?
> 
> 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 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 
>> destination.
>> - 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) 
>> 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 
>> 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 
>> athttps://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
> 
> 
> _______________________________________________
> Gerrit-admin mailing list
> Gerrit-admin at qt-project.org
> https://lists.qt-project.org/listinfo/gerrit-admin
> 

-- 
---
Kari Oikarinen
Senior Software Engineer

The Qt Company
Elektroniikkatie 13
90590, Oulu, Finland
kari.oikarinen at qt.io
+358 50 5281010
http://qt.io
---