Restrictions d’accès aux vignettes avec des mappages en double
Cette section décrit les limitations d’accès aux vignettes avec les mappages en double.
Copie de ressources en mosaïques avec la source et la destination qui se chevauchent
Si les vignettes de la zone source et de destination d’une opération Copy* ont des mappages en double dans la zone de copie qui se seraient superposés même si les deux ressources n’étaient pas des ressources en mosaïques et que l’opération Copy* prend en charge le chevauchement des copies, l’opération Copier* se comportera correctement (comme si la source était copiée dans un emplacement temporaire avant d’atteindre la destination). Toutefois, si le chevauchement n’est pas évident (comme les ressources source et de destination sont différentes, 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 en mosaïque avec des vignettes dupliquées dans la zone de destination
La copie vers une ressource en mosaïque avec des vignettes dupliquées 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 des ordres différents.
Accès UAV aux mappages de vignettes en double
Supposons qu’une vue d’accès non ordonnée (UAV) sur une ressource en mosaïque comporte 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 dupliquées 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 en mosaïque ont changé ou si le contenu des vignettes de pool de vignettes mappées a changé via les mappages d’une autre ressource en mosaïques, et que la ressource en mosaïque va être rendue via l’affichage cible de rendu ou le gabarit de profondeur, l’application doit Effacer (à l’aide de la fonction fixe Clear API) ou copier entièrement à l’aide des API Copy*/Update* les vignettes qui ont changé dans la zone rendue (mappée ou non). L’échec de l’effacement ou de la copie d’une application dans ces cas entraîne l’obsolescence des structures d’optimisation matérielle pour la vue cible de rendu ou la vue de gabarit de profondeur donnée, ce qui entraîne des résultats de rendu de la mémoire sur certains matériels et des incohérences entre différents matériels. Ces structures de données d’optimisation masquées utilisées par le matériel peuvent être locales à des mappages individuels et non visibles par d’autres mappages sur la même mémoire.
L’opération ID3D11DeviceContext1::ClearView prend en charge la suppression des vues cibles de rendu avec des rectangles. Pour le matériel qui prend en charge les ressources en mosaïque, ClearView 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 la mémoire existante des zones d’une ressource en mosaïque où les mappages ont été modifiés, cette application doit contourner l’exigence claire. L’application peut effectuer ce travail de contournement en enregistrant d’abord le contenu où les mappages de vignettes ont changé (en les copiant sur une surface temporaire, par exemple, à l’aide de ID3D11DeviceContext2::CopyTiles), en émettant la commande clear requise, puis en recopiant le contenu. Bien que cela puisse accomplir la tâche de conservation du 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 en mosaïques en même temps et que le contenu des vignettes est manipulé par tous les moyens (rendu, copie, etc.) via l’une des ressources mosaïques, si la même vignette doit être affichée via une autre ressource en mosaïque, la vignette doit d’abord être effacée comme décrit précédemment.
Rendu en vignettes partagées en dehors de la zone de rendu
Supposons qu’une zone d’une ressource en mosaïque soit rendue dans et que les vignettes du pool de vignettes référencées par la zone de rendu soient également mappées à partir de l’extérieur de la zone de rendu (y compris via d’autres ressources mosaïques, en même temps ou non). Il n’est pas garanti que les données rendues sur ces vignettes s’affichent 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û à l’optimisation des structures de données utilisées par certains matériels qui peuvent être locaux à des mappages individuels pour des surfaces restaurables et non visibles par d’autres mappages au 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 supprimant cette mémoire ou en y copiant d’autres données si l’ancien contenu n’est plus nécessaire). Bien que cette solution de contournement semble redondante, elle permet à tous les autres mappages à la même mémoire de comprendre correctement comment accéder à son contenu, et au moins les économies de mémoire d’avoir une seule sauvegarde de mémoire physique restent intactes. En outre, lorsque vous basculez entre l’utilisation de différentes ressources en mosaïques qui partagent des mappages (sauf si vous lisez uniquement), vous devez appeler l’API ID3D11DeviceContext2::TiledResourceBarrier entre les commutateurs.
Rendu en vignettes partagées dans la zone de rendu
Si une zone d’une ressource en mosaïque est rendue dans 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 vignettes de partage de ressources en mosaïques
Supposons que plusieurs ressources en mosaïques ont des mappages aux mêmes emplacements de pool de mosaïques 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, si des appels appropriés à ID3D11DeviceContext2::TiledResourceBarrier sont effectués et que les ressources en mosaïques sont compatibles les unes avec les autres. Ce dernier est décrit ici en termes d’incompatibilité entre les ressources en mosaïques qui partagent des vignettes. Les conditions d’incompatibilité d’accès aux mêmes données entre les mappages de vignettes en double sont l’utilisation de dimensions ou de formats de surface différents, ou des différences dans la présence d’indicateurs de liaison de la cible de rendu ou du gabarit de profondeur sur les ressources. L’écriture en mémoire avec un type de mappage produit des résultats non définis si vous lisez ou effectuez un rendu via un mappage à partir d’une ressource incompatible. Si les autres mappages de partage de ressources sont initialisés pour la première fois avec de nouvelles données (recyclage de la mémoire dans un autre but), l’opération de lecture ou de rendu suivante est correcte, car les données ne saignent pas entre des interprétations incompatibles. Toutefois, vous devez appeler l’API TiledResourceBarrier lorsque vous basculez entre l’accès à des mappages incompatibles comme celui-ci.
Si l’indicateur de liaison de la cible de rendu ou du gabarit de profondeur n’est défini sur aucune des ressources partageant des mappages entre elles, 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 la taille équivalente non compressée 32 bits ou 16 bits 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 non mosaïques.
Le partage entre les vignettes empaquetées et non emballées est très bien si les formats sont compatibles et si les vignettes sont remplies de couleur unie.
Enfin, si rien n’est commun sur les ressources qui partagent des mappages de vignettes, sauf qu’aucun n’a d’indicateurs de liaison de cible ou de gabarit de profondeur de rendu, seule la mémoire remplie avec 0 peut être partagée en toute sécurité ; le mappage apparaît sous la forme du décodage de 0 pour la définition du format de ressource donné (généralement 0).
Rubriques connexes