Syntaxe
typedef enum D3D12_STATE_OBJECT_FLAGS
{
D3D12_STATE_OBJECT_FLAG_NONE = 0,
D3D12_STATE_OBJECT_FLAG_ALLOW_LOCAL_DEPENDENCIES_ON_EXTERNAL_DEFINITIONS = 1,
D3D12_STATE_OBJECT_FLAG_ALLOW_EXTERNAL_DEPENDENCIES_ON_LOCAL_DEFINITIONS = 2
} D3D12_STATE_OBJECT_FLAGS
Constantes
| Constante | Description |
|---|---|
| D3D12_STATE_OBJECT_FLAG_NONE | Aucune contrainte d’objet d’état. |
| D3D12_STATE_OBJECT_FLAG_ALLOW_LOCAL_DEPENDENCIES_ON_EXTERNAL_DEFINITIONS | Cet indicateur s’applique uniquement aux objets d’état de type collection. Sinon, il est ignoré. Les exportations de cette collection sont autorisées à avoir des références non résolues (dépendances) qui devront être résolues (définies) lorsque la collection sera incluse dans un objet d’état conteneur, tel qu’un objet d’état de pipeline de lancer de rayons (RTPSO). Cela inclut le fait de dépendre d’associations de sous-objets définies en externe pour associer un sous-objet externe (par exemple, une signature racine) à une exportation locale. En l’absence de cet indicateur, toutes les exportations de cette collection doivent avoir leurs dépendances entièrement résolues localement, y compris toutes les associations de sous-objets nécessaires, qui doivent être définies localement. Les implémentations/pilotes avancés disposeront de suffisamment d’informations pour compiler le code de la collection et n’auront pas besoin de conserver de code non compilé (sauf si l’indicateur D3D12_STATE_OBJECT_FLAG_ALLOW_EXTERNAL_DEPENDENCIES_ON_LOCAL_DEFINITIONS est défini), de sorte que lorsque la collection est utilisée dans un objet d’état conteneur (par exemple, un RTPSO), le pilote n’ait qu’un minimum de travail à effectuer, idéalement une liaison « peu coûteuse » au plus. |
| D3D12_STATE_OBJECT_FLAG_ALLOW_EXTERNAL_DEPENDENCIES_ON_LOCAL_DEFINITIONS | Cet indicateur s’applique uniquement aux objets d’état de type collection. Sinon, il est ignoré. Si cette collection est incluse dans un autre objet d’état (par exemple, un RTPSO), les nuanceurs/fonctions du reste de l’objet d’état conteneur sont autorisés à dépendre des exportations de cette collection (par exemple, à les appeler). En l’absence de cet indicateur (par défaut), les exportations de cette collection ne peuvent pas être directement référencées par d’autres parties des objets d’état conteneurs (par exemple, un RTPSO). Cela peut légèrement réduire l’empreinte mémoire de la collection, car les pilotes n’ont pas besoin de conserver du code non compilé dans la collection au cas où il serait appelé par une fonction externe qui compilerait alors tout le code ensemble. Cela dit, si toutes les associations de sous-objets nécessaires n’ont pas été définies localement pour le code de cette collection, le pilote risque de ne pas encore pouvoir compiler le code du nuanceur et de devoir quand même conserver du code non compilé. Une association de sous-objet définie en externe qui associe un sous-objet externe à une exportation locale ne compte pas comme une dépendance externe sur une définition locale ; la présence ou l’absence de cet indicateur n’a donc aucune incidence sur l’autorisation ou non de l’association. En revanche, si la collection actuelle définit une association de sous-objet entre un sous-objet défini localement et une exportation externe (par exemple, un nuanceur), cela compte comme une dépendance externe sur une définition locale et cet indicateur doit être défini. Indépendamment de la présence ou de l’absence de cet indicateur, les points d’entrée de nuanceur (tels que les groupes d’impact ou les nuanceurs d’échec) de la collection sont visibles en tant que points d’entrée d’un objet d’état conteneur (par exemple, un RTPSO) s’ils sont exportés par celui-ci. Dans le cas d’un RTPSO, les points d’entrée exportés peuvent être utilisés dans les tables de nuanceurs pour le lancer de rayons. |
Configuration requise
En-tête : d3d12_xs.h ou d3d12_x.hBibliothèque : d3d12_xs.lib ou d3d12_x.lib
Plateformes prises en charge : consoles XBOX Series et famille XBOX One