CUDA, Directcompute, Open CL

Möglichkeiten und Grenzen von GPU-Computing

GTC

Am Vortag von Nvidias GPU Technology Conference (GTC) gaben Entwickler von Khronos, Microsoft und Nvidia einen Überblick über die Einsatzgebiete von GPUs für allgemeine Berechnungen. Der Konsens: GPUs sind schnell, aber nur, wenn man sie richtig programmiert.

Artikel veröffentlicht am 21. September 2010, 9:07 Uhr, Nico Ernst

CUDA, Directcompute und Open CL - gleich drei Programmierschnittstellen gibt es, um auf Nvidia-GPUs Rechenaufgaben durchzuführen. Welche die beste ist, wagten auch die Entwickler in den Einführungsvorträgen der GTC nicht zu behaupten. An verschiedenen Beispielen zeigten sie jedoch, dass auch längst gelöste Probleme wie die Fourier-Transformation (FFT) oder Matrizenreduktion auf GPUs besonderer Behandlung bedürfen.

Die höhere Parallelität einer GPU im Vergleich mit einer CPU wirkt sich nur dann positiv aus, wenn der Chip ständig viel zu tun hat. Dafür gilt es vor allem, mit dem immer knappen Hauptspeicher - was in diesem Fall das auf der Karte verfügbare RAM ist - und dessen Bandbreite sorgfältig umzugehen. Ein weiterer Eckpfeiler: Threads dürfen sich nicht gegenseitig behindern.

• 

Ein Foto aus der Realität, ...

So zeigte Nvidia, dass sich für die parallele Matrizenreduktion Beschleunigungen bis zum Dreißigfachen erreichen lassen. Das gilt aber nur, wenn sich Verzweigungen (Branches) weitgehend vermeiden lassen, die Speicherzugriffe aneinander ausgerichtet und verschachtelt sind (interleaving) und in einem Thread mehrere Objekte behandelt werden. Das ist ein Unterschied zum Füttern von Threads auf x86-CPUs. Diese Chips kommen mit Abhängigkeiten von Aufgaben untereinander wesentlich besser zurecht.

Da der Speicher immer knapp ist, müssen manchmal Zwischenschritte eingeschoben werden, auch bei grafikorientierten Routinen. Da die Tessellation von DirectX-11 nur 64 Detailstufen vorsieht, empfahl Nvidia für die Darstellung von Bergen eine weitere Unterteilung per fraktaler Selbstähnlichkeit. Das kann dann, auch innerhalb einer Grafikanwendung, ein Directcompute-Shader erledigen. Dafür ist jedoch ein Kontextwechsel nötig, was wieder Rechenzeit kostet.

Statt einer einzelnen Spiegelung wie durch das Objektiv des Betrachters lassen sich so auch viel Flares an mehreren Lichtquellen erzeugen. Ein weiteres Beispiel führte Microsoft an. Die Linsenreflexionen (lens flares), die in Spielen den von Filmen gewohnten Eindruck des gewollten fotografischen Fehlers vermitteln sollen, lassen sich auch über eine Fourier-Transformation erzielen.

Ohne ein exponentielles Ansteigen der Rechenzeit geht das aber nur, wenn 3D-Modell und Compute-Shader zusammenarbeiten. Wie schon bei der Tessellation lassen sich solche Effekte also nicht nachträglich auf bestehende Programme anwenden, sie müssen von Anfang an einkalkuliert werden.