Rechnen per CUDA

Simulationen mit Matrizen etc. lassen sich sehr gut parallelisieren, auch der Design Rule Check bei uns im BAE High End ist bereits parallelisiert (der merkt, wenn weitere Cores anwesend sind). Signalverarbeitung schreit auch danach.

Hingegen wird man sich beim Autorouter sehr schwer tun, weil es eine recht eklige Abhängigkeit der Daten voneinander gibt, die allen Dijkstra-ähnlichen Algorithmen gemein ist:

Siehe z.B.:

Die Synchronisierung ist - auch nach unserern ausgiebigen Tests - das große Problem. Bei handelsüblichen n-Core Prozessoren für PC's kostet die mehr Zeit als das Parallelisieren bringt, bei einer Grafikkarte wäre das noch zu untersuchen.

Gruß Oliver

Frank Buss :

Klingt ja interessant. Was passiert eigentlich, wenn die Grafikkarte schon vom Direct-X Treiber benutzt wird?

M.

Hallo!

"Frank Buss" wrote

Sehr schön, ich wollte mich schon immer mal damit beschäftigen. Gibts dazu ein Tutorial/Buch?

alsdenn, Jens

Sollte schon. Wenn die Grafikkarte auch tatsaechlich fuer Grafik benutzt wird, gibt aber einen Watchdog (ich glaube 5 Sek. warens), so dass der Bildschirm nicht von einem lange rechnenden Kernel geblockt werden kann.

Florian

Hallo,

Dieses Paper [1] koennte in diesem Zusammenhang ganz interessant sein. Oder auch jenes hier [2].

Bjoern

Björn Franke schrieb:

Hat da jemand Zugriff auf das Paper und kann es mir evtl. zukommen lassen? Herzlichen Dank!

Klaus Rotter schrieb:

Danke, habe es erhalten!

Am besten erstmal CUDA Treiber, Toolkit und SDK installieren. Im Toolkit gibt es zwei gute PDFs: Ein Programmers Guide, mit einer auführlichen Beschreibung und Beispielen, und eine API-Referenz (auch als CHM). Gibt auch viele Beispiele, aber ich habe ein einfaches Hello-World, ohne Abhängigkeiten zu den Beispiel-Commons, vermisst und daher das hier als Basis verwendet:

Der Library-Pfad ist absolut in den Project-Settings codiert, den ggf. einfach durch $(CUDA_LIB_PATH) ersetzen, dann läuft es und man kann das leicht für eigene Experimente verwenden.

Scheint keine Probleme zu geben, wenn man ein wenig sogfältig programmiert. Ich habe hier Vista mit Aero und kann während der Berechnung ohne Probleme z.B. Windows-Tab drücken, für die 3D-Ansicht der Fenster. Ruckelt während der Berechnung allerdings recht stark. Die Berechnung ging über 12 Sekunden, waren allerdings immer einzelne kleine Häppchen.

Ich habe eben mal ein "while (1);" eingebaut und scheint tatsächlich ein Timeout von ca. 5 Sekunden zu geben: Die Abarbeitung bricht dann ab. Scheint also wirklich so zu sein, daß alles stehen bleibt, was mit Grafik zu tun hat, solange ein Programm per CUDA ausgeführt wird, denn während der Endlosschleife kann man nur die Maus bewegen, aber sonst ist alles eingefroren (CPU-Zeit ist natürlich immer noch vorhanden). Nach dem Abbruch kommt eine Meldung, daß es einen Fehler im Displaytreiber gegeben hat, man kann aber sonst danach weiterarbeiten.

Hier übrigens die Ausgabe für die 12 Sekunden Rechenzeit: 1000 gerade stromdurchflossene Leiterstücke, in einer komplexen Kurve angeordnet und dann das Magnetfeld von 1600x1200 Punkten im Raum vektoriell berechnet, die in einer passenden Ebene liegen und logarithmisch dargestellt werden, wobei die x/y/z-Komponenten jedes Magnetfeldvektors jeweils für RGB (Modulo 256) verwendet werden. Also nichts sinnvolles, aber sieht hübsch aus :-)

Die Synchronisierung soll laut dem Programming Guide sehr optimiert sein. Auch das Scheduling ist recht ausgeklügelt und soll so gut wie keinen Overhead haben. Muß es auch, bei hunderten von parallel laufenden Threads und der dynamischen Verteilung je nach Blockanzahl und Auslastung, und je nach Grafikkarte. Bleibt aber natürlich noch das Problem, daß man den Algorithmus so schreiben muß, daß die Threads nicht allzu lange Leerlauf haben beim synchronisieren.

Allerdings gibt es einige schöne Hilfsmittel. Z.B. Matrixoperationen werden bis zu 3 Dimensionen speziell von der Hardware unterstützt, sodaß die Implementierung des parallelen Algorithmus schon fast trivial wird. Werde ich vielleicht mal bei Gelegenheit ausprobieren.

Das Jonglieren mit local-, global-, host-Memory und Threads, Blöcken und Registern (wobei letzteres der Compiler einem abnimmt), Speicherzugriffsstrategien usw., ist allerdings nicht ganz trivial, wenn man wirklich das letzte an Geschwindigkeit herausholen will.

Der Auftraggeber hat auch diese Version freigegeben, hier ist die aktualisierte Webseite:

Kann man auch gut als Beispielprojekt für eigene Experimente mit CUDA verwenden.