GTX 680 CUDA GPU rendering performance in OctaneRender

[t_3]

http://www.refractivesoftware.com/
...aus meinen post dort:
benchmark scene (pathtracing):
gtx 680 @ default clocks on cuda 4.2 ... ~1.68ms/sec ... 43%
gtx 560 @ default clocks on cuda 4.2 ... ~1.79ms/sec ... 46%
gtx 570 @ default clocks on cuda 4.2 ... ~2.27ms/sec ... 58% ... 72%
gtx 570 @ default clocks on cuda 4.1 ... ~3.14ms/sec ... 80% ... 100%
gtx 580 @ default clocks on cuda 4.1 ... ~3.92ms/sec ... 100%


complex scene, 1mio tris, hdri environment, 3 mesh lights, misc. mats including sss & specular (pmc):
gtx 560 @ default clocks on cuda 4.2 ... ~0.59ms/sec ... 52%
gtx 680 @ default clocks on cuda 4.2 ... ~0.64ms/sec ... 56%
gtx 570 @ default clocks on cuda 4.2 ... ~0.77ms/sec ... 68% ... 81%
gtx 570 @ default clocks on cuda 4.1 ... ~0.95ms/sec ... 83% ... 100%
gtx 580 @ default clocks on cuda 4.1 ... ~1.14ms/sec ... 100%

overclocking ability was around 15% with my card.

Anzumerken ist, dass das mit einem nightly build des Renderers für CUDA 4.2 getestet wurde, d.h. es sind natürlich in der Engine selbst noch Optimierungen erforderlich als auch möglich - daher ist die Performance auch insgesamt um einiges geringer als noch mit dem CUDA 4.1 build - und vmtl. wird Nvidia auch noch CUDA Optimierungen für die Kepler Architektur bringen. Dennoch sieht es dzt. nicht so aus, als würde die 680er eine 580er auf diesem Gebiet um halbwegs achtbare Werte überbieten können (falls sie überhaupt nahe kommen sollte).

Noch ein Hinweis: OctaneRender arbeitet mit SP Math, daher sollte die bekannte double precision Schwäche des GK104 eigtl. keine Rolle spielen...

[Nighthawk13]

Unterstützt der Hersteller die 680 bereits offiziell?

Wenn die grundlegende Aufteilung in Cuda-Threads/Blocks nicht passt(weil auf Fermi-SMs zugeschnitten), ist ein Faktor 2 noch locker drin.

Die 680 sollte zur 580 zumindest gleichziehen können.

[kunibätt]

Ohje....
Im Blender Cycles ( ziemlich ähnlich wie Ocatane) macht eine 580 auch ne 680 alle. Dort ist eine 680 aber minimal schneller als eine 570..

[Simon]

Mit so vorlaeufigen und vor allem unangepassten Sachen waer ich mal vorsichtig. Es geht auch anders (http://www.tml.tkk.fi/~timo/HPG2009/index.html) ;) Da ist dann die GTX 680 etwa doppelt so schnell wie die 480 ;)

[t_3]

Mit so vorlaeufigen und vor allem unangepassten Sachen waer ich mal vorsichtig. Es geht auch anders (http://www.tml.tkk.fi/~timo/HPG2009/index.html) ;) Da ist dann die GTX 680 etwa doppelt so schnell wie die 480 ;)
Danke für den Link!

Was da aber vor allem anders zu sein scheint, ist, dass das kein realistisches Anwendungsszenario ist, und diesbezüglich eben auch nicht besonders aussagekräftig. Ich hab' diese Tests mal mit meinen Karten durchgeführt (560 ti, 570, 580, 680), und da liegt die 680er bereits mit dem _nicht_ optimierten Fermi kernel vor der 580er, was sich mit realistischen Anwendungen im GPU rendering bisher nicht annähernd nachvollziehen lässt.

Die beschriebene Optimierung (die in dem Link oben zahlenmäßig nicht verglichen wurde) macht letzendlich "nur" etwa 30% Performance-steigerung aus - umgelegt auf die Ergebnisse von z.B. Octane würde die 680er bestenfalls auf das Niveau einer 580er kommen. Und ich wette (allerdings nicht um viel ;)), dass auch genau das rauskommen wird, wenn erstmal optimierte Anwendungen zur Verfügung stehen...

[t_3]

Unterstützt der Hersteller die 680 bereits offiziell?

Wenn die grundlegende Aufteilung in Cuda-Threads/Blocks nicht passt(weil auf Fermi-SMs zugeschnitten), ist ein Faktor 2 noch locker drin.

Die 680 sollte zur 580 zumindest gleichziehen können.
... wie geschrieben ist das ein nicht optimierter (und nicht offizieller) nightly build. Ich seh' das sonst schon ungefähr ähnlich, und abgesehen von der Performance bietet Kepler bzw. die 680er auch noch einige andere Vorteile wie z.B. kein Texturelimit mehr, oder Non-pro Karten mit 4GB; selbst auf dem Leistungsniveau einer 580er also für manche eine Überlegung wert.

Es wäre natürlich viel schöner gewesen, auch in diesem Anwendungsbereich eine gehörige Leistungssteigerung zu sehen, jedoch scheint Nvidia diese "Nische" nicht mit besonders viel Aufmerksamkeit zu bedenken. Was und wieviel der GK110 daran ändern wird, und zu welchem Preis, wird man auch erst sehen müssen...

[Simon]

Was da aber vor allem anders zu sein scheint, ist, dass das kein realistisches Anwendungsszenario ist, und diesbezüglich eben auch nicht besonders aussagekräftig.
Was ist denn daran nicht realistisch? Das Texturen fehlen? Die TUs werden ja wohl kaum langsamer auf der 680 sein, die werden ja zum Zocken mit genutzt ;)

[starfish]

Ich würd ja in dem Bereich auf eine Kepler Quadro Karte warten.

Und diese dann mit der 6000er vergleichen.

[t_3]

Was ist denn daran nicht realistisch? Das Texturen fehlen? Die TUs werden ja wohl kaum langsamer auf der 680 sein, die werden ja zum Zocken mit genutzt ;)
Nun, um realistische Materialeigenschaften zu berechnen, wird doch noch ein bisschen mehr benötigt als ein paar diffuse Texturen. Wenn es einfach damit getan wäre, hier noch ein paar Texturen draufzuklatschen, gäbe es GPU-Renderer wie Sand am Meer ;) Tatsache ist, dass da erheblich mehr Mathematik benötigt wird, was natürlich zulasten der Endgeschwindigkeit geht... und daher ist die Applikation eben nicht realistisch. Wie schon geschrieben, merkt man das u.a., wenn man die Beispiele mit dem nicht optimierten Fermi-Kernel auf einer 680er laufen lässt, die dabei gar nicht so dramatisch langsamer ist.

[Coda]

Solang es keine gescheite Doku gibt ist das eh alles Kaffeesatzlesen. Vielleicht gibt es irgendeine elementare Compute-Schwäche, vielleicht ist es auch nur ein Compiler-Problem.

Ich würde momentan eher auf Compiler tippen, da ein Großteil des Scheduling jetzt nicht mehr von der Hardware gemacht wird. Wobei mich die Vergangenheit da eigentlich eines Besseren belehren sollte ;)

Nun, um realistische Materialeigenschaften zu berechnen, wird doch noch ein bisschen mehr benötigt als ein paar diffuse Texturen. Wenn es einfach damit getan wäre, hier noch ein paar Texturen draufzuklatschen, gäbe es GPU-Renderer wie Sand am Meer ;) Tatsache ist, dass da erheblich mehr Mathematik benötigt wird, was natürlich zulasten der Endgeschwindigkeit geht... und daher ist die Applikation eben nicht realistisch. Wie schon geschrieben, merkt man das u.a., wenn man die Beispiele mit dem nicht optimierten Fermi-Kernel auf einer 680er laufen lässt, die dabei gar nicht so dramatisch langsamer ist.
Gerade bei reiner Mathematik ohne irgendwelche atomics, etc. sollte es exakt gar keinen Grund geben, warum Kepler nicht seine Rohleistung fast erreichen sollte bei Compute-Kerneln.

[Zergra]

Ist CUDA nicht gerade am austerben und NV versucht Händerringend OpenCL mehr zu unterstützen ? Da war doch mal was ich gehört habe... Denn Apple baut dort auf AMD Grafikkarten da die in OpenCl 2-3 mal so schnell sind... und auch mit der 680GTX hat sich das wenig geändert

[DaBrain]

Wäre mit neu dass NV schon das Aus von CUDA plant. Besonders im Offline Rendering Bereich.

Mental Images (Nvidia) scheint doch noch fleißig an iRay zu arbeiten (CUDA GPU Renderer).


Wäre natürlich schön wenn OpenCL sich durchsetzen könnte. Auf längere Sicht gehe ich auch davon aus.

[Simon]

Wäre natürlich schön wenn OpenCL sich durchsetzen könnte. Auf längere Sicht gehe ich auch davon aus.
Wie lange soll diese Sicht denn sein?
OpenCL ist auf Nvidia-Karten immer noch arg benachteiligt und das seit "langem"...

[Skysnake]

Wo sollen die denn OpenCL benachteiligen auf nvidia Karten?

Es stehen halt nur nicht alle Möglichkeiten offen, die CUDA bietet, aber eben nach OpenCL nicht spezifiziert sind. Teils ist das aber auch umgekehrt so, wenn ich mich recht erinnere.

[Dural]

ich glaub mal gelesen zu haben das OpenCL bei NV so wie so auch über Cuda läuft. vieleicht wird es ja auch deswegen etwas ausgebremst

[Simon]

Wo sollen die denn OpenCL benachteiligen auf nvidia Karten?

Quelle (http://www.pcgameshardware.de/aid,866066/Jetzt-auch-mit-Radeon-HD-7950-im-Test-Luxmark-20-GPU-Raytracing-Benchmark-auf-Radeon-HD-7970-und-Geforce-GTX/Grafikkarte/Test/):
Mit den älteren 275.33er-Treibern erreichten und erreichen die Geforce-Karten wesentlich bessere Werte, als mit aktuellen Treibern

OpenCL wird da ordentlich benachteiligt im Vergleich zu CUDA.

Noch ein Paper: Klick (http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=0CGIQFjAG&url=http%3A%2F%2Fwww.netlib.org%2Flapack%2Flawnspdf%2Flawn228.pdf&ei=82aFT8TmBqjs0gHQ86XCBw&usg=AFQjCNHc4b1tPYI2tCVTJDZoW0U9i0IZlw&sig2=g0_r72lujJVBnLXzMrw2LA) Figure 6 ist sehr interessant ;)
Ähnliches lässt sich im Nvidia-Forum finden, im BlenderArtists-Forum, ompf, etc.

[KiBa]

OpenCL wird bei nvidia äußerst stiefmütterlich behandelt. Das ist für die nicht mehr als ein Checklisten-feature. Wenn man ein Problem in der Implementierung gefunden hat und das als registrierter Developer meldet, kommt eine Antwort in Richtung "won't fix, please use CUDA".
z.B. lassen sich keine Buffer zwischen OpenCL und OpenGL sharen, es wird immer kopiert (in meinem Fall sogar über die CPU). Das macht OpenCL nutzlos für Postprocessing Effekte, die sind dann mit GLSL schneller. AMD erreicht mit leistungsschwächerer Hardware auch sonst regelmäßig bessere Ergebnisse in realen Anwendungen. Dafür haben die viel häufiger Probleme mit OpenGL. Keine schöne Situation gerade, um mit OpenCL zu arbeiten.

[Skysnake]

Quelle (http://www.pcgameshardware.de/aid,866066/Jetzt-auch-mit-Radeon-HD-7950-im-Test-Luxmark-20-GPU-Raytracing-Benchmark-auf-Radeon-HD-7970-und-Geforce-GTX/Grafikkarte/Test/):


OpenCL wird da ordentlich benachteiligt im Vergleich zu CUDA.

Noch ein Paper: Klick (http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=0CGIQFjAG&url=http%3A%2F%2Fwww.netlib.org%2Flapack%2Flawnspdf%2Flawn228.pdf&ei=82aFT8TmBqjs0gHQ86XCBw&usg=AFQjCNHc4b1tPYI2tCVTJDZoW0U9i0IZlw&sig2=g0_r72lujJVBnLXzMrw2LA) Figure 6 ist sehr interessant ;)
Ähnliches lässt sich im Nvidia-Forum finden, im BlenderArtists-Forum, ompf, etc.

Das Paper ist aber auch schon älter. Inzwischen hat sich bei beiden viel getan bzgl OpenCL Support. Je besser AMD dort ist, desto mehr steht nVidia auch unter druck dort nach zu legen, da die Leute echt keinen bock mehr haben, sich auf Gedeih und Verderben an nVidia zu ketten und dabei gleichzeitig die ganzen AMD User aus zu schließen.

@KiBa:
Wenn Sie das wirklich noch machen sollten, dann bewegen Sie sich auf verdammt dünnem Eis. CUDA fällt immer weiter zurück, und mit solchen Aktionen schießt man sich eher selbst ins Bein als alles andere.

[Simon]

Das Paper ist aber auch schon älter.
Dann finde doch mal was aktuelleres.
Von welchen "Leuten" redest du eigentlich?

@KiBa:
Wenn Sie das wirklich noch machen sollten, dann bewegen Sie sich auf verdammt dünnem Eis. CUDA fällt immer weiter zurück, und mit solchen Aktionen schießt man sich eher selbst ins Bein als alles andere.
Klar. Wo fällt Cuda denn bitte weiter zurück? Die Pathscale-Jungens (ich hoffe, ich hab den Namen gerade richtig im Kopf) entwickeln bestimmt nicht zum Spass einen Open-Source-Cuda-Stack: Gdev (http://www.phoronix.com/scan.php?page=news_item&px=MTA3OTI).
Auf der anderen Seite gibt es dann verschiedene OpenCL-Stacks und kaum Tools dazu. Die Cuda-Tools hingegen sind :up:

[Skysnake]

Papers hab ich jetzt keins zur Hand, hab mich darüber aber mit nem Dr. unterhalten, der letztes Semester meine GPU-Computing Vorlesung gehalten hat. Der hat mit CUDA anfangs gearbeitet und ist jetzt aber auf OpenCL umgestiegen wegen der Portabilität. Der Umstieg findet halt schleichend statt bei den Leuten, die CUDA bereits in ihren Projekten verwenden, da man oft einfach nicht die Manpower/Geld hat, um das bestehende Zeug zu portieren. Wenn neu angefangen wird, wird da OpenCL auf jeden Fall berücksichtigt. Ich kenn eigentlich niemanden mehr, der OpenCL kategorisch ausschließt. Wenn wird wegen mangelnder OpenCL kenntnisse doch nochmal auf CUDA gesetzt. Die Bestrebungen sich OpenCL know-how bei den Leuten anzueigenen sind aber definitiv da.

Aufm FDS 2011 hatten Sie ja auch die Zahlen einer Studie zu den unterschiedlichen Programmiersprachen gezeigt. Demnach sei OpenCL im Durchschnitt bereits verbreiterter als CUDA, und der Trend wird auch anhalten. Vor allem wenn Intel IB endlich auf den Markt bringt. IB kann nämlich endlich OpenCL auf der iGPU. DAS wird einen gewaltigen Schub für OpenCL bringen, denn damit kann praktisch die überwiegende Mehrheit der Desktop "CPUs" dann OpenCL auf der iGPU.

Wer setzt denn da noch auf CUDA, wenn er es nicht aus welchen Gründen auch immer unbedingt muss?

Also gerade was kommerzielle Software anbelangt, wird CUDA von OpenCL bald verdrängt sein, was Neuentwicklungen betrifft.

Für CUDA wird auch das eine oder andere entwickelt. nVidia machts den Leuten aber auch nicht einfach, da gerade bzgl Treiber eben nicht alles offengelegt wird. Insbesondere manche grundlgende Funktionen. Das ist aber wieder ein anderes Thema.

Bzgl. Leistungsfähigkeit von OpenCL muss ich mich halt auch auf das verlassen, was mir Leute erzählen, die mit beidem arbeiten/gearbeitet haben, und das schon länger. Demnach ist gerade bei nVidia OpenCL in den letzten Jahren deutlich verbessert worden. Auch wenn man sich die Treiber ansieht, ist da genau wie bei AMD öfters davon die Rede, das man die Treiber optimeirt hätte.

Ich merk das z.B. bei meiner eigenen AMD, dass der erste Durchlauf eines Kernels deutlich flotter geht. Hier hat man wohl stark an der LLVM gearbeitet und dem runtime-Compiler.

[starfish]

Grade in der neuen PC Games Hardware drüber gefallen:

Im Luxmark (keine Ahnung ob der was taugt), welcher auch OpenCL ist, hat die GTX 680 auch enorme Probleme.
Deutlich hinter einer 580er und die 7870 ist weit mehr als doppelt so schnell.

[starfish]

Hatte heute die Chance mich mit einem unserer Renderer-Entwickler zu unterhalten.
Der meinte, die miese Cuda/OpenCL Performance ist auf der 680er eine reine Treiberlimitation.

Nvidia hat uns mitgeteilt, diese Limitation sei bei den kommenden Quadros entfernt.

[Skysnake]

Nutzt der DP oder SP?

Und von welcher Quadro wird gesprochen? Es ist ja nicht klar, ob es von GK104 überhaupt ne Quadro geben wird.