Partager via

Restrictions d’accès aux vignettes avec des mappages en double

  • Article

Il existe des limitations sur l’accès aux vignettes avec des mappages en double, par exemple lors de la copie de ressources de diffusion en continu avec une source et une destination qui se chevauchent, ou lors du rendu sur des vignettes partagées dans la zone de rendu.

Copie de ressources de diffusion en continu avec chevauchement de la source et de la destination

Si les vignettes dans la zone source et de destination d’une opération Copy* ont des mappages en double dans la zone de copie qui se chevauchent même si les deux ressources n’étaient pas des ressources de diffusion en continu et que l’opération Copy* prend en charge les copies qui se chevauchent, l’opération Copy* se comporte correctement (comme si la source est copiée dans un emplacement temporaire avant d’accéder à la destination). Toutefois, si le chevauchement n’est pas évident (comme les ressources source et de destination sont différents, mais que les mappages de partage ou les mappages sont dupliqués sur une surface donnée), les résultats de l’opération de copie sur les vignettes partagées ne sont pas définis.

Copie vers une ressource de diffusion en continu avec des vignettes en double dans la zone de destination

La copie vers une ressource de diffusion en continu avec des vignettes en double dans la zone de destination produit des résultats non définis dans ces vignettes, sauf si les données elles-mêmes sont identiques ; différentes vignettes peuvent écrire les vignettes dans différents ordres.

Accès UAV aux mappages de vignettes en double

Supposons qu’une vue d’accès non ordonnée (UAV) sur une ressource de streaming possède des mappages de vignettes en double dans sa zone ou avec d’autres ressources liées au pipeline. L’ordre des accès à ces vignettes en double n’est pas défini s’il est effectué par différents threads, tout comme tout ordre d’accès à la mémoire aux UAV en général n’est pas ordonné.

Rendu après les modifications de mappage de vignettes ou les mises à jour de contenu à partir de mappages externes

Si les mappages de vignettes d’une ressource de streaming ont changé ou si le contenu des vignettes de pool en mosaïques mappées a changé via les mappages d’une autre ressource de diffusion en continu et que la ressource de diffusion en continu sera rendue via la vue de la cible de rendu ou de profondeur, l’application doit effacer (à l’aide des API Clear de fonction fixe) ou copier entièrement à l’aide des API Copy*/Update* les vignettes qui ont changé dans la zone affichée (mappée ou non).

L’échec de l’effacement ou de la copie d’une application dans ces cas entraîne des structures d’optimisation matérielle pour la vue cible de rendu donnée ou la vue de gabarit de profondeur obsolète, ce qui entraîne l’obsolescence des résultats du rendu des mémoires sur certains matériels et incohérences sur différents matériels. Ces structures de données d’optimisation masquées utilisées par le matériel peuvent être locales pour des mappages individuels et non visibles par d’autres mappages à la même mémoire.

Lorsque vous effacez une vue de ressource (en définissant tous les éléments d’une vue de ressource sur une valeur), vous pouvez effacer les affichages cibles de rendu avec des rectangles. Pour le matériel prenant en charge les ressources de diffusion en continu, l’effacement d’une vue de ressource doit également prendre en charge l’effacement des vues de gabarit de profondeur avec des rectangles, pour les surfaces de profondeur uniquement (sans gabarit). Cette opération permet aux applications d’effacer uniquement la zone nécessaire d’une surface.

Si une application doit conserver le contenu de mémoire existant des zones dans une ressource de streaming où les mappages ont changé, cette application doit contourner les exigences claires. L’application peut accomplir ce travail en enregistrant d’abord le contenu où les mappages de vignettes ont changé (en les copiant dans une surface temporaire), en émettant la commande clear requise, puis en copiant le contenu. Bien que cela puisse accomplir la tâche de préserver le contenu de la surface pour le rendu incrémentiel, l’inconvénient est que les performances de rendu ultérieures sur la surface peuvent souffrir, car les optimisations de rendu peuvent être perdues.

Si une vignette est mappée en plusieurs ressources de diffusion en continu en même temps et que le contenu de la vignette est manipulé par n’importe quel moyen (rendu, copie, et ainsi de suite) via l’une des ressources de diffusion en continu, si la même vignette doit être rendue via une autre ressource de diffusion en continu, la vignette doit d’abord être effacée comme décrit précédemment.

Rendu sur des vignettes partagées en dehors de la zone de rendu

Supposons qu’une zone d’une ressource de diffusion en continu soit rendue et que les vignettes de pool de mosaïques référencées par la zone de rendu sont également mappées à partir de l’extérieur de la zone de rendu (y compris via d’autres ressources de diffusion en continu, en même temps ou non). Les données rendues dans ces vignettes ne sont pas garanties d’apparaître correctement lorsqu’elles sont affichées via les autres mappages, même si la disposition de mémoire sous-jacente est compatible. Ce fait est dû aux structures de données d’optimisation utilisées par certains matériels qui peuvent être locaux à des mappages individuels pour les surfaces restituables et qui ne sont pas visibles par d’autres mappages vers le même emplacement de mémoire.

Vous pouvez contourner cette restriction en copiant à partir du mappage rendu vers tous les autres mappages vers la même mémoire accessible (ou en désactivant cette mémoire ou en copiant d’autres données si l’ancien contenu n’est plus nécessaire). Bien que ce travail semble redondant, il rend tous les autres mappages à la même mémoire correctement comprendre comment accéder à son contenu, et au moins les économies de mémoire d’avoir un seul stockage de mémoire physique reste intact.

En outre, lorsque vous basculez entre l’utilisation de différentes ressources de diffusion en continu qui partagent des mappages (sauf si seule la lecture), vous devez spécifier une contrainte d’ordre d’accès aux données (une barrière) entre plusieurs ressources en mosaïques, entre les commutateurs.

Rendu sur des vignettes partagées dans la zone de rendu

Si une zone d’une ressource de diffusion en continu est affichée et dans la zone de rendu, plusieurs vignettes sont mappées au même emplacement de pool de vignettes, les résultats de rendu ne sont pas définis sur ces vignettes.

Compatibilité des données entre les ressources de streaming partageant des vignettes

Supposons que plusieurs ressources de streaming ont des mappages aux mêmes emplacements de pool de vignettes et que chaque ressource est utilisée pour accéder aux mêmes données. Ce scénario n’est valide que si les autres règles relatives à l’évitement des problèmes liés aux structures d’optimisation matérielle sont évitées, les barrières appropriées sont spécifiées (en spécifiant une contrainte d’ordre d’accès aux données entre plusieurs ressources en mosaïques) et les ressources de diffusion en continu sont compatibles entre elles.

Ce dernier est décrit ici en termes de signification pour que les ressources de diffusion en continu partagent des vignettes soient incompatibles. Les conditions d’incompatibilité d’accès aux mêmes données entre les mappages de mosaïques en double sont l’utilisation de différentes dimensions ou formats de surface, ou des différences en présence d’indicateurs de liaison de cible de rendu ou de profondeur sur les ressources. L’écriture dans la mémoire avec un type de mappage produit des résultats non définis si vous lisez ou effectuez un rendu par la suite via un mappage à partir d’une ressource incompatible.

Si les autres mappages de partage de ressources sont d’abord initialisés avec de nouvelles données (recyclage de la mémoire à des fins différentes), l’opération de lecture ou de rendu suivante est correcte, car les données ne sont pas en cours de saignement dans les interprétations incompatibles. Toutefois, lorsque vous basculez entre l’accès aux mappages incompatibles comme celui-ci, vous devez spécifier des barrières (en spécifiant une contrainte d’ordre d’accès aux données entre plusieurs ressources en mosaïques).

Si l’indicateur de liaison de la cible de rendu ou de profondeur n’est pas défini sur l’un des mappages de partage de ressources entre eux, il existe beaucoup moins de restrictions. Tant que les types de format et de surface (par exemple, Texture2D) sont identiques, les vignettes peuvent être partagées. Les différents formats compatibles sont des cas tels que les surfaces BC* et le format 32 bits ou 16 bits équivalent par composant, comme BC6H et R32G32B32A32. De nombreux formats 32 bits par élément peuvent également être alias avec R32_* (R10G10B10A2_*, R8G8B8A8_*, B8G8R8A8_*,B8G8R8X8_*,R16G16_*) ; cette opération a toujours été autorisée pour les ressources qui ne sont pas diffusées en continu.

Le partage entre les vignettes emballées et non emballées est correct si les formats sont compatibles et que les vignettes sont remplies de couleur unie.

Enfin, si rien n’est courant sur les ressources qui partagent des mappages de vignettes, sauf qu’aucun indicateur de liaison cible ou profondeur de rendu n’est possible, seule la mémoire remplie de 0 peut être partagée en toute sécurité ; le mappage apparaît sous la forme de 0 décodages pour la définition du format de ressource donné (généralement seulement 0).

Accès de pipeline aux ressources de diffusion en continu