Prise en charge de plusieurs processeurs
Les pilotes d’affichage en mode utilisateur sur des ordinateurs à processeurs multiples peuvent permettre au runtime Microsoft Direct3D de gérer les optimisations de plusieurs processeurs, ou les pilotes peuvent effectuer leurs propres optimisations sur plusieurs processeurs.
Optimisations des Multiple-Processor gérées par le runtime
Les optimisations multiprocesseurs gérées par le runtime Direct3D sont activées uniquement sur les pilotes qui prennent en charge les fonctions LockAsync, UnlockAsync et Rename . Ces fonctions permettent aux optimisations de plusieurs processeurs de fonctionner correctement avec les applications qui verrouillent fréquemment les ressources dynamiques. Les fonctions LockAsync et UnlockAsync , ainsi que la fonction GetQueryData , doivent être réentrées sur les pilotes qui exposent une version DDI de 0x0000000B ou supérieure. Le pilote retourne la valeur de version DDI dans le membre DriverVersion de la structure D3D10DDIARG_OPENADAPTER dans un appel à la fonction OpenAdapter du pilote. Lorsque le runtime appelle une fonction de pilote de manière réentrée, un thread peut s’exécuter à l’intérieur de cette fonction tandis qu’un autre thread qui fait référence au même périphérique d’affichage s’exécute à l’intérieur d’une autre fonction de pilote.
Le runtime Direct3D utilise des optimisations de plusieurs processeurs dans certaines situations pour décharger le travail sur un processeur distinct et améliorer les performances de l’ordinateur. Lorsque les optimisations de plusieurs processeurs sont activées, une couche logicielle supplémentaire est ajoutée entre le runtime Direct3D et le pilote d’affichage en mode utilisateur. Cette couche logicielle intercepte tous les appels que le runtime Direct3D ferait autrement pour les fonctions du pilote d’affichage en mode utilisateur.
Au lieu d’appeler directement le pilote d’affichage en mode utilisateur, la couche logicielle met en file d’attente les commandes dans des lots qu’un thread de travail traite de manière asynchrone. Toutefois, la couche logicielle ne peut pas traiter par lot tous les appels effectués vers les fonctions du pilote d’affichage en mode utilisateur. En particulier, la couche logicielle ne peut pas traiter par lots les appels aux fonctions qui retournent des informations (par exemple, CreateResource). Lorsque la couche logicielle doit appeler l’un de ces types de fonctions de pilote, elle vide toutes les commandes mises en file d’attente via le thread worker, puis la couche logicielle appelle la fonction pilote sur le thread d’application main.
Optimisations des Multiple-Processor gérées par le pilote
Si un pilote effectue ses propres optimisations à plusieurs processeurs, il ne doit pas implémenter les fonctions LockAsync, UnlockAsync et Rename . Dans ce cas, le pilote doit appeler la fonction pfnSetAsyncCallbacksCb pour indiquer au runtime si le runtime démarre ou cesse de recevoir des appels aux fonctions de rappel du runtime à partir d’un thread worker.
Si le pilote effectue ses propres optimisations sur plusieurs processeurs, il doit suivre la même stratégie que celle que le runtime Direct3D utilise lorsqu’il détermine pour activer les optimisations de plusieurs processeurs. Cette stratégie permet un partage équitable des ressources système entre tous les processus. En particulier, le pilote doit désactiver les optimisations de plusieurs processeurs dans les situations suivantes :
L’application s’exécute en mode fenêtré.
L’ordinateur ne contient qu’un seul processeur (ou cœur de processeur) ; le pilote doit désactiver les optimisations sur les ordinateurs monoprocesseurs avec hyper-threading.
L’application a demandé qu’aucune optimisation de plusieurs processeurs ne soit activée, ou l’application utilise le traitement du vertex logiciel ; ces informations sont transmises à la fonction CreateDevice du pilote.
Si les fournisseurs souhaitent activer l’optimisation de plusieurs processeurs dans l’une de ces situations, ils doivent d’abord contacter Microsoft.