XBOX360 und PS-3 CPUs stinken ab ?

wie gut oder wie schlecht die protzen mit ihren cores und pipelines und was weiss ich nicht noch alles sind, denke ich, wird sich eh erst in ca. 1-2 jahren herausstellen. dann wird man warscheinlich erst soweit sein alles aus den kisten herauszuholen. das war so beim comodore 64 (das war mal n computer und heute n schlechter taschenrechner ) und bei so ziemlich allen consolen. beim c64 hat man erst herausbekommen was der kann als der schon lange totgesagt war, doch steuern selbst heute noch diese kisten lichtanlagen und ändere sachen. bei den consolen war es bisher natürlich nicht so drastisch, aber wenn man sich die spiele die z.b. für die psx herauskamen in chronologischer reihenfolge anschaut sieht man auch das die spiele immer besser aussahen wenn die programmierer gelernt haben mit der vorhandenen hardware umzugehen. bevor ihr mich anschreit das ich keine ahnung habe, gebe ich es zu. ich weiss auch das die komponenten erstmal theoretisch ausgelotet werden was sie in der regel schaffen sollten bevor sie dann auch in produktion gehen. das damit einhergehende wahre potenzial unterscheidet sich mittlerweile nicht mehr so stark vom theoretischen, aber es ist noch nie etwas herausgekommen (glaube ich) was es verdient hat so verrissen zu werden wie es derzeit die konsolen werden. lasst uns erstmal schaun was wirklich dahinter steckt. die programmierer haben, denke ich, schon recht genaue vorstellungen was die consolen können, sonst würden sie die xbox360 und die ps3 so links liegen lassen wie den gamecube. der war übrigens nicht schlecht von der leistung her, sondern nur sehr umständlich zu programmieren, wie die dreamcast damals auch.


grz


cpushreder

Wenn man sich nun dieses Ingamevideo(HDTV) anschaut, könnte man meinen, daß die reine Grafikqualität/Renderleistung die aktuellen Desktopsysteme nicht gerade übertrifft.

die leute programmieren doch immer noch für die sdk-kisten und nicht für die reinen konsolen und es ist doch allgemein bekannt, daß die ersten spiele für eine konsole noch bei weitem nicht dem potential der konsole entsprechen (vergleich mal gt3 und gt4)

Die Optimierung der Software läuft bei den Konsolen-CPUs in 2 Bereichen ab:

1. Optimierung eines Threads für die Ausführung auf einem Kern (auch SPE)
2. Optimierung der gesamten Software in Bezug auf möglichst gute Ausnutzung der Mehrkernigkeit

1. ist (im Vergleich zum Itanium) recht trivial, da durch fehlende OOO-Ausführung, geringere Zahl von parallel ausführbaren Befehlen und generell einfacherer Prozessorarchitektur es leichter ist, einen recht guten Code dafür zu erzeugen (man denke nur an den GCC DFA Scheduler). Nur die SIMD-Einheiten bedürfen natürlich vektorisierender Compiler (wenn z.B. für 3D-/Physik-Berechnungen keine vorhandenen OS-/Bibliotheks-Funktionen genutzt werden können), wofür es aber auch langzeitige Compiler-Entwicklungserfahrung mit Vektorisierung allgemein gibt (von Vektorprozessoren über RISC-CPUs mit SIMD-Erweiterungen zu 3DNow!, SSEn und AltiVec).

2. ist der wirklich komplexe Punkt, aber hierfür gibt es wenigstens schon die Erfahrung aus mehreren Jahrzehnten bei der Arbeit mit Mehrprozessorsystemen (und etwas anderes sind die Multicores ja auch nicht).

Und schließlich hängt die Leistung der meisten Konsolenspiele von einem Großteil an Algorithmen ab, welche nicht ständig neu geschrieben werden müssen, sondern im Konsolen-OS oder in Form von Bibliotheken bereitgestellt werden. Diese sind dann schon für ihre Aufgaben optimiert (an vielen Stellen wohl auch per Hand).

Die spezifische Logik einzelner Games macht dann den größten Teil dessen aus, was noch zu optimieren wäre und dafür sollte genügend Roh-Leistung vorhanden sein, um zumindest einen flüssigen Spielablauf (falls z.B. der AI-Code tatsächlich länger brauchen sollte, als das Berechnen der Szenerie) zu ermöglichen.

Selbst seltener auf Konsolen anzutreffende Spielgenres wie Strategiespiele (z.B. HOI2) könnten trotz ungeeigneter Einzelkerne noch genügend Leistung innerhalb der gesamten Konsolen-CPU finden. Schließlich sind gerade solche Spiele vom Prinzip her gut in mehrere Threads aufteilbar (z.B. AI, Economy Engine, User Interface).

Und die nun für die Konsolen verwendeten CPUs sind wohl kaum die Hauptpunkte auf der Suche nach eventuellen Beschränkungen bei Spielen, da dazu v.a. auch Grafikleistung/-speicher, Speichermenge/-geschwindigkeit, aufgebrachter Entwicklungsaufwand (Qualität von Texturen, Objekten, Levels, AI u.a. Programmcode) zählen.

Schließlich wird ein geschriebener Text einer Sekretärin mit Hauptschul-Durchschnitt 3,7 auch nicht besser, wenn man einen Dual-Core-PC vor ihre Nase stellt Genausowenig könnte dieser eine umfangreiche 3D-Welt wie bei Farcry auf einer ET4000-Karte flüssig darstellen *g*

http://www.golem.de/0507/39524.html

Als ein Highlight der Siggraph 2005 in Los Angeles zeigt das Team der Saarbrücker Informatik den ersten Prototypen
von Echtzeit-Raytracing auf dem neuen und auch in der PlayStation 3 zum Einsatz kommenden Cell-Prozessor.
In einer sehr kurzen Entwicklungszeit von nur zwei Wochen wurden die
Raytracing-Algorithmen für den neuen Hochleistungsprozessor in Zusammenarbeit mit IBM Deutschland völlig überarbeitet.
Schon mit einem einzelnen Cell-Prozessor sollen Echtzeit-Bildraten bei voller Bildschirmauflösung erreicht werden.

Ok, die hatten dann natürlich keine Zeit bei planet3dnow mal die Wahnvorstellungen zum CELL zu korrigieren.

Der Cell schafft also das gleiche, wie der doch recht konventionell getaktete FPGA? (ok, ein klein wenig besser iser schon).
Klingt für mich eher nach unseren Wahnvorstellungen, als nach deinen realistischen Einschätzungen.

Dresdenboy schrieb:

aus diesem Posting

Die Optimierung der Software läuft bei den Konsolen-CPUs in 2 Bereichen ab:

1. Optimierung eines Threads für die Ausführung auf einem Kern (auch SPE)
2. Optimierung der gesamten Software in Bezug auf möglichst gute Ausnutzung der Mehrkernigkeit

1. ist (im Vergleich zum Itanium) recht trivial, da durch fehlende OOO-Ausführung, geringere Zahl von parallel ausführbaren Befehlen und generell einfacherer Prozessorarchitektur es leichter ist, einen recht guten Code dafür zu erzeugen (man denke nur an den GCC DFA Scheduler).

Zum Vergrößern anklicken....

Wieso ist das auf dem Itanium schwerer, als auf dem modifizierten PPC-Core?

Ist mir neu, das man nun ernsthaft Äpfel mir Birnen vergleichen kann.

Der Cell Prozessor hat doch eine völlig andere Architektur als ein P4 oder A64. Von daher sollte man den Artikel wohl nicht ernst nehmen, wenn das alles so einfach ist warum ist das z.b heute kein PC mit aktueller Hardware eine sogesehen langsamere PS-2 zu emulieren. Dann steckt eben noch ein wenig mehr dahinter.

Zidane schrieb:

aus diesem Posting

Ist mir neu, das man nun ernsthaft Äpfel mir Birnen vergleichen kann.

Der Cell Prozessor hat doch eine völlig andere Architektur als ein P4 oder A64. Von daher sollte man den Artikel wohl nicht ernst nehmen, wenn das alles so einfach ist warum ist das z.b heute kein PC mit aktueller Hardware eine sogesehen langsamere PS-2 zu emulieren. Dann steckt eben noch ein wenig mehr dahinter.

Zum Vergrößern anklicken....

Bist du dir sicher, dass das nicht, möglich wäre ?
Ich mir nicht so. Ich denke durchaus, dass der PC imstande ist die Playstation 2 zu emulieren.
Denk mal an die Anfänge von der EMU Szene bei der Playstation 1 was da noch für Hardware gab und da lief es schon einigermaßen flüssig.
Und denk mal was hier heute für eine Hardware haben und vor allem wie lange schon die PS2 auf dem Markt ist, da sollte die Playstation 2 in sachen EMU kein Problem darstellen.
Vor allem wenn man von Hyperthreading und 64 Bit Befehlen gebrauch nehmen kann.
Und jetzt die Dual Core Prozzis.
Es fehlt nur der richtige Emulator mit dem optimalen Code der ebenhalt auch von den Features gebrauch nimmt.
Bei dem PS 1 Emu wird mir voll schlecht wenn ich die Blockade nicht einschalten würde, dann würde ich keine Filmsequenzen und keine Ingame Grafik sehen, weil das so davon rauscht und man beachte das mit allten Plugins die nur directx7 verwenden.

das thema ps2 emulation hatten wir schon oft, die ps2 architektur ist absolut nicht mit der von der ps1 zu vergleichen, denn die emotion engine besitzt so viele eigenheiten (sehr kleiner lvl2 cache und vektoreinheiten), die die programmierer zu sehr vielen "tricks" zwingen und diese zu emulieren, ist extrem schwer

es gibt zwar emulatoren, aber die können kaum etwas emulieren und sind dabei saulangsam

PuckPoltergeist schrieb:

aus diesem Posting

Wieso ist das auf dem Itanium schwerer, als auf dem modifizierten PPC-Core?

Zum Vergrößern anklicken....

Daß Optimierung für den Itanium an sich schwer ist, hast du ja weiter vorn schon selbst bestätigt. Aber auch die Antwort auf die Differenz, die ich hier anspreche, gibst du schon teilweise selbst: Der PPC-Core wurde modifiziert - und zwar vereinfacht: kein OOO, 2-way-issue, also Pentium-Niveau, allerdings mit effektiverer RISC-Architektur.

Das heißt wiederum, daß ein Compiler sich nicht um parallele Ausführung mehrerer Loop-Iterationen, conditional execution (mit sehr vielen Prädikat-Registern), 8 Sprungregister, aufgeteilte Speicherlade-Operationen (erst LD, später CHK vor der Verwendung), optimale Befehlsgruppierung (ohne zuviele NOPs) usw. kümmern muß, was beim Itanium notwendig ist. Die Aktionen des vereinfachten PPC-Cores sind wesentlich besser vorhersagbar (deshalb mein Verweis auf den DFA Scheduler), damit ist auch guter Code leichter zusammenzustellen.

Und die Nachteile, die durch in-order-execution wieder eingebracht wurden, werden wieder durch SMT ausgeglichen (was es in dieser Kombination noch nicht gab), da dann ein Speicherzugriff, Sprung oder einfach ein wartender Befehl (in einer dependency chain), nicht zum Komplettstillstand führen, sondern in der Zeit der andere Thread mehr Chancen für die Nutzung der CPU-Ressourcen bekommt.

Wie ich schon schrieb, ist der schwierigere Teil bei den Konsolen-CPUs das Ausnutzen der vielen Kerne (v.a., wenn das automatisch geschehen soll), was ich aber deutlich von meinem Punkt 1 getrennt habe.

Dresdenboy:

Du meinst also, auf Grund der Anzahl der Ausführungseinheiten, auf die der Scheduler verteilen muss, ist es einfacher optimierten Code für den TriCore-PPC zu erstellen, als für den Itanium? Oder habe ich dich jetzt vollkommen falsch verstanden?

PuckPoltergeist schrieb:

Du meinst also, auf Grund der Anzahl der Ausführungseinheiten, auf die der Scheduler verteilen muss, ist es einfacher optimierten Code für den TriCore-PPC zu erstellen, als für den Itanium? Oder habe ich dich jetzt vollkommen falsch verstanden?

Zum Vergrößern anklicken....

Nein, ich hatte das nach Optimierung des Codes eines einzelnen Threads (mein Punkt 1) und Optimierung der Core-Ausnutzung (Punkt 2) getrennt. Das meiste, was ich schrieb, bezog sich auf Punkt 1 und die Möglichkeiten dort. Die automatische Optimierung für mehrere Cores ist nicht so trivial, deswegen hatte ich das gleich auf die Programmierer abgewälzt

Dresdenboy schrieb:

aus diesem Posting

Nein, ich hatte das nach Optimierung des Codes eines einzelnen Threads (mein Punkt 1) und Optimierung der Core-Ausnutzung (Punkt 2) getrennt. Das meiste, was ich schrieb, bezog sich auf Punkt 1 und die Möglichkeiten dort.

Zum Vergrößern anklicken....

Logisch, steht ja auch so da. Lesen müsste man können.

Die automatische Optimierung für mehrere Cores ist nicht so trivial, deswegen hatte ich das gleich auf die Programmierer abgewälzt

Zum Vergrößern anklicken....

Na, schämst du dich nicht, die armen Programmierer so zu quälen?

PuckPoltergeist schrieb:

Na, schämst du dich nicht, die armen Programmierer so zu quälen?

Zum Vergrößern anklicken....

Ich quäle die Spieleprogrammierer mit weniger aufwändiger Multithreading-Entwicklung, um die Compilerprogrammierer davon zu bewahren, sich umfangreich damit beschäftigen zu müssen Ich darf das außerdem, weil ich selbst einer bin *g*

Ich könnte mir das Brainstorming zu einer guten Verteilung der Aufgaben auf die vorhandenen Ressourcen sogar als interessant und spaßbehaftet vorstellen

Ich kann mir auch vorstellen, daß es Unterstützung in Form von Erweiterungen/Bibliotheken/neuer Compiler-Direktiven geben wird.

Übrigens beschäftigte sich ein kürzlich von Intel zu AMD gewechselter µP-Architektur-Experte in seiner Entwicklungslaufbahn schon mit multiskalaren Prozessoren, die selbst mehrere Mikro-Threads aus einem Code-Strom extrahieren können.

Dresdenboy schrieb:

aus diesem Posting
Übrigens beschäftigte sich ein kürzlich von Intel zu AMD gewechselter µP-Architektur-Experte in seiner Entwicklungslaufbahn schon mit multiskalaren Prozessoren, die selbst mehrere Mikro-Threads aus einem Code-Strom extrahieren können.

Zum Vergrößern anklicken....

Könnte dann zukünftig in der CPU zur Laufzeit entschieden werden, ob mehrere Mikro-Threads einfach linear abgearbeitet werden oder in weiteren CPU-Cores (in Hardware oder virtuelle Cores) parallel abgearbeitet werden ?

rkinet schrieb:

Könnte dann zukünftig in der CPU zur Laufzeit entschieden werden, ob mehrere Mikro-Threads einfach linear abgearbeitet werden oder in weiteren CPU-Cores (in Hardware oder virtuelle Cores) parallel abgearbeitet werden ?

Zum Vergrößern anklicken....

So etwa. Die Mikro-Threads selber werden festgestellt (so etwas ginge gut mit Trace Caches - zu diesen wurde kürzlich ein AMD Patent veröffentlicht) und auf Mikrocores ausgeführt (ähnlich den Ausführungseinheiten jetzt, nur in größerer Zahl und u.U. geclustert).

Zu den Arbeiten von Scott Breach kannst du dich hier belesen. Diese sind alle unabh. von AMD (und wohl auch Intel) entstanden, könnten aber ein Grund für den Wechsel zu AMD sein (an den schon vorhandenen Ergebnissen aus seiner Forschung sollten die Fähigkeiten deutlich genug zu erkennen sein).

http://www.heise.de/newsticker/meldung/62391

3D-Modeling-Software unterstützt Ageias Physik-Prozessor

Zumindest Sony greift ja auf das Software-Design ebenfalls zu und dürfte einen brauchbare Umsetzung für den Cell entworfen haben.

-----

UND bei der XBox 360 :

XNA Technology Map

Sieht auf den ersten Blick eigentlich so aus, als wären da viele Aufgaben parallelisierbar.
Teils sicherlich in GraKa und Audio-Hardware, vieles aber auch im Tricore.






aus: http://www.the-inquirer.com/?article=25066

http://www.heise.de/newsticker/meldung/62391



Die Ageia-Typen machen zum richtigen Zeitpunkt dir richtigen Kooperationen.
Ich bin mir sicher, das sie das PhysX-SDK für einen Appel und ein Ei lizensiert haben - nur um einen Fuß in die Tür zu bekommen.

Analog zur früheren Software-OpenGL-Implementierung muss zuerst eine Software-Basis geschaffen werden. Und die schlechtesten Performer werden der Cell und der Xenon nicht sein - massive Parallelisierung sei dank.

Ob die Optimierung der Ageia-dll Ageia selbst macht wage ich zu bezweifeln. Microsoft programmiert auch nicht Direct3d-Treiber für ATI.

Ageia wird eine Art Referenzimplementierung an Microsoft/Sony geben und diese kümmern sich dann um die Optimierung.

Zusätzlich dazu kann jetzt auch noch in der Modelling-Software Physik hineingelegt werden.
Zum Beispiel lässt sich via Makros im Softimage gleich inverse Kinematik implementieren:
Man zieht an einem Hebel in der Bagger-Fahrerkabine, ein Hubzylinder setzt sich in Bewegung und der Baggerarm bewegt sich nach oben. Via Export lässt sich dies dann gleich so in die Engine integrieren.

Grüße,
Tom

Ein frischer Artikel zu Cell:
http://www.realworldtech.com/page.cfm?ArticleID=RWT072405191325

Im zugehörigen Thread kam die Idee auf, daß die PPE sich von der Größe her ja nicht so sehr von den SPEs unterscheidet und man doch auch einen Prozessor mit viel mehr PPEs (also nicht nur 3) bauen könnte. Das würde zumindest der DP FP-Leistung auf die Sprünge helfen, aber auch Kompromisse beim Speichersubsystem inkl. der L2-Caches erfordern, da man dann wohl auf Cache-Koherenz in Teilen verzichten sollte, um den damit verbundenen Verkehr zu vermeiden. Geregelt werden könnte dies z.B. durch Core-weise reservierte Speicherbereiche oder aktive Cache-Steuerung (also wieder ein ähnlicher Aufwand, wie bei den lokalen SRAM-Arrays der SPEs).

http://www.golem.de/0508/39913.html

Die 'Stink-Box 360' im Budget Preisniveau und gleichzeitig guter Grafik.
Mehr dann die nächsten Tage, wenn die Spiele/ die Konsole live zu sehen sind.



---
http://www.theregister.co.uk/2005/08/17/toshiba_mep_h1/


Der Cell, noch so ne 'lahme Ente':
Toshiba also said this week it had developed a Cell companion chip which connects directly to the processor's chip-to-chip bus and provides hardware decoding for up to 48 separate standard-resolution video streams

Packt doch locker auch ein Celeron 733, oder

rkinet schrieb:

aus diesem Posting

http://www.theregister.co.uk/2005/08/17/toshiba_mep_h1/


Der Cell, noch so ne 'lahme Ente':
Toshiba also said this week it had developed a Cell companion chip which connects directly to the processor's chip-to-chip bus and provides hardware decoding for up to 48 separate standard-resolution video streams

Zum Vergrößern anklicken....

Und was hat das mit dem Cell zu tun? Ach ja, bestimmt der Teil:
"Curiously, that's also the role that Toshiba has in mind for the Cell processor, which it co-developed with Sony and IBM. Sony, of course, wants Cell for PlayStation 3, but it too has said it plans to build the chip into future consumer electronics product."

Packt doch locker auch ein Celeron 733, oder

Zum Vergrößern anklicken....

Klar, wenn der Dekoder-Chip dem System zur Verfügung steht. Was ist daran so lustig?

PuckPoltergeist schrieb:

aus diesem Posting
Und was hat das mit dem Cell zu tun? Ach ja, bestimmt der Teil:
"Curiously, that's also the role that Toshiba has in mind for the Cell processor, which it co-developed with Sony and IBM. Sony, of course, wants Cell for PlayStation 3, but it too has said it plans to build the chip into future consumer electronics product."

Zum Vergrößern anklicken....

Ein extra Media-Prozessor, weshalb ?
Wäre die Meldung bei eetimes.com o.ä. erschienen, wäre der Preis dabei gestanden.
So ein Media-Prozessor wird etwas den einstelligen Dollar/ Stück Preis übersteigen bei 10.000 Stück Abnahme.
Da wird der Cell noch länger das 2-5 fache kosten ...


Zum Hardware-Zusatz bzgl. video-streams:
Diese Hardware führt mit großer Wahrscheinlichkeit die ADC/Sync Konvertierung durch und einige elementare sonstige Konvertierungen der Daten.
Der Cell aber dann den großen Rest an Berechnungen mit der Hilfe der SPUs - daher eben auch die Anbindung an den 45/33 GByte/s Bus des Cell
(s. http://www.the-cell-chip.de/wiki/index.php?title=Technik)


Bem: Der Cell ist eben moderner CPU-Bau für die 65nm ff. Ära;
aber Intel wird ja auch was an viel besserer Performance (im Vergleich zu Netburst oder SC-P-M) in Kürze nachreichen.

rkinet schrieb:

aus diesem Posting

Ein extra Media-Prozessor, weshalb ?
Wäre die Meldung bei eetimes.com o.ä. erschienen, wäre der Preis dabei gestanden.
So ein Media-Prozessor wird etwas den einstelligen Dollar/ Stück Preis übersteigen bei 10.000 Stück Abnahme.
Da wird der Cell noch länger das 2-5 fache kosten ...


Zum Hardware-Zusatz bzgl. video-streams:
Diese Hardware führt mit großer Wahrscheinlichkeit die ADC/Sync Konvertierung durch und einige elementare sonstige Konvertierungen der Daten.
Der Cell aber dann den großen Rest an Berechnungen mit der Hilfe der SPUs - daher eben auch die Anbindung an den 45/33 GByte/s Bus des Cell
(s. http://www.the-cell-chip.de/wiki/index.php?title=Technik)

Zum Vergrößern anklicken....

Erklär mir mal den Sinn von diesen Zeilen. Und erklär mir bei dieser Gelegenheit auch gleich noch, wieso der Cell einen extra Chip zu Dekodierung von Videostreams benötigt. Immerhin soll er doch 1000mal leistungsfähiger sein, als heutige PC-CPUs. Ich meine, ob mein PC (Opteron 144, sprich 1.8GHz) 48 Streams gleichzeitig dekodieren kann, weiß ich nicht. Für 5 gleichzeitig reichts aber locker, das braucht nicht mal 25% der CPU-Leistung. Und da der Cell ja so viel leistungsfähiger sein soll, ist der Faktor 10 wohl kein Problem für ihn, oder?

PuckPoltergeist schrieb:

aus diesem Posting
Erklär mir mal den Sinn von diesen Zeilen.

Und erklär mir bei dieser Gelegenheit auch gleich noch, wieso der Cell einen extra Chip zu Dekodierung von Videostreams benötigt.

Zum Vergrößern anklicken....

Jenseits der heilen Chipsatz Desktopwelt wird heute höchste Performance maßgeschneidert für industrielle und Consumer Elektronik gebraucht - zu möglichst niedrigen Preisen. Daher ist der Cell eben nur ein Baustein von vielen - wenn weniger Performance nötig ist, werden einfachere und preiswertere Designs verwendet.

Eine Media-CPU für ca. $10-$20 oder ein Cell für ca. $35-$99 - das sind gewaltige Unterschiede für viele Anwendungen. Auch benötigt eine 1 GHz Media-CPU auch deutlich weniger Strom / weniger Aufwand bei der Stromversorgung.


Extra Chip bei Video ?
Nun, man muss die analogen Signale erst digitalisieren, vielleicht noch in Bandbreitenschonendere Formate umwandeln.
Allerdings sind bei 48 Kanälen ca. 7 GByte/s max. beim Cell abzuliefern, was der chip-to-chip Bus aber schon packen könnte.
Es bleibt noch genügend Arbeit für den Cell übrig ...