ALU-Leistung der GPUs abseits der Peak-Werte

[AnarchX]

Nahezu jeder wird hier die Peak-Werte für einfache Genauigkeit oder doppelte Genauigkeit für Fließkommaberechnungen auf den aktuellen GPUs kennen.

Aber darüber hinaus gibt es diverse Feinheiten für einige Rechenarten, die in diesem Thread explizit gesammelt werden sollen.

[=Floi=]

man sollte aber auch bei games beachten, dass die karten hier nicht durchgehend voll ausgenutzt werden. Gerade bei ati würde mehr GPGPU voll durchschlagen und man würde mit physx kreise um nv drehen.

[deekey777]

Nahezu jeder wird hier die Peak-Werte für einfache Genauigkeit oder doppelte Genauigkeit für Fließkommaberechnungen auf den aktuellen GPUs kennen.

Aber darüber hinaus gibt es diverse Feinheiten für einige Rechenarten, die in diesem Thread explizit gesammelt werden sollen.
Videoencoding. Da braucht man Integerleistung.
Oder das ganze Knacker-Zeug (das sind auch ganze Zahlen).
http://www.planet3dnow.de/vbulletin/showthread.php?t=375718&garpg=14#content_start
http://www.planet3dnow.de/vbulletin/showthread.php?t=375718&garpg=15#content_start

[Fetza]

man sollte aber auch bei games beachten, dass die karten hier nicht durchgehend voll ausgenutzt werden. Gerade bei ati würde mehr GPGPU voll durchschlagen und man würde mit physx kreise um nv drehen.

Warum?

[wizardSE]

Siehe c't 19/10 S. 106, Im Zeitalter des CUDAismus

--> praktische GPU-Rechenleistung, was wird von den theoretischen Größen tatsächlich erreicht

[PatkIllA]

Videoencoding. Da braucht man Integerleistung.Da wird Integer an vielen Stellen nur als Notlösung gebraucht, weil so eine massive Floatingpoint Power wie bei GPUs meistens nicht zur Verfügung steht. Oder in vielen Umgebungen gibt es auch mal gar Floatingpoint-Einheit.
Man sollte mit GPUs eine ordentliche Videocodierung hinbekommen, aber da kann man halt nicht einfach mal den Codec so wie er ist nach CUDA schieben, sondern kann sich jeden Teilschritt und die Parallelisierung erneut anschauen und im Prinzip schreibt man das Teil dann komplett neu. Das vorhandene Encoder mit Integer arbeiten ist da wohl eher ein Randproblem. Selbst bei den Decodern scheint es ja noch wie vor einfacher zu sein, einen extra Teil im Chip extra dafür abzustellen, der nur dafür zuständig ist.

[deekey777]

Wo brauchst du beim Videoencoding FP-genauigkeit? Ich kenne keine einzige Aussage von Leuten wie DarkShikari, dass irgendwo FP gebraucht wird.

[PatkIllA]

Wo brauchst du beim Videoencoding FP-genauigkeit? Ich kenne keine einzige Aussage von Leuten wie DarkShikari, dass irgendwo FP gebraucht wird.
Ich habe auch nie gesagt, dass die gebraucht wird, aber die meisten Rechnungen kannst du auch als FP machen. Bei einer CPU sinnlos, aber bei einer GPU, die FP Power zum umfallen hat, aber schlecht im Integerbereich ist möglich. Und wenn man Sachen die man mit 8 Bit Integer gut machen kann auf ein 32 Bit FP umsetzt.
Es bleibt aber das effiziente parallelisieren und damit einer praktischen Neuentwicklung.
Die jetzigen GPU Encoder unterstützen AFAIK doch auch nur bestenfalls einen kleinen Teil der Möglichkeiten von H264 und das auch wohl noch mit einer eher schlechten Qualität. Da kann man auch fast schon genauso gut x264 mit den schnellsten Einstellungen laufen lassen.

[Senior Sanchez]

Wo brauchst du beim Videoencoding FP-genauigkeit? Ich kenne keine einzige Aussage von Leuten wie DarkShikari, dass irgendwo FP gebraucht wird.

Arbeiten nicht solche Geschichten wie Motion Estimation (z.B. via Blockmatching) mit Subpixelgenauigkeit? Ergo bräuchte man dort FP-Genauigkeit. ;)

[sputnik1969]

Arbeiten nicht solche Geschichten wie Motion Estimation (z.B. via Blockmatching) mit Subpixelgenauigkeit? Ergo bräuchte man dort FP-Genauigkeit. ;)
Nein, als Programmierer kann ich dir sagen, das kann ich auch mit 32bit Integer erledigen. Nicht so komfortabel, aber das ist ja nicht die Fragestellung gewesen.

[Coda]

Arbeiten nicht solche Geschichten wie Motion Estimation (z.B. via Blockmatching) mit Subpixelgenauigkeit? Ergo bräuchte man dort FP-Genauigkeit. ;)
Nö. Das macht man das mit fixed point. Machen auch die GPUs bei Subpixel Präzision.

[pest]

ja da kann man sich dann stundenlang Gedanken machen wie man perfekt bei mehreren Schritten rundet.
Der Vorteil von fixed-point ist weiterhin, dass den Code dann keiner mehr versteht, auch wenn man nur 1/(1+exp(-z)) macht,
weil man table-lookups benutzt und wild shiftet. Kack diskrete Computer.
a*b, ist ja z.B. in fixed-point (a*b+(1<<11))>>12, wenn a,b 12-bit Genauigkeit haben und Zahlen zwischen 0 und 1 repräsentieren.

[Senior Sanchez]

Das "brauchen" war jetzt auch etwas anders gemeint. Natürlich kann ich das ganze mit Integer oder Fixed Point machen, aber
1. ist das aufwändig zu implementieren, wie pest schon andeutete
2. (habs neulich erst wieder in einem Paper gelesen, sodass ich mal davon ausgehe, dass es stimmt) erreichen die Lösungen eben nicht die Genauigkeit von echten FP-Varianten.

[pest]

Ist aber schneller, und das mit der Genauigkeit ist so eine Sache. Das muss nicht unbedingt sein.
Kann sogar unter Umständen besser sein.

[Senior Sanchez]

Ist aber schneller, und das mit der Genauigkeit ist so eine Sache. Das muss nicht unbedingt sein.
Kann sogar unter Umständen besser sein.

Sicherlich ist Integer oder Fixed Point in der Regel schneller, aber dass die Genauigkeit da besser sein soll glaube ich eigentlich nicht. Höchstens in Form durch Zufall oder günstige Rundungsfehler, aber die Regel ist es nicht.

[Coda]

Doch doch. Fixed Point teilt einen Wertebereich in gleichbreite Abschnitte ein, Floating Point nicht (je nach Exponent sind sie kleiner oder größer). Das kann durchaus numerisch deutlich gutmütiger sein, je nach Anwendungsfall.

Gerade bei Subpixelpräzision ist Fixed Point besser, weil man den Exponent ja sowieso fixiert und immer weiß wo das Komma ist.

[Senior Sanchez]

Doch doch. Fixed Point teilt einen Wertebereich in gleichbreite Abschnitte ein, Floating Point nicht (je nach Exponent sind sie kleiner oder größer). Das kann durchaus numerisch deutlich gutmütiger sein, je nach Anwendungsfall.

Gerade bei Subpixelpräzision ist Fixed Point besser, weil man den Exponent ja sowieso fixiert und immer weiß wo das Komma ist.

Stimmt, da hast du Recht.

[AnarchX]

Cayman ist wohl für DP-MUL nur noch 1/4 statt 1/2 auf Cypress?

[PCGH_Carsten]

Eins hat die T-Unit gemacht, eins die anderen vier zusammen. Nun fehlt „T”.

[deekey777]

http://developer.amd.com/gpu_assets/Heterogeneous_Computing_OpenCL_and_the_ATI_Radeon_HD_5870_Architecture_201003.pd f
Folie 58:
1 64b FP MUL/clk, es hat sich nichts geändert.
Fattie hat nie was mit DP getan.

Oder es ist malwieder der gleiche Fehler, der in die Cayman-Präsentation übernommen wurde und alles, was DP-fähig ist, auch 2xDP-MUL pro Takt beherrscht.

[PCGH_Carsten]

Hm, sieht wirklich so aus. Damn.
Allerdings hat sich die AMD-Präsentation seit dem Barts-Launch auch etwas bewegt.
Waren's zuvor noch zwei 64 Bit MUL or ADD, gibt es jetzt nur noch 2 64 Bit ADDs.

[deekey777]

Hm, sieht wirklich so aus. Damn.
Allerdings hat sich die AMD-Präsentation seit dem Barts-Launch auch etwas bewegt.
Waren's zuvor noch zwei 64 Bit MUL or ADD, gibt es jetzt nur noch 2 64 Bit ADDs.
Ich hab's:
http://forum.beyond3d.com/showthread.php?p=1496412#post1496412

[=Floi=]

gibt es eigentlich auch irgendwo benchmarks oder theoretische überlegungen, wie stark die VLIW 5 einheiten den VLIW 4 einheiten der neuen designs bei optimiertem perfektem code überlegen sind/wären?

mein gedankengang ist hier von den consolen inspieriert, weil dort viel mehr optimiert werden kann und ein effizienteres design eher bevorzugt wird.

[y33H@]

Kannst ja mal rechnen. Die T-Unit fehlt, dafür müssen nun 3/4 Slots ran. Je nachdem wie der Code ausschaut halt ...