makiyt schrieb:
Bist du da sicher? Ich hatte sehr oft was von Steigerungen gelesen mit Werten um das ca. 8fache...
Bei fast rein synthetischen Code kann das schon gut sein.
Bin aber eher der (HD-) Videoschnipsler, vllt ist das da anders. Auf jeden Fall hab ich mal nen Benchmark gesehen, wo beim CUDA-Rendern die GTX460 den dicksten Core i7 (glaub es war ein 920er) locker abgezogen hat und ca 600% schneller war.
Da wurde dann wahrscheinlich vom gesamt Umfang der Software irgendeine kleine Spezialfunktion wegen entsprechenden Zuschüssen und technischer Unterstützung von Nvidia optimiert, wo vorher nicht einmal eine ordentliche Dual Core Unterstützung da war. Da kann das dann schon gut hinkommen.
Eigene Beobachtung:
Mein Intel Core 2 Duo T9500 (2 x 2,6 Ghz, 6 MB L2 Cache) rendert AVCHD ca. 60% langsamer als mit GPU-Unterstützung durch eine GeForce 8600M GT.
Die 8600M hat noch gar kein CUDA unterstützt geschweige denn OpenCL. Von was du redest ist wahrscheinlich nur die reine OpenGL Optimierung, die es schon seit Jahren gibt. Das ist kein GPU Computing. Hier macht die Grafikkarte nur das, was sie immer schon gemacht hat nämlich Bilder berechnen und diese dann ausgeben bzw. in den Speicher der CPU zurück lesen. Dafür braucht man aber kein DirectX11 oder viele Recheneinheiten, da alleine durch das Vorhandensein der Grafikkarte die Last schon wieder bei der CPU ist.
7bf schrieb:
Gerade bei den "langsameren" mobilen Rechnern ist die GPU Beschleunigung von Browsern auch nett. Dadurch steigt ja nicht nur die Rendergeschwindigkeit sondern auch die Akkulaufzeit. Ich würde das nicht so einfach zur Seite schieben, gerade wenn man Atom und Bobcat vergleicht ist das ganze schon ein Vorteil.
Ich habe nichts gegen eine integrierte Grafikkarte in der CPU. Für das darstellen von Grafik ist die Grafikkarte notwendig. Es wird aber nicht extrem viel Leistung benötigt. Typische Internetseiten kann auch eine 5 Jahre alte Bürokarte ordentlich darstellen. Da braucht es auch kein DirectX11 oder 1GB RAM in der CPU, die man sehr viel sinnvoller investieren könnte (z.B. ein weiterer Kern, mehr Cache usw.)
Limit schrieb:
Schwachsinn ist das ganz bestimmt nicht. Für bestimmte Aufgabenbereiche ist eine GPU-Architektur deutlich schneller und effizienter als herkömmliche CPU Architekturen. Die meisten Programme außerhalb des HPC Marktes sind von ihrer Charakteristik aber gemischt, manche Unterprogramme laufen besser auf der CPU und manche besser auf der GPU. Bei CPU + Grafikkarte kannst du die Teilprogramme aber nicht oder nur sehr grob-granular auf CPU und GPU aufteilen, weil einfach die Latenzen zwischen CPU und GPU zu hoch und die Bandbreite zu niedrig ist. Wenn man nun die GPU richtig in die CPU integriert, könnte man das Problem komplett beheben.
Das Problem ist, dass das Entwickeln von Code für die GPU um Welten komplexer ist, als das Entwickeln von Code für die CPU. Dagegen ist das Implementieren einer Dual/Quad Core Optimierung gar nichts und selbst das wird nur beim Rechenkern selbst gemacht, aber nicht beim ganzen Programm.
Die Bandbreite zur GPU ist auch hoch genug, genauso die Latenzen. Das Problem ist, dass es sich hier um IO Operationen handelt, die vom Betriebssystem verwaltet werden und wo ein Prozesswechsel notwendig wird, der um die 10µs braucht und das bekommt man mit einem integrierten Kern auch nicht weg.
Ach ja, deswegen gibt es ja auch schon so viele Programme, die jeder Homeuser benutzt....
Das Problem ist eben, dass es verdammt viel Aufwand macht solche Software zu entwickeln und dann nur ein paar Leute davon profitieren und das sind so gut wie nur Heimuser, mit denen man sowieso kein Geld machen kann.
Bei entsprechenden Problemen könnte sogar Mainstream GPUs schneller sein als jede zur Zeit erhältliche CPU. Der Haken ist aber wie oben schon erwähnt, dass es kaum Anwendungen gibt, die sich komplett für GPU optimieren lassen, d.h. es gibt immer Codeabschnitte, die sich auf einer CPU trotz geringerer Rohpower um ein vielfaches schneller ausführen ließen als auf einer GPU. Genau deshalb wollen ja alle plötzlich CPU + GPU vereinigen.
Die CPU lässt sich nicht so einfach mit der GPU vereinigen. Das eine ist normaler x86 Code, das andere ist nur ein Schreiben von Daten in den Speicher der Grafikkarte inkl. dem Code für die Berechnung und warten, bis man sich das Ergebnis wieder abholen kann. Das macht nur Sinn, wenn genug Arbeit am Stück da ist. Die meisten Algorithmen brauchen einiges an Cache, den die GPU so gut wie überhaupt nicht hat usw.
Ist es nicht so, dass es nur für den CPU-Teil einen entsprechenden OpenCL "Treiber" geben soll?
Ein Treiber läuft immer auf der CPU und zwar auf Kernel Ebene. Da kann man die Grundfunktionen der Grafikkarte verwenden, aber Code der Applikation hat auf der Ebene nichts verloren. Das hat Microsoft mit der zwingenden Treibersignierung auf x64 Systemen noch einmal deutlich gemacht. Das wäre ein Rückschritt zu Win98, wo ein Bug in der Software jedes Mal einen Bluescreen nach sich gezogen hat.
