Copie et consultation des données des ressources
Les indicateurs d’utilisation indiquent la façon dont l’application a l’intention d’utiliser les données de ressource pour placer des ressources dans la zone de mémoire la plus performante possible. Les données de ressources sont copiées entre les ressources afin que le processeur ou le GPU puisse y accéder sans avoir d’impact sur les performances.
Il n’est pas nécessaire de considérer les ressources comme étant créées dans la mémoire vidéo ou la mémoire système, ou de décider si le runtime doit gérer ou non la mémoire. Avec l’architecture de WDDM (modèle de pilote d’affichage Windows), les applications créent des ressources Direct3D avec différents indicateurs d’utilisation pour indiquer comment l’application envisage d’utiliser les données de ressource. Ce modèle de pilote virtualise la mémoire utilisée par les ressources ; il incombe au gestionnaire de mémoire/pilote/pilote d’exploitation de placer des ressources dans la zone de mémoire la plus performante possible, compte tenu de l’utilisation attendue.
Le cas par défaut est que les ressources soient disponibles pour le GPU. Il existe des moments où les données de ressource doivent être disponibles pour l’UC. La copie des données de ressources autour de sorte que le processeur approprié puisse y accéder sans avoir d’impact sur les performances nécessite une connaissance du fonctionnement des méthodes d’API.
Copie des données de ressources
Les ressources sont créées en mémoire lorsque Direct3D exécute un appel Create. Elles peuvent être créées dans la mémoire vidéo, la mémoire système ou tout autre type de mémoire. Étant donné que le modèle de pilote WDDM virtualise cette mémoire, les applications n’ont plus besoin de suivre le type de ressources de mémoire qui sont créées.
Dans l’idéal, toutes les ressources se trouvent dans la mémoire vidéo afin que le GPU puisse y accéder immédiatement. Toutefois, il est parfois nécessaire que l’UC lise les données de ressource ou que le GPU accède aux données de ressource dans laquelle l’UC a écrit. Direct3D gère ces différents scénarios en demandant à l’application de spécifier une utilisation, puis propose plusieurs méthodes pour copier des données de ressources si nécessaire.
Selon la façon dont la ressource a été créée, il n’est pas toujours possible d’accéder directement aux données sous-jacentes. Cela peut signifier que les données de ressource doivent être copiées de la ressource source vers une autre ressource accessible par le processeur approprié. En termes de Direct3D, les ressources par défaut sont accessibles directement par le GPU, les ressources dynamiques et intermédiaires sont directement accessibles par l’UC.
Une fois qu’une ressource a été créée, son utilisation ne peut pas être modifiée. Au lieu de cela, copiez le contenu d’une ressource vers une autre ressource qui a été créée avec une autre utilisation. Vous copiez des données de ressource d’une ressource vers une autre ou copiez des données de la mémoire vers une ressource.
Il existe deux types de ressources principaux : mappable et non mappable. Les ressources créées avec des utilisations dynamiques ou intermédiaires sont mappables, tandis que les ressources créées avec des utilisations par défaut ou immuables ne sont pas mappables.
La copie de données entre les ressources non mappables est très rapide, car il s’agit du cas le plus courant et a été optimisé pour fonctionner correctement. Étant donné que ces ressources ne sont pas directement accessibles par l’UC, elles sont optimisées afin que le GPU puisse les manipuler rapidement.
La copie de données entre les ressources mappables est plus problématique, car les performances dépendent de l’utilisation avec laquelle la ressource a été créée. Par exemple, le GPU peut lire une ressource dynamique assez rapidement, mais ne peut pas y écrire, et le GPU ne peut pas lire ou écrire directement dans des ressources intermédiaires.
Les applications qui souhaitent copier des données d’une ressource avec une utilisation par défaut vers une ressource avec une utilisation intermédiaire (pour permettre au processeur de lire les données , autrement dit, le problème de lecture gpu) doivent le faire avec soin. Consultez l’accès aux données de ressources, ci-dessous.
Accès aux données de ressources
L’accès à une ressource nécessite un mappage de la ressource ; le mappage signifie essentiellement que l’application tente d’accorder à l’UC l’accès à la mémoire. Le processus de mappage d’une ressource afin que l’UC puisse accéder à la mémoire sous-jacente peut entraîner des goulots d’étranglement des performances et, pour cette raison, vous devez prendre soin de savoir comment et quand effectuer cette tâche.
Les performances peuvent se bloquer si l’application tente de mapper une ressource au mauvais moment. Si l’application tente d’accéder aux résultats d’une opération avant la fin de cette opération, un blocage du pipeline se produit.
L’exécution d’une opération de carte à un moment incorrect peut entraîner une baisse grave des performances en forçant le GPU et l’UC à se synchroniser les uns avec les autres. Cette synchronisation se produit si l’application souhaite accéder à une ressource avant la fin de la copie du GPU dans une ressource que l’UC peut mapper.
Considérations relatives aux performances
Il est préférable de considérer un PC comme une machine s’exécutant en tant qu’architecture parallèle avec deux types principaux de processeurs : un ou plusieurs processeurs et un ou plusieurs GPU. Comme dans toute architecture parallèle, les meilleures performances sont obtenues lorsque chaque processeur est planifié avec suffisamment de tâches pour l’empêcher d’être inactif et lorsque le travail d’un processeur n’attend pas le travail d’un autre.
Le pire scénario pour le parallélisme GPU/PROCESSEUR est la nécessité de forcer un processeur à attendre les résultats du travail effectué par un autre. Direct3D supprime ce coût en rendant les méthodes de copie asynchrones ; la copie n’a pas nécessairement été exécutée au moment où la méthode retourne.
L’avantage est que l’application ne paie pas le coût de performances de la copie réelle des données tant que le processeur n’accède pas aux données, c’est-à-dire lorsque map est appelé. Si la méthode Map est appelée une fois les données copiées, aucune perte de performances ne se produit. En revanche, si la méthode Map est appelée avant que les données aient été copiées, un blocage du pipeline se produit.
Les appels asynchrones dans Direct3D (qui sont la grande majorité des méthodes, et en particulier les appels de rendu) sont stockés dans ce qu’on appelle une mémoire tampon de commandes. Cette mémoire tampon est interne au pilote graphique et est utilisée pour traiter les appels par lots vers le matériel sous-jacent afin que le passage coûteux du mode utilisateur au mode noyau dans Microsoft Windows se produit aussi rarement que possible.
La mémoire tampon de commande est vidée, ce qui provoque un commutateur en mode utilisateur/noyau, dans l’une des quatre situations suivantes.
- Le présent est appelé.
- Le vidage est appelé.
- La mémoire tampon de commande est pleine ; sa taille est dynamique et est contrôlée par le système d’exploitation et le pilote graphique.
- Le processeur nécessite l’accès aux résultats d’une commande en attente d’exécution dans la mémoire tampon de commande.
Parmi les quatre situations ci-dessus, le nombre quatre est le plus critique pour les performances. Si l’application émet un appel pour copier une ressource ou une sous-ressource, cet appel est mis en file d’attente dans la mémoire tampon de commande.
Si l’application tente ensuite de mapper la ressource intermédiaire qui était la cible de l’appel de copie avant que la mémoire tampon de commande ait été vidée, un blocage du pipeline se produit, car non seulement l’appel de méthode copy doit s’exécuter, mais toutes les autres commandes mises en mémoire tampon dans la mémoire tampon de commande doivent également s’exécuter. Cela entraîne la synchronisation du GPU et de l’UC, car l’UC attend d’accéder à la ressource intermédiaire pendant que le GPU vide la mémoire tampon de commande et enfin en remplissant la ressource dont le processeur a besoin. Une fois que le GPU a terminé la copie, le processeur commence à accéder à la ressource intermédiaire, mais pendant ce temps, le GPU est inactif.
Le fait de le faire fréquemment au moment de l’exécution dégrade gravement les performances. Pour cette raison, le mappage des ressources créées avec l’utilisation par défaut doit être effectué avec soin. L’application doit attendre suffisamment longtemps pour que la mémoire tampon de commande soit vidée et que toutes ces commandes se terminent avant de tenter de mapper la ressource intermédiaire correspondante.
Combien de temps l’application doit-elle attendre ? Au moins deux images, car cela permet au parallélisme entre le ou les processeurs et le GPU d’être exploités au maximum. La façon dont fonctionne le GPU est que pendant que l’application traite le frame N en envoyant des appels à la mémoire tampon de commande, le GPU est occupé à exécuter les appels à partir de l’image précédente, N-1.
Par conséquent, si une application souhaite mapper une ressource qui provient de la mémoire vidéo et copie une ressource au niveau de l’image N, cet appel commence à s’exécuter au niveau de l’image N+1, lorsque l’application envoie des appels pour l’image suivante. La copie doit être terminée lorsque l’application traite la trame N+2.
| Frame | État du PROCESSEUR/GPU |
|---|---|
| N |
|
| N+1 |
|
| N+2 |
|
| N+3 |
|
| N+4 | ... |
Rubriques connexes