Différences dans le modèle de liaison de Direct3D 11
L’une des principales décisions de conception derrière la liaison DirectX12 consiste à la séparer d’autres tâches de gestion. Cela place certaines exigences sur l’application pour gérer certains risques potentiels.
L’avantage principal du modèle de liaison D3D12 est qu’il permet aux applications de modifier fréquemment les liaisons de texture, sans coût énorme des performances du processeur. D’autres avantages sont que les nuanceurs ont accès à un très grand nombre de ressources, les nuanceurs n’ont pas besoin de savoir à l’avance combien de ressources seront liées et qu’un modèle de liaison de ressources unifié peut être utilisé indépendamment du matériel ou du flux de contenu des applications.
Pour améliorer les performances, le modèle de liaison n’exige pas que le système effectue le suivi des liaisons qu’une application a demandées au GPU d’utiliser et qu’il existe une intégration propre entre les listes de commandes multithread et de liaison.
Les sections suivantes répertorient certaines des modifications apportées au modèle de liaison de ressources depuis D3D11.
- Gestion de la résidence de mémoire séparée de la liaison
- Gestion de la durée de vie des objets séparée de la liaison
- Suivi de l’état des ressources du pilote séparé de la liaison
- Synchronisation de mémoire mappée par gpu processeur séparée de la liaison
- Rubriques connexes
Gestion de la résidence de mémoire séparée de la liaison
Les applications disposent d’un contrôle explicite sur les surfaces dont ils doivent être disponibles pour que le GPU utilise directement (appelé « résident »). À l’inverse, ils peuvent appliquer d’autres états sur des ressources telles que les rendre explicitement non résidentes ou laisser le système d’exploitation choisir pour certaines classes d’applications qui nécessitent un encombrement de mémoire minimal. Le point important est que la gestion de l’application de ce qui est résident est complètement découplée de la façon dont elle donne accès aux ressources aux nuanceurs.
Le découplage de la gestion des résidences du mécanisme permettant aux nuanceurs d’accéder aux ressources réduit le coût système/matériel du rendu, car le système d’exploitation n’a pas à inspecter constamment l’état de liaison local pour savoir quoi faire résident. En outre, les nuanceurs n’ont plus à savoir quelles surfaces exactes ils peuvent avoir besoin de référencer, tant que l’ensemble des ressources éventuellement accessibles a été rendu résident à l’avance.
Gestion de la durée de vie des objets séparée de la liaison
Contrairement aux API précédentes, le système ne suit plus les liaisons de ressources vers le pipeline. Cela permet au système de conserver les ressources vivantes publiées par l’application, car elles sont toujours référencées par un travail GPU exceptionnel.
Avant de libérer une ressource, telle qu’une texture, les applications doivent maintenant s’assurer que le GPU a terminé de le référencer. Cela signifie qu’avant qu’une application puisse libérer en toute sécurité une ressource, le GPU doit avoir terminé l’exécution de la liste de commandes faisant référence à la ressource.
Suivi de l’état des ressources du pilote séparé de la liaison
Le système n’inspecte plus les liaisons de ressources pour comprendre quand des transitions de ressources ont eu lieu, ce qui nécessite un travail de pilote ou gpu supplémentaire. Un exemple courant pour de nombreux GPU et pilotes doit savoir quand une surface passe d’une vue cible de rendu (RTV) à la vue de ressource du nuanceur (SRV). Les applications elles-mêmes doivent maintenant identifier quand des transitions de ressources que le système peut se soucier de se produire via des API dédiées.
Synchronisation de mémoire mappée par gpu processeur séparée de la liaison
Le système n’inspecte plus les liaisons de ressources pour comprendre si le rendu doit être retardé, car il dépend d’une ressource mappée pour l’accès au processeur, mais n’a pas encore été maappée. Les applications ont désormais la responsabilité de synchroniser les accès en mémoire processeur et GPU. Pour cela, le système fournit des mécanismes permettant à l’application de demander le sommeil d’un thread processeur jusqu’à ce que le travail soit terminé. L’interrogation peut également être effectuée, mais peut être moins efficace.
Rubriques connexes