News Neuer Artikel: GPU Computing - Review und Analyse

[aspro]

Ich find es etwas enttäuschend, dass sich in einem Artikel über GPU Computing nur mit Distributed Computing beschäftigt wird, aber "produktive" Software bspw. zum Video Encoding, was mich persönlich interessieren würde, außen vor gelassen wird.

 

[tomturbo]

Ich find es etwas enttäuschend, dass sich in einem Artikel über GPU Computing nur mit Distributed Computing beschäftigt wird, aber "produktive" Software bspw. zum Video Encoding, was mich persönlich interessieren würde, außen vor gelassen wird.

Es gibt dzt. keine Software die nur einigermaßen vernünftige Qualität liefert.
Von Problemen mit den unterschiedlichen Tonformaten gar nicht zu reden.
Von daher sind Tests von bestenfalls Alpha-ware sinnlos, denke ich.

lg
__tom

 

[freetgy]

dem kann man zustimmen.

 

[aspro]

Ist ja schön, dass ihr da so gut Bescheid weißt, aber auf viele andere trifft das sicher nicht zu. Deshalb halte ich es nicht für sinnlos, etwas zu testen, was evtl. nicht so gut funktioniert. Zudem darf man fragen, woher ihr das wisst? Gibt es andere Artikel dazu, eigene Erfahrungen oder einfach nur Hörensagen?
Auch würde ich bezweifeln, dass das pauschal so stimmt. MediaCoder ist bspw. ein gutes und universelles Transcoding-Tool, was auch CUDA unterstützt. Da würde ich mich schon stark wundern, wenn das nur schlechte Qualität liefert, sondern frag mich nur, wie es da mit der Performance aussieht. Mangels nVidia Karte kann ich das aber nicht selbst testen.

 

[tomturbo]

Ich habs mit ATI Karten ausprobiert und kann nur sagen Totalversagen!
Besser kann man es nicht bezeichnen.
Wenn man aus HD handy-video machen will ist man allerdings gut damit bedient

Fein wäre es wenn Du Erfahrungen anderer auch anerkennen würdest auch wenn sie Deinen persönlichen Erwartungen nicht entsprechen, aspro.

lg
__tom

 

[deekey777]

Ich find es etwas enttäuschend, dass sich in einem Artikel über GPU Computing nur mit Distributed Computing beschäftigt wird, aber "produktive" Software bspw. zum Video Encoding, was mich persönlich interessieren würde, außen vor gelassen wird.

Es sieht so aus:
Bis auf Badaboom nutzen alle Programme Nvidias Cuda-Encoder und ATis AVIVO-Xcoder. Letztes ist totaler Schrott. Dagegen verdient Nvidia Riesenlob.
Das Problem ist: Wenn man zB MediaShow Espresso auf verschiedenen Grafikkarten plus CPU testet, so hat man eigentlich drei verschiedene Encoder mit unterschiedlichen Einstellungen getestet. Des Weiteren sind die Ergebnisse schon deswegen sinnlos, wenn die Bildqualität unterschiedlich ist. Aber das scheint die meisten Redakteure nicht zu stören, insbesondere wenn der Reviewerguide auch die Tests mit MSE oder PowerDirector nahelegt, um die Dominanz gegenüber CPUs zu zeigen.

Man hätte schon einige Worte darüber verlieren können, aber keine (absolute) Vergleichbarkeit möglich ist, steht der Aufwand in keinem Verhältnis zum Nutzen. Insbesondere wenn mit x264 die Alternative verfügbar ist.

Was mich an dem Artikel stört, ist das:
http://www.planet3dnow.de/vbulletin/showthread.php?t=375718&garpg=16#content_start

Der folding@home Client GPU2 stammt aus dem April 2008, mit diesem "neuen" Client wurde die ATI/AMD Version auf CAL umgestellt. Ziel dieser Vorgehensweise war es, eine von der Hardware unabhängigere Version zu schaffen und dies ist auch teilweise gelungen

Das ist schon klar, dass die Grafikkarte über CAL angesprochen wird (ist ja Endstation), der Client selbst ist in Brook+ geschrieben (ihr wisst schon, was ich meine), der IL-Code, denn der Brook+ Compiler ausspuckt ist so optimal, so dass eine nachträgliche Optimierung des IL-Codes nicht nötig ist. Dass die Radeons ggü Geforces so abkacken, liegt es einmal an der Hardware, aber insbesondere daran, weil der GPU2-Client für die R600er geschrieben wurde und seitdem nicht weiterentwickelt wird. Es würde mich nicht überraschen, dass die Basis der GPU1-Client war.

 

[KIDH]

Der folding@home Client GPU2 stammt aus dem April 2008, mit diesem "neuen" Client wurde die ATI/AMD Version auf CAL umgestellt. Ziel dieser Vorgehensweise war es, eine von der Hardware unabhängigere Version zu schaffen und dies ist auch teilweise gelungen

Das ist schon klar, dass die Grafikkarte über CAL angesprochen wird (ist ja Endstation), der Client selbst ist in Brook+ geschrieben (ihr wisst schon, was ich meine), der IL-Code, denn der Brook+ Compiler ausspuckt ist so optimal, so dass eine nachträgliche Optimierung des IL-Codes nicht nötig ist. Dass die Radeons ggü Geforces so abkacken, liegt es einmal an der Hardware, aber insbesondere daran, weil der GPU2-Client für die R600er geschrieben wurde und seitdem nicht weiterentwickelt wird. Es würde mich nicht überraschen, dass die Basis der GPU1-Client war.

Dass die Graka über CAL angesprochen wird ist nicht so klar, denn GPU1 lief über DirectX und kann damit schonmal nicht direkt Basis für GPU2 gewesen sein.

Und warum werden immer Clients und Cores durcheinandergeworfen? Nicht der Client ist in Brook+ geschrieben, sondern der Core / die Cores. Der Client verwaltet/steuert nur WUs, Cores, Serverzugriffe usw - mit der Berechnung hat der gar nichts am Hut.

 

[[P3D] Crazy_Chris]

Auf http://www.3dcenter.org/ gibs in den News ein Kommentar zu Test.

"Der Planet 3DNow! ist einen eher ungewöhnlichen Grafikkarten-Test angetreten: Radeon HD 4890 vs. Radeon HD 5850 vs. GeForce GTX 275 – und dies nicht unter Spielen, sondern unter GPU-Computing. Die landläufige Meinung hierzu ist ja, daß nVidia in dieser Disziplin klar führend ist, was sich aber laut den Erhebungen des Planet 3DNow! nicht bestätigen läßt: Hier führt in den praktischen Tests weiterhin die Radeon HD 4890 vor der GeForce GTX 275, die Radeon HD 5850 marschiert dann weit voran. Dies hängt zum einen damit zusammen, daß ATI trotz keiner besonderen GPGPU-Neigung seiner Grafikchips dieses Thema gerade in der RV8xx-Generation einfach mit massig Shader-Performance erschlagen kann: Bei einer Peakleistung von 2720 GFlops bei der Radeon HD 5870 kommt nVidia schon lange nicht mehr mit.

Zum anderen hängt dieser Benchmark-Sieg der ATI-Karten aber natürlich auch an den benutzten Test-Programmen, welche allesamt aus der Sparte "Distributed Computing @ Home" stammen. Dies ist insofern verfälschend, als daß im professionellen Segment gänzlich andere Software benutzt wird, weil dort eben keine Distributed-Computing-Projekte zum Einsatz kommen. Gut möglich, daß nVidia bei eben dieser professionellen Software wieder deutlich besser darsteht – anders ist es auch kaum zu erklären, daß nVidia beim Vergleich Quadro- zu FireGL-Karten derzeit ca. 90 Prozent Marktanteil verbuchen kann. Hier spielen natürlich auch noch solche (von außen schlecht erkennbare) Punkte wie Treiberarbeit, Gewährleistung und Support ihre gewichtige Rolle, währenddessen der hohe Anschaffungspreis in diesem Spezialsegment nicht so wild gesehen wird."

 

[CapJo]

Dies ist insofern verfälschend, als daß im professionellen Segment gänzlich andere Software benutzt wird, weil dort eben keine Distributed-Computing-Projekte zum Einsatz kommen.

Gut möglich, daß nVidia bei eben dieser professionellen Software wieder deutlich besser darsteht – anders ist es auch kaum zu erklären, daß nVidia beim Vergleich Quadro- zu FireGL-Karten derzeit ca. 90 Prozent Marktanteil verbuchen kann. Hier spielen natürlich auch noch solche (von außen schlecht erkennbare) Punkte wie Treiberarbeit, Gewährleistung und Support ihre gewichtige Rolle, währenddessen der hohe Anschaffungspreis in diesem Spezialsegment nicht so wild gesehen wird."

Meiner Ansicht nach gibt es im GPGPU-Bereich noch keine professionelle Software. Keine die mir Bekannt ist und reif für den produktiven Einsatz wäre.

Das ist genau das Thema meiner Masterarbeit, ob GPU-Computing überhaupt bereit ist für den Einsatz im Kommerziellen Umfeld. Derzeit gibt es gleich einige Punkte die dagegen Sprechen, die sich aber mit Einführung von Fermi (GF100) und dem neuen integrierten Debugger Nexus bessern werden.

Das ist zum einen, dass es derzeit unter Windows nicht möglich ist sein Programm auf der Hardware zu debuggen. Es gibt zwar den Emulator, dieser ist jedoch weit von der echten Hardware entfernt, unglaublich langsam und viele Bugs treten nur auf der Grafikkarte selbst auf. So wird das Fehler finden wirklich zum Gedultsspiel - Fehler tritt in der Emulation nicht auf und das debuggen auf der Hardware ist nicht möglich. Da GT200 basierende Karten nur einen Kernel (Algorithmus) gleichzeitig ausführen können, benötigt man 2 Grafikkarten um auf der Hardware debuggen zu können. Die GF100 unterschützt mehrere gleichzeitige Kernel und es wird angenommen, dass dann eine GPU ausreichend ist um sein Programm auf der Hardware zu debuggen. Die Emulation wird auch in der nächsten Release von CUDA verschwinden. Unter Linux ist es schon länger möglich auf einer compute-only Karte per CUDA-GDB Schnittstelle zu debuggen

Der 2. Punkt ist die fehlende Unterstützung von ECC-Cache. Ohne ECC kann man sich nicht sicher sein, dass das Ergebnis einer langen Berechnung (Stunden, Tage) korrekt ist. Dies ist insbesondere für HPC-Systeme wichtig.

Der nächste Punkt ist, dass viele Firmen den Aufwand für CUDA scheuen. Es muss ja sichergestellt werden, dass die Anwendung auch ohne CUDA-fähige Karte nutzbar ist. Also muss ein 2. redundanter Code-Pfad erstellt und gepflegt werden und das will eigentlich keiner machen. Das Problem könnte in Zukunft auch besser werden, einerseits durch OpenCL für Grafikkarte und CPU. AMD hat das bereits jetzt, aber die Software ist noch nicht für den produktiven Einsatz geeignet. NVIDA verfolgt wahrscheinlich einen anderen Weg. Der PTX-Zwischencode, wird verwendet um über einen Backend-Compiler den x86 Code zu erzeugen - ähnlich Ocelot (PhD-Thesis-Projekt).

 

[DonGeilo]

Ich grabe das hier mal aus, da ja heute die GTX480 vorgestellt wurde und ich ein wenig von der Flop Leistung erschrocken bin,

5870 = 2.720 GFLOPs
GTX480 = 1.345 GFLOPs

laut Computerbase

Nun frage ich mich wie schnell wird die GTX beim DC !?

Und kann mir vllt einer erklären warum die AMD in Tesselation so schlecht abschneidet ähnelt die Berechnung nicht dem was beim DC getan wird !??

Ich stelle die frage extra hier weil hier ja die Spezi´s unterwegs sind.

 

[Emploi]

Tessellation

So schlecht finde ich das gar nicht, aber auf dem Metro 2033 (was zur "Nvidia the way it's ment to be played" Serie gehört und NVIDIA PhysX nutzt) Spiel würde ich nicht soviel geben.

Bei der "Unigine Heaven" Demo sieht man für den GTX 480 140% einer 5780, eine eher schwache Vorstellung, wenn man sieht das der gesamte PC unter Volllast 148% mehr verbraucht. 147 Watt mehr Verbrauch, da kann man bedenkenlos noch eine zweite 5780 dazu stecken.

 

[[P3D] Crazy_Chris]

Ich grabe das hier mal aus, da ja heute die GTX480 vorgestellt wurde und ich ein wenig von der Flop Leistung erschrocken bin,

5870 = 2.720 GFLOPs
GTX480 = 1.345 GFLOPs

Das sind wohl nur Angaben für "Single-Precision" Berechnungen. Bei Double-Precision, also 64bit Float, sieht es wieder anders aus und auf die kommt es in vielen GPGPU Projekten eher an. Fermi schafft übrigens 712 GFLOPs mit double-precision. Die HD 5870 so um die 500 GFLOPs soweit ich weiß. Man sieht eben schon wo ein Schwerpunkt der GTX 480 liegt und wo es wohl damit hingehen soll. Tesla ahoi.

 

[Bobo_Oberon]

... Und kann mir vllt einer erklären warum die AMD in Tesselation so schlecht abschneidet ähnelt die Berechnung nicht dem was beim DC getan wird !??

Ich stelle die frage extra hier weil hier ja die Spezi´s unterwegs sind.

Weil bei Nvidia Geforce 100 alle Einheiten daran rumrechnen, während bei ATIs Evergreens das eine eigene Einheit ist.

Gut für Nvidia wenig dynamische weitere Inhalte berechnet werden müssen.
Gut für ATI, da die Rechenleistung der Tesselation völlig entkoppelt ist von den anderen Grafikberechnungen.

MFG Bobo(2010)

 

[DonGeilo]

während bei ATIs Evergreens das eine eigene Einheit ist.

MFG Bobo(2010)

Sehr interessant, dann sollte es für AMD ja ein leichtes sein, diese Einheit auf einer Zukünftigen Karte zu verbessern, ich dachte das hat was mit den Shadern zutuen....
.
EDIT :
.

Das sind wohl nur Angaben für "Single-Precision" Berechnungen. Bei Double-Precision, also 64bit Float, sieht es wieder anders aus und auf die kommt es in vielen GPGPU Projekten eher an. Fermi schafft übrigens 712 GFLOPs mit double-precision. Die HD 5870 so um die 500 GFLOPs soweit ich weiß. Man sieht eben schon wo ein Schwerpunkt der GTX 480 liegt und wo es wohl damit hingehen soll. Tesla ahoi.

Danke auch das wollte ich wissen also wäre eine GTX480 im DC Theoretisch schneller aber die DP Leistung hat bei AMD nichts mit der Tesselation Leistung zutuhen.

 

[[P3D] Crazy_Chris]

Theoretisch schon. Es kommt aber immernoch stark auf die Software an und wie stark auf die jeweilige Architektur optimiert wird. Zumal sind APIs wie OpenCL, CUDA 3.0 oder Direct Compute und Treiber erst am Anfang und es fehlen sicher noch einige Erfahrungen um das ganze Potenzial zu nutzen. Es werden sich auch Anwendungen finden lassen wo die vermeintlich unterlegene ATI schneller ist. In einigen Monaten kann man da sicher mehr sagen wenn die GTX 480 großflächig verfügbar ist und es optimierte Anwendungen direkt für diese Karte gibt. Das Optimierungspotenzial ist im Gegensatz zu x86 höher denke ich da sich die Architekturen der GPUs untereinander deutlich unterscheiden.

 

[deekey777]

...

Danke auch das wollte ich wissen also wäre eine GTX480 im DC Theoretisch schneller aber die DP Leistung hat bei AMD nichts mit der Tesselation Leistung zutuhen.

Es gab ja vor einiger Zeit das Gerücht, dass die Desktop-Fermis in der DP-Leistung beschnitten werden, um die Teslas nicht zu gefährden.
http://forum.beyond3d.com/showpost.php?p=1414410&postcount=42

the FMA DP is about 168 GFLOPS in opencl, 1/4 tesla.

Ich konnte keinen einzigen Tests entdecken, wo die DP-Performance gemessen wurde, selbst nicht mit SiSoft Sandra 2010.

Dass die Graka über CAL angesprochen wird ist nicht so klar, denn GPU1 lief über DirectX und kann damit schonmal nicht direkt Basis für GPU2 gewesen sein.

Zumindest für den, der Gipsels Artikel gelesen hat, sollte es klar sein.

Der GPU1-Client lief über BrookGPU mit DX als Backend. GPU2 über Brook+ und dann CAL als Backend (Ich weiß, dass dieser Satz wenig Sinn ergibt, aber die Richtung der Aussage sollte stimmen).

 

[[P3D] Crazy_Chris]

Es gab ja vor einiger Zeit das Gerücht, dass die Desktop-Fermis in der DP-Leistung beschnitten werden, um die Teslas nicht zu gefährden.

Aber doch nur bei der GTX 470 und dem GF104, GF108?

 

[deekey777]

Aber doch nur bei der GTX 470 und dem GF104, GF108?

Bei den GF104 und kleiner wird IMHO gar keine DP-Fähigkeit geben (wie beim RV830 und kleiner).

Sonst: Ehrlich gesagt, keine Ahnung. Nirgendwo wurde die DP-Leistung gemessen, und glaube kaum, dass das ein Zufall ist.

Ich hab's:
http://www.ixbt.com/video3/gf100-2-part1.shtml (http://translate.google.de/translat...bt.com/video3/gf100-2-part1.shtml&sl=ru&tl=de )

?? ??, ?? ?? ?? ? ? ? ? , ?? ? ?? ?? Fermi, ? ? ?? ? ? GF100 ? ?? ? , ??. 64- ? ? GeForce GTX 480 ? ??. ? GTX 480 — ?? 168 ?? 672.

In Etwa:
Die DP-Performance der GTX480 wird künstlich auf ein Viertel gebremst.

 

[Emploi]

Das ist einer der Sprachen die ich vollständig verdrängt habe, und der g00gleübersetzer teilweise auch, wo steht das mit der DP Leistung?

EDIT

Ich habe es gefunden, kann aber nix damit anfangen...

 

[[MTB]JackTheRipper]

D.h. für GPGPU sollte man im privaten Bereich weiterhin auf ATi setzen, sollten sich diese Werte bewahrheiten.

 

[deekey777]

D.h. für GPGPU sollte man im privaten Bereich weiterhin auf ATi setzen, sollten sich diese Werte bewahrheiten.

Würdest du wirklich mit einer GTX480, wie sie jetzt ist, folden?

 

[[MTB]JackTheRipper]

Nein, die Aussage war rein hypothetisch zu sehen

 

[indiana_74]

Bei veröffentlichung des Artikels kam schnell die Vermutung auf, dass der verwendete distributed.net Client die HD5850 nicht voll auslasten würde, ich habe die HD5850 daher nun mit einem aktuellen Client (v2.9108.517 vom 28.06.2010) erneut getestet.

Ergebnis war: 958.946.983 key/s
Ergebnis ist: 1.443.596.978 key/s (+50.54%)

Die Vermutung war also richtig und das Ergebnis ist mehr als beeindruckend.

Mal wieder ein schönes Beispiel dafür wie wichtig eine saubere Programmierung ist.

 

[mibo]

Das ist ja ein ordentlicher Schub
Danke für die Nachmeldung. Ob es bei Nvidia auch Performance-Verbesserungen gab?

 

[Sabroe SMC]

Hab mal meine 5870 dran gesetzt: 2,073,527,822 keys/s