Syntaxe
Paramètres
pHeap _In_Type : ID3D12Heap* Pointeur vers l’interface ID3D12Heap qui représente le tas dans lequel la ressource est placée. HeapOffset
Type : UINT64 Décalage, en octets, vers la ressource. HeapOffset doit être un multiple de l’alignement de la ressource, et HeapOffset plus la taille de la ressource doit être inférieur ou égal à la taille du tas. GetResourceAllocationInfo doit être utilisé pour connaître la taille des ressources de texture. pDesc _In_
Type : D3D12_RESOURCE_DESC1* Pointeur vers une structure D3D12_RESOURCE_DESC1 qui décrit la ressource. InitialState
Type : D3D12_RESOURCE_STATES État initial de la ressource, sous forme de combinaison OR au niveau du bit de constantes d’énumération D3D12_RESOURCE_STATES. Lorsqu’une ressource est créée avec un tas D3D12_HEAP_TYPE_UPLOAD, InitialState doit être D3D12_RESOURCE_STATE_GENERIC_READ. Lorsqu’une ressource est créée avec un tas D3D12_HEAP_TYPE_READBACK, InitialState doit être D3D12_RESOURCE_STATE_COPY_DEST. pOptimizedClearValue _In_opt_
Type : D3D12_CLEAR_VALUE* Spécifie une structure D3D12_CLEAR_VALUE qui décrit la valeur par défaut d’une couleur d’effacement. pOptimizedClearValue spécifie une valeur pour laquelle les opérations d’effacement sont les plus optimales. Lorsque la ressource créée est une texture avec l’indicateur D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET ou D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL, votre application doit choisir la valeur avec laquelle l’opération d’effacement sera le plus souvent appelée. Les opérations d’effacement peuvent être appelées avec d’autres valeurs, mais ces opérations ne seront pas aussi efficaces que lorsque la valeur correspond à celle transmise lors de la création de la ressource. pOptimizedClearValue doit être NULL lorsqu’il est utilisé avec D3D12_RESOURCE_DIMENSION_BUFFER. riid _In_
Type : REFIID Identificateur global unique (GUID) de l’interface de ressource. Il s’agit d’un paramètre d’entrée. Le REFIID, ou GUID, de l’interface vers la ressource peut être obtenu à l’aide de la macro __uuidof. Par exemple, __uuidof(ID3D12Resource) obtient le GUID de l’interface vers une ressource. Bien que riid soit le plus souvent le GUID d’ID3D12Resource, il peut s’agir de n’importe quel GUID de n’importe quelle interface. Si l’objet ressource ne prend pas en charge l’interface correspondant à ce GUID, la création échoue avec E_NOINTERFACE. ppvResource _COM_Outptr_
Type : void** Pointeur vers un bloc de mémoire qui reçoit un pointeur vers la ressource. ppvResource peut être NULL, afin de permettre les tests de capacités. Lorsque ppvResource est NULL, aucun objet n’est créé et S_FALSE est retourné lorsque pResourceDesc et les autres paramètres sont valides.
Valeur de retour
Type : HRESULT Cette méthode retourne E_OUTOFMEMORY si la mémoire est insuffisante pour créer la ressource. Consultez Codes de retour Direct3D 12 pour connaître les autres valeurs de retour possibles.Remarques
CreatePlacedResource revient à mapper entièrement une ressource réservée à un décalage dans un tas ; toutefois, l’espace d’adressage virtuel associé à un tas peut également être réutilisé. Les ressources placées sont plus légères à créer et à détruire que les ressources validées (committed). En effet, aucun tas n’est créé ni détruit au cours de ces opérations. De plus, les ressources placées permettent une technique de réutilisation de la mémoire encore plus légère que la création et la destruction de ressources, à savoir la réutilisation par alias et barrières d’alias. Plusieurs ressources placées peuvent se chevaucher simultanément sur le même tas, mais une seule ressource qui se chevauche peut être utilisée à la fois. Il existe deux sémantiques d’utilisation des ressources placées : un modèle simple et un modèle avancé. Nous vous recommandons de choisir le modèle simple (il maximise la prise en charge des outils graphiques dans l’écosystème varié des GPU), sauf si et jusqu’à ce que vous constatiez que le modèle avancé est nécessaire pour votre application.Modèle simple
Dans ce modèle, vous pouvez considérer qu’une ressource placée se trouve dans l’un des deux états suivants : active ou inactive. Il n’est pas valide que le GPU lise ou écrive dans une ressource inactive. Les ressources placées sont créées à l’état inactif. Pour activer une ressource avec une barrière d’alias dans une liste de commandes, votre application doit transmettre la ressource dans D3D12_RESOURCE_ALIASING_BARRIER::pResourceAfter. pResourceBefore peut être laissé NULL lors d’une activation. Toutes les ressources qui partagent la mémoire physique avec la ressource activée deviennent alors inactives, ce qui inclut les ressources placées et réservées qui se chevauchent. Les barrières d’alias doivent être regroupées et soumises ensemble, afin de maximiser l’efficacité. Après l’activation, les ressources dotées de l’indicateur de cible de rendu ou de profondeur-gabarit doivent être initialisées davantage. Consultez les notes sur l’initialisation requise des ressources ci-dessous.Notes sur l’initialisation requise des ressources
Certains types de ressources nécessitent toujours une initialisation. Les ressources dotées de l’indicateur de cible de rendu ou de profondeur-gabarit doivent être initialisées avec une opération d’effacement ou un ensemble de copies complètes de sous-ressources. Si une barrière d’alias a été utilisée pour indiquer la transition entre deux ressources aliasées, l’initialisation doit avoir lieu après la barrière d’alias. Cette initialisation reste requise chaque fois qu’une ressource aurait été activée dans le modèle simple. Les ressources placées et réservées dotées de l’indicateur de cible de rendu ou de profondeur-gabarit doivent être initialisées avec l’une des opérations suivantes avant que d’autres opérations ne soient prises en charge. Une opération Clear ; par exemple ClearRenderTargetView ou ClearDepthStencilView. Une opération DiscardResource. Une opération Copy ; par exemple CopyBufferRegion, CopyTextureRegion ou CopyResource. Les applications doivent privilégier l’opération la plus explicite qui entraîne la modification du moins grand nombre de texels. Considérez les exemples suivants. L’utilisation d’une mémoire tampon de profondeur pour résoudre la visibilité des pixels nécessite généralement que chaque texel de profondeur commence à 1.0 ou 0. Par conséquent, une opération Clear devrait être l’option la plus efficace pour l’initialisation d’une mémoire tampon de profondeur aliasée. Une application peut utiliser une cible de rendu aliasée comme destination pour le tone mapping. Étant donné que l’application effectuera le rendu de chaque pixel pendant le tone mapping, DiscardResource devrait être l’option la plus efficace pour l’initialisation.Modèle avancé
Dans ce modèle, vous pouvez ignorer l’abstraction des états actif/inactif. Vous devez plutôt respecter les règles de plus bas niveau suivantes. Une barrière d’alias doit se trouver entre deux accès différents du GPU à une ressource de la même mémoire physique, tant que ces accès se trouvent dans le même appel ExecuteCommandLists. La première opération de rendu sur certains types de ressources aliasées doit toujours être une initialisation, comme dans le modèle simple. Les opérations d’initialisation doivent porter sur une sous-ressource entière ou sur une granularité de 64 Ko. L’initialisation d’une sous-ressource entière est prise en charge pour tous les types de ressources. Une granularité d’initialisation de 64 Ko, alignée sur un décalage de 64 Ko, est prise en charge pour les mémoires tampons et les textures dotées de la disposition de texture 64KB_UNDEFINED_SWIZZLE ou 64KB_STANDARD_SWIZZLE (voir D3D12_TEXTURE_LAYOUT).Notes sur la barrière d’alias
La barrière d’alias peut définir NULL pour pResourceAfter et pResourceBefore. La définition de la cohérence de la mémoire d’ExecuteCommandLists et celle d’une barrière d’alias sont identiques, de sorte que deux accès aliasés à la même mémoire physique ne nécessitent aucune barrière d’alias lorsque les accès ont lieu dans deux appels ExecuteCommandLists différents. Pour les modèles d’utilisation avancés de D3D12, la définition de la synchronisation d’ExecuteCommandLists équivaut à une barrière d’alias. Par conséquent, les applications peuvent soit insérer une barrière d’alias entre les réutilisations de la mémoire physique, soit s’assurer que les deux utilisations aliasées de la mémoire physique se produisent dans deux appels distincts à ExecuteCommandLists. L’étendue de l’inactivation varie en fonction des propriétés de la ressource. Les textures dont la disposition de mémoire n’est pas définie constituent le pire cas, car la texture entière doit être inactivée de manière atomique. Pour deux ressources qui se chevauchent et dont les dispositions sont définies, l’inactivation peut ne concerner que les régions alignées qui se chevauchent d’une ressource. L’héritage des données peut même être bien défini. Pour plus d’informations, consultez Alias de mémoire et héritage des données.Configuration requise
En-tête : d3d12_xs.h Bibliothèque : d3d12_xs.libPlateformes prises en charge : consoles XBOX Series