x86 <> Grafikchip

[Crass Spektakel]

Die x86 ist bei serieller Rechenleistung nicht schlecht. Sie verwendet kompakten Code, arbeitet recht schnell, wen wunderts, alle heutigen Architekturen, auch x86, sind intern RISC oder gar VLIW und übersetzen in Echtzeit den x86-Code in einen RISC/VLIW-Code. Performance kostet sowas in keinster Weise, es bläht halt den Chip um ein paar Promille auf, dafür ist man über Generationen Binärcodekompatibel. PPC, Sparc usw. machen es genau so.

Aber bei paralleler Architektur arbeitet man anders, da verwendeet man extrem minimalistische CPU-Kerne ohne jeden Schnörkel. Mag bei einem i7 der x86-Kompatibilitätsanteil nur 1% ausmachen so ist in einem Larrabe jeder Kern mit einer eigenen x86-Dekodereinheit zu versehen, ratzfatz hat man dann bei 32 einfachen Kernen 32mal einen dicken x86-Dekoder und dann macht das 20-30 Prozent der Chipfläche aus. Daß man dabei gewisse Pipeline-Controllvorteile verliert kommt dazu. Binärkompatibilität bei GPUs ist einfach ein unerfüllbarer Wunschtraum, da hat sich seit der Erfindung von GPU-Code schon zweimal der AMD und dreimal der NVidia-Standard geändert.

Zumal echte Lowlevel-GPU-Programmierugn gerade bei AMD (man sieht daß AMD da mit der AMD29000-Architektur einiges zu bieten hat) wirklich ultra-extrem-lowlevel ist, dagegen ist eine ARM- oder 6502-Architektur geradezu Beletristik. Da ist es wirklich so daß man in einem Very-Long-Instruction-Word genau weis daß der Opcode von Bit#7 bis Bit#12 in der Pipeline an Platz Drei zum dritten Taktzyklus abgearbeitet wird während der Comparator von Bit#23 bis Bit#25 parallel zur Akkumanipulation bei Bit#32 bis #47 erfolgt und muß was draus machen. Damit programmiert man keine Alltagsanwendungen sondern Bitpopelige Pfrimmelei, da läuft kein Windows drauf sondern eine wenige tausend Byte grosse Fourier-Transformation. Für alles andere ist sowas ungeeignet, aber nunmal im Spezialfall nicht zu schlagen.

In der GPU-Welt wird der einzelne Core nur über den Takt "schneller", niemals über Peephole-Optimizing. Wenn die Technologie voranschreitet werden mehr Cores implementiert, nicht die alten optimiert. Heute haben wir 1600GPU-Kerne in einem Die, in zehn Jahren dann halt eine Million. Jedem Bildschirmpixel eine eigene GPU-Einheit.

Das erschlägt alles die übergeordnete Softwarearchitektur, da ist mit x86 absolut kein Preis zu gewinnen, das steht nur im Wege... Wenn Intel das einsieht und mit ihrem Know-How eine ultraparallele Micro-RISC-Architektur bauen, dann wird das was.



1 mal bearbeitet, zuletzt am 05.12.09 15:16 durch Crass Spektakel.

[BildschirmMensch]

tl;dr

[RMMD]

Also erstmal Gratulation zu dem Beitrag. So einen kompetenten Beitrag sieht man hier im Golem-Forum selten.

Ein weitere Unterschied zwischen GPU und CPU waere auch das Verwenden Branches. Waehrend das Grafikrendering sehr linear ablauft, muss die CPU auch mit Codeverzweigungen klar kommen und auch dahingehend optmimiert werden. Das fuehrt ebenfalls zu einem groesseren DIE der fuer reines Rendering nicht notwendig waere.

Ich schaetzte mal fuer Intel stellt das Zusammenschalten von altbewaehrten Kernen deutlich weniger Aufwand dar, als eine komplett neue Architektur. Von daher kann man die Entscheidung schon nachvollziehen.

[alle Beiträge auf einen Blick oder in Baumstruktur]

RMMD schrieb:
--------------------------------------------------------------------------------
> Waehrend das Grafikrendering sehr linear ablauft, muss die CPU
> auch mit Codeverzweigungen klar kommen und auch dahingehend optmimiert
> werden.

Tja. und das ist auch der grund warum gpus in jetziger form die klassische cpu architektur noch lange nicht ablösen werden.

[Nicht ganz richtig]

Leider stimmt die erste Aussage nicht ganz:

Die Larrabee Architektur ist vom Pentium P54C abgeleitet. Das bedeutet, dass es sich um einen vollwertigen CISC Prozessor mit vollem Microcode handelt. Da gibt es keine RISC Bestandteile, die uOps werden direkt ausgeführt. Darum ist auch kein RISC Übersetzer notwendig.