OpenCL

[bstea]

Ich hab' immer zwischen OpenCL und CUDA/Stream unterschieden, frag' mich ob das der Autor hier auch versteht.
Ersteres hat das Ziel eine einfache gemeine Basis zu erstellen und Aufgaben von allen Recheneinheiten also auch GPU zu nutzen und letztere dienen zum ausschließlichen berechnen auf der Grafikkarte. Nebenbei wurde OpenCL auch mit Hilfe von AMD weiterentwickelt.

[TheUltimateStar]

Hatte mich erst letzte Woche damit kurz beschäftigt, der Syntax von CUDA und OpenCL schien ja erstmal nicht sonderlich groß zu sein, auch das Drumherum wirkte ähnlich. Sofern es vom Hersteller beides einigermaßen unterstützt wird dürfte die Performance doch gleich sein, womit der Punkt bei mir erstmal an OpenCL ging.
Okay, die erreichte Geschwindigkeit blieb weiter hinter den Erwartungen zurück, aber das schob ich mal auf mein mangelndes Detailwissen :D

[pwn2own]

TheUltimateStar schrieb:
--------------------------------------------------------------------------------
> Okay, die erreichte Geschwindigkeit blieb weiter hinter den Erwartungen
> zurück, aber das schob ich mal auf mein mangelndes Detailwissen :D

Da magst du wohl recht haben. Bei GPGPU gbt es viele kleine Schräubchen und Zahnrädern, an denen man drehen kann/muss, damit es ordentlich läuft :)

[TheUltimateStar]

pwn2own schrieb:
--------------------------------------------------------------------------------
> Da magst du wohl recht haben. Bei GPGPU gbt es viele kleine Schräubchen und
> Zahnrädern, an denen man drehen kann/muss, damit es ordentlich läuft :)
Als Informatiker gefallen einem diese viele Schräubchen ja eigentlich auch, hätte aber halt schon erwartet das ein Straight-Forward-Lösung zu mindestens erstmal eine solide Leistung erzielt. Luft zum Optimum wäre ja verständlich, aber das meine stupide SSE-Implementierung fast 10x so schnell ist spricht nicht für die Einsteigerfreundlichkeit des Frameworks. Wobei ich im Nachhinein aber auch denke dass das Problem auch nicht so gut auf die GPU passt, letztlich sollte da nur jedes Texel einer Luminenztexture mit einem Gewicht aus einem Float-Puffer multipliziert und aufaddiert werden. Dabei jedes Texel nur genau einmal zu lesen und quasi dazwischen nichts groß zu tun überfordert die Texelfetch-Units vielleicht, dem widerspricht nur ein wenig dass das Hinzufügen der Multiplikation mit den Gewichten nochmal im Vergleich zum reinen aufsummieren deutlich Zeit kostet. Aber da ich in der Zeit die zum synchronisieren zwischen OpenGL und OpenCL notwendig ist die Textur auch genauso gut in den Hauptspeicher kopiert habe war es letztlich halt sinnlos da weiter die ms zusammen zu suchen.

[rayo]

Hallo

Was mir zu deinem Problem gerade einfällt:
- Float-Puffer muss am Anfang in den Shared Memory geladen werden (jeder Thread 1 Wert)
- Jeder Thread sollte dann mehrere Werte in der Textur mit dem Puffer multiplizieren. Wenn N Threads laufen, sollte Thread 1 die Werte an Position ThreadID, ThreadID+N, ThreadId+2N, etc berechnen. Damit laden die einzelnen Threads die Daten sequentiell (was schneller ist)


Also was zu beachten ist:
- Shared memory ist für viele Zugriffe innerhalb einer WorkUnit schnell
- Daten aus dem Global Memory immer Sequentiell laden
- Nicht zu wenige Berechnungen pro Thread
- Work Load der GPU sollte möglichst gross sein (limiterender Faktor könnte shared memory, register count, thread count, workload unit size sein)


Gruss