QQuickGraphicsConfiguration Class

Description détaillée

La classe QQuickGraphicsConfiguration est un conteneur de paramètres graphiques de bas niveau pouvant influencer la manière dont l’API graphique sous-jacente, telle que Vulkan, est initialisée par le graphe de scène d’ Qt Quick. Elle permet également de contrôler certains aspects du moteur de rendu du graphe de scène.

Configuration pour les moteurs de rendu externes ou les API XR

Lors de la construction et de l’affichage d’une QQuickWindow utilisant Vulkan pour le rendu, une instance Vulkan (VkInstance), un périphérique physique (VkPhysicalDevice), un périphérique (VkDevice) et les objets associés (files d’attente, pools) sont initialisés via l’API Vulkan. Il en va de même, pour l’essentiel, lorsque l’on utilise ` QQuickRenderControl ` pour rediriger le rendu vers une cible de rendu personnalisée, telle qu’une texture. Bien que la construction de ` QVulkanInstance ` soit alors sous le contrôle de l’application, l’initialisation des autres objets graphiques s’effectue de la même manière dans ` QQuickRenderControl::initialize()` que dans le cas d’un rendu à l’écran ` QQuickWindow`.

Pour la plupart des applications, aucune configuration supplémentaire n’est nécessaire, car Qt Quick fournit des valeurs par défaut raisonnables pour de nombreux paramètres graphiques de bas niveau, par exemple les extensions de périphérique à activer.

Cela ne sera toutefois pas toujours suffisant. Dans des cas d’utilisation avancés, lors de l’intégration de contenu Vulkan direct ou d’autres API graphiques, ou lors de l’intégration avec un moteur 3D ou VR externe, tel qu’OpenXR, l’application souhaitera spécifier son propre ensemble de paramètres pour certains détails, comme les extensions de périphérique à activer.

C’est précisément ce que permet cette classe. Elle permet de spécifier, par exemple, une liste d’extensions de périphérique qui sera ensuite reprise par le graphe de scène lors de l’utilisation de Vulkan, ou d’API graphiques où ce concept s’applique. Lorsque certains concepts ne s’appliquent pas, les paramètres correspondants sont simplement ignorés.

Parmi les fonctions de cette catégorie, on peut citer ` setDeviceExtensions()` et ` preferredInstanceExtensions()`. Cette dernière est utile lorsque l’application gère son propre ` QVulkanInstance `, qui est ensuite associé à la ` QQuickWindow ` via ` QWindow::setVulkanInstance()`.

Qt Quick Configuration du moteur de rendu du graphe de scène

Une autre catégorie de paramètres concerne le moteur de rendu du graphe de scène. Dans certains cas, les applications peuvent souhaiter contrôler certains comportements, comme l’utilisation du tampon de profondeur lors du rendu de contenu 2D. Dans Qt 5, ces paramètres n'étaient soit pas contrôlables du tout, soit gérés via des variables d'environnement. Dans Qt 6, QQuickGraphicsConfiguration offre un nouvel emplacement pour ces paramètres, tout en conservant la prise en charge des variables d'environnement héritées, le cas échéant.

setDepthBufferFor2D() en est un exemple.

Configuration des périphériques graphiques

Lorsque les objets d’instance et de périphérique graphique (par exemple, VkInstance et VkDevice avec Vulkan, ID3D11Device avec Direct 3D, etc.) sont créés par Qt lors de l’initialisation d’un QQuickWindow, certains paramètres peuvent nécessiter d’être contrôlés par les applications ou les bibliothèques dans certaines circonstances.

Avant Qt 6.5, certains de ces paramètres pouvaient être contrôlés via des variables d’environnement. Par exemple, ` QSG_RHI_DEBUG_LAYER ` ou ` QSG_RHI_PREFER_SOFTWARE_RENDERER`. Celles-ci sont toujours disponibles et continuent de fonctionner comme auparavant. `QQuickGraphicsConfiguration` fournit en outre des accesseurs C++.

Par exemple, la fonction `main()` suivante ouvre un ` QQuickView ` tout en spécifiant que la validation Vulkan ou la couche de débogage Direct3D doit être activée :

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();
}

Sauvegarde et chargement du cache du pipeline

Qt Quick prend en charge la sauvegarde sur disque du cache du pipeline graphique/de calcul, ainsi que sa relecture lors des exécutions suivantes d’une application. Le contenu exact du cache du pipeline, le fonctionnement des recherches et les éléments précis qui sont accélérés dépendent tous du backend Qt RHI et de l’API graphique native sous-jacente utilisée lors de l’exécution. Les différentes API 3D ont des concepts distincts en matière de shaders, de programmes et d’objets d’état de pipeline, ainsi que de mécanismes de cache correspondants. Le concept de haut niveau de cache de pipeline présenté ici résume tout cela à la sauvegarde et à la récupération d’un seul blob binaire vers et depuis un fichier.

Lorsque le même programme de shader et/ou le même état de pipeline que lors d’une exécution précédente est rencontré, un certain nombre d’opérations sont susceptibles d’être ignorées, ce qui accélère les temps d’initialisation des shaders et des matériaux ; le démarrage peut ainsi être plus rapide, et les ralentissements ainsi que les « saccades » pendant le rendu peuvent être réduits, voire évités.

Lors de l’exécution avec une API graphique où la récupération et le rechargement du cache du pipeline (ou des binaires de shader/programme) ne sont pas applicables ou ne sont pas pris en charge, tenter d’utiliser un fichier pour enregistrer et charger le cache n’a aucun effet.

Il existe des exceptions au problème de dépendance vis-à-vis du pilote, notamment Direct 3D 11, où le « cache de pipeline » sert uniquement à stocker les résultats de la compilation HLSL->DXBC à l’exécution et est donc indépendant du périphérique et du fournisseur.

Dans certains cas, il peut être souhaitable d’optimiser la toute première exécution de l’application en « préremplissant » le cache. Cela est possible en fournissant le fichier de cache enregistré lors d’une exécution précédente et en y faisant référence sur une autre machine ou un autre périphérique. De cette manière, l’application ou le périphérique dispose dès son premier lancement des programmes de shaders et des pipelines déjà rencontrés lors de l’exécution qui a généré le fichier de cache. Le transfert et le déploiement du fichier de cache n’ont de sens que si le périphérique et les pilotes graphiques sont identiques sur le système cible ; dans le cas contraire, le fichier de cache est ignoré si la version du périphérique ou du pilote ne correspond pas (à l’exception de D3D11), comme décrit ci-dessus.

Une fois le contenu du cache chargé, il est toujours possible que l’application construise des pipelines graphiques et de calcul qui n’ont pas été rencontrés lors des exécutions précédentes. Dans ce cas, le cache s’agrandit, les pipelines et programmes de shaders y étant ajoutés. Si l’application choisit également d’enregistrer le contenu (peut-être même dans le même fichier), les anciens et les nouveaux pipelines seront alors tous deux stockés. Le chargement à partir du même fichier et l’enregistrement dans celui-ci à chaque exécution permettent d’obtenir un cache en constante expansion qui stocke tous les pipelines et programmes de shaders rencontrés.

En pratique, on peut s’attendre à ce que le cache de pipelines Qt corresponde aux fonctionnalités suivantes de l’API graphique native :

• Vulkan - VkPipelineCache - L'enregistrement du cache de pipelines stocke en fait le blob récupéré via vkGetPipelineCacheData, accompagné de métadonnées supplémentaires permettant d’identifier de manière fiable le périphérique et le pilote, car le blob du cache de pipelines dépend du pilote précis.
• Metal - MTLBinaryArchive - Lorsque l’enregistrement du cache de pipeline est activé, Qt stocke tous les pipelines de rendu et de calcul rencontrés dans un fichier MTLBinaryArchive. L’enregistrement du cache de pipeline stocke le blob récupéré à partir de l’archive, accompagné de métadonnées supplémentaires permettant d’identifier le périphérique. Remarque : actuellement, l’utilisation de MTLBinaryArchive est désactivée sur macOS et iOS en raison de divers problèmes sur certains matériels et certaines versions du système d’exploitation.
• OpenGL - Il n’existe pas de concept natif de pipelines ; le « cache de pipeline » stocke un ensemble de binaires de programme récupérés via glGetProgramBinary. Les binaires de programme sont regroupés dans un seul blob, accompagnés de métadonnées supplémentaires permettant d’identifier le périphérique, le pilote et la version à partir de laquelle les binaires ont été récupérés. La mise en cache persistante des binaires de programme n’est pas une nouveauté dans Qt : Qt 5 disposait déjà d’une fonctionnalité similaire dans QOpenGLShaderProgram, voir par exemple addCacheableShaderFromSourceCode(). En réalité, ce mécanisme est également toujours actif dans Qt 6 lors de l’utilisation d’ Qt Quick avec OpenGL. Cependant, lorsque l’on utilise la nouvelle abstraction de cache de pipeline indépendante de l’API graphique fournie ici, le cache de binaires de programme de l’époque de Qt 5 est automatiquement désactivé, car ce même contenu est désormais regroupé dans le « cache de pipeline ».
• Direct 3D 11 – Il n’existe pas de concept natif de pipelines ni de récupération de binaires pour la deuxième phase de compilation (lorsque le bytecode intermédiaire, indépendant du fournisseur, est compilé en jeu d’instructions spécifique au périphérique). Les pilotes utilisent généralement leur propre système de mise en cache à ce niveau. À la place, le « cache de pipeline » d’ Qt Quick est utilisé pour accélérer les cas où les shaders contiennent du code source HLSL qui doit d’abord être compilé au format bytecode intermédiaire. Cela peut apporter des gains de performances significatifs dans les applications et les bibliothèques qui composent du code de shader à l’exécution, car lors des exécutions suivantes, les appels à D3DCompile(), potentiellement coûteux et non mis en cache, peuvent être évités si le bytecode est déjà disponible pour le shader HLSL rencontré. Un bon exemple est Qt Quick 3D, où les shaders générés à l’exécution pour les matériaux impliquent de gérer du code source HLSL. La sauvegarde et le rechargement du cache de pipeline Qt Quick peuvent donc apporter des améliorations considérables dans les scènes contenant un ou plusieurs éléments View3D. Qt Quick lui-même peut constituer un contre-exemple : comme la plupart des shaders intégrés pour le contenu 2D sont fournis avec du bytecode DirectX généré au moment de la compilation, le cache n’apportera pas d’améliorations significatives.

Tout cela est indépendant du traitement des shaders effectué par le module Qt Shader Tools et ses outils en ligne de commande tels que qsb. Prenons l’exemple de Vulkan. Il est judicieux de compiler le code source GLSL compatible Vulkan en SPIR-V soit hors ligne, soit au moment de la compilation (directement via qsb ou CMake), car cela permet d’éviter la compilation coûteuse à partir du code source lors de l’exécution. Le SPIR-V est toutefois un format intermédiaire indépendant du fournisseur. Au moment de l’exécution, lors de la construction de pipelines graphiques ou de calcul, une nouvelle étape de compilation a probablement lieu, cette fois-ci du format intermédiaire vers le jeu d’instructions spécifique au fabricant du GPU (et cela peut dépendre de certains états du pipeline graphique ainsi que des cibles de rendu). Le cache du pipeline facilite cette dernière phase.

Appelez ` setPipelineCacheSaveFile()` et ` setPipelineCacheLoadFile()` pour contrôler les fichiers dans lesquels ` QQuickWindow ` ou ` QQuickView ` enregistre et charge le cache du pipeline.

Pour vous faire une idée des effets de l’activation du stockage sur disque du cache du pipeline, activez les journaux les plus importants relatifs au graphe de scène et aux graphismes, soit via la variable d’environnement QSG_INFO=1, soit via les catégories de journalisation qt.scenegraph.general et qt.rhi.general. À la fermeture de l’ QQuickWindow, un message de journalisation similaire à celui-ci s’affiche :

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

Cela donne une idée approximative du temps consacré à la création du pipeline graphique et de calcul (qui peut inclure différentes étapes de compilation des shaders) pendant la durée de vie de la fenêtre.

Lorsque le chargement à partir d’un fichier de cache de pipeline est activé, cela est confirmé par un message :

Attempting to seed pipeline cache from 'filename'

De même, pour vérifier si l’enregistrement du cache est bien activé, recherchez un message tel que celui-ci :

Writing pipeline cache contents to 'filename'

Le cache de pipeline automatique

Lorsqu’aucun nom de fichier n’est fourni pour l’enregistrement et le chargement, la stratégie de mise en cache automatique du pipeline est utilisée. Cela implique le stockage des données à l’emplacement de cache spécifique à l’application du système (QStandardPaths::CacheLocation).

Cette fonctionnalité peut être désactivée de l’une des manières suivantes :

• Définissez l’attribut d’application Qt::AA_DisableShaderDiskCache. (désactive complètement la mise en cache automatique)
• Définir la variable d’environnement QT_DISABLE_SHADER_DISK_CACHE sur une valeur non nulle. (désactive complètement le stockage automatique)
• Définissez la variable d’environnement QSG_RHI_DISABLE_SHADER_DISK_CACHE sur une valeur non nulle. (désactive complètement la mise en cache automatique)
• Appeler setAutomaticPiplineCache() en définissant l'argument enable sur false. (désactive complètement le stockage automatique)
• Définissez un nom de fichier en appelant la fonction ` setPipelineCacheLoadFile()`. (désactive uniquement le chargement à partir de la mémoire cache automatique, en privilégiant à la place le fichier spécifié)
• Définissez un nom de fichier en appelant ` setPipelineCacheSaveFile()`. (Cela désactive uniquement l'écriture dans le stockage automatique, en privilégiant le fichier spécifié à la place.)

Les deux premiers sont des mécanismes existants utilisés depuis Qt 5.9 pour contrôler le cache binaire du programme OpenGL. Pour des raisons de compatibilité et de familiarité, le même attribut et la même variable d’environnement sont pris en charge pour le cache de pipeline amélioré de Qt 6.

Le cache de pipeline automatique utilise un seul fichier par application, mais un fichier différent pour chaque backend RHI (API graphique). Cela signifie que le passage à une autre API graphique lors de la prochaine exécution de l’application n’entraînera pas la perte du cache de pipeline généré lors de l’exécution précédente. Les applications comportant plusieurs instances d’ QQuickWindow s affichées simultanément peuvent toutefois ne pas en tirer pleinement parti, car le cache automatique ne peut stocker que les données collectées à partir d’un seul objet RHI à la fois. (Et avec la boucle de rendu par défaut threaded, chaque fenêtre dispose de son propre RHI, le rendu s’effectuant de manière indépendante sur des threads dédiés). Pour tirer pleinement parti du cache disque dans une application comportant plusieurs fenêtres, il est préférable de définir explicitement le nom de fichier pour chaque fenêtre via ` setPipelineCacheSaveFile()` ().