Niveau de fonctionnalité Direct3D 12 Core 1.0

Le niveau de fonctionnalité Core 1.0 est un sous-ensemble de l’ensemble complet de fonctionnalités Direct3D 12. Le niveau de fonctionnalité Core 1.0 peut être exposé par une catégorie d’appareils appelés appareils de calcul uniquement. Le modèle de pilote global pour les appareils de calcul uniquement est le modèle de pilote de calcul Microsoft (MCDM). MCDM est un homologue avec mise à l’échelle descendante du modèle de pilote de périphérique Windows (WDDM), qui a une étendue plus grande.

Un appareil qui prend en charge uniquement les fonctionnalités d’un niveau de fonctionnalité de base est appelé appareil core.

Notes

L’appareil de calcul uniquement, l’appareil MCDM, l’appareil de niveau de fonctionnalité core et l’appareil Core signifient tous la même chose. Nous préférerons l’appareil Core pour plus de simplicité.

Création d’un appareil Core

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

Si vous spécifiez un niveau de fonctionnalité de 9 à 12, l’appareil retourné est un appareil riche en fonctionnalités, tel qu’un GPU traditionnel (qui prend en charge un sur-ensemble de fonctionnalités d’un appareil Core). Un appareil Core n’est jamais retourné pour cette plage de niveaux de fonctionnalités.

En revanche, si vous spécifiez un niveau de fonctionnalité Core (par exemple, D3D_FEATURE_LEVEL::D 3D_FEATURE_LEVEL_1_0_CORE), l’appareil retourné peut être riche en fonctionnalités, ou il peut s’agir d’un appareil Core.

// d3dcommon.h
D3D_FEATURE_LEVEL_1_0_CORE = 0x1000

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

Modèle de nuanceur pour les appareils core

Un appareil Core prend en charge le modèle nuanceur 5.0+.

Le runtime effectue la conversion de 5.x modèles de nuanceur non DXIL vers 6.0 DXIL. Par conséquent, le pilote n’a besoin que de prendre en charge 6.x.

Modèle de gestion des ressources pour les appareils principaux

  • Dimensions des ressources prises en charge : tampons bruts et structurés uniquement (aucune mémoire tampon typée, texture1d/2D, etc.)
  • Aucune prise en charge des ressources réservées (mosaïques)
  • Aucune prise en charge des tas personnalisés
  • Aucune prise en charge de l’un de ces indicateurs de tas :
    • D3D12_HEAP_FLAG_HARDWARE_PROTECTED
    • D3D12_HEAP_FLAG_ALLOW_WRITE_WATCH
    • D3D12_HEAP_FLAG_ALLOW_DISPLAY
    • D3D12_HEAP_FLAG_ALLOW_SHADER_ATOMICS (notez que des atomes de nuanceur sont requis, cet indicateur concerne une autre fonctionnalité, les atomics d’adaptateurs croisés)

Modèle de liaison de ressources pour les appareils principaux

  • Prise en charge du niveau de liaison de ressources 1 uniquement
  • Exceptions :
    • Aucune prise en charge des échantillonneurs de texture
    • Prise en charge de 64 UAV comme le niveau de fonctionnalité 11.1+ (contre seulement 8)
    • Les implémentations n’ont pas besoin d’implémenter la vérification des limites sur les accès du nuanceur aux ressources par le biais de descripteurs. Les accès hors limites produisent un comportement non défini.
      • En tant que sous-produit, l’indicateur de plage de descripteurs D3D12_DESCRIPTOR_RANGE_FLAG_DESCRIPTORS_STATIC_KEEPING_BUFFER_BOUNDS_CHECKS dans les signatures racines n’est pas pris en charge.
  • Les descripteurs UAV/CBV ne peuvent être effectués que sur les ressources à partir de tas par défaut (donc pas de tas de chargement/lecture). Cela force votre application à effectuer des copies pour obtenir des données sur l’UC-GPU<>.
  • Bien qu’il s’agit du niveau de capacité de liaison le plus bas, certaines fonctionnalités sont requises même dans ce niveau qui mérite d’être soulignée :
    • Les tas de descripteurs peuvent être mis à jour après l’enregistrement des listes de commandes (voir D3D12_DESCRIPTOR_RANGE_FLAG_DESCRIPTORS_VOLATILE dans la spécification de liaison de ressource)
    • Les descripteurs racines sont essentiellement des pointeurs GPUVA
      • Même s’il n’existe aucune prise en charge MMU/VA, les machines virtuelles de mémoire tampon utilisées dans les descripteurs racine peuvent être émulées par les implémentations en effectuant des correctifs d’adresse.

Restrictions de mémoire tampon structurée

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

La foulée spécifiée dans les descripteurs doit correspondre à la foulée spécifiée dans HLSL.

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

Calculez et copiez uniquement des files d’attente (aucune file d’attente 3D, vidéo, etc.).

Prise en charge du nuanceur pour les appareils Core

Nuanceurs de calcul uniquement, aucun nuanceur graphique (vertex, nuanceurs de pixels, etc.) ni aucune fonctionnalité associée comme les cibles de rendu, les chaînes d’échange, l’assembleur d’entrée.

Précision arithmétique

Les appareils principaux n’ont pas besoin de prendre en charge les dénorms pour les opérations à virgule flottante 16 bits.

API prises en charge pour les appareils principaux

La liste ci-dessous représente le sous-ensemble pris en charge de l’interface de programmation d’application complète (les API qui ne sont pas prises en charge dans Core 1.0 Feature Level ne sont pas répertorié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