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.ag...@qt.io >> <mailto:laszlo.ag...@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@qt-project.org <mailto:Development@qt-project.org> >> https://lists.qt-project.org/listinfo/development > > > _______________________________________________ > Gerrit-admin mailing list > gerrit-ad...@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.oikari...@qt.io +358 50 5281010 http://qt.io --- _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development