QQuickGraphicsConfiguration Class

Detaillierte Beschreibung

Die Klasse QQuickGraphicsConfiguration ist ein Container für Low-Level-Grafikeinstellungen, die beeinflussen können, wie die zugrundeliegende Grafik-API, wie z.B. Vulkan, durch den Qt Quick Szenengraphen initialisiert wird. Sie kann auch bestimmte Aspekte des Szenengraphen-Renderers steuern.

Konfiguration für externe Rendering-Engines oder XR-APIs

Beim Erstellen und Anzeigen einer QQuickWindow, die Vulkan zum Rendern verwendet, werden eine Vulkan-Instanz (VkInstance), ein physisches Gerät (VkPhysicalDevice), ein Gerät (VkDevice) und zugehörige Objekte (Warteschlangen, Pools) über die Vulkan-API initialisiert. Das Gleiche gilt in den meisten Fällen, wenn QQuickRenderControl verwendet wird, um das Rendering auf ein benutzerdefiniertes Rendering-Ziel, wie z. B. eine Textur, umzuleiten. Während die Konstruktion von QVulkanInstance dann unter der Kontrolle der Anwendung steht, erfolgt die Initialisierung anderer Grafikobjekte in QQuickRenderControl::initialize() auf die gleiche Weise wie bei einem On-Screen QQuickWindow.

Für die meisten Anwendungen ist keine zusätzliche Konfiguration erforderlich, da Qt Quick vernünftige Standardwerte für viele Low-Level-Grafikeinstellungen bietet, z. B. welche Geräteerweiterungen aktiviert werden sollen.

Dies wird jedoch nicht immer ausreichend sein. In fortgeschrittenen Anwendungsfällen, bei der Integration direkter Vulkan- oder anderer Grafik-API-Inhalte oder bei der Integration mit einer externen 3D- oder VR-Engine, wie z. B. OpenXR, wird die Anwendung ihre eigenen Einstellungen festlegen wollen, wenn es um Details geht, z. B. welche Geräteerweiterungen zu aktivieren sind.

Genau das ermöglicht diese Klasse. Sie ermöglicht beispielsweise die Angabe einer Liste von Geräteerweiterungen, die dann vom Szenegraphen bei der Verwendung von Vulkan oder von Grafik-APIs, auf die das Konzept anwendbar ist, übernommen wird. Wenn einige Konzepte nicht anwendbar sind, werden die entsprechenden Einstellungen einfach ignoriert.

Beispiele für Funktionen in dieser Kategorie sind setDeviceExtensions() und preferredInstanceExtensions(). Letztere ist nützlich, wenn die Anwendung ihre eigene QVulkanInstance verwaltet, die dann über QWindow::setVulkanInstance() mit der QQuickWindow verknüpft wird.

Qt Quick Konfiguration des Scene Graph Renderers

Eine weitere Klasse von Einstellungen bezieht sich auf den Renderer des Szenengraphen. In manchen Fällen möchten Anwendungen ein bestimmtes Verhalten steuern, wie zum Beispiel die Verwendung des Tiefenpuffers beim Rendern von 2D-Inhalten. In Qt 5 waren solche Einstellungen entweder überhaupt nicht steuerbar oder wurden über Umgebungsvariablen verwaltet. In Qt 6 bietet QQuickGraphicsConfiguration ein neues Zuhause für diese Einstellungen, während die Unterstützung für die alten Umgebungsvariablen beibehalten wird, wo dies möglich ist.

Ein Beispiel aus dieser Kategorie ist setDepthBufferFor2D().

Grafikgeräte-Konfiguration

Wenn die Grafikinstanz und die Geräteobjekte (z. B. die VkInstance und das VkDevice bei Vulkan, das ID3D11Device bei Direct 3D usw.) von Qt bei der Initialisierung eines QQuickWindow erstellt werden, gibt es Einstellungen, die Anwendungen oder Bibliotheken unter bestimmten Umständen kontrollieren möchten.

Vor Qt 6.5 waren einige dieser Einstellungen über Umgebungsvariablen steuerbar. Zum Beispiel QSG_RHI_DEBUG_LAYER oder QSG_RHI_PREFER_SOFTWARE_RENDERER. Diese sind immer noch verfügbar und funktionieren wie zuvor. QQuickGraphicsConfiguration bietet zusätzlich C++ Setter.

Zum Beispiel öffnet die folgende main()-Funktion eine QQuickView und gibt dabei an, dass die Vulkan-Validierung oder die Direct3D-Debug-Schicht aktiviert sein soll:

int main(int argc, char *argv[])
{
    QGuiApplication app(argc, argv);

    QQuickGraphicsConfiguration config;
    config.setDebugLayer(true);

    QQuickView *view = new QQuickView;
    view->setGraphicsConfiguration(config);

    view->setSource(QUrl::fromLocalFile("myqmlfile.qml"));
    view->show();
    return app.exec();
}

Pipeline-Cache speichern und laden

Qt Quick unterstützt das Speichern des Grafik-/Rechen-Pipeline-Caches auf der Festplatte und das erneute Laden in späteren Durchläufen einer Anwendung. Was genau der Pipeline-Cache enthält, wie Lookups funktionieren und was genau beschleunigt wird, hängt vom Qt RHI Backend und der zugrunde liegenden nativen Grafik-API ab, die zur Laufzeit verwendet wird. Verschiedene 3D-APIs haben unterschiedliche Konzepte, wenn es um Shader, Programme und Pipeline-Statusobjekte und entsprechende Cache-Mechanismen geht. Das High-Level-Pipeline-Cache-Konzept hier abstrahiert all dies auf das Speichern und Abrufen eines einzelnen binären Blob in und aus einer Datei.

Wenn derselbe Shader-Programm- und/oder Pipeline-Zustand wie in einem früheren Lauf angetroffen wird, werden wahrscheinlich eine Reihe von Operationen übersprungen, was zu schnelleren Shader- und Materialinitialisierungszeiten führt, was bedeutet, dass der Start schneller erfolgen kann und Verzögerungen und "Ruckler" während des Renderns reduziert oder vermieden werden können.

Wenn Sie mit einer Grafik-API arbeiten, bei der das Abrufen und erneute Laden des Pipeline-Caches (oder von Shader-/Programmbinärdateien) nicht möglich ist oder nicht unterstützt wird, hat der Versuch, eine Datei zum Speichern und Laden des Caches zu verwenden, keine Auswirkungen.

Es gibt Ausnahmen von dem Problem der Treiberabhängigkeit, insbesondere Direct 3D 11, wo der "Pipeline-Cache" nur zum Speichern der Ergebnisse der HLSL->DXBC-Kompilierung zur Laufzeit verwendet wird und daher geräte- und herstellerunabhängig ist.

In einigen Fällen kann es wünschenswert sein, den allerersten Lauf der Anwendung zu verbessern, indem der Cache "vorgesättigt" wird. Dies ist möglich, indem man die Cache-Datei, die bei einem früheren Lauf gespeichert wurde, versendet und auf einem anderen Rechner oder Gerät referenziert. Auf diese Weise stehen der Anwendung oder dem Gerät bereits beim ersten Lauf die Shader-Programme/Pipelines zur Verfügung, die bei dem Lauf, bei dem die Cache-Datei gespeichert wurde, bereits verwendet wurden. Das Versenden und Bereitstellen der Cache-Datei ist nur dann sinnvoll, wenn das Gerät und die Grafiktreiber auf dem Zielsystem identisch sind. Andernfalls wird die Cache-Datei ignoriert, wenn die Geräte- oder Treiberversion nicht übereinstimmt (mit Ausnahme von D3D11), wie oben beschrieben.

Sobald der Cache-Inhalt geladen ist, besteht immer noch die Möglichkeit, dass die Anwendung Grafik- und Berechnungspipelines erstellt, die bei früheren Durchläufen nicht angetroffen wurden. In diesem Fall wird der Cache erweitert und die Pipelines/Shader-Programme werden hinzugefügt. Wenn die Anwendung den Inhalt auch speichert (vielleicht sogar in der gleichen Datei), werden sowohl die alten als auch die neuen Pipelines gespeichert. Das Laden aus und Speichern in dieselbe Datei bei jedem Lauf ermöglicht einen ständig wachsenden Cache, der alle angetroffenen Pipelines und Shader-Programme speichert.

In der Praxis kann man davon ausgehen, dass der Qt-Pipeline-Cache den folgenden nativen Grafik-API-Features entspricht:

• Vulkan - VkPipelineCache - Das Speichern des Pipeline-Caches speichert effektiv den Blob, der von vkGetPipelineCacheData abgerufen wird, mit zusätzlichen Metadaten, um das Gerät und den Treiber sicher zu identifizieren, da der Pipeline-Cache-Blob vom genauen Treiber abhängig ist.
• Metal - MTLBinaryArchive - Wenn das Speichern des Pipeline-Caches aktiviert ist, speichert Qt alle angetroffenen Render- und Compute-Pipelines in einem MTLBinaryArchive. Das Speichern des Pipeline-Caches speichert den aus dem Archiv abgerufenen Blob mit zusätzlichen Metadaten, um das Gerät zu identifizieren. Hinweis: Derzeit ist die Verwendung von MTLBinaryArchive unter macOS und iOS aufgrund verschiedener Probleme bei einigen Hardware- und Betriebssystemversionen deaktiviert.
• OpenGL - Es gibt kein natives Konzept von Pipelines, der "Pipeline-Cache" speichert eine Sammlung von Programm-Binaries, die über glGetProgramBinary abgerufen werden. Die Programm-Binärdateien werden in einen einzigen Blob gepackt, mit zusätzlichen Metadaten zur Identifizierung des Geräts, des Treibers und seiner Version, von dem die Binärdateien abgerufen wurden. Das dauerhafte Zwischenspeichern von Programm-Binärdateien ist in Qt nicht neu: Qt 5 hatte bereits eine ähnliche Funktionalität in QOpenGLShaderProgram, siehe z.B. addCacheableShaderFromSourceCode(). In der Tat ist dieser Mechanismus auch in Qt 6 immer aktiv, wenn Qt Quick mit OpenGL verwendet wird. Wenn man jedoch die neue, von der Grafik-API unabhängige Pipeline-Cache-Abstraktion verwendet, die hier zur Verfügung gestellt wird, wird der binäre Programm-Cache aus der Qt-5-Ära automatisch deaktiviert, da derselbe Inhalt nun in den "Pipeline-Cache" verpackt wird.
• Direct 3D 11 - Es gibt kein natives Konzept für Pipelines oder das Abrufen von Binärdateien für die zweite Phase der Kompilierung (in der der herstellerunabhängige, zwischengeschaltete Bytecode in den gerätespezifischen Befehlssatz kompiliert wird). Die Treiber verwenden in der Regel ihr eigenes Caching-System auf dieser Ebene. Stattdessen wird der Qt Quick "Pipeline-Cache" verwendet, um Fälle zu beschleunigen, in denen die Shader HLSL-Quellcode enthalten, der zunächst in das Zwischen-Bytecode-Format kompiliert werden muss. Dies kann in Anwendungen und Bibliotheken, die Shader-Code zur Laufzeit kompilieren, zu erheblichen Leistungsverbesserungen führen, da in nachfolgenden Läufen die potenziell teuren, nicht zwischengespeicherten Aufrufe von D3DCompile() vermieden werden können, wenn der Bytecode für den angetroffenen HLSL-Shader bereits verfügbar ist. Ein gutes Beispiel ist Qt Quick 3D, wo die zur Laufzeit generierten Shader für Materialien den Umgang mit HLSL-Quellcode erfordern. Das Speichern und erneute Laden des Qt Quick Pipeline-Caches kann daher in Szenen, die ein oder mehrere View3D Elemente enthalten, erhebliche Verbesserungen bringen. Ein Gegenbeispiel könnte Qt Quick selbst sein: Da die meisten eingebauten Shader für 2D-Inhalte mit DirectX-Bytecode ausgeliefert werden, der zur Erstellungszeit generiert wird, wird der Cache keine wesentlichen Verbesserungen bringen.

All dies ist unabhängig von der Shader-Verarbeitung, die durch das Qt Shader Tools Modul und seine Befehlszeilen-Tools wie qsb durchgeführt wird. Nehmen wir als Beispiel Vulkan. Es ist gut, den Vulkan-kompatiblen GLSL-Quellcode entweder zur Offline- oder zur Build-Zeit (direkt über qsb oder CMake) nach SPIR-V zu kompilieren, da die teure Kompilierung aus dem Quellcode zur Laufzeit vermieden wird. SPIR-V ist jedoch ein herstellerunabhängiges Zwischenformat. Zur Laufzeit, beim Aufbau von Grafik- oder Rechenpipelines, findet wahrscheinlich eine weitere Kompilierungsrunde statt, diesmal vom Zwischenformat in den herstellerspezifischen Befehlssatz der GPU (und dies kann auch von bestimmten Zuständen in der Grafikpipeline und den Render-Targets abhängig sein). Der Pipeline-Cache hilft bei dieser letzten Phase.

Rufen Sie setPipelineCacheSaveFile() und setPipelineCacheLoadFile() auf, um zu steuern, in welche Dateien QQuickWindow oder QQuickView den Pipeline-Cache speichert bzw. aus ihnen lädt.

Um einen Eindruck von den Auswirkungen der Aktivierung der Festplattenspeicherung des Pipeline-Caches zu bekommen, aktivieren Sie die wichtigsten Szenegrafik- und Grafikprotokolle entweder über die Umgebungsvariable QSG_INFO=1 oder die beiden Protokollierungskategorien qt.scenegraph.general und qt.rhi.general. Beim Schließen von QQuickWindow gibt es eine Log-Meldung wie die folgende:

Total time spent on pipeline creation during the lifetime of the QRhi was 123 ms

Dies gibt eine ungefähre Vorstellung davon, wie viel Zeit während der Lebensdauer des Fensters für die Erstellung von Grafiken und Berechnungspipelines aufgewendet wurde (was verschiedene Stufen der Shader-Kompilierung beinhalten kann).

Wenn das Laden aus einer Pipeline-Cache-Datei aktiviert ist, wird dies mit einer Meldung bestätigt:

Attempting to seed pipeline cache from 'filename'

Um zu überprüfen, ob das Speichern des Caches erfolgreich aktiviert wurde, suchen Sie nach einer Meldung wie dieser:

Writing pipeline cache contents to 'filename'

Der automatische Pipeline-Cache

Wenn kein Dateiname für das Speichern und Laden angegeben wird, wird die automatische Pipeline-Caching-Strategie verwendet. Dabei werden die Daten im anwendungsspezifischen Cache-Speicher des Systems gespeichert (QStandardPaths::CacheLocation).

Dies kann auf eine der folgenden Arten deaktiviert werden:

• Setzen Sie das Anwendungsattribut Qt::AA_DisableShaderDiskCache. (schaltet die automatische Speicherung vollständig aus)
• Setzen Sie die Umgebungsvariable QT_DISABLE_SHADER_DISK_CACHE auf einen Wert ungleich Null. (schaltet die automatische Speicherung vollständig aus)
• Setzen Sie die Umgebungsvariable QSG_RHI_DISABLE_SHADER_DISK_CACHE auf einen Wert ungleich Null. (schaltet die automatische Speicherung vollständig aus)
• Rufen Sie setAutomaticPiplineCache() auf und setzen Sie das Argument enable auf false. (schaltet die automatische Speicherung vollständig aus)
• Setzen eines Dateinamens durch Aufruf von setPipelineCacheLoadFile(). (deaktiviert nur das Laden aus dem automatischen Speicher und bevorzugt stattdessen die angegebene Datei)
• Setzen eines Dateinamens durch Aufruf von setPipelineCacheSaveFile(). (deaktiviert nur das Schreiben in den automatischen Speicher, stattdessen wird die angegebene Datei bevorzugt)

Die ersten beiden sind existierende Mechanismen, die seit Qt 5.9 verwendet werden, um den Binärcache des OpenGL-Programms zu kontrollieren. Aus Gründen der Kompatibilität und Vertrautheit werden das gleiche Attribut und die gleiche Umgebungsvariable auch für den erweiterten Pipeline-Cache von Qt 6 unterstützt.

Der automatische Pipeline-Cache verwendet eine einzige Datei pro Anwendung, aber eine andere für jedes RHI-Backend (Grafik-API). Das bedeutet, dass ein Wechsel zu einer anderen Grafik-API beim nächsten Durchlauf der Anwendung nicht dazu führt, dass der im vorherigen Durchlauf erzeugte Pipeline-Cache verloren geht. Anwendungen mit mehreren QQuickWindow Instanzen, die gleichzeitig angezeigt werden, profitieren jedoch möglicherweise nicht zu 100 % davon, da der automatische Cache nur die von jeweils einem RHI Objekt gesammelten Daten speichern kann. (und mit der Standard-Rendering-Schleife threaded hat jedes Fenster sein eigenes RHI, da das Rendering unabhängig auf dedizierten Threads läuft). Um den Disk-Cache in Anwendungen mit mehreren Fenstern voll auszunutzen, sollten Sie den Dateinamen explizit pro Fenster über setPipelineCacheSaveFile() festlegen.