Interfaces WGF11 (WoW64)

Ce test automatisé vérifie différentes parties du matériel et du pilote pour l’exécution valide du nuanceur lorsque des interfaces sont utilisées.

Le test se concentre sur la couverture des informations de mémoire tampon masquées fournies au pilote via la DDI, qui inclut les types d’interface et les emplacements des ressources. Certaines informations utilisées dans les interfaces sont incorporées dans le nuanceur lui-même, telles que les tables de fonctions et les tables de type de classe. Le matériel est nécessaire uniquement pour appeler et indexer correctement ces tables, car le runtime effectue toute la gestion nécessaire pour conserver les informations organisées et mappées correctement.

Le test exécute uniquement des scénarios valides et vérifie que les résultats sont réussis. Aucune défaillance n’est censée se produire sur le matériel D3D11 certifiable.

Les journaux de test sur WTT, comme les tests de conformité précédents, contiennent des informations utiles sur l’échec de l’IHV à déboguer leurs échecs.

Cette rubrique s’applique aux travaux de test suivants :

• WGF11 Interfaces

• Interfaces WGF11 (WoW64)

Détails du test

Documentation supplémentaire

Les tests de cette zone de fonctionnalité peuvent avoir une documentation supplémentaire, y compris les conditions préalables, l’installation et les informations de résolution des problèmes, que vous trouverez dans les rubriques suivantes :

• Documentation supplémentaire Device.Graphics

Exécution du test

Avant d’exécuter le test, effectuez la configuration du test comme décrit dans les conditions requises pour le test : Conditions préalables pour le test de l’adaptateur graphique ou du chipset.

Dépannage

Pour la résolution des problèmes génériques des échecs de test HLK, consultez Résolution des échecs de test HLK Windows.

Pour plus d’informations sur la résolution des problèmes, consultez Résolution des problèmes liés aux tests Device.Graphics.

Le test retourne SKIP lorsqu’il est exécuté au niveau < de fonctionnalité 11. Le test retourne SKIP lorsqu’il est exécuté au niveau < de fonctionnalité 11.

Plus d’informations

WGF11Interfaces - Exécution du nuanceur d’interface

Les WGF11Interfaces couvrent tous les aspects du transfert de données vers le pilote, ainsi que l’exécution correcte du nuanceur IL.

Une description de chaque groupe de test et du paramètre de ligne de commande nécessaire est répertoriée plus loin dans cette section. Les nuanceurs entiers ne sont pas fournis dans cette documentation. Toutefois, une description de l’objectif prévu du nuanceur et des types d’entrées est décrite pour fournir des informations sur la façon de tester dans Windows Hardware Quality Labs (WHQL). En outre, chaque test est exécuté sur toutes les étapes du nuanceur pour vérifier le comportement cohérent d’une fonctionnalité qui respecte les objectifs de l’architecture unifiée.

Les tests utilisent des ints et uints comme entrées et pendant le calcul dans la mesure du possible, car la précision et la vérification des calculs à virgule flottante sont couvertes dans un test de conformité différent.

Les tests qui utilisent des échantillonneurs effectuent un échantillonnage de points et utilisent la couleur de bordure pour vérifier si l’échantillonneur correct est utilisé. Le filtrage et d’autres aspects de la couverture de l’échantillonneur sont couverts dans un test de conformité différent. Les tests d’interface concernent uniquement l’indexation correcte des échantillonneurs utilisés par les instances de classe pendant l’exécution.

Les tests qui utilisent des ressources se concentrent sur les formats avec des canaux 8 bits et aucun niveau MIP. D’autres tests vérifient l’exactitude des ressources. Les tests d’interface concernent uniquement l’indexation correcte des textures utilisées par les instances de classe pendant l’exécution. Seules les charges de ressources sont utilisées. Étant donné qu’ils ne peuvent pas être indexés, les UAV ne sont pas importants pour les interfaces.

Les tests sont exécutés sur chaque étape du nuanceur, car la fonctionnalité est censée s’intégrer à l’architecture unifiée du modèle nuanceur 5.0.

Chaque test a une tâche Pri-1 et une tâche Pri-2, qui, lorsqu’elles sont combinées, complètent la couverture de la fonctionnalité. Les tâches Pri-1 nécessitent qu’un test s’exécute uniquement sur une étape spécifique du nuanceur. Les tâches Pri-2 testent les étapes restantes du nuanceur.

Toutes les instances sont créées par le runtime à l’aide des appels d’API suivants :

HRESULT CreateClassInstance(LPCWSTR pszClassTypeName,UINT ConstantBufferOffset,UINT ConstantVectorOffset,UINT TextureOffset,UINT SamplerOffset,ID3D11ClassInstance **ppInstance);

Les instances sont définies lorsque le nuanceur est défini à l’aide d’appels XXSetShader().

WGF11Interfaces.exe Interfaces\FunctionTables and fcall\[ PS]

Pri-1 16 heures

Le test de table de fonctions volumineuse vérifie si le matériel est en mesure de gérer la sortie des programmes de nuanceur par le compilateur. Cette vérification est spécifique aux nuanceurs qui ont de nombreux appels d’interface en cascade qui ont entraîné de grandes générations de code qui ont de nombreux corps de fonction. Ce test ne teste pas les performances de ces nuanceurs, mais vérifie si l’exécution est correcte par rapport au rastériseur de référence.

Plusieurs nuanceurs sont écrits pour doubler séquentiellement le nombre de corps de fonction créés par le compilateur. Ces nuanceurs sont ensuite exécutés avec plusieurs variantes sur les instances qui remplissent les emplacements, afin de vérifier l’exécution correcte via un sous-ensemble de chemins de code. À tout moment, le test peut tenter de valider tous les chemins de code, et il est attendu que le matériel n’échoue sur aucun d’entre eux. Si le matériel retourne une mémoire insuffisante au moment de la création du nuanceur, le test retourne RESULT_SKIP, lorsque cela est raisonnable. Les besoins en ressources de ces nuanceurs ne doivent pas repousser les limites du matériel. Par conséquent, le nuanceur doit se lier et s’exécuter correctement. Si le matériel échoue sur même les petites tables de fonctions, un avertissement se produit. Le matériel doit prendre en charge un minimum de 4 Ko de corps de fonction.

Les fonctions en cascade sont conçues à l’aide de plusieurs types d’interface, chacun s’appuyant sur un objet d’un autre instance pour son paramètre. Ces appels sont conçus pour avoir plusieurs couches de profondeur et peuvent facilement entraîner la création de plus de 1 000 corps de fonction.

Le test fournit également une couverture de l’instruction fcall en appelant largement d’autres fonctions pour obtenir une couverture appropriée des corps de fonction de 4 Ko dans le nuanceur. Pour ce faire, vous pouvez faire varier les instances liées à l’aide de XXSetShader par le runtime. L’infrastructure fournit un moyen simple d’obtenir une couverture adéquate par le biais de permutations de types liés.

Pour vous assurer que le test n’a pas besoin de maintenance en raison des modifications apportées au compilateur, chaque corps de fonction doit être unique de tous les autres corps de fonction. En effet, le compilateur peut à un moment donné réduire les corps de fonction avec du code identique pour réduire la taille du code et fournir une table de fonctions plus optimisée. En vous assurant que tous les corps de fonction sont différents, vous empêchez le test d’être modifié ou de devenir obsolète lorsque cette optimisation est ajoutée au compilateur. Il est important de passer en revue l’il pour vous assurer que le code attendu est produit.

Exemple :

interface Type0{ float2 func( float x );};interface Type1{ float4 func( const Type0 param, inout float2 y );};interface Type2{ float func( Type0 param0, Type1 param1 );};interface Type3{ uint func( out float z, Type0 param0, Type1 param1, Type2 param2 );};class AT0 : Type0;class BT0 : Type0;class CT0 : Type0;class DT0 : Type0;class ET0 : Type0;class FT0 : Type0;class AT1 : Type1;class BT1 : Type1;class CT1 : Type1;class DT1 : Type1;class AT2 : Type2;class BT2 : Type2;class CT2 : Type2;class DT2 : Type2;class ET2 : Type2;class AT3 : Type3;class BT3 : Type3;class CT3 : Type3;class DT3 : Type3;class ET3 : Type3;class FT3 : Type3;

Si l’interface de Type3 est appelée et que chaque implémentation appelle la méthode d’interface d’un paramètre d’entrée, 720 corps de fonction sont créés par tous les chemins de code possibles, chacun optimisé pour son chemin de code particulier. Étant donné qu’il n’existe aucune limitation à la taille du code autre que la mémoire, même les nuanceurs très volumineux doivent s’exécuter sans erreur.

Le code du nuanceur étant optimisé sur les sites fcall, il est possible que chaque appel soit unique en fonction des informations de l’appelant et de l’appelé. La simple multiplication par une constante ne suffit pas ; au lieu de cela, chaque corps de fonction doit être unique en effectuant des opérations différentes et en utilisant des variables membres. La sortie résultante doit être vérifiée, de sorte que la multiplication par nombres premiers ou quelque chose de similaire fonctionne. Pour vérifier que le nuanceur a été exécuté correctement, la même mathématique doit être effectuée sur le processeur en fonction des instances de classe liées.

Ce test couvre également la profondeur de l’arborescence des appels (32). Il est important de vérifier que plus de 32 appels fcalls entraînent une absence d’opération (vous ne pouvez tester que 33 à un moment donné). Le compilateur n’autorise pas l’écriture de code pour tester simplement ce cas. Vous avez donc besoin d’une approche plus sophistiquée qui peut modifier dynamiquement la profondeur de l’appel et vérifier que chaque appel a été effectué (ou non).

Une séquence de fibinachi ou similaire peut être utile pour cela. Les appels récursifs ne étant pas autorisés, il doit y avoir 33 interfaces qui peuvent être appelées les unes après les autres. Localement, les instances doivent décider de poursuivre ou non la profondeur fcall. Le runtime lie les données pour conduire ces tests.

Ce test est écrit pour le nuanceur de pixels en pri-1.

La réalisation de ce test prouve ce qui suit :

• Le fcall fonctionne.

• Les tables de fonctions sont correctes et sont utilisées correctement.

• La limite de table de fonction de 4 Ko est prise en charge.

• La profondeur de l’appel est de 32.

Les résultats du test sont capturés dans la cible de rendu suivante :

WGF11Interfaces.exe Interfaces\FunctionTables and fcall \[VS,GS, HS,DS,CS]

Pri-2

Le test couvre toutes les étapes du nuanceur.

La vérification de cette fonctionnalité prend en charge un large éventail de modèles de conception valides et de techniques de programmation OO que le nuanceur modèle 5.0 a été conçu pour prendre en charge.

Les résultats de ces tests sont capturés dans une mémoire tampon de flux sortant pour VS, HS, DS et GS. Les résultats pour PS et CS sont capturés par des cibles de rendu et des tampons pouvant être écrits.

interfacesWGF11Interfaces.exe\GroupExecutionPathDifferences\[ CS]

Pri-1 40 heures

L’exploitation du parallélisme est très importante lors de la conception du matériel. Toutefois, la mise en valeur de telles opportunités ne doit pas perturber l’exécution correcte d’un nuanceur lorsque les chemins de code divergent. Ce test s’exécute sur chaque étape du nuanceur et fournit une couverture qui exécute différents chemins de code, même si les pixels, les sommets et d’autres primitives de phase de pipeline peuvent être exécutés en tant que groupes d’étapes de verrouillage. Ce test ne teste pas les performances dans de tels cas. Au lieu de cela, il vérifie uniquement un résultat valide après l’exécution.

Il est important de fournir des données à chaque étape du pipeline et doit être effectué en segments importants pour vérifier la couverture des différentes exécutions entre les groupes. La méthode suivante fournit les données aux tests pour chaque étape du nuanceur :

• Nuanceur de calcul :

  Les données utilisées pour sélectionner des instances basées sur des emplacements de tableau sont fournies à l’aide de ressources dans le nuanceur de calcul. Les SV_GroupID et les SV_GroupThreadID sont utilisés pour sélectionner les données appropriées à partir de la ressource afin de choisir les instances de classe à utiliser lors de l’appel d’un nuanceur. Les résultats de l’exécution sont écrits dans une mémoire tampon accessible en écriture pour vérifier qu’ils sont corrects. Un grand nombre de dimensions de threads dans chaque dimension est utilisé. Cela inclut un grand nombre premier de threads et plusieurs groupes qui seront distribués pour obtenir une couverture adéquate pour ce test.

Chaque thread matériel doit exécuter un appel de méthode dans un type différent fourni par le runtime. Le runtime est en mesure de calculer le résultat de la vérification en fonction du type utilisé, des données fournies et de l’algorithme du type. Le code de chaque méthode doit varier en longueur et en complexité pour prouver que le matériel peut gérer des nuanceurs comme celui-ci. 12 à 18 implémentations de classes différentes doivent être utilisées, et chaque valeur de SV_[Index] peut être pseudo-rembourrée pour choisir quel index de tableau et quelle classe instance exécuter.

interfacesWGF11Interfaces.exe\GroupExecutionPathDifferences\[VS,GS,PS,HS,DS]

Pri-2 40 heures

Le test est étendu aux autres étapes du nuanceur.

• Nuanceur de vertex :

  Un ensemble d’index de tableau d’emplacements d’interface est ajouté aux données de vertex et utilisé lors de l’exécution du nuanceur de vertex pour déterminer l’interface instance appeler. Les données couvrent également les instances utilisées comme paramètres lorsque des méthodes sont appelées. Un bloc d’au moins 512 points est dessiné pour vérifier le comportement du matériel. Les résultats sont interceptés par une mémoire tampon de flux.

• Nuanceur de coque :

  Les index du tableau d’emplacements d’interface sont ajoutés à la structure d’entrée du point de contrôle, ce qui permet à chaque point de déterminer quelles instances de classe sont appelées au cours du nuanceur. Ces données couvrent également les instances utilisées comme paramètres lorsque des méthodes sont appelées. Un correctif complet de 32 points est dessiné plusieurs fois pour vérifier le comportement du matériel. Les résultats seront interceptés par un tampon de sortie de flux.

  Ce test transfère également les données à la fonction Patch Constant, qui vérifie également le comportement correct.

  En outre, le SV_OutputControlPointID et le code de duplication spécifique sont activés dans le compilateur. Le code de duplication provoque également des chemins d’exécution de code divergents à l’aide d’interfaces dans cette phase. La duplication est accessible à l’aide d’une boucle et en appelant une méthode d’interface à partir de la boucle.

• Nuanceur de domaine :

  Les données sont transmises via le nuanceur Hull sur chaque point de contrôle, puis récupérées à l’aide des SV_PrimitiveID disponibles dans le nuanceur de domaine. Les positions de sortie du tessellateur sont combinées avec les SV_PrimitiveID pour créer les index dans la classe instance emplacements disponibles pendant l’exécution. Le correctif complet de 32 points est dessiné plusieurs fois pour vérifier le comportement du matériel. Les résultats sont interceptés par une mémoire tampon de flux. L’objectif n’est pas de couvrir tous les types de domaine.

• Nuanceur de géométrie :

  Les index d’emplacement d’interface sont attachés aux primitives de points fournies au nuanceur de géométrie. Les index sont utilisés pour choisir des instances de classe sur lesquelles appeler des méthodes et les utiliser comme paramètres pendant l’exécution du nuanceur. Un bloc d’au moins 512 points est dessiné pour vérifier le comportement du matériel. Les résultats sont capturés dans une mémoire tampon de sortie de flux à des fins de vérification.

• Nuanceur de pixels :

  Pour les nuanceurs de pixels, une texture est utilisée pour fournir la classe instance index pour chaque pixel. La texture correspond exactement à la taille de la cible de rendu en dessinant un grand quad. Une zone d’au moins 512 x 512 pixels est dessinée, avec les ressources de prise en charge, pour vérifier le comportement matériel. Les résultats sont capturés dans une cible de rendu pour validation. SV_Position et SV_SampleIndex peuvent également être utilisés pour déterminer la façon dont un index de pixel entre dans les emplacements d’interface. Dessiner un triangle est plus intéressant que dessiner un quad.

WGF11Interfaces.exe Interfaces\IndexingResources and this[]\[VS]

Pri-1 26 heures

Toutes les ressources utilisées par une interface ont été rendues indexables par l’il afin de prendre en charge la liaison de runtime dynamique. Les données sont fournies par le biais de la DDI et incluent les informations suivantes :

• ID de type de classe

• Cbuffer

• Décalage Cbuffer

• Emplacement de texture

• Emplacement de l’échantillonneur

Ce test garantit que toutes ces informations sont utilisées correctement par l’exécution du pilote et du nuanceur. L’accès à ces informations ne peut être effectué que via le mot clé « this », qui utilise une mémoire tampon réservée masquée. Les instances de classe de 256 octets peuvent être liées à un nuanceur. Ce test fournit donc une couverture pour l’utilisation des 256 emplacements instance. Cela implique que cela doit être utilisé en combinaison avec chacun des autres domaines de ce test. Toutefois, les autres zones n’ont pas besoin d’être vérifiées par permutation entre elles.

L’emplacement des cycles de test pour tous les différents emplacements et décalages dans les ressources et utilise ces ressources lors de la production des résultats.

Pour obtenir une couverture complète, chaque instance de classe doit exécuter une méthode qui utilise les données de ressource pour produire un résultat. Ce faisant, il garantit que l’ID de type instance est utilisé correctement par rapport aux tables de fonctions.

Chaque cbuffer doit être testé pour les données de classe. Les données doivent être placées dans la mémoire tampon à l’aide du paramètre offset. Pour ce faire, vous pouvez lier 256 instances avec chacune un emplacement différent défini par le runtime. Le nuanceur peut exécuter 256 sommets et utiliser le SV_PrimitiveID pour déterminer l’emplacement instance à utiliser.

Chaque emplacement tbuffer dans le 128 disponible doit être utilisé de la même manière que mentionné précédemment. Seule une mémoire tampon ou texture2d simple doit être utilisée, et seule l’instruction de chargement est testée. Le test s’intéresse uniquement à l’indexation correcte des registres de textures.

Chaque emplacement d’échantillonneur dans les 16 phases disponibles pour un nuanceur doit être utilisé de la même manière que mentionné précédemment. Les échantillonneurs seront échantillonné en dehors de la limite de texture afin qu’une couleur de bordure soit retournée. Chacun des 16 échantillonneurs doit avoir une couleur de bordure unique pour que le test vérifie que l’échantillonneur correct a été utilisé.

Ceux-ci peuvent être testés séparément. La couverture combinée n’est pas nécessaire.

F11Intefaces.exe Interfaces\IndexingResources and this[]\[GS,PS,HS,DS,CS]

Pri-2 26 heures

Le test précédent est étendu pour couvrir toutes les étapes du nuanceur.

(Pri 1 18 heures) Le contexte différé doit également être utilisé dans ces tests.

Les cas de test décrits seront également exécutés sur un contexte différé à l’aide de listes de commandes pour définir des classes et des instances.

Les listes de commandes n’héritent pas de l’état du contexte immédiat. Par conséquent, les instances définies sur le contexte immédiat ne doivent pas être accessibles lors de l’exécution d’une liste de commandes.

L’effacement d’état sur le contexte différé (via le paramètre bool dans ExecuteCommandList et FinishCommandList) doit être testé avec des interfaces et des classes.

Syntaxe de commande

Liste de fichiers

Paramètres