QQuickGraphicsConfiguration Class

Ausführliche Beschreibung

Die Klasse `QQuickGraphicsConfiguration` ist ein Container für Low-Level-Grafikeinstellungen, die Einfluss darauf haben können, wie die zugrunde liegende Grafik-API, wie z. B. Vulkan, durch den Szenenbaum von ` Qt Quick ` initialisiert wird. Sie kann außerdem bestimmte Aspekte des Szenenbaum-Renderers steuern.

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

Beim Erstellen und Anzeigen eines „ QQuickWindow “, das zum Rendern Vulkan 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 größtenteils auch, wenn „ QQuickRenderControl “ verwendet wird, um das Rendering in ein benutzerdefiniertes Renderziel, wie beispielsweise eine Textur, umzuleiten. Während die Erstellung von „ QVulkanInstance “ dann unter der Kontrolle der Anwendung steht, erfolgt die Initialisierung anderer Grafikobjekte in „ QQuickRenderControl::initialize()“ auf dieselbe Weise wie bei einem Bildschirm- QQuickWindow.

Für die meisten Anwendungen ist keine zusätzliche Konfiguration erforderlich, da Qt Quick für viele Low-Level-Grafikeinstellungen sinnvolle Standardwerte bereitstellt, beispielsweise welche Geräteerweiterungen aktiviert werden sollen.

Dies reicht jedoch nicht immer aus. In fortgeschrittenen Anwendungsfällen, bei der Integration von direktem Vulkan- oder anderem Grafik-API-Inhalt oder bei der Anbindung an eine externe 3D- oder VR-Engine wie beispielsweise OpenXR, möchte die Anwendung ihre eigenen Einstellungen für Details festlegen, beispielsweise welche Geräteerweiterungen aktiviert werden sollen.

Genau das ermöglicht diese Klasse. Sie erlaubt es beispielsweise, eine Liste von Geräteerweiterungen anzugeben, die dann bei der Verwendung von Vulkan oder anderen Grafik-APIs, bei denen das Konzept anwendbar ist, vom Szenengraphen übernommen wird. Wo bestimmte 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 ihren eigenen „ QVulkanInstance “ verwaltet, der dann über „ QWindow::setVulkanInstance()“ mit dem „ QQuickWindow “ verknüpft wird.

Qt Quick Konfiguration des Szenengraph-Renderers

Eine weitere Klasse von Einstellungen bezieht sich auf den Renderer des Szenengraphen. In manchen Fällen möchten Anwendungen möglicherweise bestimmte Verhaltensweisen steuern, wie beispielsweise die Verwendung des Tiefenpuffers beim Rendern von 2D-Inhalten. In Qt 5 waren solche Einstellungen entweder gar nicht steuerbar oder wurden über Umgebungsvariablen verwaltet. In Qt 6 bietet `QQuickGraphicsConfiguration` einen neuen Speicherort für diese Einstellungen, wobei die Unterstützung für die bisherigen Umgebungsvariablen, soweit zutreffend, beibehalten wird.

Ein Beispiel aus dieser Kategorie ist ` setDepthBufferFor2D()`.

Konfiguration von Grafikgeräten

Wenn die Grafikinstanz und die Geräteobjekte (z. B. `VkInstance` und `VkDevice` bei Vulkan, `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 steuern möchten.

Vor Qt 6.5 konnten einige dieser Einstellungen über Umgebungsvariablen gesteuert werden. Zum Beispiel „ QSG_RHI_DEBUG_LAYER “ oder „ QSG_RHI_PREFER_SOFTWARE_RENDERER “. Diese sind weiterhin verfügbar und funktionieren wie bisher. „QQuickGraphicsConfiguration“ stellt zusätzlich C++-Setter zur Verfügung.

Die folgende `main()`-Funktion öffnet beispielsweise eine ` QQuickView ` und legt dabei fest, dass die Vulkan-Validierung oder die Direct3D-Debug-Ebene 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();
}

Speichern und Laden des Pipeline-Caches

Qt Quick unterstützt das Speichern des Grafik-/Rechen-Pipeline-Caches auf Festplatte und das erneute Laden bei nachfolgenden Ausführungen einer Anwendung. Was genau der Pipeline-Cache enthält, wie das Abrufen funktioniert 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 verfolgen unterschiedliche Konzepte in Bezug auf Shader, Programme und Pipeline-Zustandsobjekte sowie die entsprechenden Cache-Mechanismen. Das hier verwendete übergeordnete Pipeline-Cache-Konzept abstrahiert all dies auf das Speichern und Abrufen eines einzigen binären Blobs in eine bzw. aus einer Datei.

Wenn dasselbe Shader-Programm und/oder derselbe Pipeline-Zustand wie bei einem vorherigen Lauf vorliegt, werden wahrscheinlich eine Reihe von Operationen übersprungen, was zu schnelleren Initialisierungszeiten für Shader und Materialien führt. Dies bedeutet, dass der Start schneller erfolgen kann und Verzögerungen sowie „Ruckler“ während des Renderings reduziert oder vermieden werden können.

Bei der Verwendung einer Grafik-API, bei der das Abrufen und Neuladen des Pipeline-Caches (oder der Shader-/Programm-Binärdateien) nicht möglich oder nicht unterstützt ist, hat der Versuch, den Cache über eine Datei zu speichern und zu laden, keine Wirkung.

Es gibt Ausnahmen vom Problem der Treiberabhängigkeit, insbesondere bei Direct 3D 11, wo der „Pipeline-Cache“ ausschließlich zum Speichern der Ergebnisse der HLSL->DXBC-Kompilierung zur Laufzeit verwendet wird und daher geräte- und herstellerunabhängig ist.

In manchen Fällen kann es wünschenswert sein, die Leistung beim allerersten Start der Anwendung zu verbessern, indem der Cache „vorab gefüllt“ wird. Dies ist möglich, indem die aus einem früheren Lauf gespeicherte Cache-Datei mitgeliefert und auf einem anderen Rechner oder Gerät referenziert wird. Auf diese Weise stehen der Anwendung oder dem Gerät bereits beim ersten Start die Shader-Programme bzw. Pipelines zur Verfügung, die bereits bei dem Lauf vorhanden waren, bei dem die Cache-Datei gespeichert wurde. Das Mitführen 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 das Gerät oder die Treiberversion nicht übereinstimmt (mit Ausnahme von D3D11), wie oben beschrieben.

Sobald der Cache-Inhalt geladen ist, besteht weiterhin die Möglichkeit, dass die Anwendung Grafik- und Rechenpipelines erstellt, die in früheren Durchläufen noch nicht aufgetreten sind. In diesen Fällen wird der Cache erweitert, indem die Pipelines bzw. Shader-Programme hinzugefügt werden. Wenn die Anwendung zudem den Inhalt speichert (möglicherweise sogar in derselben Datei), werden sowohl die alten als auch die neuen Pipelines gespeichert. Das Laden aus und Speichern in dieselbe Datei bei jedem Durchlauf ermöglicht einen ständig wachsenden Cache, der alle angetroffenen Pipelines und Shader-Programme speichert.

In der Praxis lässt sich davon ausgehen, dass der Qt-Pipeline-Cache den folgenden nativen Grafik-API-Funktionen entspricht:

• Vulkan – VkPipelineCache – Beim Speichern des Pipeline-Caches wird im Wesentlichen der über vkGetPipelineCacheData abgerufene Blob gespeichert, ergänzt um zusätzliche Metadaten zur sicheren Identifizierung des Geräts und des Treibers, da der Pipeline-Cache-Blob vom jeweiligen Treiber abhängt.
• Metal – MTLBinaryArchive – Bei aktiviertem Speichern des Pipeline-Caches speichert Qt alle angetroffenen Render- und Compute-Pipelines in einem MTLBinaryArchive. Beim Speichern des Pipeline-Caches wird der aus dem Archiv abgerufene Blob zusammen mit zusätzlichen Metadaten zur Identifizierung des Geräts gespeichert. 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-Binärdateien, die über `glGetProgramBinary` abgerufen wurden. Die Programm-Binärdateien werden in einem einzigen Blob gebündelt, zusammen mit zusätzlichen Metadaten zur Identifizierung des Geräts, des Treibers und der Treiberversion, aus der die Binärdateien abgerufen wurden. Das dauerhafte Zwischenspeichern von Programm-Binärdateien ist in Qt nichts Neues: Qt 5 verfügte bereits über eine ähnliche Funktionalität in „ QOpenGLShaderProgram “; siehe beispielsweise addCacheableShaderFromSourceCode(). Tatsächlich ist dieser Mechanismus auch in Qt 6 immer aktiv, wenn „ Qt Quick “ mit OpenGL verwendet wird. Bei Verwendung der hier bereitgestellten neuen, von der Grafik-API unabhängigen Pipeline-Cache-Abstraktion wird der Programm-Binärcode-Cache aus der Qt-5-Ära jedoch automatisch deaktiviert, da derselbe Inhalt nun im „Pipeline-Cache“ gebündelt ist.
• Direct 3D 11 – Es gibt kein natives Konzept für Pipelines oder das Abrufen von Binärdateien für die zweite Kompilierungsphase (in der der herstellerunabhängige Zwischen-Bytecode in den gerätespezifischen Befehlssatz kompiliert wird). Treiber setzen auf dieser Ebene in der Regel ein eigenes Caching-System ein. 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 zu erheblichen Leistungssteigerungen in Anwendungen und Bibliotheken führen, die Shader-Code zur Laufzeit zusammenstellen, da bei nachfolgenden Durchläufen die potenziell aufwendigen, nicht zwischengespeicherten Aufrufe von `D3DCompile()` vermieden werden können, wenn der Bytecode für den auftretenden HLSL-Shader bereits verfügbar ist. Ein gutes Beispiel ist Qt Quick 3D, wo die zur Laufzeit generierten Shader für Materialien die Verarbeitung von HLSL-Quellcode erfordern. Das Speichern und erneute Laden des „ Qt Quick “-Pipeline-Caches kann daher in Szenen mit einem oder mehreren „ View3D “-Elementen zu erheblichen Verbesserungen führen. Ein Gegenbeispiel könnte Qt Quick selbst sein: Da die meisten integrierten Shader für 2D-Inhalte mit DirectX-Bytecode ausgeliefert werden, der bereits bei der Erstellung generiert wurde, wird der Cache hier keine nennenswerten Verbesserungen bringen.

Shader ToolsAll dies ist unabhängig von der Shader-Verarbeitung, die vom Qt XML-ph-0000@deepl.internal-Modul und seinen Befehlszeilentools wie qsb durchgeführt wird. Nehmen wir als Beispiel Vulkan. Es ist sinnvoll, den Vulkan-kompatiblen GLSL-Quellcode entweder offline oder zur Erstellungszeit (direkt über qsb oder CMake) zu SPIR-V zu kompilieren, da so die rechenintensive Kompilierung aus dem Quellcode zur Laufzeit vermieden wird. SPIR-V ist jedoch ein herstellerunabhängiges Zwischenformat. Zur Laufzeit findet beim Aufbau von Grafik- oder Rechenpipelines wahrscheinlich eine weitere Kompilierungsrunde statt, diesmal vom Zwischenformat zum herstellerspezifischen Befehlssatz der GPU (und dies kann auch von bestimmten Zuständen in der Grafikpipeline und den Renderzielen abhängen). Der Pipeline-Cache hilft bei dieser letzten Phase.

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

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

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

Dies vermittelt einen ungefähren Eindruck davon, wie viel Zeit während der Lebensdauer des Fensters für die Erstellung der Grafik- und Rechenpipeline (die verschiedene Phasen der Shader-Kompilierung umfassen kann) aufgewendet wurde.

Wenn das Laden aus einer Pipeline-Cache-Datei aktiviert ist, wird dies durch folgende 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 zum Speichern und Laden angegeben wird, kommt die Strategie des automatischen Pipeline-Cachings zum Einsatz. Dabei werden Daten am anwendungsspezifischen Cache-Speicherort des Systems (QStandardPaths::CacheLocation) abgelegt.

Dies kann auf eine der folgenden Weisen deaktiviert werden:

• Setzen Sie das Anwendungsattribut ` Qt::AA_DisableShaderDiskCache`. (Deaktiviert die automatische Speicherung vollständig.)
• Setzen Sie die Umgebungsvariable `QT_DISABLE_SHADER_DISK_CACHE` auf einen Wert ungleich Null. (Deaktiviert die automatische Speicherung vollständig.)
• Setzen Sie die Umgebungsvariable `QSG_RHI_DISABLE_SHADER_DISK_CACHE` auf einen Wert ungleich Null. (Deaktiviert die automatische Zwischenspeicherung vollständig.)
• Rufen Sie `setAutomaticPiplineCache()` auf, wobei das Argument `enable` auf `false` gesetzt ist. (deaktiviert die automatische Speicherung vollständig)
• Legen Sie einen Dateinamen fest, indem Sie ` setPipelineCacheLoadFile()` aufrufen. (Deaktiviert nur das Laden aus dem automatischen Speicher und verwendet stattdessen die angegebene Datei.)
• Legen Sie einen Dateinamen fest, indem Sie ` setPipelineCacheSaveFile()` aufrufen. (Deaktiviert lediglich das Schreiben in den automatischen Speicher und bevorzugt stattdessen die angegebene Datei)

Die ersten beiden sind bereits seit Qt 5.9 vorhandene Mechanismen zur Steuerung des OpenGL-Programm-Binär-Caches. Aus Gründen der Kompatibilität und Vertrautheit werden dieselben Attribute und Umgebungsvariablen auch für den erweiterten Pipeline-Cache von Qt 6 unterstützt.

Der automatische Pipeline-Cache verwendet eine einzige Datei pro Anwendung, jedoch eine unterschiedliche für jedes RHI-Backend (Grafik-API). Das bedeutet, dass ein Wechsel zu einer anderen Grafik-API beim nächsten Start der Anwendung nicht zum Verlust des im vorherigen Durchlauf generierten Pipeline-Caches führt. Anwendungen mit mehreren gleichzeitig angezeigten „ QQuickWindow “-Instanzen profitieren jedoch möglicherweise nicht zu 100 %, da der automatische Cache jeweils nur die von einem RHI-Objekt gesammelten Daten speichern kann. (Und bei der Standard-Render-Schleife „ threaded “ verfügt jedes Fenster über ein eigenes RHI, da das Rendering unabhängig in dedizierten Threads erfolgt.) Um den Vorteile des Festplatten-Caches in Anwendungen mit mehreren Fenstern voll auszuschöpfen, sollten Sie den Dateinamen explizit pro Fenster über ` setPipelineCacheSaveFile()` festlegen.