Jetzt, da die erste Beta-Version von Qt 5.14 näher rückt, ist es an der Zeit, über eines der wichtigsten neuen Features zu sprechen. Es ist schwierig, alle Details zu den Verbesserungen des Grafikstacks und dem Weg zu Qt 6 in einem Artikel zu behandeln, daher werden Teil 1 und 2 den Hintergrund behandeln und einen genaueren Blick darauf werfen, was mit Version 5.14 ausgeliefert wird. Später, in einer anderen Artikelserie, werden wir uns mit den technischen Details und zukünftigen Richtungen befassen.
Auf der Seite mit den neuen Funktionen von 5.14 wird Folgendes erwähnt: * Die erste Vorschau des Grafik-API-unabhängigen Szenen-Renderers wurde als optionale Funktion hinzugefügt. Dadurch können Sie entsprechende Qt Quick-Anwendungen auf Vulkan, Metal oder Direct3D 11 anstelle von OpenGL* ausführen.
Was bedeutet das in der Praxis?
Eines der Hauptziele von Qt 6 ist es, von der direkten Verwendung von OpenGL an den meisten Stellen in Qt wegzukommen und mit geeigneten Abstraktionen eine größere Vielfalt von Grafik-APIs wie Vulkan, Metal und Direct3D zu ermöglichen. Natürlich bleibt OpenGL (und OpenGL ES) eine Option. Die Hauptmotivation dafür ist nicht die Verbesserung der Leistung, sondern die Bereitstellung von Qt Everywhere in Zukunft, auch auf Plattformen und Geräten, auf denen OpenGL entweder nicht verfügbar oder unerwünscht ist. Gleichzeitig kann die Möglichkeit, moderne Low-Level-APIs zu verwenden, auch Möglichkeiten eröffnen, wenn es um Leistungsverbesserungen (z. B. geringere CPU-Auslastung durch geringeren API-Overhead) und neue Arbeitsweisen in Rendering-Engines für Qt Quick und andere Module geht wie das kürzlich angekündigte Qt Quick 3D.
Auch die Fähigkeit, Benutzeroberflächen mit dem zugrunde liegenden Framework der am meisten unterstützten Grafik-API zu rendern, ist eine großartige Neuigkeit für Anwendungen, die ihr eigenes natives 2D- oder 3D-Grafik-Rendering durchführen, wenn sie Qt zum Rendern der Benutzeroberfläche verwenden. In einem solchen Fall hat Qt oft nicht das Sagen, wenn es um die Entscheidung geht, welche Grafik-API verwendet werden soll. Wenn beispielsweise eine Desktop-Anwendung auf macOS Metal für ihre eigenen 3D-Inhalte verwenden möchte und sich dabei auf Qt Quick verlässt, um 2D-UI-Elemente zu rendern, dann ist es sehr hilfreich, wenn Qt Quick auch über Metal rendert. Das wird denen bekannt vorkommen, die die Grafikentwicklung in Qt 5.x verfolgt haben. Konzeptionell unterscheidet sich dies nicht von der Einführung der Unterstützung für die Arbeit in OpenGL-Kernprofilkontexten im Qt Quick-Renderer. Qt Quick selbst benötigt dies nicht, aber um die Integration von externem Rendering-Code im Zusammenhang mit Kernprofilfunktionen zu ermöglichen, muss Qt Quick darüber Bescheid wissen und damit umgehen können. In diesem Sinne ist die Geschichte also eine natürliche Erweiterung dessen, was in Qt 5 war, und wird nun erweitert, um Nicht-OpenGL-Grafik-APIs abzudecken.
All dies kann zwei offensichtliche Fragen aufwerfen:
• Inwiefern gilt dies für Qt 5.x? Ist das nicht das ganze Qt 6-Zeug?
• Warum nicht einfach
<Name einer Grafik-API-Übersetzungslösung> (
Also, was ist in Qt 5.14?
Eine vollständige Überarbeitung der Grafikbits an allen (oder zumindest den meisten) Stellen in Qt ist in der Tat für Qt 6 gedacht. Die Arbeit an 5.x jedoch einzustellen und zu versuchen, alles in einem Rutsch zu erfinden, zu entwickeln und umzugestalten, in der Hoffnung, dass dies der Fall ist Alles wird gut ist in der Praxis nicht sehr attraktiv. Wie die Qt-Entwickler gesagt haben (und immer noch sagen), ist die erste Iteration einer API wahrscheinlich suboptimal. Stattdessen verwenden die Qt-Entwickler einen entwickelten parallelen Ansatz , der sich auf eine bestimmte Benutzeroberflächentechnologie in Qt, Qt Quick, konzentriert.
Qt 5.14 wird voraussichtlich mit einer Vorschau auf den neuen Rendering-Pfad von Qt Quick ausgeliefert. Standardmäßig ist dies inaktiv und es gibt keine sichtbare Änderung für Anwendungen, die intern denselben direkten OpenGL-basierten Codepfad durchlaufen wie in früheren Versionen. Wer den neuen Ansatz aber ausprobieren möchte, kann sich anmelden: entweder durch Setzen einer Umgebungsvariable oder durch Anfordern über die C++-API in main().
Wenn wir uns einen Schnappschuss der Qt 5.14-Dokumentation ansehen, finden wir Folgendes:
Nicht alle Anwendungen funktionieren sofort, wenn sie mit installiertem QSG_RHI ausgeführt werden. Benutzerdefinierte QQuickItem-Implementierungen mit Szenendiagrammknoten, die direkte OpenGL-Aufrufe durchführen oder GLSL-Shader-Code in benutzerdefinierten Materialien enthalten, funktionieren nicht, wenn RHI-basiertes Rendering aktiviert ist. Gleiches gilt für ShaderEffect-Elemente mit GLSL-Quellcode. Lösungen zum Erstellen von benutzerdefinierten Materialien und Effekten auf moderne Weise sind größtenteils bereits vorhanden, erfordern jedoch eine entsprechende Anwendungsmigration. Frühe Benutzer können bereits in 5.14 und 5.15 damit experimentieren, aber eine breite Akzeptanz und Migration wird natürlich nicht vor Qt 6.0 erwartet. Andererseits funktionieren viele bestehende QML-Anwendungen wahrscheinlich auch dann, wenn die zugrunde liegende Rendering-Engine durch eine völlig andere API wie Vulkan oder Metal geleitet wird.
Warum nicht Ebene XYZ übersetzen?
Zunächst ist es wichtig anzumerken, dass die Möglichkeit zur Verwendung von Shader-Übersetzungs-APIs und -Layern wie MoltenVK, MoltenGL, ANGLE, Zink und anderen weiterhin besteht, auch wenn sie nicht immer standardmäßig verfügbar sind. Mit MoltenVK können Sie beispielsweise auch Qt Quick-Benutzeroberflächen über Vulkan auf macOS anzeigen. Wenn eine Qt Quick-App nur Vulkan verwenden und dennoch auf macOS laufen möchte, ist MoltenVK eine Option (solange ein ordnungsgemäß konfigurierter Build von Qt bereitgestellt wird, ist MoltenVK auf den Systemen der Benutzer verfügbar usw.).
Eine solche Übersetzungsschicht zu einer erforderlichen Abhängigkeit zu machen und sie dann mit Qt zu aktivieren und bereitzustellen, ist eine ganz andere Geschichte.
Natürlich ist es nicht ideal, Qt Everywhere in Qt Only Where External Dependencies Allow (Qt Only Where External Dependencies Allow) zu ändern.
Qt zielt auf mehr Plattformen und Umgebungen ab, als allgemein angenommen wird. Es kann sich nur auf obligatorische Abhängigkeiten von Drittanbietern verlassen, die in "exotischen" Umgebungen kompiliert und funktionieren und bei besonderen Anforderungen leicht anzupassen sind (z seltene Notwendigkeit, sich an private Teile anzupassen, oder manchmal die Notwendigkeit, vielleicht, je nach Anbieter, auf nicht standardmäßige Weise mit verschiedenen Grafik- oder Kompositions-APIs zu interagieren, von denen Sie dachten, dass sie schon lange tot sind, etc. All dies erfordert Flexibilität und Anpassung an jede Ebene der Qt-Rendering-Stack).
Die Übersetzung zwischen Schattierungssprachen (oder Zwischenformaten) zur Laufzeit ist nicht gerade ideal. Die Shader-Pipeline in Qt 6 soll sich voraussichtlich mehr auf das Arbeiten im Offline-Modus oder spätestens während des Anwendungs-Builds konzentrieren. Wenn sich die Übersetzungsschicht in der Mitte befindet und die Realität verbirgt (welche API, welche Sprache tatsächlich verwendet wird), werden diese Bemühungen in der Praxis schnell nutzlos, da es keine Möglichkeit gibt, Shader oder Bytecode für die wirklich zugrunde liegende API vorzubereiten oder einzufügen .
Einige der genannten Optionen sind aufgrund des aktuellen Stands der Realität nicht verhandelbar: OpenGL (ES) ist und bleibt auf absehbare Zeit das wichtigste Arbeitspferd auf vielen Geräten. Die direkte Verwendung einer einzelnen API könnte also bedeuten, dass die API OpenGL oder eine Übersetzungsschicht ist, die auf OpenGL abzielen kann (und auch für Low-End-Geräte recht effizient ist).
Fälle, in denen die Rendering-Engines von Qt mit benutzerdefiniertem, nativem Rendering-Code erweitert werden, funktionieren in der Regel am besten, wenn beide Parteien direkt dieselben APIs verwenden. Die Verwendung einer Übersetzungsschicht ist in dieser Hinsicht nicht immer blockierend, solange sie den Zugriff auf die zugrunde liegenden nativen Objekte ermöglichen (stellen Sie sich beispielsweise vor, wie die Interaktion zwischen Direct3D und Qt Quick durch EGL-Erweiterungen ermöglicht wird, wenn Qt 5 auf ANGLE ausgeführt wird Windows) und wenn dies der Fall ist, kann dies zu einem weiteren Problem führen, dem Sie sich stellen müssen.
Es gibt lizenzrechtliche Auswirkungen und Probleme. Denken Sie daran, dass Apache 2.0 nicht GPLv2-kompatibel ist. Auf kommerzielle Lösungen zu setzen, kommt sowieso nicht in Frage.
Erfahrungsgemäß (teilweise mit ANGLE und teilweise mit MoltenVK) war die Nutzung solcher Lösungen noch nie so einfach wie anfangs gewünscht. Irgendwann kann der Aufwand, der erforderlich ist, um alle Optionen am Laufen zu halten, zu groß werden. In diesem Fall sollte dieser Aufwand besser darauf verwendet werden, die Dinge direkt mit der nativen API "richtig" zu machen. Die inhärent plattformabhängige Natur einiger dieser Übersetzungslösungen ist auch alles andere als ideal, wenn man für jede Qt-Zielplattform eine andere verwenden muss, werden die Dinge schnell unhaltbar.
Anstatt sich also auf Low-Level-API-Übersetzer zu verlassen, definiert Qt seine eigene High-Level-Abstraktion für 3D-Grafiken (für den internen Gebrauch, derzeit nicht für Anwendungen verfügbar). Dies wird dann durch API-spezifische Backend-Implementierungen unterstützt, ein Muster, das von vielen Komponenten in Qt bekannt ist. In einigen Fällen ist das Backend nativ (Metal, D3D), während in einigen anderen ein Backend auf eine API, aber mehrere Plattformen abzielt (Vulkan, OpenGL). Ergänzt wird dies durch eine neue Shader-Steuerungspipeline, die auf mehreren Projekten von Drittanbietern wie glslang und SPIRV-Cross basiert. Weitere Einzelheiten zu all dem werden in den folgenden Artikeln besprochen.
Funktioniert es wirklich?
Schauen wir uns ein Beispiel an, nämlich die bekannte Demoanwendung Qt5 Cinematic Experience von QUIt Coding. Wir verwenden eine leicht modifizierte Version, die einige ShaderEffect-Elemente aktualisiert, damit sie mit beiden Qt Quick-Sollwert-Renderpfaden funktionieren.
Wenn die Anwendung normal mit QSG_INFO=1 gestartet wird, erhalten wir:
Wie die in den Debug-Ergebnissen gedruckten Protokolle zeigen, funktioniert dies in OpenGL auf einem Linux-Desktop:
qt.scenegraph.general: threaded render loop qt.scenegraph.general: Using sg animation driver qt.scenegraph.general: Animation Driver: using vsync: 16.95 ms qt.scenegraph.general: opengl texture atlas dimensions: 2048x1024 qt.scenegraph.general: GL_VENDOR: X.Org qt.scenegraph.general: GL_RENDERER: AMD Radeon (TM) R9 M360 (VERDE, DRM 3.23.0, 4.15.0-62-generic, LLVM 8.0.1) qt.scenegraph.general: GL_VERSION: 4.5 (Compatibility Profile) Mesa 19.2.0-devel (git-08f1cef 2019-07-25 bionic-oibaf-ppa) qt.scenegraph.general: GL_EXTENSIONS: ... qt.scenegraph.general: Max Texture Size: 16384 qt.scenegraph.general: Debug context: false
Wie ändert sich das, wenn wir QSG_RHI=1 setzen?
qt.scenegraph.general: Using QRhi with backend OpenGL graphics API debug/validation layers: 0 QRhi profiling and debug markers: 0 qt.scenegraph.general: threaded render loop qt.scenegraph.general: Using sg animation driver qt.scenegraph.general: Animation Driver: using vsync: 16.95 ms qt.rhi.general: Created OpenGL context QSurfaceFormat(version 4.5, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 0, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) qt.rhi.general: OpenGL VENDOR: X.Org RENDERER: AMD Radeon (TM) R9 M360 (VERDE, DRM 3.23.0, 4.15.0-62-generic, LLVM 8.0.1) VERSION: 4.5 (Compatibility Profile) Mesa 19.2.0-devel (git-08f1cef 2019-07-25 bionic-oibaf-ppa) qt.scenegraph.general: MSAA sample count for the swapchain is 1. Alpha channel requested = no. qt.scenegraph.general: rhi texture atlas dimensions: 2048x1024
Auf den ersten Blick nicht viel anders. Es scheint immer noch über OpenGL zu passieren. Allerdings gibt es intern keine direkte Verwendung von OpenGL und keine GLSL-Shader-Quellen mehr in der Qt-Quick-Szene. Stattdessen läuft das Rendern über QRhi, die Hardware-Rendering-Schnittstelle von Qt (im Moment eine private API im QtGui-Modul).
Jetzt setzen wir QSG_RHI_BACKEND=vulkan :
qt.scenegraph.general: Using QRhi with backend Vulkan graphics API debug/validation layers: 0 QRhi profiling and debug markers: 0 qt.scenegraph.general: threaded render loop qt.scenegraph.general: Using sg animation driver qt.scenegraph.general: Animation Driver: using vsync: 16.95 ms WARNING: radv is not a conformant vulkan implementation, testing use only. qt.rhi.general: Physical device 0: 'AMD RADV CAPE VERDE (LLVM 8.0.1)' 19.1.99 qt.rhi.general: using this physical device qt.rhi.general: queue family 0: flags=0xf count=1 qt.rhi.general: queue family 1: flags=0xe count=2 qt.rhi.general: 55 device extensions available qt.scenegraph.general: MSAA sample count for the swapchain is 1. Alpha channel requested = no. qt.scenegraph.general: rhi texture atlas dimensions: 2048x1024 qt.rhi.general: Creating new swapchain of 3 buffers, size 1280x720, presentation mode 2
Anscheinend geschieht das Rendern jetzt über Vulkan. Aber auch die exotischsten Features von Qt Quick, wie Textwiedergabe in einem Distanzfeld, Shader-Effekte und Partikel, sind wie erwartet vorhanden.
Das Ausführen der Anwendung in RenderDoc und das Erfassen eines Frames ergibt Folgendes. Qt Quick erstellt die Zustandsobjekte und Befehlspuffer der Vulkan-Pipeline, und der Shader-Code wird als SPIR-V-Bytecode bereitgestellt.
Der zweite Teil dieser Serie befasst sich mit dem, was Qt 5.14 für macOS und Windows zu bieten hat. Lassen Sie uns danach damit fortfahren, wie alles unter der Haube funktioniert und welche Auswirkungen es auf Anwendungen hat, die benutzerdefinierte Materialien und Effekte erfordern.
