Optimaler Speicherzugriff bei Verwendung von Nachschlagetabellen auf der GPU?

Ich untersuche Isoflächenalgorithmen auf der GPU für ein Bachelor-Projekt (wobei ich mich speziell auf binäre In / Out-Voxeldaten anstatt auf reelle Felder konzentriere). Ich habe also eine CPU-Implementierung von guten alten Marschwürfeln, die in OpenFrameworks ausgeführt werden, und bin gerade dabei, sie auf GLSL-Compute-Shader zu portieren und die Fallstricke zu berücksichtigen, bevor ich eintauche. Ich habe nur Vert- und Frag-Shader geschrieben vorher ist alles neu für mich.

Mein erstes Problem ist, wie eine Nachschlagetabelle über Dutzende oder Hunderte von Threads in einer Arbeitsgruppe hinweg effizient verwendet werden kann. Ich verstehe, dass eine GPU verschiedene Arten von Speicher für verschiedene Aufgaben hat, aber nicht ganz sicher ist, wie jede funktioniert oder welcher Typ verwendet werden soll.

Die klassische Copypasta-Tabelle von Paul Bourke ist ein 256 * 16-Array. Wenn Sie also einen skalaren Bytetyp verwenden, kann dieser vermutlich in eine 4-KB-Textur oder SSBO gepackt werden.

Die Frage ist, wie man verhindert, dass sich die verschiedenen Fäden gegenseitig auslösen. Viele Cubes in jeder Arbeitsgruppe können möglicherweise dieselbe Konfiguration haben und versuchen daher, gleichzeitig auf denselben Speicherort im Puffer zuzugreifen. Gibt es eine Problemumgehung oder Optimierung, um damit umzugehen?

— russ
quelle

Wenn es sich um eine schreibgeschützte Nachschlagetabelle handelt, können Sie einfach einen Puffer / eine Textur verwenden. Sie können es entweder in eines der normalen Texturformate packen oder einige der neueren Funktionen von DX11 / OpenGL verwenden, um ein benutzerdefiniertes Format zu erhalten. UAV im DX11-Land oder ein Textur- / Shader_image_load_store im OpenGL-Land.

— RichieSams

Schauen Sie sich diese Präsentation außerdem an: cvg.ethz.ch/teaching/2011spring/gpgpu/cuda_memory.pdf Es ist für CUDA, aber es sollte Ihnen eine bessere Vorstellung davon geben, was auf der zugrunde liegenden Hardware geschieht

— RichieSams

Keine vollständige Antwort, aber je weniger Speicher Sie verwenden, desto besser, da er mit größerer Wahrscheinlichkeit in Caches passt und weniger Cache-Fehler aufweist. Wenn Sie interpolierbare Werte haben, z. B. Punkte auf einer Kurve in Texturen ausbacken

— Alan Wolfe

Der beste Ort, um eine Nachschlagetabelle für einen GPU-Compute-Shader zu erstellen, hängt von der Größe der Nachschlagetabelle und der Häufigkeit / Kohärenz des Zugriffs ab. In Ihrem Fall (Sie haben 4 KB erwähnt) ist der gemeinsam genutzte lokale Speicher wahrscheinlich am besten (vorausgesetzt, Sie benötigen diesen Speicher nicht für andere Zwecke im selben Kernel). Dieser Speicher hat unterschiedliche Namen in verschiedenen APIs, ist jedoch dieselbe Architektur und folgt denselben Leistungsrichtlinien:

CUDA: Threadgroup Shared Memory
DirectCompute: Gruppenfreigabespeicher
OpenCL: lokaler Speicher
Metall: Threadgruppenspeicher
OpenGL: Shared Memory

Das Speichern der Nachschlagetabelle im globalen Speicher als schreibgeschützter Puffer kann je nach Cache-Größe (n) der jeweiligen GPU, auf der Sie ausgeführt werden, genauso gut funktionieren.

Beachten Sie, dass ich davon ausgehe, dass dies eine schreibgeschützte Nachschlagetabelle ist. Eine Lese- / Schreib-Nachschlagetabelle ist ein völlig anderes Tier, und Sie haben dort keine guten Optionen.

— GroverManheim
quelle

Es gibt auch Fälle, in denen ein schreibgeschützter Puffer besser funktioniert als das Speichern von 4 KB schreibgeschützten Daten im gemeinsam genutzten lokalen Speicher. Das Speichern im lokalen Speicher kann beispielsweise bedeuten, dass für jede Thread-Gruppe eine eindeutige Kopie Ihrer Daten vorhanden ist. Wenn der Puffer in den Cache passt, ist es durchaus möglich, dass der Cache für schreibgeschützte Zugriffsmuster eine bessere Leistung als der lokale Speicher erbringt.

— John Calsbeek

Danke für das Feedback Jungs. Ich habe das Projekt beendet, das ich jetzt verwendet habe, und bin nur mit einer r8ui schreibgeschützten Puffertextur fertig geworden, die ziemlich gut funktioniert hat :)

— russ