AMDs Pläne für ATI Vector Processor

[AnarchX]

http://img5.pcpop.com/ArticleImages/500x375/0/315/000315540.jpg
http://babelfish.altavista.com/babelfish/trurl_pagecontent?lp=zh_en&trurl=http%3a%2f%2fwww.pcpop.com%2fdoc%2f0%2f147%2f147621.shtml

[Gmax]

Was kann man unter diesen Vektorprozessor verstehen?
Ist das eine abgewandelte Gpu?

[del_4901]

Das ist einfach ein Vektor Prozessor .. wie (teilweise) ISSE oder der Vertexshader ... Die CPUs im Worldsimulator oder der PhysX.

Wird warscheinlich als Physikberechnungslösung in einen "Nebensockel" gesteckt.

[AnarchX]

Wird warscheinlich als Physikberechnungslösung in einen "Nebensockel" gesteckt.

Vorerst per HTX-Port, aber laut dieser "Roadmap" landet er irgendwann in der CPU.

Wofür könnte er im Umfeld des Opteron genutzt werden?

[mrt]

Das ist sicher für Server/ Workstation gedacht. Im Consumer-Bereich seh ich da in nächster Zeit keine Anwendung die das nutzen wird.

Im Simulationsbereich sicher nicht schlecht.

[del_4901]

Vorerst per HTX-Port, aber laut dieser "Roadmap" landet er irgendwann in der CPU.

Wofür könnte er im Umfeld des Opteron genutzt werden?

Atombombensimulatonen, Wettervorhersage, so ziehmlich vieles lässt sich "vektorisieren".

[Avalox]

Im Consumer-Bereich seh ich da in nächster Zeit keine Anwendung die das nutzen wird.


der coherent hyper transport Link deutet auf eine Verwendung im Opteron Bereich hin. Allerdings kann man mal spekulieren, ob nicht doch zumindest die 4x4 Plattform CPUs ebenfalls kohärente HT Links besitzen.

Ich sehe schon im Consumer Bereich eine Anwendung. Unterhaltungssoftware, Spiele sind ein absolut ideales Feld für Vektorprozessoren.

Das Problem ist dort letztendlich nur die Software Schnittstelle. Aber wer weiss, vielleicht zeigt ja MS eine Lösung.

Auf jeden Fall zeigt es in die richtige Richtung. Spezialisierte skalierbare Kerne, statt immer komplexere Kerne. Ich bin mir sicher, dass AMD solche auch auf den Desktop Markt bringt, wenn erstmal eine Software Schnittstelle gefunden ist.

Da ja nun auch Grafik und Hauptprozessor von einen Hersteller stammen, könnte man sich ja auch einen tollen Grafiktreiber vorstellen, welcher eine Vorverarbeitung auf einen extra Vektor Prozessor nahe der CPU und dem Hauptspeicher ausführt.

[oliht]

Das ist sicher für Server/ Workstation gedacht. Im Consumer-Bereich seh ich da in nächster Zeit keine Anwendung die das nutzen wird.

Im Simulationsbereich sicher nicht schlecht.

Vektorisierung könnte schon etwas bei der Pro Mhz Leistung auch bei normalen Anwendungen bringen. Automatische Vektorsierung ist ja nicht etwas neues, gerade bei Signalverarbeitungsalgorithmen könnte das was bringen. Problematisch bei Vektorrechnern ist natürlich die Speicheranbindung.

[Bauer]

Also ich lese da GPU Package..

Ist das nicht nur ein Grafikkern der mehr und mehr mit der CPU verschmilzt?

[stav0815]

Also ich lese da GPU Package..

Ist das nicht nur ein Grafikkern der mehr und mehr mit der CPU verschmilzt?
Genau genommen ist eine GPU ein spezialisierter Vektorprozessor

[ShadowXX]

Ich sehe schon im Consumer Bereich eine Anwendung. Unterhaltungssoftware, Spiele sind ein absolut ideales Feld für Vektorprozessoren.

Das Problem ist dort letztendlich nur die Software Schnittstelle. Aber wer weiss, vielleicht zeigt ja MS eine Lösung.

Die Schnittstelle gibt es quasi schon: Direct3D 10(++).

[BlackBirdSR]

Also ich lese da GPU Package..

Ist das nicht nur ein Grafikkern der mehr und mehr mit der CPU verschmilzt?

Verschmelzen im Sinne von "nebeneinander auf einem die" ja, aber die fusion von beiden auf elementarer Ebene dürfte noch für lange Zeit unrentabel sein.

[Avalox]

Genau genommen ist eine GPU ein spezialisierter Vektorprozessor

Ich denke auch die SIMD Einheiten der heutigen CPUs nehmen starke Anleihen. ... obwohl GPUs sollten ja auch SIMD sein.

[OBrian]

... Problematisch bei Vektorrechnern ist natürlich die Speicheranbindung.Dann wird man wohl nicht normale Spiele damit beschleunigen und die Grafikkarte ersetzen wollen, weil die ja mit dediziertem RAM wesentlich mehr Bandbreite zur Verfügung stellt. Eher etwas, wo die Pixelshader intensiv dran herumrechnen müssen und dementsprechend weniger Bandbreite benötigt wird.

Insgesamt ist in der "Direct-Connect"-Architektur ja relativ viel Bandbreite vorhanden, mit jedem Sockel wächst sie auch noch. Die 12,8GB/s, die ein Sockel mit Dual Channel DDR2-800 bietet, können ja auch vom anderen Sockel mitbenutzt werden. Man könnte sich also vorstellen, daß der sehr bandbreitenhungrige Vektorprozessor dann z.B. 20GB/s nutzt und die "normale" CPU mit dem Rest völlig auskommt, weil sie dann auch wesentlich weniger zu tun hat. Bei 4 oder mehr Sockeln nimmt das entsprechend weiter zu, aber wenn dann eine CPU und drei GPUs rechnen, kann sich jede der GPUs natürlich nicht mehr so viel von der CPU klauen.

Was man auch machen könnte: "Normale" Grafikkarten mit eigenem RAM statt in PCIe- in HTX-Slots zu packen und in die NUMA mit einzubinden. Sozusagen Hypermemory auf höherem Level. Dann müßte man natürlich ein vernünftiges Speichermanagment haben, damit oft benötigte Daten im lokalen, kleinen Karten-RAM abgelegt werden und der langsamere, aber größere RAM des CPU-Sockels für den Rest bleibt.

Naja, machbar ist vieles, wir werden ja sehen, ob und wie es umgesetzt wird und wofür.

[robbitop]

Letztendlich erfordert das nichtmal viel R&D. Praktisch sind GPUs ja nichts anderes als solche Vektorprozessoren (natürlich mit noch anderen Einheiten drin). Und in Richtung D3D10 passt das immer mehr. Ergo müsste man lediglich ein jeweils aktuelles GPU Derivat mit einem HT Interface statt einem PEG Interface ausstatten + hier und da ein paar Änderungen und Kürzungen (z.B. könnte man den 2D Kern, den Crossbar, die ROPs und den Memcontroller entfernen) und fertig ist der Vektor-Coprozessor.

[Bokill]

Letztendlich erfordert das nichtmal viel R&D. Praktisch sind GPUs ja nichts anderes als solche Vektorprozessoren (natürlich mit noch anderen Einheiten drin). Und in Richtung D3D10 passt das immer mehr. Ergo müsste man lediglich ein jeweils aktuelles GPU Derivat mit einem HT Interface statt einem PEG Interface ausstatten + hier und da ein paar Änderungen und Kürzungen (z.B. könnte man den 2D Kern, den Crossbar, die ROPs und den Memcontroller entfernen) und fertig ist der Vektor-Coprozessor. Ein typisches ASIC Design zu überführen auf GHz -starke CPU Designs empfinde ich als alles andere, nur eben nicht trivial.

Grafikchips sind in der EDA Methodik näher an ASICs, als an CPUs. Das mag bei einem externen Chip über einen Zweitsockel (oder HTX Slot) kein Problem sein.

Bei einer Integration in die AMD CPU-Architektur hingegen schon.

Ich zweifel nicht daran, dass AMD derartige Überlegungen mancht, nur für "simpel", "leicht" und "so mal eben machbar" halte ich derartiges nicht.

Ein Vorteil hat AMD aber. Rapid Prototyping/Simulation/Debugging. Seit der Entscheidung auch Fremdchips auf den Sockel 940 zu lassen (und nun auch in andere AMD Sockel), kann AMD auf der eigenen Systemplattform mit HyperTransport und FPGAs (von Altera, Xilinx) (http://www.orthy.de/index.php?option=com_content&task=view&id=1760&Itemid=86)* einsetzen.

FPGAs haben den Vorteil, dass diese im Vergleich zu Softareemulationen/Simulationen sie um mindestens Faktor 10x (http://www.orthy.de/index.php?option=com_content&task=view&id=1780&Itemid=86)* schneller sind. Unter diesem Gesichtspunkt könnte daher die Entwicklung doch sehr beschleunigt werden ... "simpel" bleibt derartiges aber dennoch sicher nicht. Man kann mit FPGAs nur viel schneller Schrott und Bugs aussortieren.

MFG Bobo(2006)

* = Orthy.de

[Relic]

Hmm genau das was ich im Thread über den Zusammenschluss angekündigt habe ;)

[Gast]

Ein typisches ASIC Design zu überführen auf GHz -starke CPU Designs empfinde ich als alles andere, nur eben nicht trivial.

Grafikchips sind in der EDA Methodik näher an ASICs, als an CPUs. Das mag bei einem externen Chip über einen Zweitsockel (oder HTX Slot) kein Problem sein.

Bei einer Integration in die AMD CPU-Architektur hingegen schon.

Ich zweifel nicht daran, dass AMD derartige Überlegungen mancht, nur für "simpel", "leicht" und "so mal eben machbar" halte ich derartiges nicht.

Ein Vorteil hat AMD aber. Rapid Prototyping/Simulation/Debugging. Seit der Entscheidung auch Fremdchips auf den Sockel 940 zu lassen (und nun auch in andere AMD Sockel), kann AMD auf der eigenen Systemplattform mit HyperTransport und FPGAs (von Altera, Xilinx) (http://www.orthy.de/index.php?option=com_content&task=view&id=1760&Itemid=86)* einsetzen.

FPGAs haben den Vorteil, dass diese im Vergleich zu Softareemulationen/Simulationen sie um mindestens Faktor 10x (http://www.orthy.de/index.php?option=com_content&task=view&id=1780&Itemid=86)* schneller sind. Unter diesem Gesichtspunkt könnte daher die Entwicklung doch sehr beschleunigt werden ... "simpel" bleibt derartiges aber dennoch sicher nicht. Man kann mit FPGAs nur viel schneller Schrott und Bugs aussortieren.

MFG Bobo(2006)

* = Orthy.de
Eine GPU ist ein ASIC.

Dazu: Wieso sollte man das Design überführen müssen? Leistung wird üblicherweise aus Parallelität*Takt gewonnen - wenn die Vectorprozessoren parallel genug sind, braucht's keine 3 GHz.

[BlackBirdSR]

Eine GPU ist ein ASIC.

Dazu: Wieso sollte man das Design überführen müssen? Leistung wird üblicherweise aus Parallelität*Takt gewonnen - wenn die Vectorprozessoren parallel genug sind, braucht's keine 3 GHz.

Ich denke du hast nicht ganz die Richtung erblickt, die Bokill andeuten wollte.
Will man die Sache auf das DIE der CPU integrieren, so müsste man wohl ähnliche Taktraten erreichen.
Und das ist ersteinmal ein Problem.

[HOT]

HTX wird offen sein, auch NV kann dafür Vektorprozessoren basteln.

[StefanV]

Ich denke du hast nicht ganz die Richtung erblickt, die Bokill andeuten wollte.
Will man die Sache auf das DIE der CPU integrieren, so müsste man wohl ähnliche Taktraten erreichen.
Und das ist ersteinmal ein Problem.
Warum soll man das schaffen müssen??

Wenn mans wollte, könnt man diesen CoPro auch mit einem anderen Takt takten lassen...

[Demirug]

Will man die Sache auf das DIE der CPU integrieren, so müsste man wohl ähnliche Taktraten erreichen.

Nein, das ist nicht notwendig. Man kann auf einem Chip durchaus unterschiedliche Taktdomaines haben.

[BlackBirdSR]

Nein, das ist nicht notwendig. Man kann auf einem Chip durchaus unterschiedliche Taktdomaines haben.

Natürlich, wie man am Pentium4 sieht.
Aber will man das, wenn Caches und Ähnliches geteilt werden?

[Gast]

Ich denke du hast nicht ganz die Richtung erblickt, die Bokill andeuten wollte.
Will man die Sache auf das DIE der CPU integrieren, so müsste man wohl ähnliche Taktraten erreichen.
Und das ist ersteinmal ein Problem.
Ich glaube nicht, dass das notwendig ist. Bereits heute gibt es Dies, die mit sehr unterschiedlichen Teil-Takten laufen.

[Bokill]

Eine GPU ist ein ASIC.

Dazu: Wieso sollte man das Design überführen müssen? Leistung wird üblicherweise aus Parallelität*Takt gewonnen - wenn die Vectorprozessoren parallel genug sind, braucht's keine 3 GHz. Wie BlackbirdSR sehr richtig anmerkte ...

Es bestehen kleine Unterschiede zwischen potenziell 3 GHz und 500 MHz. Genau damit müsste sich AMD beschäftigen, wenn sie eine Vektoreinheit aus der ATI-Entwicklerschmiede in zukünftige CPU Designs verschmelzen will.

Demirug hat natürlich Recht, dass es verschiedene Taktdomains auf einem Chip/Die geben kann. Aber wer CPU Geschichte länger betreibt, dem wird auffallen, dass am Ende die Designs lieber im "Gleichklang (Takt ) schwingen" -> wollen.
Es gibt natürlich auch "Taktlose" Designs, ich denke aber dass wir einen weiten Bogen beschreiben und wir uns alle am Mainstream bewegen.

Die EDA-Tools (http://www.orthy.de/index.php?option=com_glossary&Itemid=55&func=view&id=311) sind in diesem Sinne eben noch nicht angeglichen (Methodik EDA ASIC -> EDA Methodik CPU) ...

MFG Bobo(2006)

[StefanV]

Natürlich, wie man am Pentium4 sieht.
Aber will man das, wenn Caches und Ähnliches geteilt werden?
Warum nicht??
Ich sehe nicht, warum das ein Problem sein soll...

[ilPatrino]

Ich denke du hast nicht ganz die Richtung erblickt, die Bokill andeuten wollte.
Will man die Sache auf das DIE der CPU integrieren, so müsste man wohl ähnliche Taktraten erreichen.

zwangsläufig? es sollte doch problemlos möglich sein, den vector-part unabhängig zu takten (eventuell auch dynamisch, um dualcore-stromsparmechanismen der letzten zeit anzusprechen) und per ringbuffer/x-bar zu füttern

€dit: man, bin ich langsam
€dit2: irgendwie war grade ein teil des freds verschwunden :uconf:

[BlackBirdSR]

Ich gebe mich der Mehrheit geschlagen ;)
War etwas kurzsichtig von mir.
Danke für die ganzen Einblicke.