Unity Burst und Jobs: Abhängigkeiten rund um gemeinsam genutzte native Daten entwerfen

Kompilierung und Scheduling trennen

Burst unterstützt eine eingeschränkte Teilmenge von C#, die sich für die native Kompilierung eignet; das Job System plant die Arbeit und deren Abhängigkeiten ein. Das Hinzufügen von [BurstCompile] legt nicht fest, in welcher Reihenfolge separate Jobs auf gemeinsame Daten zugreifen dürfen. Zuerst den Datenfluss entwerfen, danach die Berechnung an die von Burst unterstützten Typen anpassen. Dieser Artikel stützt sich auf die Vorgaben der zitierten Dokumentation zu Unity 6.0 und Burst 1.8. [1][3]

Zugriff auf die Allokation deklarieren

Ein NativeArray<T> ermöglicht den Zugriff auf nativen Speicher. Kopien seines Container-Werts verweisen auf dieselbe zugrunde liegende Allokation. Wird der Container an mehrere Jobs übergeben, erhält daher nicht jeder Job einen eigenen, unabhängigen Ergebnispuffer. [2][3]

Ein Job-Feld mit [ReadOnly] markieren, wenn der Job es nur liest. Mehrere lesende Jobs können dann dieselbe Eingabe teilen, ohne fälschlich Schreibzugriff anzumelden. Zwischen einem Producer, der ein Array beschreibt, und einem Consumer, der es liest, ist eine explizite Abhängigkeit nötig. Auch der Main Thread muss ausstehende Zugriffe beachten; von den Sicherheitsregeln des Containers ist er nicht ausgenommen. [2]

Ein anschauliches Beispiel: Bojenberechnung

Angenommen, eine Szene enthält 256 Bojen. Deren Positionen werden als Eingabedaten aufbereitet. Ein Job zur Wellenabtastung schreibt ein Höhen-Array, ein davon unabhängiger Job zur Windabtastung schreibt ein Wind-Array. Beide können das Positions-Array lesen; keiner der beiden Producer sollte die Ausgabe des anderen überschreiben.

Die Handles beider Jobs mit JobHandle.CombineDependencies zusammenführen und das kombinierte Handle beim Einplanen eines Jobs für die Kraftberechnung übergeben, der beide Ergebnisse liest. Die Kombination bewirkt, dass der Consumer auf beide Producer wartet. Sie zwingt die Producer nicht, gleichzeitig zu laufen, und allein die Reihenfolge des Einplanens würde die erforderliche Abhängigkeit nicht herstellen. Die genannten Namen und die Anzahl der Bojen beschreiben einen vorgeschlagenen Projektentwurf. [3]

Die Übergabe an den Main Thread festlegen

Das Handle des letzten Jobs aufbewahren. Complete aufrufen, bevor der Main Thread dessen Ergebnispuffer liest, und die daraus folgenden Änderungen an der Szene anschliessend vom Main Thread aus anwenden. Der Abschluss dieses abhängigen Jobs schliesst auch die Abhängigkeiten ab, die für sein Ergebnis erforderlich sind. [3]

Diese Übergabe dort platzieren, wo das Ergebnis tatsächlich gebraucht wird. Wird jeder Producer sofort abgeschlossen, gehen Möglichkeiten verloren, sinnvolle Arbeit zu überlappen. Auch bei Abbruch oder beim Abbau der Szene muss die Verantwortung für den Container nachvollziehbar bleiben: Ausstehende Zugriffe beenden, bevor die Allokation mit Dispose freigegeben wird. Einen Allocator wählen, dessen dokumentierte Lebensdauer dazu passt, wie lange der Puffer in Gebrauch bleibt. [2][3]

Grenzen prüfen und die Last messen

Gewöhnliche verwaltete Objektgraphen liegen ausserhalb des von Burst unterstützten Datenmodells. Geeignete Wertdaten und native Container aufbereiten, anstatt Referenzen auf Szenenobjekte in den numerischen Kernel zu übergeben. Für konkrete Ausnahmen und Einschränkungen die Typreferenz konsultieren; die Unterstützung ist differenzierter als die pauschale Aussage, jedes C#-Konstrukt funktioniere. [1]

Die Bojen-Pipeline auf fehlende Abhängigkeiten, versehentliche Schreibzugriffe, zu frühen Abschluss und wiederholte Allokation prüfen. Scheduling-Overhead, Berechnung und Wartezeit des Main Threads auf dem Zielgerät messen. Ein korrekter Abhängigkeitsgraph stellt eine sichere Reihenfolge her; bei kleinen Workloads verspricht er keine Beschleunigung.

Quellen

1. C# type support — Burst 1.8 — Unity Technologies.
2. Introduction to NativeContainer — Unity Technologies.
3. Job dependencies — Unity Technologies.