Qt Contributor Summit 2019 - QtGui RHI 3D

== Qt 3D on QRhi?

• Recommendation: Do not worry about some things not supported, start with a proof of concept.
• Triangle -> mesh -> materials etc.
• For shaders, either use the offline approach Qt Quick is using (run qsb manually to generate .qsb files) or just pull in qtshadertools at runtime and use QShaderBaker. (licensing, special platforms, etc. are not an issue for a PoC)
• Extending rendering with native Vulkan/GL/Metal/D3D calls: possible, see Qt Quick (underlay, overlay, etc.). QRhiCommandBuffer::beginExternal(), endExternal(). Query native objects via nativeHandles(). (on Vulkan the command buffer returned from QRhiCommandBuffer::nativeHandles() between a begin-endExternal() is a secondary command buffer inheriting the renderpass).

== Contributing to QRhi

• Backends. Already 4, 5 with null, may grow to 6 or 7 in the future. Any new stuff should be implemented and tested for all of them.
• Can use feature flags (isFeatureSupported) in some cases, but be conservative.
• Add manual tests (qtbase/tests/manual/rhi) following the pattern there so that anyone can try out the new stuff on all the supported platforms.
• Documentation. QRhi has it even though private API!

== OpenGL strategy (desktop vs. ES, core vs. non-core)

• Same as before. ES 2.0 as baseline, use some ES 3.0 and 3.1 stuff when available (multisample renderbuffer, compute), but limit. Must be able to function in core profiles as well.

== Default platforms

In 5.14 QSG_RHI=1 (without setting QSG_RHI_BACKEND) does this in Qt Quick:

• Windows: D3D11
• macOS: Metal
• other: OpenGL

Vulkan is only used when explicitly specified.

This is in Qt Quick's scope, QRhi does not have any such logic, up to the client to say what it wants.

Quick: Maybe think about probing (try something first, if failed to initialize, try something else).

== Vulkan on Embedded without a windowing system?

We'll see when we have some board with a software stack where this is a thing.

== How to start with QRhi

• Depends what your purpose is (what do you want to implement with it)

Paul describes his experience with doing the QRhi-based paint engine (QPainter backend):

• Read the documentation. The manually generated snapshot at alpqr.github.io is out of date but still useful. We will absolutely want to continue having docs, even though it's a private API for now.

• Played with manual tests.

• Did own "manual tests", to try out things that will be needed later on.

== Tools

• RenderDoc very useful
• validation/debug layer on Vulkan and D3D. Make sure it works and opt-in with the flag in QRhi (manual tests do this always, for Qt Quick one can set QSG_RHI_DEBUG_LAYER=1)
• bad experiences with Vulkan (NVIDIA) on Linux: make a mistake - graphics locks up
• good experiences with Windows (Vulkan, D3D, OpenGL can all be tested and developed there, NVIDIA is stable)

== CI

• In addition to the manual tests, an autotest exists as well.
• Already exercises rendering. To be extended later on.
• It tries to execise all backends that succeed to initialize. But only OpenGL and D3D11(?) are available in the VMs in practice. Did some tests for Swiftshader: is its Vulkan implementation usable? Did not work very well a few weeks ago. But this could be a good solution (deploy DLL into a Windows CI config., and run on Vulkan with that)

Lancelot. Runs on real machines and devices. Have RHI-enabled Qt Quick runs?

Null backend allows testing the backend interface.

== HDR

• We do have simple sRGB texture and swapchain flags, probably not needed in practice.
• QImage now has metadata for colorspaces. Use shaders to do something with it.
• May be more relevant in Qt Quick 3D context.

== Shader/material graphs

• Qt3D approach may not be what we want. Rather: true C++ graph.

== Action points

Check with doc team if possible to have docs generated and published for private and semi-private APIs (QPA, QRhi, etc.)