News Neuer Artikel: GPU Computing - Review und Analyse

[KIDH]

Klick, klick, klick...

Noch fernab von einem Stadium, wo ich den Clienten auf einem Produktivrechner einsetzen würde. Aber ich weiß ja, das es heutzutage "in" ist, halbgare Software als "toll" hinzustellen. Die Erfahrung mache ich ja (wieder mal) im Windows 7 Thread.

Ähm...ich dachte hier geht's darum wie die Leistungsfähigkeit ausgenutzt wird und nicht darum, was es für Probleme in der Handhabung gibt...das ist nämlich wieder ne ganz andere Sache und hat nicht allzu viel mit GPGPU an sich zu tun.

BTW: Bei mir läufts seit irgend einem 9er Catalyst ohne Probleme.

...Deswegen denke ich auch, die on-die GPU sind da eher geeignet, weil die ja nicht so leistungsfähig sind, dass sie die CPU als bottleneck haben, und auch besser kontrolliert werden können. Selbst wenn ich eine ATI GPU habe mit einer AMD CPU... da es ja so viel Modelle gibt ist das schwerer umzusetzen als mit in-die GPU. und auch potentiell weniger Latenzen mit on-die GPU...

Was für Latenzen? GPUs rechnen bereits relativ autark...sowas wie Polling ist mittlerweile auch gegessen, das war bei DirectX @Folding @Radeon X1000er der Fall. Speicher hat die Grafikkarte auch ihren eigenen. GPU@CPU wäre in der Hinsicht eher ein Rückschritt, da die GPU ihren eigenen SPeicher einbüßt.

OT: persönlich hoffe ich, dass weniger Leute Aliens suchen würden. SETI kann uns alle umbringen. Schon mal dran gedacht, dass die Aliens die wir finden uns überlegen sind wenn sie herkommen? Und es ist ja wohl klar (und die Menschen haben das bewiesen in der Geschichte) was passiert wenn Zivilisationen aufeinandertreffen und die eine der anderen technologisch überlegen ist?

Mal davon abgesehen, dass ich selber auch lieber was sinnvolleres mache, heißt "Suchen" nicht, dass wir usn ihnen mitteilen...außerdem sind mögliche Zivilisationen Lichtjahre von uns entfernt. Sollte es da irgendwen geben, so sind wir auch in den nächsten Jahrhunderten noch alleine. Ich nehme mir jetzt mal raus zu behaupten, dass unsere bisherigen physikalischen Erkenntnisse grundlegend sind.

 

[ShiningDragon]

Spoiler

Ja, dass CUDA nicht so toll ist hab ich auch gehört.

Hören ist immer so eine Sache... selber probieren ist besser. Aber in Anbetracht mangelnder Software kein leichtes Unterfangen.

Mit den Multi-core CPUs bin ich aber anderer Meinung(...)

Du sprachst die softwareseitige Unterstützung von MultiCore Prozessoren an. Genau darauf bezieht sich meine Antwort. Einen Singlecore würde ich mir heutzutage nicht mehr antun, das sehen wir Beide gleich.

Ich denke sogar, dass alles was man mit CPUGPU machen könnte von hyperthreading erledigt werden kann.

Das sind zwei völlig verschiedene Welten. Hyperthreading sorgt nur dafür, das die Recheneinheiten der CPU besser ausgelastet werden. Es ist also sehr Applikationslastig ob überhaupt und wieviel Vorteil man durch Hyperthreading hat. Es gibt auch Szenarien, wo Hyperthreading kontraproduktiv ist.

(...)klar kann man 100e von Sachen gleichzetig machen, aber nur primitive Sachen(...).

Das ist der Knacktus, Faktus. Eigentlich wäre Videotranskoding optimal für die Recheneinheiten einer GPU, bisher scheitert es jedoch noch an entsrechenden Programmierkünsten und -fertigkeiten.

Mit einer sehr starken GPU wird die CPU dann zum bottleneck.

Wenn Applikation X mit GPU Beschleunigung ca. genauso schnell ist, wie mit einem Quad ohne GPU Support, dann stimmt was mit der Programmierung nicht.

Schon mal dran gedacht, dass die Aliens die wir finden uns überlegen sind wenn sie herkommen?

Fehler macht man nur einmal... das gilt auch für den lieben Gott, oder denkst Du der würde so eine bekloppte humanoide Rasse ein zweites Mal erschaffen?

Und es ist ja wohl klar(...)

Wir driften ab...

PS: Don't drink and write.

Ähm...ich dachte hier geht's darum wie die Leistungsfähigkeit ausgenutzt wird(...)

Mal Hand auf's Herz: Was interessiert Otto-Normal, wie toll irgendwelche DC Anwendungen die GPU auslasten. Wir wollen "unsere" Software auf GPU optimiert haben. Und zwar ohne das wir 5.000 EUR und mehr auf den Tisch legen müssen. Immerhin werden uns die Grafikkarten doch genau mit DIESEM Leistungsspektrum seit einigen Generationen zum Kauf angepriesen? Seit der G80 darf ich lesen, wie TOLL CUDA doch ist.
G80, G92, G92b, G200, G200b... und nun steht der Fermi in den Startlöchern und immer noch gibt es keine wirklich endkundentauglichen CUDA Lösungen. Das sind 6(!) Generationen (Refresh, Relabeling hin oder her). Das geht so nicht, es läßt sich schon fast als Kundenverarsche bezeichnen.
Nichts gegen DC'ler, habe ich ja selber mal gemacht, wünsche wirklich JEDEM viel Spaß dabei. Aber hey: DC ist nicht das Maß der Dinge, das wird nur von einer "handvoll" Leuten praktiziert (Anzahl Teilnehmer vs. Anzahl PC Besitzer).

Soviel zum Thema Leistungsfähigkeit. Denn die können die "Normalos" kaum feststellen.

EDIT: Spoilern um den Thread nicht unnötig zu verunstalten.

 

[KIDH]

Mal Hand auf's Herz: ...

Darum gings doch gar nicht, darüber will ich auch gar nicht reden, weil mir das egal ist.

Für mich gibt's Grakas für Spiele und DC und der Rest tangiert mich gar nicht.

 

[ShiningDragon]

Darum gings doch gar nicht.

Richtig, es ging um den Optimierungsprozess, den Du in Sachen F@H mit einem WTF beantwortet hast und als Synonym selbständig das Wort Leistung eingesetzt hast.

 

[KIDH]

Richtig, es ging um den Optimierungsprozess, den Du in Sachen F@H mit einem WTF beantwortet hast und als Synonym selbständig das Wort Leistung eingesetzt hast.

Ich kenn mich mit Folding ganz gut aus, bin seit 5 1/2 Jahren dabei, kann das glaub ganz gut beurteilen und hab einfach nur geschrieben, daß es da anders aussieht als du beschreibst...alles andere bleibt da außen vor.

Nochmal: Folding@home ist Vorreiter beim GPGPU-Computing, die haben damit angefangen als CUDA, CAL und OpenCL noch nichtssagende Buchstabenkolonnen waren.

 

[ShiningDragon]

Nochmal: Folding@home ist Vorreiter beim GPGPU-Computing, die haben damit angefangen als CUDA, CAL und OpenCL noch nichtssagende Buchstabenkolonnen waren.

Es ist mir völlig humpe, ob sie Vorreiter, Nachreiter, Mitläufer oder Nachtgespenst waren. Der Client ist noch immer in Entwicklung. Nachwievor treten in bestimmten Umgebungen Bugs auf. Positiv ist, das der Client weiterentwickelt wird, und das nennt man gemeinhin einen Optimierungsprozess. Ich verstehe also nicht, worauf Du nun hinauswillst?

 

[KIDH]

Wär ja auch bißchen blöd, wenn er nicht mehr in Entwicklung wäre, wa? Alles was nicht in Entwicklung ist, ist tot!

Es ging um die Ausnutzung von GPUs und das macht Folding@home sehr gut...was du als Optimierungsprozess bezeichnest, hat mehr mit der Software an sich als mit der Ausnutzung der GPUs zu tun (worum es eigentlich ging). Software kann man immer verbessern...weniger Bugs, Beeinträchtigungen, bessere Bedienbarkeit und was weiß ich noch alles...aber an der Ausnutzung der GPUs wird sich nicht allzu viel ändern, vll werden die Algorithmen etwas effizienter gemacht, doch das liegt nicht in der Hand vom Folding@home Team...das machen vorwiegend die GROMACS-Leute.

 

[ShiningDragon]

(...)doch das liegt nicht in der Hand vom Folding@home Team...das machen vorwiegend die GROMACS-Leute.

Erbsenzählerei...

 

[KIDH]

Erbsenzählerei...

->

(man sieht es ja selbst an den großen Forschungsprogrammen von Folding und BOINC wie langwierig der Optimierungsprozess auf GPUs ist).

Ich hab's für dich in Sachen F@H widerlegt. Mehr gibt's dazu nicht zu sagen.

 

[ShiningDragon]

Ich hab's für dich in Sachen F@H widerlegt.

Gleicher Prozess/selbe Anwendung, Du reitest auf dem Namen rum. Widerlegung nicht erfolgreich (da gibt es nichts zu widerlegen, widerlegen hiesse: Entwicklung steht). *aucherbsenzähl*

 

[HerrKaLeun]

Leute, seid ihr SCHON oder NOCH auf? Hier ist es 22:46, also 5:46 bei euch... kein Grund über GPU computing zu streiten... 8)

 

[ShiningDragon]

Leute, seid ihr SCHON oder NOCH auf? Hier ist es 22:46, also 5:46 bei euch... kein Grund über GPU computing zu streiten... 8)

Wir streiten nicht. Wir zählen Erbsen.

 

[indiana_74]

Zur Lebensdauer der Karten bei Einsatz für DC kann ich nichts sagen und es ist auch schwer möglich das zu testen denke ich, Pflicht ist aber sicherlich ein gut gelüftetes Gehäuse.
Ich habe ein System mit vier 4850 Karten im Betrieb, alles unterschiedliche Hersteller und Designs, die Karte mit Referenzdesign bleibt in dieser Konfiguration am kühlsten.
Die anderen "schmoren" da eher in ihrem eigenen Saft

Mir selbst ist in einem anderen System mal eine GTX280 verdampft und im P3D-Cluster sind uns innerhalb eines Jahres drei 8800GT abgeraucht, alle drei billig Modele mit Singleslotkühlung.

 

[Emploi]

...
PS

Könnte man das nicht mal ändern, dass man bei solchen Artikeln nicht dem Autor danken kann?

^^^Da isser, also los auf die Waage!

EDIT: und schon hat Indie auch mal nen

Gnubbel ... (steht dir gut)

 

[indiana_74]

guter Artikel, Danke.

Was mich am GPU computing interessiert, kann man damit auch was machen was dem Computer user nutzt? [...]

In meinem Artikel ging es ja um die Nutzung für DC, deshalb hab ich es nicht weiter betrachtet aber natürlich sind die Karten auch für andere Dinge einsetzbar.



Hier nur einige Beispiele für Programme die schon die ATI-Stream oder CUDA Fähigkeit der Karten nutzen:

Flash Video Beschleunigung:
Adobe Flash Player 10.1 Beta (ATI + CUDA)

Bildbearbeitung:
Adobe Photoshop (CUDA)

Videocliperstellung:
Muvee reveal (CUDA)

Bildverwaltung mit Gesichtserkennung:
Cyberlink Media Show 5 (CUDA)

Video Uscaling auf HD:
Arcsoft Media Theatre (ATI + CUDA)
Cyberlink PowerDVD 9 (CUDA)

Video Transcodierung auf mobile Geräte:
Elemental Badaboom (CUDA)
Cyberlink Espresso (ATI + CUDA)
Nero MoveIT (CUDA)


Video Bearbeitung:
Cyberlink Power Director (ATI + CUDA)
Loiloscope Mars (CUDA)
Pegasys TMPGenc (CUDA)

HD Video Beschleunigung:
Windows 7 Media Player (CUDA)
CoreAVC (CUDA)

Video Verbesserung:
MotionDSP vReveal (CUDA)

Die Liste erhebt keinen Anspruch auf Vollständigkeit.

Auf der AMD Seite hab ich diese Grafik zum Thema gefunden:

Beschleunigung einer Viedeo Trancodierung mit Cyberlink Espresso durch die Nutzung einer ATI-Stream tauglichen Grafikkarte.

Das einzige was du als Anwender tun must um diese Zusatzfunktionalität nutzen zu können ist einen aktuellen Grafiktreiber installieren und die entsprechende Version der Software nutzen.

 

[Bobo_Oberon]

Flash Video Beschleunigung:
Adobe Flash Player 10.1 Beta (ATI + CUDA)

Bildbearbeitung:
Adobe Photoshop (CUDA)

Videocliperstellung:
Muvee reveal (CUDA)

Bildverwaltung mit Gesichtserkennung:
Cyberlink Media Show 5 (CUDA)

Video Uscaling auf HD:
Arcsoft Media Theatre (ATI + CUDA)
Cyberlink PowerDVD 9 (CUDA)

Video Transcodierung auf mobile Geräte:
Elemental Badaboom (CUDA)
Cyberlink Espresso (ATI + CUDA)
Nero MoveIT (CUDA)


Video Bearbeitung:
Cyberlink Power Director (ATI + CUDA)
Loiloscope Mars (CUDA)
Pegasys TMPGenc (CUDA)

HD Video Beschleunigung:
Windows 7 Media Player (CUDA)
CoreAVC (CUDA)

Video Verbesserung:
MotionDSP vReveal (CUDA)
...
Das einzige was du als Anwender tun must um diese Zusatzfunktionalität nutzen zu können ist einen aktuellen Grafiktreiber installieren und die entsprechende Version der Software nutzen.

Ich rede mir den Mund auch fusselig. Es gibt tatsächlich schon Programme, die auf die eine und andere Weise die GPUs nutzen.

Teilweise aber lediglich nur, weil spezielle Einheiten ausgenutzt werden (Stichwort UVD Videocodec-Beschleunigung). Ist aber im Bezug zur Entlastung der Rechenlast auf dem Hauptprozessor unwesentlich.

Der Knackpunkt ist, dass ein Konsument auch entsprechende neue Anwender-Software neu kaufen muss, um vom GPGPU-Computing tatsächlich zu profitieren.

MFG Bobo(2010)

 

[CapJo]

Ich beschäftige mich jetzt mittlwerweile seit ca. einem Jahr mit GPGPU-Computing. Vor allem mit der Programmierung und den Vor- und Nachteilen die damit verbunden sind.

Als erstes zu den Peak-Werten der Hersteller. Diese sind nicht Herstellerübergreifend zu vergleichen, da jeder Hersteller eine andere Art hat diese zu berechnen. Was mir im Kopf rumschwebt ist, dass NVIDIA Speicherzugriffe über die Textureinheit als FLOP mitrechnet, weil da ne lineare interpolation stattfinden. Ich kann mich irren, aber dieser teil ist schon ein 1/3 des Peak-Wertes. So versucht jeder Hersteller die Peak-Werte hochzurechen.

Als nächstes find ich den Vergleich etwas ungerecht, es wurde eine GTX 275 getestet. Wieso keine GTX 285 die eher dem Konterpart von ATI entsprochen hätte, der Radeon 4890. Das ist jedoch nur nebensächlich.

Das Problem bei dem ganzen Benchmark ist, dass die Codebasis und wahrscheinlich auch der Optimierungsgrad absolut unterschiedlich ist, vor allem wenn man weiß, dass man Double-Prescision auf NVIDA-Karten im Moment relativ vergessen kann, da man nur 1/8 der Singe-Precision Performance hat. Bei ATI ist es der ca. Faktor 1/2 von single to double Precision. So wirds auch bei der kommenden Fermi Karte sein (GF100). 2 Single-Precision Einheiten werden zu einer double-precision Einheit.

Mit CUDA hat NVIDIA bereits vor geraumer Zeit eine Programmierschnittstelle geschaffen, die es Entwicklern erlaubt mit relativ einfachen Mitteln GPGPU-Programmierung zu bewerkstelligen. Das war das große Plus der NVIDIA-Karten in den letzten 2 Jahren. Mit der Einführung von OpenCL als gemeinsamer Nenner sollte sich dieser Vorteil in den kommenden Monaten und Jahren egalisieren.

Das ist immer noch ein großes Plus und die Frage ist auch wie sich das ganze änderen wird. Es gibt einen Grund warum ca. 95 % Forschung auf Nvidia-Karten durchgeführt wird. OpenCL ist noch ganz am Anfang und wird bei AMD leider auch nur zögerlich vorrangetrieben. Das aktuelle Stream SDK unterstützt noch bei weitem nicht den kompletten OpenCL Standard. Es fehlt da noch sehr viel.

Apple ist derzeit der einzige Hersteller, der OpenCL vernünftig und wirklich gut unterstützt. Auf dem MAC ist es sogar möglich, den Arbeitsaufwand einer OpenCL-Anwendung automatisch auf CPU und GPU aufzuteilen. Davon ist man auf dem PC noch weit weg.

Aber auch wenn OpenCL sich als gemeinsamer Standard durchsetzen wird es aufgrund der unterschiedlichen Hardwarearchitektur von ATI und NVIDIA nötig sein, seine Programme auf die jeweilige Architektur zu optimieren. Das Problem ist, das NVIDIA auf Skalarprozessoren setzt während ATI SIMD-Einheiten nutzt. Das bedeutet z. B. dass sich die Datenstrukturen unterscheiden werden. Auf ATI hätte man float4 während es auf bei NVDIA einfache floats wären. Natürlich lässt sich mit OpenCL ein Programm schreiben, dass sowohl auf ATI und NVIDIA läuft, aber der Entwickler wird Kompromisse eingehen müssen und wohl auch für seine eigene Plattform optimieren (oder für den, der mehr Zahlt oder ihn besser unterstützt).

OpenCL ist außerdem zu CUDA sehr ähnlich. CUDA Kernel an sich laufen fast 1:1 unter OpenCL. Das erzeugen des Kontexts und das ganze Setup unterscheidet sich jedoch, ist aber zur CUDA Driver API sehr ähnlich.

Ein weiteres Problem mit OpenCL ist, dass es zeitlich hinterherhinken wird. Neue Features der Intdustrie werden relativ spät oder per Extension in OpenCL eingefügt werden. Das Nutzen der Extension führt dann dazu, dass der Code auf anderen Plattformen nicht ausgeführt werden kann.

NVIDIA hat mit der Fermi-Karte was tolles geschaffen (für den GPGPU-Bereich). Es gibt jedoch ein relativ großes Problem für NVIDIA. Sie haben keine eigene x86 CPU. In Zukunft werden Grafikkarte und CPU wohl stärker zusammenwachsen und auf ein einzelnes DIE kommen. Die Speicherbandbreite wird (Anzahl der Speicher-Kanäle. Beim Core 7i sind es 3) wachsen und was insbesondere wichtig ist, ist dass der Cache gemeinsam von CPU und Grafikkarte genutzt werden kann. Außerdem wird es möglich sein auf einem gemeinsamen Adressraum zu arbeiten. Dies führt dazu, dass die Datentransfers zwischen PC-RAM und GPU-RAM entfallen.

Intel versucht mit neuen Schnittstellen andere Chipsatzhersteller herauszudrängen (neuer Atom, Core *i Plattform), indem man die Lizensierung verweigert und AMD/ATI hat es auch nicht schwer NVIDA im Regen stehen zu lassen.

Es gibt relativ viele Algorithmen, die zwar absolut parallel sind aber nicht genügend Rechenintensität haben um die Zeit für den Datentransfer zwischen CPU und GPU zu kompensieren. Ein Beispiel ist die Sparse-Matrix Multiplication. Die GPU (GTX 280) würde die Berechnung um den Faktor 7 beschleunigen im Vergleich zu einem (Core i7). Der dafür nötige Datentransfer macht jedoch jeden Performancegewinn zunichte. Auch für viele kleinere Anwendungen und damit rede ich von Datenmengen < 64 MB lohnt es sich gar nicht die Grafikkarte zu nutzen weil der Overhead im Moment noch viel zu hoch ist. Das bedeutet, dass die CPU die Aufgaben schon erledigt hat bevor die GPU erstmal startet. Warum es noch keine Anbindung der Grafikkarte per Hyper-Transport gibt entzieht sich meines Wissen, denn Hyper-Transport würd es auch als Slot-Schnittstelle geben.

Für was wird die Grafikkarte also derzeit verwenden? Auf dem Desktop ist es vor allem das Video-Encoding und dann zur Simulation (Folding@Home). Das sind alles Anwendungen mit hohen Laufzeiten und hoher Rechenintensität. Für viele andere Berechnungen sehe ich die Grafikkarte als relativ schlecht geeignet. Man darf auch nicht vergessen, dass sehr viele Algorithmen seriell sind und nicht parallelisierbar sind. Sowas kann man auch auf der Grafikkarte auf einer einzelnen Ausführungseinheit laufen lassen, aber das will sich wirklich keiner antun. Somit wird die CPU für serielle Programme und kleinere parallele Anwendungen noch ein langes Leben haben.

Sorry, ich hab mich jetzt doch etwas lang gefasst ...

 

[ShiningDragon]

Ist aber im Bezug zur Entlastung der Rechenlast auf dem Hauptprozessor unwesentlich.

Eben. Nehmen wir als Beispiel h264. Dies kann via GPU beschleunigt wiedergegeben werden, WENN... es bis Profil Level 5.1 (HD) oder Profil Level 3.1 (SD) kodiert worden ist. Abweichungen zu diesem Standard sorgen dafür, das die GPU nichts mehr dekodiert, sondern die Arbeit gleich wieder bei der CPU bleibt.
Zweites Manko: Oftmals ist die GPU Beschleunigung sinnfrei, da fehlt dann die Intelligenz um zwischen der CPU oder GPU Beschleunigung zu wechseln.

Der Knackpunkt ist, dass ein Konsument auch entsprechende neue Anwender-Software neu kaufen muss, um vom GPGPU-Computing tatsächlich zu profitieren.

Wobei das "Profitieren" ein zweischneidiges Schwert ist. Klein Lisa kauft sich Cyberlink PowerDirecter. WoW! CUDA-beschleunigt, muß ja abgehen wie eine Rakete! Blöd' nur, wenn Klein Lisa bereits eine potente Quadcore CPU im System hat, denn dann sind die Umwandlungszeiten unter Power Director 7 nahezu identisch zu einer starken CUDA Grafikkarte. Letztere würde ihre Stärken erst ausspielen, wenn CUDA Filter ins Spiel kämen. Hätte Klein Lisa KEINEN potenten QuadCore, sondern einen sparsamen DualCore Prozessor, DANN hätte Klein Lisa zum derzeitigen Stand der Software einen Umwandlungsvorteil mit h264 ohne Filter.

Andere CUDA Programme wiederum, die beispielsweise potenter als Power Director 7 zu Werke gehen, haben dann wieder den Nachteil, das sie sich kaum konfigurieren lassen. Das nur festgelegte Profile zum Umwandeln genutzt werden können. Das bringt einen als Videosammler oftmals in Bedrängnis: Entweder unnötig große Dateien in Kauf nehmen, oder aber Qualitätseinbussen der Komprimierung akzeptieren (Realfilme vs. Zeichentrick).

Ich habe mir bereits die Finger wund gegooglet, verschiedene Applikationen ausprobiert und getestet (natürlich auch den Baddaboom Converter) und bisher eigentlich ziemlich enttäuscht. Soll die "dicke" GTX260² mit ihren XX CUDA Cores tatsächlich einem veralteten Q6600 unterliegen? Oder gibt es hier noch reichlich Optimierungsmöglichkeiten an der Software?

Sorry, ich hab mich jetzt doch etwas lang gefasst ...

Dennoch sehr informativ.

 

[GHad]

Naja, aus Java-Entwickler Sicht ist das Thema OpenCL eigentlich ziemlich spanned, da gerade mehrere OpenCL-Bibliotheken für Java (und auch .Net aifak) im Entstehen sind. D.h. sehr viele Entwickler weltweit können diese Schnittstelle dann bald nutzen und in allen möglichen regulären Programmen verwenden. Ich verfolg das mangels Zeit leider nur am Rande, das Thema interessiert mich aber durchaus und ich möchte in nächster Zeit, wenn ich wieder mehr davon habe auch in die Richtung mal ein paar Experimente programmieren

Ebenso soll doch auch Firefox 3.7 mit WebGL kommen und ich denke auch, dass dies dann OpenCL beschleunigt wird (kann auch falsch liegen), jedenfalls wirds auch nicht mehr lange dauern, bis wir "echte" und schnelle 3D-Webseiten und Webanwendeungen sehen werden. In Verbindung mit 3D-Monitoren und Touchscreens überall brauchen wir nicht mehr wie beim Handy und bei den UMPCs wieder bei 0 anfangen, wenn um Grafik und Interfaces geht, da die Leistung dank OpenCL bereits in der Hardware schlummert. Hoffentlich war das jetzt nicht zu wirr

Greetz,
GHad

 

[oldDirty]

Um auf das Thema Cuda noch mal einzugehen, es ist sicher nicht gerechtfertigt diese Anwendung als Betabuggy oder sonstwas zu bezeichnen wie ein Seite vorher geschehen. Es gibt über F@h hinaus wissenschaftliche Projekte bzw medizintechnische Anwendungen, die sich auf Cuda beziehen/profitieren. Ich halte es für völlig ausgeschlossen, das man sich ansonsten in Forschngsbereichen auf die Unterstützung von TESLA Karten/Systemen einlassen würde. Und Tesla ist nur eine Variante der GT200 Chips, also keinen Steinwurf von den Desktopkarten entfernt.

 

[Drohne]

Noch im vergangenen Jahr hieß es, AMD werde Adobes CS4 ohne Einschränkungen zwischen Konsumkarten und prof. Fire-GL Karten in Sachen GPGPU unterstützen, während nVidia eine Varianz zwischen Quadro- und Konsumkarten plante. CS4 kommt derweil bei uns auf diversen Workstations zum Einsatz, wovon ca. 50% neuere HD4000 GraKarten haben, die anderen 50% sind mit nVidia-Karten ausgerüstet. Auf den AMD/ATi-Maschinen ist unter Photoshop so gut wie nichts von einer Leistungssteigerung zu spüren, während selbst auf einer kleinen alten unterstützen Quadro ein enormer Schub verspürbar ist.

Um in der wiss. Gemeinschaft Modellsoftware möglichst plattformübergreifend verteilen zu können, setzen wir und andere auf CUDA (CuBLAS, CuFFT). Die Portierung von symplektischen Integrationsalgorithmen in OpenCL ist CUDA sehr ähnlich, so daß eine schnelle Migration bei Reife des OpenCL möglich scheint. Aus diesem Grunde spielt AMD derzeit keine Rolle, wenn es um die Frage der zu beschaffenden Graphikkartenlösung geht!

AMD mag auf dem Papier mit den besseren Leistungswerten, gerade im doppelt genauen Fließkommabereich, brillieren, man bringt diese aber nur schlecht zum Anwender. Spielzeuge wie jene aus Standford mögen zwar den technologischen Stand gut reflektieren, sind aber untauglich, wenn es um allgemeine Problemlösungen gehen soll.
Ernüchternd ist in diesem Hinblick auch die schlechte OpenCL-Tauglichkeit der HD4000 Serie. Bis 'Fermi' am Markt ist, wird es keine größeren HD5000 Investitionen geben, warum auch, wenn sich AMDs Bemühungen weiterhin so 'erfolgreich' zeigen wie bisher?

 

[CapJo]

NVIDIA selbst hat kein Interesse OpenCL zu unterstützen und so lange AMD/ATI keine vernünftige Lösung haben wird es die auch von NVIDIA nicht geben.

Es ist doch für NVIDIA viel besser die Kunden an CUDA zu binden, vor allem weil es ausgereifter, performanter und auch noch mehr Features unterstützt.

Wie schon vorher näher ausgeführt, auch mit OpenCL wird es nötig sein für die jeweilige Hardwarearchtektur angepassten Code zu schreiben oder Kompromisse einzugehen.

 

[Emploi]

...
NVIDIA hat mit der Fermi-Karte was tolles geschaffen (für den GPGPU-Bereich). Es gibt jedoch ein relativ großes Problem für NVIDIA. Sie haben keine eigene x86 CPU. In Zukunft werden Grafikkarte und CPU wohl stärker zusammenwachsen und auf ein einzelnes DIE kommen. Die Speicherbandbreite wird (Anzahl der Speicher-Kanäle. Beim Core 7i sind es 3) wachsen und was insbesondere wichtig ist, ist dass der Cache gemeinsam von CPU und Grafikkarte genutzt werden kann. Außerdem wird es möglich sein auf einem gemeinsamen Adressraum zu arbeiten. Dies führt dazu, dass die Datentransfers zwischen PC-RAM und GPU-RAM entfallen.
...

Soviel Blech auf einen Haufen hab ich bisher nur bei einem Nebelunfall auf der BAB gesehen.

 

[Dr@]

Kann mir einer der Wissenden hier erklären, was bei der durch die Khronos Group zertifizierten OpenCL 1.0 Umsetzung von AMD fehlen soll?

 

[CapJo]

Es fehlt z. B. der Image-Support in OpenCL bei AMD/ATI.

Das bedeutet, dass der Speicherzugriff über die Textureinheit der Grafikkarte noch nicht funktioniert. Beim Texturzugriff hat man den Vorteil, dass dieser gecached wird und zusätzliche Adressierungsmodi unterstützt. (Ist wohl optional in der OpenCL-Spezifikation (weil nicht auf jeder Hardware verfügbar (CPU), aber für ne Grafikkarte sollte es schon da sein).

Außerdem fehlt "Double Precision" noch vollständig. (Auch optional in der Spezifikation, aber wenns schon die Hardware dafür vorhanden ist.)

Von stabil kann man noch gar nicht sprechen. Außerdem ist die Spec wohl in einigen Punkten nicht ganz eindeutig, so das einige OpenCL-Beispielprogramme von AMD nicht auf NVIDIA-Hardware laufen und andersrum.

Weitere Infos im developer Forum.

http://forums.amd.com/devforum/messageview.cfm?catid=390&threadid=127257&highlight_key=y&keyword1=image