Partager via

sample (sm4 - asm)

  • Article

Échantillonne les données de l’élément/texture spécifié à l’aide de l’adresse spécifiée et du mode de filtrage identifié par l’échantillonneur donné.

sample[_aoffimmi(u,v,w)] dest[.mask], srcAddress[.swizzle], srcResource[.swizzle], srcSampler
Élément Description
Dest
 [in] Adresse du résultat de l’opération.
srcAddress
 [in] Ensemble de coordonnées de texture. Pour plus d’informations, consultez la section Remarques.
srcResource
 [in] Registre de textures. Pour plus d’informations, consultez la section Remarques.
srcSampler
 [in] Registre de l’échantillonneur. Pour plus d’informations, consultez la section Remarques.

Notes

Les données sources peuvent provenir de n’importe quel type de ressource, autre que les mémoires tampons.

srcAddress fournit l’ensemble des coordonnées de texture nécessaires à l’exécution de l’exemple, sous forme de valeurs à virgule flottante référençant l’espace normalisé dans la texture. Les modes d’habillage d’adresse (wrap/miroir/clamp/border, etc.) sont appliqués pour les coordonnées de texture en dehors de la plage [0...1], pris à partir de l’état de l’échantillonneur (s#) et appliqués après l’application d’un décalage d’adresse aux coordonnées de texture.

srcResource est un registre de textures (t#). Il s’agit simplement d’un espace réservé pour une texture, y compris le type de données de retour de la ressource échantillonnées. Toutes ces informations sont déclarées dans le préambule du nuanceur. La ressource réelle à échantillonner est liée au nuanceur en externe à l’emplacement # (pour t#).

srcSampler est un(s) registre(s) d’échantillonneur. Il s’agit simplement d’un espace réservé pour une collection de contrôles de filtrage tels que les contrôles de point par rapport aux contrôles linéaires, mipmapping et de habillage d’adresses.

L’ensemble des informations requises pour que le matériel effectue l’échantillonnage est divisé en deux parties orthogonales. Tout d’abord, le registre de textures fournit des informations sur le type de données source, y compris, par exemple, des informations indiquant si la texture contient des données SRGB. Il fait également référence à la mémoire réelle échantillonnées. Deuxièmement, le registre de l’échantillonneur définit le mode de filtrage à appliquer.

Ressources de tableau

Pour les tableaux Texture1D, le composant g srcAddress (POS-swizzle) sélectionne la tranche de tableau à partir de laquelle extraire. Celle-ci est toujours traitée comme une valeur float mise à l’échelle, plutôt que comme l’espace normalisé pour les coordonnées de texture standard, et une paire d’arrondie à proche est appliquée à la valeur, suivie d’une pince à la plage BufferArray disponible.

Pour les tableaux Texture2D, le composant srcAddress b (POS-swizzle) sélectionne la tranche de tableau à partir de laquelle extraire, sinon en utilisant la sémantique décrite pour les tableaux Texture1D .

Décalage d’adresse

Le suffixe facultatif [_aoffimmi(u,v,w)] (décalage d’adresse par entier immédiat) indique que les coordonnées de texture de l’exemple doivent être décalées par un ensemble de constantes d’espace texel immédiates fournies. Les valeurs littérales sont un ensemble de nombres complémentaires de 4 bits 2, ayant une plage d’entiers [-8,7]. Ce modificateur est défini pour toutes les ressources, y compris les tableaux Texture1D/2D et Texture3D, mais il n’est pas défini pour TextureCube.

Le matériel peut tirer parti de la connaissance immédiate qu’un parcours sur une certaine empreinte de texels sur un emplacement commun est effectué par un ensemble d’exemples d’instructions. Cela peut être transmis à l’aide de _aoffimmi(u,v,w).

Les décalages sont ajoutés aux coordonnées de texture, dans l’espace texel, par rapport à chaque miplevel accessible. Ainsi, même si les coordonnées de texture sont fournies sous forme de valeurs float normalisées, le décalage applique un décalage entier texel-espace.

Les décalages d’adresse ne sont pas appliqués le long de l’axe des tableaux Texture1D/2D.

_aoffimmi composants v,w sont ignorés pour Texture1Ds.

_aoffimmi composant w est ignoré pour Texture2Ds.

Les modes d’habillage d’adresse (wrap/miroir/clamp/border, etc.) à partir de l’état de l’échantillonneur (s#) sont appliqués après l’application d’un décalage d’adresse aux coordonnées de texture.

Contrôle de type de retour

Le format de données retourné par l’exemple au registre de destination est déterminé par le format de ressource (DXGI_FORMAT*) lié au paramètre srcResource (t#). Par exemple, si le t# spécifié a été lié à une ressource au format DXGI_FORMAT_A8B8G8R8_UNORM_SRGB, l’opération d’échantillonnage convertit les texels échantillonnés de gamma 2.0 en 1.0, applique un filtrage, et le résultat est écrit dans le registre de destination en tant que valeurs à virgule flottante dans la plage [0..1].

Les valeurs retournées sont des vecteurs à 4 (avec des valeurs par défaut spécifiques au format pour les composants non présents dans le format). Le swizzle sur srcResource détermine comment swizzle le résultat à 4 composants provenant de l’exemple/filtre de texture, après quoi .mask sur dest détermine quels composants dans dest sont mis à jour.

Lorsque l’échantillon lit une valeur float 32 bits dans un registre 32 bits, avec échantillonnage de points (aucun filtrage), il peut ou non vider les valeurs dénormales, mais sinon les nombres ne sont pas modifiés. Si l’incertitude avec des valeurs dénormales d’échantillonnage de points est un problème pour une application, utilisez l’instruction ld , qui garantit que les valeurs float 32 bits sont lues sans modification.

Calcul LOD

Pour plus d’informations sur la façon dont les dérivés sont calculés dans le processus de détermination de LOD pour le filtrage, consultez deriv_rtx et deriv_rty. L’exemple d’instruction calcule implicitement les dérivés sur les coordonnées de texture à l’aide de la même définition que celle utilisée par les instructions du nuanceur de dérivation. Cela ne s’applique pas aux instructions sample_l ou sample_d . Pour ces instructions, LOD ou dérivés sont fournis directement par l’application.

Pour l’exemple d’instruction, les implémentations peuvent choisir de partager le même calcul LOD sur les 4 pixels dans un tampon de 2 x 2 (mais pas de zone plus grande), ou d’effectuer des calculs LOD par pixel.

Détails divers

Pour Buffer & Texture1D, les composants .gba srcAddress (POS-swizzle) sont ignorés. Pour les tableaux Texture1D, les composants .ba srcAddress (POS-swizzle) sont ignorés. Pour Texture2Ds, le composant srcAddress .a (POS-swizzle) est ignoré.

L’extraction à partir d’un emplacement d’entrée qui n’a rien de lié retourne 0 pour tous les composants.

Restrictions

  • srcResource doit être un registre t#. srcResource ne peut pas être un ConstantBuffer, qui ne peut pas être lié à des registres t#.
  • srcSampler doit être un registre s#.
  • L’adressage relatif sur srcResource ou srcSampler n’est pas autorisé.
  • srcAddress doit être un registre temporaire (r#/x#), constantBuffer (cb#), un registre d’entrée (v#) ou une ou plusieurs valeurs immédiates.
  • dest doit être un registre temporaire (r#/x#) ou de sortie (o*#).
  • _aoffimmi(u,v,w) n’est pas autorisé pour les TextureCubes.

Cette instruction s’applique aux étapes suivantes du nuanceur :

Nuanceur de sommets Nuanceur de géométrie Nuanceur de pixels
x

Modèle de nuanceur minimal

Cette fonction est prise en charge dans les modèles de nuanceur suivants.

Modèle de nuanceur Prise en charge
Modèle de nuanceur 5 Oui
Modèle de nuanceur 4.1 Oui
Modèle de nuanceur 4 Oui
Modèle de nuanceur 3 (DirectX HLSL) non
Shader Model 2 (DirectX HLSL) non
Modèle de nuanceur 1 (DirectX HLSL) non

Shader Model 4 Assembly (DirectX HLSL)