Partager via


Prise en charge des threads, des listes de commandes et du pipeline 3D

Cette section s’applique uniquement à Windows 7 et versions ultérieures et Windows Server 2008 R2 et versions ultérieures du système d’exploitation Windows.

Un pilote d’affichage en mode utilisateur indique les nouvelles fonctionnalités direct3D version 11 qu’il prend en charge (par exemple, threading, listes de commandes et pipeline 3D) lorsque le runtime Direct3D version 11 appelle la fonction GetCaps(D3D10_2) du pilote. GetCaps(D3D10_2) est l’une des fonctions spécifiques à l’adaptateur du pilote que le pilote fournit dans la structure D3D10_2DDI_ADAPTERFUNCS vers laquelle pointe le membre pAdapterFuncs_2 de la structure D3D10DDIARG_OPENADAPTER . Pour plus d’informations sur la fourniture de fonctions spécifiques à l’adaptateur lors de l’initialisation du pilote, consultez Initialisation de la communication avec le DDI Direct3D version 11. Lorsque sa fonction GetCaps(D3D10_2) est appelée, le pilote d’affichage en mode utilisateur fournit de nouvelles fonctionnalités Direct3D version 11 en fonction du type de requête (qui est spécifié dans le membre Type de la structure D3D10_2DDIARG_GETCAPS vers laquelle pointe le paramètre pData de la fonction GetCaps(D3D10_2).

Threading et listes de commandes

L’API Direct3D version 11 nécessite un mode de fonctionnement où elle peut synchroniser les threads d’application pour s’assurer qu’un seul des threads s’exécute dans la DDI à la fois. L’API Direct3D version 11 nécessite également un mode de fonctionnement avec une émulation logicielle de listes de commandes. Ces modes de fonctionnement sont requis par et exploités sur les DDI de version antérieure (par exemple, le DDI Direct3D version 10). Par conséquent, en tant qu’aide au développement pour les enregistreurs de pilotes, ces mêmes modes de fonctionnement sont étendus pour exister sur le DDI Direct3D version 11. Les enregistreurs de pilotes peuvent décider des modes d’opérations qu’ils souhaitent que leurs pilotes prennent en charge pour la DDI Direct3D version 11.

Tous les pilotes doivent à terme prendre entièrement en charge tous les types d’opérations de threading (autrement dit, tous les pilotes doivent à terme prendre en charge toutes les fonctionnalités de thread de la structure D3D11DDI_THREADING_CAPS ). Toutefois, le pilote peut exiger que l’API émule des listes de commandes ou applique un mode de fonctionnement à thread unique pour le pilote. L’API doit connaître les fonctionnalités de thread du pilote lors de la création d’un périphérique API, mais avant la création d’un appareil DDI. Par conséquent, le runtime détermine les fonctionnalités de thread du pilote lorsqu’il appelle la fonction spécifique à l’adaptateur GetCaps(D3D10_2) du pilote avec le membre Type de D3D10_2DDIARG_GETCAPS défini sur D3D11DDICAPS_THREADING. Le pilote retourne un pointeur vers une structure D3D11DDI_THREADING_CAPS dans le membre pData de D3D10_2DDIARG_GETCAPS qui identifie les fonctionnalités de thread du pilote. Le pilote doit prendre en charge le mode thread libre (D3D11DDICAPS_FREETHREADED) si le pilote prend également en charge les listes de commandes (D3D11DDICAPS_COMMANDLISTS_BUILD_2), car les listes de commandes s’appuient sur le mode thread libre. Le pilote doit accepter de prendre en charge les listes de commandes et de mode avec thread libre. L’application peut déterminer la prise en charge indiquée par le pilote par l’utilisation de la fonction CheckFeatureSupport au niveau de l’application et de la constante D3D11_FEATURE_THREADING ; toutefois, certaines applications peuvent ne pas s’en soucier en raison de la prise en charge que fournit l’API.

Niveau de pipeline 3D

Les pilotes qui prennent en charge direct3D version 11 DDI ne sont pas nécessaires pour prendre en charge toutes les fonctionnalités matérielles du DDI Direct3D version 11. Les pilotes peuvent prendre en charge le nouveau modèle de thread de direct3D version 11 DDI sur le matériel qui prend uniquement en charge direct3D version 10 DDI. Le runtime Direct3D version 11 détermine le niveau de support matériel maximal du pilote lorsque le runtime appelle la fonction GetCaps(D3D10_2) du pilote avec le membre Type de D3D10_2DDIARG_GETCAPS défini sur D3D11DDICAPS_3DPIPELINESUPPORT. Le pilote retourne un pointeur vers une structure D3D11DDI_3DPIPELINESUPPORT_CAPS dans le membre pData de D3D10_2DDIARG_GETCAPS qui identifie le niveau matériel maximal de prise en charge.

L’API n’utilise pas uniquement la version DDI comme indicateur principal de la prise en charge des fonctionnalités de l’API ; l’API permet au pilote de revenir dans ce processus. Le runtime choisit une valeur de D3D11DDI_3DPIPELINELEVEL et la renvoie au pilote lors de la création de l’appareil lors d’un appel à la fonction CreateDevice(D3D10) du pilote, dans le cadre du membre Flags de la structure D3D10DDIARG_CREATEDEVICE .

Si le pilote prend en charge des niveaux matériels inférieurs à Direct3D version 11 sur le DDI Direct3D version 11, il existe des ramifications mineures dans le fonctionnement du pilote. La première est que le runtime Direct3D version 11 n’appelle peut-être jamais de nombreuses nouvelles fonctions DDI Direct3D version 11. Par exemple, le runtime Direct3D version 11 n’appelle aucune des nouvelles fonctions DDI au niveau du nuanceur (comme DsSetShader) si le pilote prend en charge un niveau de fonctionnalité matérielle inférieur à Direct3D version 11. Les autres fonctions DDI suivent les règles du niveau de fonctionnalité et ignorent le fait que la DDI Direct3D version 11 peut être associée à des fonctionnalités supérieures. Par exemple, même si IAVertexInputSlots pour l’API Direct3D version 11 est 32, le niveau de fonctionnalité Direct3D version 10 n’autorise que 16 et c’est ce que le pilote doit attendre.

Les fonctionnalités déconseillées ou converties présentent un autre aspect intéressant. La dépréciation n’est pas possible au niveau de Direct3D version 11 DDI, car la dépréciation doit prendre en charge la possibilité d’exprimer des fonctions DDI de version antérieure. Par exemple, la version de l’API Direct3D 11 de PIPELINESTATS est toujours constante ; toutefois, il demande différents D3D10_DDI_QUERY_DATA_PIPELINE_STATISTICS avec les niveaux de fonctionnalités Direct3D 10 et D3D11_DDI_QUERY_DATA_PIPELINE_STATISTICS avec les niveaux de fonctionnalités Direct3D 11, etc. Même si l’API a tenté de déprécier la taille du filtre de texte, il est plus facile pour les pilotes de déprécier l’entrée de la table de fonction DDI, dans son intégralité, que de tenter de réutiliser l’entrée de la table de fonctions pour autre chose.

Même si un pilote qui prend en charge direct3D version 11 DDI ne prend pas en charge le niveau de fonctionnalité Complet de Direct3D version 11, le pilote ne peut pas refuser la « sensibilisation au format étendu », comme décrit dans Prise en charge de la prise en charge du format étendu. Étant donné que le pilote prend en charge direct3D version 11 DDI, le pilote doit gérer les tâches suivantes :

  • Prendre en charge les formats BGR

  • Répondez correctement aux appels à sa fonction CheckFormatSupport pour case activée de support XR_BIAS. Le pilote doit demander la prise en charge ou refuser la prise en charge.

  • Autoriser la conversion de mémoires tampons arrière entièrement typées

L’API Direct3D version 11 indique également au pilote si l’application utilise plusieurs threads via l’indicateur D3D11DDI_CREATEDEVICE_FLAG_SINGLETHREADED. Si cet indicateur est présent dans le membre Indicateurs de la structure D3D10DDIARG_CREATEDEVICE lorsqu’un périphérique d’affichage est créé par le biais d’un appel à la fonction CreateDevice(D3D10) du pilote, le pilote peut déterminer qu’aucun contexte différé n’est créé et que le pilote n’est pas tenu de se synchroniser, car les créations simultanées ne se produisent pas.