Graphes de rendu : déclarer les dépendances et maîtriser la durée de vie des ressources

Décrire la frame comme un flux de données

Un moteur de rendu devient difficile à modifier lorsque la propriété des ressources reste implicite. Une passe de post-traitement peut lire une image qu'une autre fonctionnalité écrase de façon inattendue, ou garder une texture temporaire en vie pendant toute la frame. Commencez par décrire, pour chaque passe, ses entrées, ses sorties et ses effets visibles de l'extérieur. Ce contrat permet de relire les dépendances d'une nouvelle fonctionnalité avant que ses commandes ne s'exécutent.

Séparer la déclaration de l'exécution

Un graphe de rendu enregistre les passes et l'usage des ressources, puis en déduit un plan d'exécution. Le RDG d'Unreal peut éliminer le travail inutilisé, gérer les ressources transitoires et planifier la synchronisation. Il distingue les ressources dont la durée de vie reste interne au graphe des ressources externes qui lui survivent. [1] Déclarer une lecture ou une écriture est une obligation de correction : un accès non déclaré donne au planificateur une vision incomplète de la frame.

Étudier un exemple d'aliasing

Considérons quatre passes ordonnées. La première écrit un masque temporaire de 8 MiB ; la deuxième en consomme le contenu final. Ce n'est qu'ensuite que la troisième crée un intermédiaire de flou de 16 MiB, consommé par la quatrième. Si les exigences mémoire sont compatibles et que l'exécution empêche tout usage simultané, les deux ressources temporaires peuvent partager une région idéalisée de 16 MiB, au lieu de régions distinctes totalisant 24 MiB.

Ce calcul ne tient compte ni du surcoût d'allocation ni d'aucune autre ressource de la frame. Si la quatrième passe lit aussi le masque d'origine, les durées de vie se chevauchent et la réutilisation envisagée n'est pas valide. L'ordre d'enregistrement des commandes côté CPU ne prouve pas à lui seul que les accès GPU sont terminés. Inspectez la chronologie réelle des ressources et les dépendances.

Valider le contrat de ressources

Nommez les ressources selon leur finalité. Déclarez précisément les lectures, les écritures et les sous-ressources concernées, et définissez si une image nouvellement allouée doit être effacée ou entièrement réécrite. Gardez l'historique temporel et les autres données persistantes sous une propriété externe explicite.

Utilisez la visualisation du graphe et la validation de l'API en activant les effets un par un. Le guide de synchronisation de Vulkan décrit les pipeline barriers comme un moyen de contrôler quels étages doivent attendre les étages précédents. [2] Le graphe doit en fin de compte produire une synchronisation adaptée à l'API sous-jacente. Pour diagnostiquer une corruption, comparez la sortie avec l'aliasing ou l'ordonnancement asynchrone désactivé ; considérez cette comparaison comme un indice, et non comme un correctif permanent.

Mesurer l'arbitrage d'ordonnancement

Le calcul asynchrone peut faire se chevaucher des travaux indépendants, mais des passes concurrentes peuvent se disputer la capacité d'exécution ou la bande passante mémoire. Le chevauchement de leurs durées de vie peut aussi réduire les occasions de réutiliser la mémoire. Comparez la durée GPU, le pic d'allocation transitoire et le coût d'enregistrement côté CPU sur la charge de travail cible.

Conservez les historiques de ressources d'une frame normale, d'un changement de résolution et d'une transition où un effet est désactivé. Un graphe qui produit correctement une capture d'écran peut tout de même contenir, sur un autre chemin, une lecture non initialisée ou un allongement involontaire de durée de vie. N'optimisez qu'une fois que ces chemins disposent d'une politique claire de propriété et d'initialisation.

Sources

[1] Render Dependency Graph — Epic Games.

[2] Vulkan synchronization guide — Khronos Group.