Philosophie de conception des files d’attente de commandes et des listes de commandes
Les objectifs de la réutilisation du travail de rendu et de la mise à l’échelle multithread ont nécessité des changements fondamentaux dans la façon dont les applications Direct3D envoient le travail de rendu au GPU. Dans Direct3D 12, le processus d’envoi du travail de rendu diffère des versions antérieures de trois manières importantes :
- Élimination du contexte immédiat. Cela permet le multithreading.
- Les applications possèdent désormais la façon dont les appels de rendu sont regroupés en éléments de travail de l’unité de traitement graphique (GPU). Cela permet la réutilisation.
- Les applications contrôlent désormais explicitement quand le travail est soumis au GPU. Cela active les éléments 1 et 2.
- Suppression du contexte immédiat
- Regroupement d’éléments de travail GPU
- Soumission de travail GPU
- Rubriques connexes
Suppression du contexte immédiat
Le changement le plus important de Microsoft Direct3D 11 à Microsoft Direct3D 12 est qu’il n’y a plus un seul contexte immédiat associé à un appareil. Au lieu de cela, pour effectuer le rendu, les applications créent des listes de commandes dans lesquelles les API de rendu traditionnelles peuvent être appelées. Une liste de commandes ressemble à la méthode render d’une application Direct3D 11 qui a utilisé le contexte immédiat, car elle contient des appels qui dessinent des primitives ou modifient l’état de rendu. Comme les contextes immédiats, chaque liste de commandes n’est pas à thread libre ; Toutefois, plusieurs listes de commandes peuvent être enregistrées simultanément, ce qui tire parti des processeurs multicœurs modernes.
Les listes de commandes sont généralement exécutées une seule fois. Toutefois, une liste de commandes peut être exécutée plusieurs fois si l’application s’assure que les exécutions précédentes sont terminées avant d’envoyer de nouvelles exécutions. Pour plus d’informations sur la synchronisation des listes de commandes, consultez Exécution et synchronisation des listes de commandes.
Regroupement d’éléments de travail GPU
En plus des listes de commandes, Direct3D 12 tire parti des fonctionnalités présentes dans tout le matériel d’aujourd’hui en ajoutant un deuxième niveau de listes de commandes, appelées bundles. Pour aider à distinguer ces deux types, les listes de commandes de premier niveau peuvent être appelées listes de commandes directes. L’objectif des bundles est de permettre aux applications de regrouper un petit nombre de commandes d’API pour une exécution ultérieure répétée à partir de listes de commandes directes. Au moment de la création d’un bundle, le pilote effectue autant de prétraitements que possible pour rendre l’exécution ultérieure efficace. Les bundles peuvent ensuite être exécutés à partir de plusieurs listes de commandes et plusieurs fois au sein d’une même liste de commandes.
La réutilisation des bundles est un important pilote d’amélioration de l’efficacité avec des threads de processeur uniques. Étant donné que les bundles sont prétraités et peuvent être envoyés plusieurs fois, certaines restrictions s’appliquent aux opérations qui peuvent être effectuées au sein d’un bundle. Pour plus d’informations, consultez Création et enregistrement de listes de commandes et d’offres groupées.
Soumission de travail GPU
Pour exécuter le travail sur le GPU, une application doit envoyer explicitement une liste de commandes à une file d’attente de commandes associée à l’appareil Direct3D. Une liste de commandes directes peut être envoyée pour exécution plusieurs fois, mais l’application est chargée de s’assurer que la liste de commandes directes a terminé de s’exécuter sur le GPU avant de la soumettre à nouveau. Les bundles n’ont pas de restrictions d’utilisation simultanée et peuvent être exécutés plusieurs fois dans plusieurs listes de commandes, mais les bundles ne peuvent pas être directement envoyés à une file d’attente de commandes pour exécution.
Tout thread peut envoyer une liste de commandes à n’importe quelle file d’attente de commandes à tout moment, et le runtime sérialise automatiquement la soumission de la liste de commandes dans la file d’attente de commandes tout en conservant l’ordre de soumission.