Newsseite - GPU in der CPU

[Gast]

"Ebenfalls denkt Intel im übrigen über die (langfristige) Integration von Grafikcores in die CPU nach, was eine durchaus interessante Vorstellung ist. Allerdings können wir uns dieses für den Moment eher nur für den absoluten LowCost-Grafikchips vorstellen, in allen anderen Segmenten dürfte sich der Markt für eine solche feste Kombination wohl viel zu schnell drehen."

ist das nicht ein ähnlicher ansatz wie von dem einen entwickler (unreal engine) angesprochen wurde, wo er andachte die grafikberrechnung wieder der cpu zukommen zu lassen...sprich wieder zum software rendering zurückzukehren?!

vielleicht ist die übersetzung dieser meldung schlicht zu ungenau und hier spricht intel genau dasselbe an wie schon (letzte woche glaub) voin diesem einen unreal entwickler?!

Was meint ihr, immerhin ist intel seinen planung immer halbwegs treu geblieben und damit wäre diese variante sicher auch mit einer breiten unterstützung gesegnet....und amd würde sich diesem markt auch nicht gänzlich verschliesen...

was könnten die folgen sein? die grafikchiphersteller werden zu cpu herstellern und gesellen sich neben intel und amd auf das feld -> mehr marktkampf? ich denke diese entwicklung könnte aus kundensicht sehr vorteilhaft (auch bei den kosten) ausgehen..

was denkst ihr darüber?

[Gast]

wenn ich das richtig verstehe sollen dann in zukünftigen multicore prozessoren, auch ein spezieller core vorhanden sein der extra für grafikberechnungen da ist (halt so wie die gpu's auf grafikkarten)

möglich wäre das bestimmt, allerdings glaube ich das weder amd und intel das know how haben um gpu's herzustellen die an denen von ati und nvidia rankommen, noch das diese cpu's herstellen können die an denen von intel und amd rankommen
wenn das kommt dann ist das wahrscheinlich eher was für bürorechner, halt wie im moment die onboard grafik

intel könnte natürlich auch ati oder nvidia aufkaufen, dann würd amd dumm dastehen

[malle]

Gast[/POST]']

intel könnte natürlich auch ati oder nvidia aufkaufen, dann würd amd dumm dastehenNö....der andere geht dann zu AMD

[san.salvador]

Gast[/POST]']wenn ich das richtig verstehe sollen dann in zukünftigen multicore prozessoren, auch ein spezieller core vorhanden sein der extra für grafikberechnungen da ist (halt so wie die gpu's auf grafikkarten)

möglich wäre das bestimmt, allerdings glaube ich das weder amd und intel das know how haben um gpu's herzustellen die an denen von ati und nvidia rankommen, noch das diese cpu's herstellen können die an denen von intel und amd rankommen
wenn das kommt dann ist das wahrscheinlich eher was für bürorechner, halt wie im moment die onboard grafik

intel könnte natürlich auch ati oder nvidia aufkaufen, dann würd amd dumm dastehen
Ist nicht Intel die Nr. 1 bei GPU-Herstellung? Da sollte genug Know-How vorhanden sein.

[drmaniac]

aber nicht für Top 3D Grafikkarten. Da kommen die nicht mit den Entwicklern von z.B. Nvidia mit. Gabs hier auch schonmal einen Artikel dazu.

[Spasstiger]

Die Speicherbandbreite einer CPU reicht nicht ansatzweise für einen flotten Grafikchip (neben der CPU, die ja ebenfalls Speicherbandbreite belegt).

[Blutmaul]

Wenn ich lese, das die kommende Grafikkartengeneration bis zu 300 Watt verbrät, kann ich mir das schlecht vorstellen, das es auch nur Mid-End-Grafik in die CPU schafft.

[BUG]

Spasstiger[/POST]']Die Speicherbandbreite einer CPU reicht nicht ansatzweise für einen flotten Grafikchip (neben der CPU, die ja ebenfalls Speicherbandbreite belegt)...vieleicht bekommt die ja in Zukunft ein eigenen Speicher Slot für DDR2 oder DDR3 Speicher. ;) ..und dann mit einer Pipe die Syncron mit dem CPU Takt taktet. ;)

cu
BUG

[Spasstiger]

BUG[/POST]']..vieleicht bekommt die ja in Zukunft ein eigenen Speicher Slot für DDR2 oder DDR3 Speicher. ;) ..und dann mit einer Pipe die Syncron mit dem CPU Takt taktet. ;)
Du hast dann trotzdem nur ein 64 Bit SI. Selbst mit 800 MHz schnellen DDR3-Speicher erreichst du damit keine brauchbaren Speicherbandbreiten (800*64*2/8 = 12,8 GB/s). 20 GB/s sollte man schon haben für einen Grafikchip, der vielleicht erst 2008 tatsächlich zum Einsatz kommt (und das wäre dann bestenfalls Low-End-tauglich).

[anddill]

GPU in der CPU gab es schon mal. Kam von Intel, hieß Timna und wurde vor Markteinführung wieder eingestampft, da zu ineffizient und zu teuer.
Aber wer weiß, bei den heutigen Speicherbandbreiten und Herstellungsprozessen könnte es sich ja doch lohnen, diesen Zombie wieder aus dem Grab zu holen.

[Ailuros]

Vorsicht mit den Taktraten bei GPUs. Falls so eine These ueberhaupt je zur Realisierung kommt wuerde ich eher denken dass der integrierte Grafik-Teil einer solchen CPU mit einer asynchronen Frequenz laufen wird.

12GB/s wuerden ausreichen fuer eine Ausnahme, aber ich halte so was momentan fuer unwahrscheinlich ;)

[Gast]

Spasstiger[/POST]']Du hast dann trotzdem nur ein 64 Bit SI. Selbst mit 800 MHz schnellen DDR3-Speicher erreichst du damit keine brauchbaren Speicherbandbreiten (800*64*2/8 = 12,8 GB/s). 20 GB/s sollte man schon haben für einen Grafikchip, der vielleicht erst 2008 tatsächlich zum Einsatz kommt (und das wäre dann bestenfalls Low-End-tauglich).Vor allem ist es nicht gerade unproblematisch GDDR3 bei 800 MHz in einem Sockel/Slot zu betreiben.

[Crazy_Chris]

anddill[/POST]']GPU in der CPU gab es schon mal. Kam von Intel, hieß Timna und wurde vor Markteinführung wieder eingestampft, da zu ineffizient und zu teuer.
Aber wer weiß, bei den heutigen Speicherbandbreiten und Herstellungsprozessen könnte es sich ja doch lohnen, diesen Zombie wieder aus dem Grab zu holen.

Gibs auch noch heute. z.B. der AMD Geode GX mit 2D Grafikcore. Ist nur was für den embedded Bereich. :|

[BUG]

Spasstiger[/POST]']Du hast dann trotzdem nur ein 64 Bit SI. Selbst mit 800 MHz schnellen DDR3-Speicher erreichst du damit keine brauchbaren Speicherbandbreiten (800*64*2/8 = 12,8 GB/s). 20 GB/s sollte man schon haben für einen Grafikchip, der vielleicht erst 2008 tatsächlich zum Einsatz kommt (und das wäre dann bestenfalls Low-End-tauglich)...naja HighEnd wird sicherlich auch nicht angestrebt, maximal unteres mittelfeld. Aber wenn ich mir z.B. den Radeon XPress 200 Chipsatz ansehe mit intigirierter Grafik, dann könnte ich mir schon vorstellen das man unteres Mainstream erreichen könnte. Im Notebook mit ATI Chipsatz teilt sich z.B. CPU und Graka das 64Bit Speicherinterface und so schlecht ist die Leistung nicht (also ich hätte es mir schlimmer vorgestellt).

cu
BUG

[haifisch1896]

Spasstiger[/POST]']Die Speicherbandbreite einer CPU reicht nicht ansatzweise für einen flotten Grafikchip (neben der CPU, die ja ebenfalls Speicherbandbreite belegt).

eDRAM sollte möglich sein und helfen können, nicht so sehr auf den Hauptspeicher des PC angewiesen zu sein.

[Lubi]

Ist ja schön und gut, für Lowend und Lowcost Lösungen absolut legetim.

Aber eine CPU hat eine wesentlich höhere Lebensdauer im System als eine Graka, die alle Nas lang verkauft wird und gegen eine stärkere ausgetauscht wird (bei uns Gamern).

Und was nun? Die HighEnd Boliden werden niemals integriert werden, höhstens wenn wir in 20 - 40 Jahren beim absoluten Photorealismus angelangt sind und jede Rechenleistung eines jeden Chips ausreicht, und es nur noch um Effiziens geht.

Aber wäre es nicht praktisch, einige grafikrelevanten Berechnungen, anstatt auf nem 2. Core, lieber auf einer integrierten Co-CPU (ist eine GPU im Endeffekt ja auch, ihr wisst aber was ich meine) berechnen zu lassen? Von mir aus ATIs vorgeschlagene Physiklösung :wink: :rolleyes: oder das Filtering? Hmm aber jeden Frame zur CPU zu schicken und dann wieder mit der Graka abzugleichen...

Villeicht wird die Grafikausgabe über den CPU gehen, sodass die GPU nicht Endstation des Frame ist. Auch umständlich, lol.

Cya Lubi

[haifisch1896]

Quasi AOC - Ageia-on-a-chip...
wäre interessant. Aber wie will man dann die Abwärme abführen?

[Lubi]

Villeicht per HT Link aufs Mobo auslagern, und nen 40 x 40 Quirl drauf :| Dann wäre es halt keine on CPU Lösung, aber auch eine Möglichkeit die zuerst in Betracht kommen würde, also Physik Onboard, bis die Strukturen klein genug sind und Intels Tri-Gate Technologie Hand und Fuß hat ;)

Vorsicht, alles höhst spekulativ....

Cya Lubi

Ps: Wenn man GPU / PPU on DIE hätte, hätte man einen großen Vorteil: Die Flexibilität im Speicherausbau. Enfach 2 extra Speicherslots für den GRAKA Speicher aufs Mobo klatschen. Spich: Oh, die 256 MB meiner x1800 XT On Die Edition reichen nicht mehr aus, einfach einen 2. 256 MB Riegel nachschieben, kost ja nix mehr ...

[Gast]

Lubi[/POST]']Ps: Wenn man GPU / PPU on DIE hätte, hätte man einen großen Vorteil: Die Flexibilität im Speicherausbau. Enfach 2 extra Speicherslots für den GRAKA Speicher aufs Mobo klatschen. Spich: Oh, die 256 MB meiner x1800 XT On Die Edition reichen nicht mehr aus, einfach einen 2. 256 MB Riegel nachschieben, kost ja nix mehr ...Das würde aber nur bei Low-End-Karten mit entsprechend lahmem Speicher funktionieren. Wie oben schon geschrieben, ist es nicht gerade einfach den hochgetakteten GDDR3-Speicher, wie er auf aktuellen Grakas eingesetzt wird, in einem Sockel zu verwenden.

[Lubi]

Gast[/POST]']Das würde aber nur bei Low-End-Karten mit entsprechend lahmem Speicher funktionieren. Wie oben schon geschrieben, ist es nicht gerade einfach den hochgetakteten GDDR3-Speicher, wie er auf aktuellen Grakas eingesetzt wird, in einem Sockel zu verwenden.

Da hast du Recht. Und 128 MB eDRAM zum Puffern ist zu teuer :(

[HOT]

Hmm.... On-Die 128Bit Memcontroller? Hochgetaktete DDR2/3 Speicher? Z-RAM für eDRAM? HMMMMM....
AMD hätte da im Moment die wesentlich bessere Technologie. Müssen sich halt nurnoch ne Serie6 Lizenz besorgen :D
Aua, wenn man sieht was sich damit für Möglichkeiten auftun :| ;D

[aths]

Ich glaube nicht, dass die CPU in 10 Jahren die (dann verfügbaren) GPUs ersetzen können. Wofür ich aber wirklich wäre, ist ein Software-Renderer – mit CPUs, die bestimmte Units zum Beschleunigen haben.

Der Software-Renderer wäre der Notfallmodus bei Treiber-Inkompatibilitäten bei SiS-, Trident-, Neomagic- und wasweißich für integrierten Chipssätzen.

[haifisch1896]

Lubi[/POST]']Da hast du Recht. Und 128 MB eDRAM zum Puffern ist zu teuer :(

Ich wage zu bezweifeln, dass man 128MB bräuchte. Ich denke, mit 64 wäre man bei eDRAM schon sehr gut bedient.

[Ailuros]

hendrikhey[/POST]']Ich wage zu bezweifeln, dass man 128MB bräuchte. Ich denke, mit 64 wäre man bei eDRAM schon sehr gut bedient.

Wenn ich das eDRAM von Xenos auf =/>60M Transistoren fuer nur 10MB einschaetze, dann erlauben mir momentan ganze 64MB keine besondere Hoffnung.

[haifisch1896]

Waren 10MB nicht genug für 1152x864x32bpp bei 2xAA? Da dachte ich, 64MB würden locker für 1600x1200x32bpp bei 4xAA und 8xAF reichen.

[AnarchX]

hendrikhey[/POST]']Waren 10MB nicht genug für 1152x864x32bpp bei 2xAA? Da dachte ich, 64MB würden locker für 1600x1200x32bpp bei 4xAA und 8xAF reichen.

Für Vista werden 10MB bedeutend zu wenig sein.

[Ailuros]

hendrikhey[/POST]']Waren 10MB nicht genug für 1152x864x32bpp bei 2xAA? Da dachte ich, 64MB würden locker für 1600x1200x32bpp bei 4xAA und 8xAF reichen.

Du hast mich wohl nicht richtig verstanden; falls die 10MB tatsaechlich ca. 60M Transistoren enstprechen, dann sind mit der gleichen Dichte 64MB in etwa ~380M Transistoren. So viel Komplexitaet ist Ueberfluss selbst fuer eine GPU, von einer so komplizierten CPU wuerde ich schon gar nicht reden.

Wie oft wurde schon erwaehnt dass eDRAM nicht wirtschaftlich fuer GPUs ist und die Chancen es in groesseren Mengen in der Zukunft zu sehen gering? Wieso solten jetzt ploetzlich CPUs komplexer werden als GPUs selber?

Selbst wenn CPU Hersteller in der absehbaren Zukunft einen kleinen 3D Kern in multi-core CPUs integrieren sollten, wird es sich nur um budget graphics handeln. GPUs werden nach wie vor 3D effizienter bedienen.

[haifisch1896]

Da hast Du recht.

Ein weiteres Problem eines Midrange-Chips auf der CPU wäre ja die Abwärme, die zusätzlich entsteht.
Wenn ich da an eine 89Watt CPU mitsamt 70W GPU in einem einzigen Package denke, wird mir schlecht.

[Leonidas]

Gast[/POST]']
ist das nicht ein ähnlicher ansatz wie von dem einen entwickler (unreal engine) angesprochen wurde, wo er andachte die grafikberrechnung wieder der cpu zukommen zu lassen...sprich wieder zum software rendering zurückzukehren?!

vielleicht ist die übersetzung dieser meldung schlicht zu ungenau und hier spricht intel genau dasselbe an wie schon (letzte woche glaub) voin diesem einen unreal entwickler?!



Eine interessante Schlußfolgerung, auf die ich unverständlicherweise nicht selber gekommen bin. Macht aber durchaus Sinn.

[StefanV]

Naja, aber warum soll man zum SW Rendering zurückkehren?! :|

Macht eigentlich kaum 'nen Sinn, vorallendingen weil Grafikbearbeitung Bandbreite braucht, die die CPU nicht hat/haben kann :|

[Demirug]

Mit einem entsprechenden Speicherkontroller bekommt man die Bandbreite auch für eine CPU hin.

Was mir allerdings gerade noch einfällt. Ich habe von Intel ein Bild gesehen von einer zukünftigen Multicore CPU. Dabei waren alle Cores Funktional identisch. Trotzdem waren sie unterschiedlich eingefärbt um zu verdeutlichen das sie bei einem Spiel unterschiedliche Aufgaben übernehmen. Bei einigen Stand Physik , bei anderen AI und wieder andere waren mit Grafik beschriftet.

[Gast]

Demirug[/POST]']Was mir allerdings gerade noch einfällt. Ich habe von Intel ein Bild gesehen von einer zukünftigen Multicore CPU. Dabei waren alle Cores Funktional identisch. Trotzdem waren sie unterschiedlich eingefärbt um zu verdeutlichen das sie bei einem Spiel unterschiedliche Aufgaben übernehmen. Bei einigen Stand Physik , bei anderen AI und wieder andere waren mit Grafik beschriftet.War da nicht eher die Aufbereitung der Daten für die GPU gemeint? Diese verschlingt doch afaik einen recht hohen Anteil der benötigten CPU-Leistung.

[RaumKraehe]

Ich denke die GPU in die CPU zu integrieren ist bei Rechnern für reine Büroanwednungen oder Servern durchaus sinnvoll und eine logische Konsequenz.
In der Zukunft werden immer mehr Komponenten in die CPU verlagert werden. AMD hat es mit dem Speicherkontroller ja auch erfolgreich vorgemacht. Als Beispiel. Nur würde ich dann nicht mehr von einer CPU reden sondern von einem "One Chip PC".

Für Gamer wird das sicher nicht sonderlich interessant sein da die Entwicklung beider Komponenten viel zu schnell vorangetrieben wird. Es sei denn man besinnt sich wieder auf das Softwarerendering und könnte CPU-Kerne modular erweiterbar machen. Aber das kann ich mir nicht vorstellen. ;)

[Gast]

StefanV[/POST]']Naja, aber warum soll man zum SW Rendering zurückkehren?! :|

Macht eigentlich kaum 'nen Sinn, vorallendingen weil Grafikbearbeitung Bandbreite braucht, die die CPU nicht hat/haben kann :|

Das hätte schon Vorteile, zum Beispiel könnte man gleich zum echtzeit raytracing übergehen :D

[Coda]

Raytracer können Rasterizer nicht ersetzen. Stichwort dynamische Geometrie. Da gibt es unglöste Probleme.

[Tigerchen]

Gast[/POST]']wenn ich das richtig verstehe sollen dann in zukünftigen multicore prozessoren, auch ein spezieller core vorhanden sein der extra für grafikberechnungen da ist (halt so wie die gpu's auf grafikkarten)

möglich wäre das bestimmt, allerdings glaube ich das weder amd und intel das know how haben um gpu's herzustellen die an denen von ati und nvidia rankommen, noch das diese cpu's herstellen können die an denen von intel und amd rankommen
wenn das kommt dann ist das wahrscheinlich eher was für bürorechner, halt wie im moment die onboard grafik

intel könnte natürlich auch ati oder nvidia aufkaufen, dann würd amd dumm dastehen

Intel hat ja bereits im seligen i860 einen 3D-Grafikkern eingebaut. Sogar mit 64 Bit breiten Registern. Denke nicht daß Intel nochmal so ein Abenteuer startet.

[Coda]

Tigerchen[/POST]']Sogar mit 64 Bit breiten Registern.
Wat? Das Ding hatte doch noch gar keine Pixelshader, was willst da mit Registern?

Sicher das du das nicht mit einem 64-bit-SI durcheinanderwirfst?

[Architekt]

Coda[/POST]']Raytracer können Rasterizer nicht ersetzen. Stichwort dynamische Geometrie. Da gibt es unglöste Probleme.

Meinst du damit die Abhängigkeit der Zeitkomplexität von der Anzahl der Primitiven (die ja beim rasterisieren nicht gegeben ist) oder wie soll ich das verstehen ¿

Ich denke dieses Problem wäre bei Spielen schon in den Griff zu bekommen.

[Neomi]

Raytracing selbst ist prima zu parallelisieren und wäre daher nicht wirklich schwer umzusetzen. Der Haken ist dabei, daß vor dem Tracing erstmal der Szenenbaum aufgebaut werden muß. Wenn viel Bewegung in der Szene ist, muß das für jeden Frame neu gemacht werden.

Architekt[/POST]']Ich denke dieses Problem wäre bei Spielen schon in den Griff zu bekommen.

Und wie soll das geschehen? Das Problem verschwindet nicht von alleine, weil es um ein Spiel geht. Das Problem ist nach wie vor da und will erstmal gelöst werden.

[Coda]

As Neomi said. Das größte Problem ist das sowas wie ein Vertexshader damit gar nicht möglich ist. Höchstens man gibt an in welchem Bereich sich die Vertices maximal bewegen können und benützt losere Bäume.

Aber richtig gute Lösungsansätze hab ich da noch nicht gesehen. Wir bewegen uns immer mehr in Richtung dynamische Geometrie (Physikbeschleuniger). Da läuft gegen ne Mauer mit nem Raytracer (entweder Szene-Tree komplett oder teilweise jedes Frame neu ausrechnen ist ziemlich bös).

Und bei einem Tracer mit ineffizientem Szenetree kommt man schnell in den O(n) statt O(log n) Bereich.

[Architekt]

Neomi[/POST]']
Raytracing selbst ist prima zu parallelisieren und wäre daher nicht wirklich schwer umzusetzen. Der Haken ist dabei, daß vor dem Tracing erstmal der Szenenbaum aufgebaut werden muß. Wenn viel Bewegung in der Szene ist, muß das für jeden Frame neu gemacht werden.


Den ganzen Baum für jedes Frame neu aufbauen ¿
Es reicht doch aus wenn man im Szenenbaum die Äste die Ihre Lage zum Bezugspunkt geändert haben aktualisiert. Wenn man den Szenenbaum so aufbaut das alle Äste den Übergeordneten Ast als Bezugspunkt haben dann hat man eine viel kleinere Anzahl änderungen im Szenenbaum als die Anzahl der im Bezug auf den Globalen Szenenursprung geänderten (neu erstellten, entfernten, verschobenen) Blätter.

Wie seht ihr das ¿

[Architekt]

Ups das eben war net ganz richtig, natürlich gilt das mit dem verringerten Aufwand nicht für die neu erstellten und entfernten Blätter.

[Coda]

Architekt[/POST]']Es reicht doch aus wenn man im Szenenbaum die Äste die Ihre Lage zum Bezugspunkt geändert haben aktualisiert.
Ein Vertexshader kann eine beliebige Position ausspucken. Und nicht die Äste ändern ihre Position sondern die Geometrie.

[Ailuros]

Waere rein theoretisch bei zukuenftigen Stream-Prozessoren ray-tracing nur stellenweise einzusetzen nicht eine Moeglichkeit? (ehrliche dumme Frage *hust*)

[Mike1]

warum Grafik in die CPU, wenn sie bei dem, für die CPU noch immer notwendigem MoBo eh schon reingeht?

[Gast]

Mike1[/POST]']warum Grafik in die CPU, wenn sie bei den, für die CPU noch immer notwendigem MoBo eh schon reingeht?


wäre vlt. billiger herzustellen und würde platz sparen, was z.b. in laptops immer gut ist :)

[Neomi]

Ailuros[/POST]']Waere rein theoretisch bei zukuenftigen Stream-Prozessoren ray-tracing nur stellenweise einzusetzen nicht eine Moeglichkeit? (ehrliche dumme Frage *hust*)

Nur, wenn das Tracing selbst sich auf einen statischen (Teil-)Szenenbaum beschränkt, aus dem man nicht mehr hinauskommt. Für die vielen Reflektionen innerhalb eines Scheinwerfers wäre das z.B. denkbar. Oder dann, wenn man durch ein (unkaputtbares) Fenster in einen statischen Raum rein bzw. eine statische Welt hinausschaut.

[incM]

Mike1[/POST]']warum Grafik in die CPU, wenn sie bei dem, für die CPU noch immer notwendigem MoBo eh schon reingeht?

spart strom,kuerzere leitungswege,weniger abwaerme
ideal fuer laptops...
zudem koennte man rechner im notfall auch mit der rumentaeren cpu-gpu laufen lassen was mir zb im moment ganz lieb waere da ich noch ne weile mit dem kauf von ner grafikkarte warten will

[Tigerchen]

Coda[/POST]']Wat? Das Ding hatte doch noch gar keine Pixelshader, was willst da mit Registern?

Sicher das du das nicht mit einem 64-bit-SI durcheinanderwirfst?

Das Ding dürfte ziemlich anders funktioniert haben als ein moderner 3D-Kern. Und warum sollen Register an Pixelshader gekoppelt sein? Register hat jeder 4 Bit Prozessor.