Partager via

Alias de mémoire et héritage de données

  • Article

Les ressources placées et réservées peuvent aliaser la mémoire physique au sein d’un tas. Les ressources placées permettent plus de scénarios d’héritage de données que les ressources réservées lorsque le tas a l’indicateur partagé défini ou lorsque les ressources qui ont un alias ont des dispositions de mémoire entièrement définies.

Alias

Une barrière d’aliasing doit être émise entre l’utilisation de deux ressources qui partagent la même mémoire physique, même si l’héritage de données n’est pas souhaité. Les modèles d’utilisation simples doivent indiquer, au minimum, la ressource de destination impliquée dans une telle opération. Veuillez consulter la section CreatePlacedResource pour plus de détails et des modèles d’utilisation avancés.

Après qu’une ressource a été accédée, toutes les ressources qui partagent la mémoire physique avec cette ressource deviennent invalidées, sauf si l’héritage de données est autorisé à se produire. Les lectures des ressources invalidées entraînent un contenu de ressource non défini. Les écritures sur les ressources invalidées entraînent également un contenu de ressource non défini, sauf si deux conditions se produisent :

  • La ressource ne possède ni le D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET ni le D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL.
  • L’écriture est une opération de copie ou de nettoyage sur un sous-ressource ou une tuile entière. L’initialisation des tuiles n’est disponible que pour les ressources avec 64KB_TILE_UNDEFINED_SWIZZLE et 64KB_TILE_STANDARD_SWIZZLE.

Les invalidations qui se chevauchent sont limitées à des granularités plus petites, lorsque les dispositions fournissent des informations sur l’emplacement des données texel et lorsque les ressources sont dans certains états de barrière de transition. Cependant, les invalidations ne peuvent pas être plus petites que les granularités d’alignement des ressources.

Une granularité d’alignement de buffer est de 64KB, et une granularité d’alignement plus grande prévaut. C’est important lorsque l’on considère des textures de 4KB, car plusieurs textures de 4KB peuvent résider dans une région de 64KB sans se chevaucher. Cependant, un buffer aliasant la même région de 64KB ne peut pas être utilisé en conjonction avec l’une de ces textures de 4KB. L’application ne peut pas garantir de manière fiable que l’accès au buffer ne croise pas les textures de 4KB, car les GPU sont autorisés à permuter les données de texture de 4KB dans la région de 64KB selon un modèle non défini.

Les dispositions de texture 64KB_TILE_UNDEFINED_SWIZZLE, 64KB_TILE_STANDARD_SWIZZLE et ROW_MAJOR informent l’application des granularités d’alignement qui ont été invalidées. Par exemple : Une application peut créer une texture cible de rendu 2D avec 2 tranches de tableau, un seul niveau de mip, et la disposition 64KB_TILE_UNDEFINED_SWIZZLE. Supposons que l’application comprenne que chaque tranche de tableau occupe 100 tuiles de 64KB. L’application peut renoncer à utiliser la tranche de tableau 0 et réutiliser cette mémoire pour un buffer de ~6MB, une texture de ~6MB avec une disposition indéfinie, etc. Pour aller plus loin, supposons que l’application n’ait plus besoin de la première tuile de la tranche de tableau 1. Ensuite, l’application pourrait également placer un buffer de 64KB là jusqu’à ce que le rendu nécessite à nouveau la première tuile de la tranche de tableau 1. L’application devrait effectuer un nettoyage ou une copie de tuile complète afin de réutiliser la première tuile avec la texture du tableau à nouveau.

Cependant, même les textures avec des dispositions définies présentent toujours des cas problématiques. Les tailles des ressources de texture peuvent différer considérablement de ce que l’application peut calculer elle-même, car certaines architectures d’adaptateurs allouent de la mémoire supplémentaire pour les textures afin de réduire la bande passante effective lors des scénarios de rendu courants. Toute invalidation dans cette région de mémoire supplémentaire entraîne l’invalidation de l’ensemble de la ressource. Veuillez consulter la section GetResourceAllocationInfo pour plus de détails.

Héritage des données

Les ressources placées permettent le plus d’héritage de données pour les textures, même avec des dispositions de mémoire indéfinies. Les applications peuvent imiter les capacités d’héritage de données que les ressources partagées et engagées permettent en plaçant deux textures avec des propriétés de ressource identiques au même décalage dans un tas partagé. La description complète de la ressource doit être identique, y compris la valeur de nettoyage optimisée et le type de méthode de création de la ressource (placée ou réservée). Cependant, les deux ressources peuvent avoir eu des états de barrière de transition initiaux différents.

Les ressources réservées permettent l’héritage de données par tuile ; mais des restrictions existent couramment pour les états de barrière de transition des ressources.

Pour hériter de données, les deux ressources doivent être dans un état de barrière de transition de ressource compatible :

  • Pour les buffers, les textures à accès simultané et les textures inter-adaptateurs, l’état de transition des ressources n’est pas important et tous les états sont « compatibles ».
  • Pour les textures réservées sans les propriétés précédentes ou d’autres héritages de données par tuile via 64KB_TILE_UNDEFINED_SWIZZLE ou 64KB_TILE_STANDARD_SWIZZLE, l’état de barrière de transition de la ressource, y compris la tuile, doit être dans l’état commun.
  • Pour toutes les autres textures, où les descriptions de ressources correspondent exactement, l’état de barrière de transition des ressources pour chaque paire correspondante de sous-ressources doit :
    • Être dans l’état commun.
    • Être égal lorsque l’état a le même indicateur de GPU-écriture.

Lorsque le GPU prend en charge le permutateur standard, les buffers et les textures permutées standard peuvent être aliasés à la même mémoire et hériter des données entre eux. L’application peut manipuler les texels à partir de la représentation du buffer, car le modèle de permutation standard décrit comment les texels sont disposés en mémoire. Le modèle de permutation visible par le CPU est équivalent au modèle de permutation visible par le GPU observé dans les buffers.

Sous-allocation au sein des tas