Partager via

API de ressource en mosaïque

  • Article

Les API décrites dans cette section fonctionnent avec des ressources en mosaïques et un pool de vignettes.

Affectation de vignettes d’un pool de vignettes à une ressource

Les API ID3D11DeviceContext2::UpdateTileMappings et ID3D11DeviceContext2::CopyTileMappings manipulent et interrogent les mappages de vignettes. Les appels de mise à jour affectent uniquement les vignettes identifiées dans l’appel, et d’autres sont laissés comme défini précédemment.

Une vignette donnée d’un pool de vignettes peut être mappée à plusieurs emplacements dans une ressource et même à plusieurs ressources. Ce mappage inclut des vignettes dans une ressource qui ont une disposition choisie par l’implémentation (empaquetage Mipmap) où plusieurs mipmaps sont regroupés dans une seule vignette. Le problème est que si les données sont écrites dans la vignette via un mappage, mais lues via un mappage configuré différemment, les résultats ne sont pas définis. Toutefois, une utilisation prudente de cette flexibilité peut toujours être utile pour une application, comme le partage d’une vignette entre des ressources qui ne seront pas utilisées simultanément, où le contenu de la vignette est toujours initialisé via le même mappage de ressources que celui à partir duquel ils seront ensuite lus. De même, une vignette mappée pour contenir les mipmaps empaquetés de plusieurs ressources différentes avec les mêmes dimensions de surface fonctionnera correctement : les données apparaîtront de la même façon dans les deux mappages.

Les modifications apportées aux affectations de vignettes pour une ressource peuvent être apportées à tout moment dans un contexte immédiat ou différé.

Interrogation du carrelage et de la prise en charge des ressources

Pour interroger le mosaïque des ressources, utilisez ID3D11Device2::GetResourceTiling.

Pour la prise en charge des autres ressources, utilisez ID3D11Device2::CheckMultisampleQualityLevels1.

Copie de données en mosaïque

Toutes les méthodes dans Direct3D pour déplacer des données autour fonctionnent avec des ressources en mosaïques comme si elles ne sont pas en mosaïques, sauf que les écritures dans les zones non maquées sont supprimées et que les lectures à partir de zones non maquées produisent 0. Si une opération de copie implique l’écriture dans le même emplacement de mémoire plusieurs fois, car plusieurs emplacements de la ressource de destination sont mappés à la même mémoire de vignette, les écritures obtenues dans des vignettes multi mappées sont non déterministes et non reproductibles. Autrement dit, les accès se produisent dans l’ordre dans lequel le matériel exécute la copie.

Direct3D 11.2 introduit des méthodes pour ces méthodes supplémentaires de copie :

  • Copier entre les vignettes d’une ressource en mosaïques (à une granularité de vignette de 64 Ko) et (vers/depuis) une mémoire tampon dans la mémoire de l’unité de traitement graphique (GPU) (ou la ressource intermédiaire) - ID3D11DeviceContext2::CopyTiles
  • Copier à partir de la mémoire fournie par l’application vers des vignettes dans une ressource en mosaïque - ID3D11DeviceContext2::UpdateTiles

Ces méthodes swizzle/deswizzle si nécessaire et autorisent un indicateur de D3D11_TILE_COPY_NO_OVERWRITE lorsque l’appelant promet que la mémoire de destination n’est pas référencée par le travail gpu en cours d’exécution.

Les vignettes impliquées dans la copie ne peuvent pas inclure de vignettes qui contiennent des mipmaps empaquetés ou dont les résultats ne sont pas définis. Pour transférer des données vers/à partir de mipmaps que le matériel empaque dans une vignette, vous devez utiliser les API de copie/mise à jour standard (non spécifiques aux vignettes) ou ID3D11DeviceContext::GenerateMips pour l’ensemble de la chaîne mip.

Remarque sur GenerateMips : L’utilisation d’ID3D11DeviceContext::GenerateMips sur une ressource avec des vignettes partiellement mappées produit des résultats qui suivent simplement les règles de lecture et d’écriture NULL appliquées à l’algorithme que le matériel et le pilote d’affichage utilisent sur GenerateMips. Par conséquent, il n’est pas particulièrement utile pour une application de prendre la peine de le faire, sauf si d’une manière ou d’une autre les zones avec des mappages NULL (et leur effet sur d’autres mips pendant la phase de génération) n’auront aucune conséquence sur les parties de la surface dont l’application se soucie.

La copie de données de vignette à partir d’une surface de préproduction ou de la mémoire de l’application serait le moyen de charger des vignettes qui ont peut-être été diffusées en continu sur le disque, par exemple. Une variante lorsque la diffusion en continu hors disque charge une sorte de données compressées dans la mémoire GPU, puis le décodage sur le GPU. La cible de décodage peut être une ressource de mémoire tampon dans la mémoire GPU, à partir de laquelle CopyTiles copie ensuite vers la ressource en mosaïque réelle. Cette étape de copie permet au GPU de swizzle lorsque le modèle swizzle n’est pas connu. Swizzling n’est pas nécessaire si la ressource en mosaïque elle-même est une ressource de mémoire tampon (par exemple, par opposition à une texture).

La disposition de la mémoire des vignettes du côté des ressources de mémoire tampon non mosaïques de la copie est simplement linéaire en mémoire dans des vignettes de 64 Ko, que le matériel et le pilote d’affichage swizzle/deswizzle par vignette selon le cas lors du transfert vers/à partir d’une ressource mosaïque. Pour les surfaces d’anti-ataliasing multi-échantillonnage (MSAA), les échantillons de chaque pixel sont parcourus dans l’ordre d’échantillonnage-index avant de passer au pixel suivant. Pour les vignettes partiellement remplies sur le côté droit (pour une surface dont la largeur n’est pas multiple en pixels), le pas/la foulée pour descendre une ligne correspond à la taille totale en octets du nombre de pixels qui correspondrait à la vignette si la vignette était pleine. Ainsi, il peut y avoir un espace entre chaque ligne de pixels dans la mémoire. Par souci de simplicité de spécification, les mipmaps plus petits qu’une vignette ne sont pas regroupés dans la disposition linéaire. Cela semble être un gaspillage d’espace mémoire, mais comme mentionné, la copie sur mips que les packs matériels ensemble n’est pas autorisé via CopyTiles ou UpdateTiles. L’application peut simplement utiliser les API UpdateSubresource*() ou CopySubresource*() génériques pour copier de petits mips individuellement, bien que dans le cas de CopySubresource*(), cela signifie que la mémoire linéaire doit avoir la même dimension que la ressource en mosaïque . CopySubresource*() ne peut pas copier à partir d’une ressource tampon vers une Texture2D pour instance.

Si un swizzle standard matériel est défini, des indicateurs peuvent être ajoutés pour indiquer que les données de la mémoire tampon doivent être interprétées dans ce format (pas de swizzle nécessaire lors du transfert), bien que d’autres approches de chargement des données puissent également être logiques dans ce cas, telles que l’autorisation aux applications d’un accès direct à la mémoire du pool de vignettes.

Les opérations de copie peuvent être effectuées dans un contexte immédiat ou différé.

Redimensionnement du pool de vignettes

Pour redimensionner un pool de vignettes, utilisez ID3D11DeviceContext2::ResizeTilePool.

Barrière des ressources en mosaïque

Pour spécifier une contrainte d’ordre d’accès aux données entre plusieurs ressources en mosaïque, utilisez ID3D11DeviceContext2::TiledResourceBarrier.

Ressources en mosaïques