sync (sm5 - asm)

Synchronisation du groupe de threads ou barrière de mémoire.

Notes

La synchronisation offre des options _uglobal, _ugroup, _g et _t.

Dans le nuanceur de pixels, seule sync_uglobal est autorisée.

Dans le nuanceur de calcul, (_uglobal ou _ugroup*) et/ou _g doivent être spécifiés. _t est également facultatif.

_uglobal

Limite de mémoire u# globale (UAV).

Toutes les lectures/écritures de mémoire u# antérieures par ce thread dans l’ordre du programme sont rendues visibles par tous les threads sur l’ensemble du GPU avant tout accès u# à la mémoire u# ultérieur par ce thread. L’ensemble de la partie GPU de la définition est remplacé par une étendue moins globale dans un cas, décrit ci-dessous.

Cela s’applique à toute la mémoire UAV liée à l’étape actuelle du nuanceur.

_uglobal est disponible dans le nuanceur de calcul ou le nuanceur de pixels.

Pour tout UAV lié qui n’a pas été déclaré comme globalement cohérent par le nuanceur, la limite de mémoire u# _uglobal n’a de visibilité que dans le groupe de threads du nuanceur de calcul actuel pour cet UAV, comme s’il s’agit d'_ugroup au lieu de _uglobal. Ce problème s’applique uniquement au nuanceur de calcul, car le nuanceur de pixels doit déclarer tous les UAV comme globalement cohérents.

_ugroup

Limite de mémoire U# (UAV) de l’étendue du groupe de threads.

Toutes les lectures ou écritures de mémoire u# antérieures par ce thread dans l’ordre du programme sont rendues visibles pour tous les threads du groupe de threads avant tout accès à la mémoire u# ultérieur par ce thread.

Cela s’applique à toute la mémoire UAV liée à l’étape actuelle du nuanceur.

_ugroup est disponible uniquement dans le nuanceur de calcul.

Si _ugroup est exposé, pour certaines implémentations. L’avantage de spécifier _ugroup au lieu de _uglobal est que l’opération de synchronisation peut se terminer plus rapidement.

D’autres implémentations ne distinguent pas _ugroup des _uglobal, de sorte que les deux opérations sont équivalentes et se comportent comme _uglobal. Les applications peuvent spécifier leur intention en demandant l’étendue de synchronisation la plus étroite nécessaire.

Même si un UAV particulier est déclaré globalement cohérent, une opération de synchronisation _ugroup fonctionnera plus efficacement sur ce drone si un obstacle global n’est pas nécessaire.

_g

limite g# (mémoire partagée du groupe de threads).

Toutes les lectures ou écritures de mémoire g# antérieures par ce thread dans l’ordre du programme sont rendues visibles par tous les threads du groupe de threads avant tout accès à la mémoire g# ultérieur par ce thread.

Cela s’applique à toute la mémoire partagée g# du groupe de threads actuel.

_g est disponible uniquement dans le nuanceur de calcul.

_t

Synchronisation du groupe de threads. Tous les threads d’un seul groupe de threads (ceux qui peuvent partager l’accès à un ensemble commun d’espace de registre partagé) sont exécutés jusqu’au point où ils atteignent cette instruction avant qu’un thread puisse continuer.

_t ne peut pas être placé dans le contrôle de flux dynamique (branches qui peuvent varier au sein d’un groupe de threads), mais peuvent être présents dans le contrôle de flux uniforme, où tous les threads du groupe sélectionnent le même chemin.

_t est disponible uniquement dans le nuanceur de calcul.

Voici une liste des variantes « sync » du nuanceur de calcul.

• sync_g
• sync_ugroup*
• sync_uglobal
• sync_g_t
• sync_ugroup_t*
• sync_uglobal_t
• sync_ugroup_g*
• sync_uglobal_g
• sync_ugroup_g_t*
• sync_uglobal_g_t

*Les variantes avec _ugroup peuvent ne pas être ciblées par le compilateur HLSL, conformément à la discussion précédente dans la section _ugroup ci-dessus.

La liste des variantes de synchronisation du nuanceur de pixels inclut sync_uglobal uniquement.

Les clôtures de mémoire empêchent les instructions affectées d’être réorganisées par les compilateurs ou le matériel sur l’ensemble de la clôture.

Plusieurs lectures de la même adresse par un appel de nuanceur qui ne sont pas séparées par des barrières de mémoire ou des écritures dans l’adresse peuvent être réduites. Il en va de même pour les écritures. Les accès séparés par une barrière ne peuvent pas être fusionnés ou déplacés au-delà de la barrière.

Les clôtures de mémoire ne sont pas nécessaires pour que les opérations atomiques sur une adresse donnée par différents threads fonctionnent correctement. Des clôtures sont nécessaires lorsque les opérations atomiques et/ou de chargement/stockage doivent être synchronisées les unes par rapport aux autres, car elles apparaissent dans des threads individuels du point de vue d’autres threads.

Dans le nuanceur de pixels, les instructions d’abandon impliquent une clôture sync_uglobal, car les instructions ne peuvent pas être réorganisées sur l’ensemble du rejet. sync_uglobal dans les pixels d’assistance (qui s’exécutent uniquement pour prendre en charge les dérivés) ou les pixels ignorés peuvent ou non avoir un impact. Il n’est pas autorisé que les pixels d’assistance ou ignorés écrivent dans des UAV si, dans le cas d’un abandon, les écritures sont émises après l’abandon. Les valeurs retournées par les UAV ne sont pas autorisées à contribuer aux calculs dérivés. Par conséquent, si sync_u est respecté ou non pour les pixels d’assistance ou lorsqu’il est émis après un rejet est sans objet.

cs_4_0 et cs_4_1 prennent en charge cette instruction.

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

Étant donné que les UAV sont disponibles à toutes les étapes du nuanceur pour Direct3D 11.1, la variante sync_uglobal de cette instruction s’applique à toutes les étapes du nuanceur pour le runtime Direct3D 11.1, disponible à partir de Windows 8.

Modèle de nuanceur minimal

Cette instruction est prise en charge dans les modèles de nuanceur suivants :

Rubriques connexes

Assembly de modèle de nuanceur 5 (DirectX HLSL)