Fonctions WDDM 2.1

Cet article fournit des détails sur les fonctionnalités et les améliorations de la version 2.1 du modèle de pilote d’affichage Windows (WDDM), qui est disponible à partir de l’édition anniversaire de Windows 10 (Windows 10, version 1607).

WDDM 2.1 lui-même est facultatif. S’il est implémenté, c’est une collection de capacités de pilote obligatoires et facultatives. Un pilote qui prend en charge l’une de ces capacités de WDDM 2.1 doit prendre en charge toutes les capacités obligatoires. Les tests du Windows Hardware Lab Kit (HLK) peuvent valider la prise en charge, mais Dxgkrnl vérifie la cohérence des capacités et des DDI.

Tableau des exigences WDDM 2.1

WDDM 2.1 prend en charge les versions D3D suivantes : D3D9, D3D10, D3D10.1, D3D11, D3D11.x, D3D12

Améliorations de l’offre et de la récupération

La fonction de rappel PFND3DDDI_RECLAIMALLOCATIONS3CB a été ajoutée pour réduire l’empreinte mémoire des applications fonctionnant en mode arrière-plan. Cette interface permet aux applications d’offrir des ressources acceptables pour une désallocation complète lorsqu’elles passent en arrière-plan. En conséquence, le gestionnaire de durée de vie des processus est capable de récupérer plus de mémoire des applications en arrière-plan qui utilisent DirectX, ce qui réduit le nombre de terminaisons d’applications en arrière-plan en cas de pression sur la mémoire.

Autres changements de DDI :

• Rappel PFND3DDDI_UPDATEALLOCATIONPROPERTYCB
• Rappel PFND3DDDI_OFFERALLOCATIONS2CB
• D3DDDICB_OFFERALLOCATIONS2, structure
• D3DDDICB_RECLAIMALLOCATIONS3, structure

Pour plus d’informations sur l’offre et la récupération de ressources, veuillez consulter la section Changements d’offre et de récupération.

Prise en charge des applications avec Windows GameDVR

L’édition anniversaire de Windows 10 inclut une capacité améliorée d’utiliser la barre de jeu Windows et GameDVR avec les jeux en plein écran.

Les pilotes WDDM 2.1 doivent prendre en charge une fonctionnalité de performance appelée présentation par lot, qui ajoute la prise en charge du multi-threading pour les chaînes d’échange en mode flip. Cette fonctionnalité essentielle garantit que les jeux en plein écran avec la barre de jeu fonctionnent au même niveau de performance que dans les versions précédentes de Windows.

Les DDI suivants ont été ajoutés pour activer cette fonctionnalité :

• Rappel PFND3DDDI_SYNCTOKENCB
• Structure D3DDDIARG_SYNCTOKEN
• Rappel PFND3DDDI_SYNCTOKEN

Affichage indirect

Dans WDDM 2.1, l’affichage indirect permet aux écrans connectés via USB de participer à toutes les mêmes expériences utilisateur que tout autre moniteur. De plus, un pilote d’affichage indirect (IDD) est un pilote en mode utilisateur, ce qui est plus simple à développer qu’un pilote en mode noyau, et contribue ainsi à une fiabilité globale accrue du système.

Dans WDDM 2.1, les fonctionnalités/expériences d’affichage USB suivantes sont activées :

• Lorsque un écran USB est connecté à une plateforme Windows ou lors de la mise à niveau des systèmes d’exploitation, les pilotes appropriés sont téléchargés et installés à partir de Windows Update.

• La connexion de moniteurs au matériel d’affichage USB détecte et définit la topologie du moniteur, la résolution et les DPI corrects.

• Les utilisateurs peuvent modifier la résolution et l’échelle du moniteur.

• Les utilisateurs peuvent déconnecter et reconnecter les écrans USB sans effets secondaires inattendus.

• La topologie du moniteur est conservée lors de la déconnexion et de la reconnexion au même moniteur.

• Les écrans USB fonctionnent correctement dans divers états d’alimentation, y compris le mode veille et la mise en veille prolongée.

Pour plus d’informations sur l’affichage indirect, veuillez consulter la section Vue d’ensemble du modèle de pilote d’affichage indirect

Magasin de pilotes et installation côte à côte

WDDM 2.1 introduit l’installation des pilotes graphiques via le magasin de pilotes. Ce mécanisme d’installation des pilotes graphiques améliore la résilience des mises à jour de pilotes à partir de Windows Update. Il élimine les incompatibilités de version des fichiers de pilote qui entraînent des instabilités du système et des redémarrages initiés par l’utilisateur. Chaque mise à jour de pilote ultérieure sera exécutée directement à partir de son emplacement unique dans le magasin de pilotes (c’est-à-dire System32\DriverStore\FileRepository\[…]), évitant ainsi les écrasements et incompatibilités de fichiers de pilotes.

La mise en œuvre de la fonctionnalité du magasin de pilotes nécessite des modifications du fichier INF du pilote graphique afin de garantir que les fichiers du pilote sont copiés dans le référentiel de pilotes unique. Les modifications INF sont expliquées en plus de détails dans la section Exigences INF.

DXIL

WDDM 2.1 introduit la transition de la pile de compilateurs de shaders GPU du DirectX Byte Code (DXBC) au DirectX Intermediate Language (DXIL), un nouveau format pour transmettre les instructions de shaders au GPU. La transition vers DXIL offre les avantages suivants aux développeurs :

• Programmabilité. La facilité de développement est améliorée et la complexité du processus de création de shaders est réduite pour les développeurs en minimisant les différences entre la syntaxe de programmation GPU et les langages CPU avec lesquels les développeurs sont familiers.

• Compilateur haute performance :

  • Performance des shaders en temps réel est activée pour offrir des performances améliorées.
  • DXIL fournit un ensemble d’intrinsèques qui permet le partage de données entre les voies des processeurs SIMD dans les GPU.

• Flexibilité du flux de travail : DXIL permet aux développeurs de contrôler leurs propres outils personnalisés et passes d’optimisation et de choisir quelles étapes de compilation sont appliquées au moment de la construction ou à l’exécution.

• Fonctionnalités avancées du langage : Un langage évolué fournit des fonctionnalités clés qui éliminent les différences entre le code GPU et le code CPU, et aplatissent la courbe d’apprentissage pour les programmeurs GPU.

Grâce à ces fonctionnalités axées sur l’apport de bénéfices aux développeurs, les utilisateurs finaux bénéficient d’une amélioration des performances des nouveaux jeux ou des jeux mis à jour, même lorsqu’ils sont exécutés sur du matériel existant.

Partage de surface mémoire DirectX pour les scénarios de caméra/capture

Dans WDDM 2.1, un composant serveur de trames a été introduit pour partager une caméra ou un appareil de capture entre plusieurs processus simultanément. Les trames capturées peuvent être enregistrées dans un seul emplacement mémoire auquel plusieurs applications peuvent accéder, au lieu de copier les données d’image entre processus et co-processus plusieurs fois. Cette fonctionnalité permet une gestion plus efficace des images capturées entre plusieurs processus, des économies d’énergie, une réduction de la bande passante et une réduction de la latence pour le matériel et les pilotes compatibles WDDM 2.1. Le résultat final est un gain de performances pour les applications et les utilisateurs.

Le serveur de trames alloue une image capturée en tant que mémoire partageable entre processus, et partage cette mémoire avec les processus demandant l’accès. Puisque le serveur de trames diffuse la texture à plusieurs processus clients, la texture doit prendre en charge la lecture concurrente. Actuellement, les textures NV12 sont prises en charge à cette fin.

Mise en cache et bibliothèque d’objets d’état de pipeline (PSO)

L’objet d’état de pipeline (PSO) est une interface qui représente les instructions et les ressources (également appelées état) du pipeline graphique comme un objet unifié pour réduire les incompatibilités entre les décompositions d’état de D3D et du pilote. L’exécution d’applications et de jeux graphiquement exigeants nécessite la création d’un grand nombre de PSO. Le PSO a été introduit dans D3D12.

La bibliothèque et la mise en cache PSO de WDDM 2.1 permettent aux applications de jeu de stocker un PSO sur un support physique après avoir été créées lors de la première exécution. Cette fonctionnalité permet à l’exécution D3D de récupérer les PSO pré-créés à partir de la bibliothèque lors des instances futures, réduisant ainsi le temps d’extraction des PSO. Par exemple, lors de l’exécution d’un jeu après la première fois ou après un redémarrage du PC, le contenu sera chargé à partir de la bibliothèque physique sous forme de PSO enregistrés.

Horodatages de début de pipeline GPU

Dans WDDM 2.1, la capacité de récupérer les horodatages des événements graphiques de début dans le pipeline GPU a été introduite. Cette fonctionnalité, utilisée avec les horodatages de fin de pipeline, fournit aux développeurs une visualisation claire et fine des parallélisations, pipelines et temporisations des activités de leur application sur le GPU. Les développeurs peuvent optimiser davantage leur code et enquêter sur les inefficacités et autres problèmes de performance lorsqu’ils disposent du temps d’exécution de chaque événement.

Cette fonctionnalité contribue à activer la collecte de données de performance GPU « en temps réel et à faible surcharge » tout en fournissant suffisamment d’informations pour visualiser et mesurer les charges de travail sur les GPU. L’objectif de cette fonctionnalité est de fournir suffisamment d’informations pour reconstruire l’ordre exact et la durée des opérations exécutées par le GPU. Avec ces informations, les outils peuvent visualiser le parallélisme et les pipelines avec un moteur, mesurer les charges de travail GPU et identifier les problèmes potentiels de synchronisation.

Visualisation du microcode GPU

WDDM 2.1 permet aux développeurs d’optimiser davantage leurs shaders en présentant une visualisation du microcode GPU. Les développeurs programment le pipeline graphique en créant des shaders dans un langage de shader de haut niveau (HLSL), qui sont ensuite compilés dans un langage intermédiaire pour le pilote GPU. Le pilote effectue des compilations et des optimisations supplémentaires pour convertir ce code en instructions spécifiques au GPU qui restaient opaques aux développeurs. Grâce à cette fonctionnalité, les développeurs peuvent visualiser un code spécifique au GPU lisible pour évaluer l’étendue de l’optimisation de leurs shaders et leur vitesse.

Cette fonctionnalité permet au pilote en mode utilisateur (UMD) de commenter chaque étape programmable du pipeline graphique (shaders) et de renvoyer des informations exploitables sur l’utilisation ou la mauvaise utilisation de ces shaders par le programmeur. Le microcode spécifique au GPU est désassemblé et présenté dans un format lisible sous forme de chaîne accompagné des commentaires du UMD. Les développeurs peuvent voir leur code HLSL mappé à un code GPU lisible côte à côte, ce qui leur permet de modifier dynamiquement leur code et de voir les résultats des optimisations du compilateur sur le code GPU.

Détermination de la version WDDM

Capacités WDDM 2.1

Les pilotes signalent la prise en charge de WDDM 2.1 via DXGK_DRIVERCAPS::WDDMVersion avec la constante de version :

DXGK_WDDMVERSION::DXGKDDI_WDDMv2_1 = 0x2100

Dxgkrnl n’utilise pas le cap WDDMVersion pour déterminer les fonctionnalités prises en charge ; cette tâche est laissée à d’autres caps ou à la présence de DDI. Cependant, si le pilote signale la prise en charge de WDDM 2.1 via le cap WDDMVersion, Dxgkrnl valide que les caps ou DDI requis par WDDM 2.1 sont présents et échoue à créer l’adaptateur s’ils ne le sont pas. Les capacités incohérentes entraînent un échec de création de l’adaptateur ou du segment.

La constante suivante a été ajoutée pour correspondre à KMT_DRIVERVERSION_WDDM_2_1 :

typedef enum _DXGIDRIVERMODELVERSION
{
    DXGIDMVERSION_1_0            = 1000,
    DXGIDMVERSION_1_1_PRERELEASE = 1102,
    DXGIDMVERSION_1_1            = 1105, 
    DXGIDMVERSION_1_2            = 1200,
    DXGIDMVERSION_1_3            = 1300,
    DXGIDMVERSION_2_0            = 2000,
    DXGIDMVERSION_2_1            = 2100,

} DXGIDRIVERMODELVERSION;

Les versions d’interface DDI dans le pilote en mode noyau (KMD) sont les suivantes :

#define DXGKDDI_INTERFACE_VERSION_VISTA      0x1052
#define DXGKDDI_INTERFACE_VERSION_VISTA_SP1  0x1053
#define DXGKDDI_INTERFACE_VERSION_WIN7       0x2005
#define DXGKDDI_INTERFACE_VERSION_WIN8       0x300E
#define DXGKDDI_INTERFACE_VERSION_WDDM1_3    0x4002
#define DXGKDDI_INTERFACE_VERSION_WDDM1_3_PATH_INDEPENDENT_ROTATION  0x4003
#define DXGKDDI_INTERFACE_VERSION_WDDM2_0    0x5023
#define DXGKDDI_INTERFACE_VERSION_WDDM2_1    0x6002

Exigences INF pour les pilotes graphiques

Les pilotes graphiques WDDM 2.1 ont des exigences INF différentes par rapport aux pilotes WDDM 2.0 ou antérieurs :

1. WDDM 2.1 doit avoir un score de fonctionnalité identique à celui du pilote graphique WDDM 2.0 (D1).

2. Les pilotes graphiques WDDM 2.1 doivent utiliser une section INF d’installation de l’OS différente.

3. Modifications INF du pilote graphique WDDM 2.1 pour l’installation dans le « magasin de pilotes ».

Pour plus d’informations, veuillez consulter la section Sections et directives du fichier INF.

Les fichiers pilotes 32 bits et 64 bits resteront dans et seront chargés à partir du magasin de pilotes. La redirection du système de fichiers WoW64 ne s’applique pas au magasin de pilotes. Les IHVs peuvent spécifier des sous-dossiers en utilisant la syntaxe INF standard pour créer, par exemple, un dossier WoW64 sous le dossier unique du magasin de pilotes si désiré.

L’exemple suivant montre comment un INF prenant en charge l’exécution à partir du magasin de pilotes diffère du comportement précédent.

WINDOWS 10 ANNIVERSARY EDITION APPROACH: RUNNING DRIVERS FROM THE DRIVER STORE
[DestinationDirs]
KMDCopyFiles = 13
UMDCopyFiles = 13
UMDWoW64CopyFiles = 13

[DDInstall]
CopyFiles=KMDCopyFiles
CopyFiles=UMDCopyFiles
CopyFiles=UMDWoW64CopyFile

[KMDCopyFiles]
myKMD.sys

[UMDCopyFiles]
myUMD64.dll
myOpenCL64.dll
myOpenGL64.dll

[UMDWow64CopyFiles]
myUMD32.dll
myOpenCL32.dll
myOpenGL32.dll

[DDInstall.Services]
AddService = serviceName, 0x00000002, serviceName_Service_Inst

[serviceName_Service_Inst]
ServiceBinary = %13%\serviceName.sys

[regAdd]
HKR,,UserModeDriverName,%REG_MULTI_SZ%,%13%\myUMD64.dll, %13%\myUMD64.dll, %13%\myUMD64.dll, %13%\myUMD64.dll
HKR,,UserModeDriverNameWoW,%REG_MULTI_SZ%, %13%\myUMD32.dll, %13%\myUMD32.dll, %13%\myUMD32.dll, %13%\myUMD32.dll
HKLM,"Software\Khronos\OpenCL\Vendors",%13%\myOpenCL64.dll,%REG_DWORD%,0x00000000
HKLM,"Software\Wow6432Node\Khronos\OpenCL\Vendors",%13%\ myOpenCL32.dll,%REG_DWORD%,0x00000000
HKR,,OpenGLDriverName,%REG_MULTI_SZ%,%13%\myOpenGL64.dll
HKR,,OpenGLDriverNameWoW,%REG_MULTI_SZ%,%13%\myOpenGL32.dll

Pour spécifier un sous-dossier, les pilotes peuvent utiliser la syntaxe montrée dans l’exemple suivant :

...
[DestinationDirs]
...
UMDWoW64CopyFiles = 13,WoW64
...
[regAdd]
...
HRK,, UserModeDriverNameWoW,%REG_MULTI_SZ%, %13%\WoW64\myUMD.dll, %13%\WoW64\myUMD.dll, %13%\

The manufacturer install section decoration for Windows 10 Anniversary edition WDDM 2.1 drivers is as follows: 
...
[Manufacturer]
%Grfx_Manf% =  IHVGfx, NTamd64.10.0…14310
...
[IHVGfx.NTamd64.10.0…14310]
; HW ID list
[list of HW IDs]

Contrôle de version des pilotes

Les fichiers DLL et SYS du pilote pour un adaptateur graphique ou un jeu de puces doivent avoir une version de fichier correctement formatée.

Le fichier d’informations du pilote (.inf), le pilote en mode noyau (.sys) et les informations de version du pilote en mode utilisateur (.dll) doivent correspondre. De plus, les informations de version pour tous les fichiers identifiés dans la section [SignatureAttributes] du .inf comme des binaires PETrust doivent correspondre au .inf. Il est recommandé que les informations de version des binaires supplémentaires dans un package de pilotes correspondent au .inf.

Pour être cohérent avec les exigences de version des fichiers des systèmes d’exploitation hérités, le formatage de la version des fichiers doit suivre un modèle AA.BB.CCCCC.DDDDD où :

• AA indique la version du modèle de pilote de l’appareil le plus performant répertorié dans le .inf

• BB (pour les pilotes WDDM 1.2 et supérieurs) indique le niveau de fonctionnalité D3D le plus élevé disponible de l’appareil le plus performant répertorié dans le .inf

• BB (pour les pilotes WDDM 1.1 et inférieurs) indique la version DDI la plus élevée disponible prise en charge par l’appareil le plus performant répertorié dans le .inf

• CCCCC est un nombre allant jusqu’à cinq chiffres de 0 à 65535 choisi par le vendeur

• DDDDD est un nombre allant jusqu’à cinq chiffres de 0 à 65535 choisi par le vendeur

Valeurs pour le champ AA :

Valeurs pour le champ BB (WDDM 1.2 et les versions ultérieures) :

Valeurs pour le champ BB (WDDM 1.1 et les versions antérieures) :

Exemples

• Windows Vista WDDM 1.0 :

  • Les pilotes D3D9 DDI peuvent utiliser 7.14.0000.0000 à 7.14.9999.9999
  • Les pilotes D3D10 DDI peuvent utiliser 7.15.0000.0000 à 7.15.9999.9999

• Windows 7 WDDM 1.1 :

  • Les pilotes D3D9 DDI peuvent utiliser 8.14.0000.0000 à 8.14.9999.9999
  • Les pilotes D3D10 DDI peuvent utiliser 8.15.0000.0000 à 8.15.9999.9999
  • Les pilotes D3D11 DDI avec FL_10_0 peuvent utiliser 8.16.0000.0000 à 8.16.9999.9999
  • Les pilotes D3D11 DDI avec FL_11_0 peuvent utiliser 8.17.0000.0000 à 8.17.9999.9999

• Windows 8 WDDM 1.2 :

  • Les pilotes FL_10_0 HW peuvent utiliser 9.15.0000.0000 à 9.15.9999.9999
  • Les pilotes FL_10_1 HW peuvent utiliser 9.16.0000.0000 à 9.16.9999.9999
  • Les pilotes FL_11_0 HW peuvent utiliser 9.17.0000.0000 à 9.17.9999.9999
  • Les pilotes FL_11_1 HW peuvent utiliser 9.18.0000.0000 à 9.18.9999.9999

• Windows 8.1 WDDM 1.3 :

  • Les pilotes FL_10_0 HW peuvent utiliser 10.15.0000.0000 à 10.15.9999.9999
  • Les pilotes FL_10_1 HW peuvent utiliser 10.16.0000.0000 à 10.16.9999.9999
  • Les pilotes FL_11_0 HW peuvent utiliser 10.17.0000.0000 à 10.17.9999.9999
  • Les pilotes FL_11_1 HW peuvent utiliser 10.18.0000.0000 à 10.18.9999.9999

• Windows 10 WDDM 2.0 :

  • Les pilotes FL_11_1 HW peuvent utiliser 20.18.0000.0000 à 20.18.65535.65535
  • Les pilotes FL_12_0 HW peuvent utiliser 20.19.0000.0000 à 20.19.65535.65535
  • Les pilotes FL_12_1 HW peuvent utiliser 20.20.0000.0000 à 20.20.65535.65535

• Windows 10 WDDM 2.1 :

  • Les pilotes FL_11_1 HW peuvent utiliser 20.18.0000.0000 à 21.18.65535.65535
  • Les pilotes FL_12_0 HW peuvent utiliser 20.19.0000.0000 à 21.19.65535.65535
  • Les pilotes FL_12_1 HW peuvent utiliser 20.20.0000.0000 à 21.20.65535.65535

Mise en application

Un test obligatoire dans la liste de certification HLK pour les builds de Windows 10 supérieurs à 10586 applique les règles spécifiées dans cet article. Le test est facultatif pour les versions antérieures du système d’exploitation. Pour les builds de Windows 10 après 10586, la version WDDM a été mise à jour vers 2.1. Une autre façon de voir cela est que l’exigence obligatoire ne s’applique qu’aux pilotes construits pour WDDM 2.1 ou supérieur.