Partager via

Niveau de fonctionnalité Direct3D 12 Core 1.0

  • Article

Le niveau de fonctionnalité Core 1.0 est un sous-ensemble de l’ensemble complet des fonctionnalités de Direct3D 12. Le niveau de fonctionnalité Core 1.0 peut être exposé par une catégorie de dispositifs connus sous le nom de compute-only devices. Le modèle de pilote global pour les compute-only devices est le Microsoft Compute Driver Model (MCDM). MCDM est un pair allégé du Windows Device Driver Model (WDDM), qui a une portée plus large.

Un dispositif qui prend seulement en charge les fonctionnalités d’un niveau de fonctionnalité Core est appelé un Core device.

Remarque

Compute-only device, MCDM device, Core Feature Level device, et Core device signifient tous la même chose. Nous préférerons Core device pour simplifier.

Créer un Core device

En général, pour créer un dispositif Direct3D 12, vous appelez la fonction D3D12CreateDevice et spécifiez un niveau de fonctionnalité minimum.

Si vous spécifiez un niveau de fonctionnalité de 9 à 12, alors le dispositif renvoyé est un dispositif riche en fonctionnalités, comme un GPU traditionnel (qui prend en charge un sur-ensemble des fonctionnalités d’un Core device). Un Core device n’est jamais renvoyé pour cette gamme de niveaux de fonctionnalités.

D’un autre côté, si vous spécifiez un niveau de fonctionnalité Core (par exemple, D3D_FEATURE_LEVEL::D3D_FEATURE_LEVEL_1_0_CORE), alors le dispositif renvoyé pourrait être riche en fonctionnalités, ou il pourrait être un Core device.

// d3dcommon.h
D3D_FEATURE_LEVEL_1_0_CORE = 0x1000

Si vous spécifiez un _COREniveau de fonctionnalité, alors l’exécution/la couche de débogage valide que les fonctionnalités que votre application utilise sont autorisées par ce niveau de fonctionnalité _CORE. Cet ensemble de fonctionnalités est défini plus loin dans cette rubrique.

Modèle de shader pour les Core devices

Un Core device prend en charge Shader Model 5.0+.

L’exécution effectue la conversion des modèles de shader 5.x non DXIL en 6.0 DXIL. Ainsi, le pilote n’a besoin de prendre en charge que 6.x.

Modèle de gestion des ressources pour les Core devices

  • Dimensions de ressources prises en charge : tampons bruts et structurés uniquement (pas de tampons typés, texture1d/2D, etc.)
  • Pas de prise en charge des ressources réservées (tiled)
  • Pas de prise en charge des heaps personnalisés
  • Pas de prise en charge de l’une de ces étiquettes de heap :
    • D3D12_HEAP_FLAG_HARDWARE_PROTECTED
    • D3D12_HEAP_FLAG_ALLOW_WRITE_WATCH
    • D3D12_HEAP_FLAG_ALLOW_DISPLAY
    • D3D12_HEAP_FLAG_ALLOW_SHADER_ATOMICS (notez que les atomiques de shader sont requis, cette étiquette est pour une autre fonctionnalité, atomiques entre adaptateurs)

Modèle de liaison des ressources pour les Core devices

  • Prise en charge de la liaison des ressources niveau 1 uniquement
  • Exceptions :
    • Pas de prise en charge des échantillonneurs de textures
    • Prise en charge de 64 UAV comme le niveau de fonctionnalité 11.1+ (au lieu de seulement 8)
    • Les implémentations n’ont pas à mettre en œuvre la vérification des limites sur les accès des shaders aux ressources via des descripteurs, les accès hors limites produisent un comportement indéfini.
      • En conséquence, l’étiquette de portée de descripteur D3D12_DESCRIPTOR_RANGE_FLAG_DESCRIPTORS_STATIC_KEEPING_BUFFER_BOUNDS_CHECKS dans les signatures racines n’est pas prise en charge.
  • Les descripteurs UAV/CBV ne peuvent être faits que sur des ressources provenant des tas par défaut (donc pas de tas de téléchargement/relecture). Cela oblige votre application à effectuer des copies pour transférer des données entre le CPU<->GPU.
  • Bien qu’étant le niveau de capacité de liaison le plus bas, il existe encore des fonctionnalités requises même dans ce niveau qui méritent d’être mentionnées :
    • Les tas de descripteurs peuvent être mis à jour après l’enregistrement des listes de commandes (voir D3D12_DESCRIPTOR_RANGE_FLAG_DESCRIPTORS_VOLATILE dans les spécifications de liaison de ressources)
    • Les descripteurs racines sont essentiellement des pointeurs GPUVA
      • Même s’il n’y a pas de prise en charge MMU / VA, les VAs de tampon utilisés dans les descripteurs racines peuvent être émulés par les implémentations en effectuant des ajustements d’adresses.

Restrictions des tampons structurés

Les tampons structurés doivent avoir une adresse de base alignée sur 4 octets, et le pas doit être de 2 ou un multiple de 4. Le cas pour un pas de 2 est pour les applications avec des données de 16 bits, d’autant plus qu’il n’y a pas de prise en charge des tampons typés dans D3D_FEATURE_LEVEL_1_0_CORE.

Le pas spécifié dans les descripteurs doit correspondre au pas spécifié dans HLSL.

Prise en charge de la file d’attente de commandes pour les Core devices

Files d’attente de calcul et de copie uniquement (pas de files d’attente 3D, vidéo, etc.).

Prise en charge des shaders pour les Core devices

Shaders de calcul uniquement, pas de shaders graphiques (shaders de vertex, de pixel, etc.) ni de fonctionnalités connexes telles que les cibles de rendu, les chaînes d’échange, l’assembleur d’entrée.

Précision arithmétique

Les Core devices n’ont pas besoin de prendre en charge les denorms pour les opérations en virgule flottante de 16 bits.

APIs prises en charge pour les Core devices

La liste ci-dessous représente le sous-ensemble pris en charge de l’interface de programmation d’application complète (les APIs qui ne sont pas prises en charge dans le niveau de fonctionnalité Core 1.0 ne sont pas listées).

Méthodes ID3D12Device

Méthodes ID3D12Device1

Méthodes ID3D12Device2

Méthodes ID3D12Device3

Méthodes ID3D12Device4

Méthodes ID3D12Device5

Méthodes ID3D12CommandQueue

Méthodes ID3D12CommandList

Méthodes ID3D12GraphicsCommandList

Méthodes ID3D12GraphicsCommandList1

Méthodes ID3D12GraphicsCommandList2

Méthodes ID3D12GraphicsCommandList4