Partager via

Modifications importantes de Direct3D 11 à Direct3D 12

Direct3D 12 représente un écart significatif du modèle de programmation Direct3D 11. Direct3D 12 permet aux applications de se rapprocher du matériel que jamais auparavant. En étant plus proche du matériel, Direct3D 12 est plus rapide et plus efficace. Mais le compromis de votre application ayant augmenté la vitesse et l’efficacité avec Direct3D 12 est que vous êtes responsable de plus de tâches que vous étiez avec Direct3D 11.

Direct3D 12 est un retour à la programmation de bas niveau ; il vous donne plus de contrôle sur les éléments graphiques de vos jeux et applications en introduisant ces nouvelles fonctionnalités : les objets pour représenter l’état global du pipeline, des listes de commandes et des bundles pour la soumission de travail, ainsi que les segments de mémoire et les tables de descripteur pour l’accès aux ressources.

Votre application a augmenté la vitesse et l’efficacité avec Direct3D 12, mais vous êtes responsable de plus de tâches que vous étiez avec Direct3D 11.

Synchronisation explicite

  • Dans Direct3D 12, CPU-GPU synchronisation est désormais la responsabilité explicite de l’application et n’est plus implicitement effectuée par le runtime, car elle se trouve dans Direct3D 11. Cela signifie également qu’aucune vérification automatique des risques de pipeline n’est effectuée par Direct3D 12. Il s’agit donc à nouveau de la responsabilité des applications.
  • Dans Direct3D 12, les applications sont chargées de diriger les mises à jour des données. Autrement dit, le modèle « Map/Lock-DISCARD » dans Direct3D 11 doit être effectué manuellement dans Direct3D 12. Dans Direct3D 11, si le GPU utilise toujours la mémoire tampon lorsque vous appelez ID3D11DeviceContext ::Map avec D3D11_MAP_WRITE_DISCARD, le runtime retourne un pointeur vers une nouvelle région de mémoire au lieu des anciennes données de mémoire tampon. Cela permet au GPU de continuer à utiliser les anciennes données pendant que l’application place les données dans la nouvelle mémoire tampon. Aucune gestion supplémentaire de la mémoire n’est requise dans l’application ; l’ancienne mémoire tampon est réutilisée ou détruite automatiquement lorsque le GPU est terminé avec celui-ci.
  • Dans Direct3D 12, toutes les mises à jour dynamiques (notamment les mémoires tampons constantes, les tampons de vertex dynamiques, les textures dynamiques, et ainsi de suite) sont explicitement contrôlées par l’application. Ces mises à jour dynamiques incluent toutes les clôtures gpu requises ou la mise en mémoire tampon. L’application est chargée de conserver la mémoire disponible tant qu’elle n’est plus nécessaire.
  • Direct3D 12 utilise des références de style COM uniquement pour les durées de vie des interfaces (à l’aide du modèle de référence faible de Direct3D lié à la durée de vie de l’appareil). Toutes les durées de vie de la mémoire de ressource et de description sont la seule responsable de l’application à conserver pendant la durée appropriée et ne sont pas comptabilisées. Direct3D 11 utilise également le comptage de références pour gérer les durées de vie des dépendances d’interface.

Gestion de la résidence de la mémoire physique

Une application Direct3D 12 doit empêcher les conditions de concurrence entre plusieurs files d’attente, plusieurs adaptateurs et les threads d’UC. D3D12 ne synchronise plus l’UC et le GPU, ni prend en charge les mécanismes pratiques pour le renommage des ressources ou la mise en mémoire tampon multiple. Les clôtures doivent être utilisées pour éviter plusieurs unités de traitement de la mémoire sur-écriture avant qu’une autre unité de traitement ne se termine à l’aide de celle-ci.

L’application Direct3D 12 doit s’assurer que les données résident en mémoire pendant que le GPU le lit. La mémoire utilisée par chaque objet est rendue résidente lors de la création de l’objet. Les applications qui appellent ces méthodes doivent utiliser des clôtures pour s’assurer que le GPU n’accède pas aux objets qui ont été supprimés.

Les obstacles aux ressources sont un autre type de synchronisation nécessaire, utilisé pour synchroniser les transitions de ressources et de sous-ressources à un niveau très granulaire.

Reportez-vous à Gestion de la mémoire dans Direct3D 12.

Objets d’état du pipeline

Direct3D 11 permet la manipulation de l’état du pipeline via un grand ensemble d’objets indépendants. Par exemple, l’état de l’assembleur d’entrée, l’état du nuanceur de pixels, l’état du rastériseur et l’état de fusion de sortie peuvent tous être modifiés indépendamment. Cette conception offre une représentation pratique et relativement élevée du pipeline graphique, mais elle n’utilise pas les fonctionnalités du matériel moderne, principalement parce que les différents états sont souvent interdépendants. Par exemple, de nombreux GPU combinent le nuanceur de pixels et l’état de fusion de sortie en une seule représentation matérielle. Toutefois, étant donné que l’API Direct3D 11 permet à ces étapes de pipeline d’être définies séparément, le pilote d’affichage ne peut pas résoudre les problèmes d’état du pipeline tant que l’état n’est pas finalisé, ce qui n’est pas avant le moment du dessin. Ce schéma retarde la configuration de l’état matériel, ce qui signifie une surcharge supplémentaire et moins d’appels de tirage maximum par image.

Direct3D 12 traite ce schéma en unifiant la majeure partie de l’état du pipeline en objets d’état de pipeline immuables (PSO), qui sont finalisés lors de la création. Le matériel et les pilotes peuvent ensuite convertir immédiatement l’authentification unique en instructions et états natifs matériels nécessaires pour exécuter le travail GPU. Vous pouvez toujours modifier dynamiquement l’authentification unique utilisée, mais pour ce faire, le matériel doit uniquement copier la quantité minimale d’état précalculé directement dans les registres matériels, plutôt que de calculer l’état matériel à la volée. En utilisant des psO, la surcharge des appels de dessin est réduite de manière significative et de nombreux appels de dessin peuvent se produire par image. Pour plus d’informations sur les psO, consultez Gestion de l’état du pipeline graphique dans Direct3D 12.

Listes de commandes et offres groupées

Dans Direct3D 11, toutes les soumissions de travail sont effectuées via le contexte immédiat , qui représente un seul flux de commandes qui vont au GPU. Pour obtenir une mise à l’échelle multithread, les jeux ont également contextes différés disponibles. Les contextes différés dans Direct3D 11 ne sont pas mappés parfaitement au matériel, donc un travail relativement faible peut être effectué dans ces contextes.

Direct3D 12 introduit un nouveau modèle de soumission de travail basé sur des listes de commandes qui contiennent l’intégralité des informations nécessaires à l’exécution d’une charge de travail particulière sur le GPU. Chaque nouvelle liste de commandes contient des informations telles que l’authentification unique à utiliser, les ressources de texture et de mémoire tampon nécessaires, ainsi que les arguments pour tous les appels de dessin. Étant donné que chaque liste de commandes est autonome et hérite d’aucun état, le pilote peut pré-calculer toutes les commandes GPU nécessaires à l’avant et de manière libre. Le seul processus série nécessaire est la soumission finale de listes de commandes au GPU via la file d’attente de commandes.

En plus des listes de commandes, Direct3D 12 introduit également un deuxième niveau de pré-calcul de travail : bundles. Contrairement aux listes de commandes, qui sont entièrement autonomes et sont généralement construites, soumises une fois et ignorées, les bundles fournissent une forme d’héritage d’état qui autorise la réutilisation. Par exemple, si un jeu souhaite dessiner deux modèles de caractères avec des textures différentes, une approche consiste à enregistrer une liste de commandes avec deux ensembles d’appels de dessin identiques. Mais une autre approche consiste à « enregistrer » un bundle qui dessine un modèle de caractère unique, puis à « lire » le bundle deux fois sur la liste de commandes à l’aide de différentes ressources. Dans ce dernier cas, le pilote d’affichage doit uniquement calculer les instructions appropriées une seule fois, et la création de la liste de commandes équivaut essentiellement à deux appels de fonction à faible coût.

Pour plus d’informations sur les listes de commandes et les offres groupées, consultez Soumission de travail dans Direct3D 12.

Segments et tables de descripteur

La liaison de ressources dans Direct3D 11 est très abstraite et pratique, mais laisse de nombreuses fonctionnalités matérielles modernes sous-utilisées. Dans Direct3D 11, les jeux créent vue des objets de ressources, puis lient ces vues à plusieurs emplacements à différentes étapes du nuanceur dans le pipeline. Les nuanceurs, à leur tour, lisent les données de ces emplacements de liaison explicites, qui sont fixes au moment du dessin. Ce modèle signifie que chaque fois qu’un jeu dessine à l’aide de différentes ressources, il doit lier à nouveau différentes vues à différents emplacements et appeler à nouveau le dessin. Ce cas représente également une surcharge qui peut être éliminée en utilisant entièrement les fonctionnalités matérielles modernes.

Direct3D 12 modifie le modèle de liaison pour qu’il corresponde au matériel moderne et améliore considérablement les performances. Au lieu d’exiger des vues de ressources autonomes et un mappage explicite aux emplacements, Direct3D 12 fournit un tas de descripteur dans lequel les jeux créent leurs différentes vues de ressources. Ce schéma fournit un mécanisme pour que le GPU écrive directement la description de ressource native matérielle (descripteur) en mémoire frontale. Pour déclarer les ressources à utiliser par le pipeline pour un appel de dessin particulier, les jeux spécifient une ou plusieurs tables de descripteur qui représentent des sous-plages du tas de descripteur complet. Comme le tas de descripteur a déjà été rempli avec les données de descripteur spécifiques au matériel appropriées, la modification des tables de descripteur est une opération extrêmement économique.

Outre les performances améliorées offertes par les segments de mémoire et les tables de descripteur, Direct3D 12 permet également aux ressources d’être indexées dynamiquement dans les nuanceurs, ce qui offre une flexibilité sans précédent et déverrouille de nouvelles techniques de rendu. Par exemple, les moteurs de rendu différé modernes encodent généralement un matériau ou un identificateur d’objet d’un type vers la mémoire tampon g intermédiaire. Dans Direct3D 11, ces moteurs doivent être prudents pour éviter d’utiliser trop de matériaux, car l’inclusion d’un trop grand nombre dans une mémoire tampon g peut ralentir considérablement la passe de rendu finale. Avec des ressources indexables dynamiquement, une scène avec mille matériaux peut être finalisée aussi rapidement qu’une seule avec seulement dix.

Pour plus d’informations sur les segments et tables de descripteur, consultez de liaison de ressources et différences dans le modèle de liaison de Direct3D 11.

Portage à partir de Direct3D 11

Le portage de Direct3D 11 est un processus impliqué, décrit dans portage de Direct3D 11 vers Direct3D 12. Reportez-vous également à la plage d’options dans Utilisation de Direct3D 11, Direct3D 10 et Direct2D.

Comprendre direct3D 12