sync (sm5 – asm)

  • Artikel

Threadgruppensynchronisierung oder Speicherbarriere.

sync[_uglobal|_ugroup][_g][_t]

 

Bemerkungen

Die Synchronisierung verfügt über Optionen _uglobal, _ugroup, _g und _t.

Im Pixelshader ist nur sync_uglobal zulässig.

Im Compute-Shader müssen (_uglobal oder _ugroup*) und/oder _g angegeben werden. _t ist zusätzlich optional.

_uglobal

Globaler u#-Speicherzaun (UAV).

Alle vorherigen u#-Speicherlese-/Schreibvorgänge durch diesen Thread in der Programmreihenfolge werden für alle Threads auf der gesamten GPU sichtbar gemacht, bevor dieser Thread auf den u#-Arbeitsspeicher zugreift. Der gesamte GPU-Teil der Definition wird in einem Fall durch einen weniger als globalen Bereich ersetzt, der unten beschrieben wird.

Dies gilt für den gesamten UAV-Speicher, der in der aktuellen Shaderphase gebunden ist.

_uglobal ist im Compute-Shader oder Pixelshader verfügbar.

Für alle gebundenen UAVs, die vom Shader nicht als Globally Coherent deklariert wurden, verfügt der _uglobal u#-Speicherzaun nur über Sichtbarkeit innerhalb der aktuellen Compute-Shaderthread-Threadgruppe für dieses UAV, als wäre er _ugroup anstelle von _uglobal. Dieses Problem gilt nur für den Compute-Shader, da der Pixelshader alle UAVs als Globally Coherent deklarieren muss.

_ugroup

Threadgruppenbereich u# (UAV)-Speicherzaun.

Alle vorherigen Lese- oder Schreibvorgänge des u#-Arbeitsspeichers durch diesen Thread in der Programmreihenfolge werden für alle Threads in der Threadgruppe sichtbar gemacht, bevor dieser thread auf u#-Speicherzugriffe zugreift.

Dies gilt für den gesamten UAV-Speicher, der in der aktuellen Shaderphase gebunden ist.

_ugroup ist nur im Compute-Shader verfügbar.

Wenn _ugroup für einige Implementierungen verfügbar gemacht wird. Der Vorteil der Angabe von _ugroup anstelle von _uglobal besteht darin, dass der Synchronisierungsvorgang schneller abgeschlossen werden kann.

Andere Implementierungen unterscheiden _ugroup nicht von _uglobal, sodass beide Vorgänge gleichwertig sind und sich wie _uglobal verhalten. Anwendungen können ihre Absicht angeben, indem sie den kleinsten erforderlichen Synchronisierungsbereich anfordern.

Selbst wenn eine bestimmte UAV als Globally Coherent deklariert wird, funktioniert ein _ugroup Synchronisierungsvorgang effizienter für diese UAV, wenn keine globale Barriere erforderlich ist.

_g

g# (thread group shared memory) fence.

Alle vorherigen g#-Speicherlesevorgänge oder -schreibvorgänge von diesem Thread in der Programmreihenfolge werden für alle Threads in der Threadgruppe sichtbar gemacht, bevor dieser Thread auf den g#-Speicher zugreift.

Dies gilt für den gesamten freigegebenen g#-Speicher der aktuellen Threadgruppe.

_g ist nur im Compute-Shader verfügbar.

_t

Threadgruppensynchronisierung. Alle Threads innerhalb einer einzelnen Threadgruppe (diejenigen, die den Zugriff auf einen gemeinsamen Satz freigegebener Registerräume gemeinsam nutzen können) werden bis zu dem Punkt ausgeführt, an dem sie diese Anweisung erreichen, bevor ein Thread fortgesetzt werden kann.

_t kann nicht in die dynamische Flusssteuerung platziert werden (Verzweigungen, die innerhalb einer Threadgruppe variieren können), können aber in einer einheitlichen Flusssteuerung vorhanden sein, bei der alle Threads in der Gruppe denselben Pfad auswählen.

_t ist nur im Compute-Shader verfügbar.

Im Folgenden finden Sie eine Liste der Compute-Shader-Synchronisierungsvarianten.

  • 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

*Varianten mit _ugroup dürfen nicht vom HLSL-Compiler als Ziel verwendet werden, wie oben im Abschnitt _ugroup weiter oben erläutert.

Die Liste der Pixelshader-Synchronisierungsvarianten umfasst nur sync_uglobal.

Speicherzäune verhindern, dass betroffene Anweisungen von Compilern oder Hardware über den Zaun hinweg neu angeordnet werden.

Mehrere Lesevorgänge aus derselben Adresse durch einen Shaderaufruf, die nicht durch Speicherbarrieren oder Schreibvorgänge in die Adresse getrennt sind, können zusammen reduziert werden. Gleiches gilt für Schreibvorgänge. Durch eine Barriere getrennte Zugänge können nicht zusammengeführt oder über die Barriere verschoben werden.

Speicherzäune sind nicht erforderlich, damit atomische Vorgänge zu einer bestimmten Adresse durch verschiedene Threads ordnungsgemäß funktionieren. Zäune sind erforderlich, wenn Atom- und/oder Lade-/Speichervorgänge in Bezug aufeinander synchronisiert werden müssen, da sie in einzelnen Threads aus der Sicht anderer Threads angezeigt werden.

Im Pixelshader impliziert Verwerfen-Anweisungen einen sync_uglobal Zaun, da Anweisungen nicht über den Verwerfen hinweg neu angeordnet werden können. sync_uglobal in Hilfspixeln (die nur zur Unterstützung von Ableitungen ausgeführt werden) oder verworfenen Pixeln können auswirkungen. Hilfs- oder verworfene Pixel dürfen nicht in UAVs schreiben, wenn die Schreibvorgänge nach dem Verwerfen ausgegeben werden. Zurückgegebene Werte von UAVs dürfen nicht zu abgeleiteten Berechnungen beitragen. Daher wird sync_u für Hilfspixel berücksichtigt oder nicht, wenn sie nach einem Verwerfen ausgegeben wird.

cs_4_0 und cs_4_1 unterstützen diese Anweisung.

Diese Anweisung gilt für die folgenden Shaderphasen:

Scheitelpunkt Hull Domain Geometrie Pixel Compute
X X

 

Da UAVs in allen Shaderphasen für Direct3D 11.1 verfügbar sind, gilt die sync_uglobal Variante dieser Anweisung für alle Shaderphasen für die Direct3D 11.1-Runtime, die ab Windows 8 verfügbar ist.

Scheitelpunkt Hull Domain Geometrie Pixel Compute
X X X X X X

 

Minimales Shadermodell

Diese Anweisung wird in den folgenden Shadermodellen unterstützt:

Shadermodell Unterstützt
Shadermodell 5 ja
Shadermodell 4.1 Nein
Shadermodell 4 Nein
Shadermodell 3 (DirectX HLSL) Nein
Shadermodell 2 (DirectX HLSL) Nein
Shadermodell 1 (DirectX HLSL) Nein

 

Shadermodell 5-Assembly (DirectX HLSL)