Playstation 4: Kommt Sonys neue Konsole noch Weihnachten 2013?
- Ersteller PCGH-Redaktion
- Erstellt am
Dafür ja der Interposer, TSVs und stacked RAM. Ich denke Sony wird das ganz klug abwägen. Sowas wie bei der PS3 werden die nicht noch mal durchziehen, also einfach irgendeiner Fantasie hinterher rennen ohne dabei auf die Kosten zu schauen.
Ausserdem sind Spielereien wie Kinect ein absolutes must-have. Sollte Sony nur mit Dualshock4 launchen, dann werden die sicher ordentlich auf die Schnauze fliegen. Die müssen irgendwas cooles, irgendwas neues bieten und das kostet je nach dem auch nen ganzen Batzen Geld.
Ich denke nicht das Sony die maximal mögliche Leistung um jeden Preis anstrebt, sondern eine Konsole bauen will, die in jeder Beziehung überzeugen kann.
Ausserdem sind Spielereien wie Kinect ein absolutes must-have. Sollte Sony nur mit Dualshock4 launchen, dann werden die sicher ordentlich auf die Schnauze fliegen. Die müssen irgendwas cooles, irgendwas neues bieten und das kostet je nach dem auch nen ganzen Batzen Geld.
Ich denke nicht das Sony die maximal mögliche Leistung um jeden Preis anstrebt, sondern eine Konsole bauen will, die in jeder Beziehung überzeugen kann.
Zuletzt bearbeitet:
Locuza
Lötkolbengott/-göttin
Ich sehe kaum einen triftigen Grund wieso ich an die CPU nicht eine dicke GPU dranflanschen sollte.
Die Verbindungslogik sollte grob die gleiche sein und unbekannt ist weder die CPU- noch GPU-Architektur, man sollte bei AMD halbwegs verlässlich voraussagen können, wie gut sich so etwas fertigen lässt.
Die Vorteile sind ja zahlreich.
Keine Verbindungslogik zwischen APU und GPU, keine 2 "kleinen" Hotspots, sondern nur ein großer, der somit auch leichter zu kühlen wäre, das ganze wäre effizienter.
Der Programmierer kann bei der GPU dynamisch alle seine Ressourcen einteilen und muss nicht das Zeug synchronisiert laufen lassen oder schauen wie viel die IGPU noch packt usw.
Die Verbindungslogik sollte grob die gleiche sein und unbekannt ist weder die CPU- noch GPU-Architektur, man sollte bei AMD halbwegs verlässlich voraussagen können, wie gut sich so etwas fertigen lässt.
Die Vorteile sind ja zahlreich.
Keine Verbindungslogik zwischen APU und GPU, keine 2 "kleinen" Hotspots, sondern nur ein großer, der somit auch leichter zu kühlen wäre, das ganze wäre effizienter.
Der Programmierer kann bei der GPU dynamisch alle seine Ressourcen einteilen und muss nicht das Zeug synchronisiert laufen lassen oder schauen wie viel die IGPU noch packt usw.
Es gibt da sehr wohl zwei Probleme: Zum einen die Yields und zum anderen das HSA Featureset. Ein Paperlaunch ist das schlimmste was einer Konsole passieren kann, vor allem zum Weihnachtsgeschäft und ob AMD in der Lage ist, dass vollständige HSA Featureset in die PS4 zu bauen, wissen wir auch nicht.
Eine Single-APU Lösung mit vollständigem HSA Featureset ist sicher anzustreben, aber ob das bis Ende 2013 realisierbar ist?
Eine Single-APU Lösung mit vollständigem HSA Featureset ist sicher anzustreben, aber ob das bis Ende 2013 realisierbar ist?
Locuza
Lötkolbengott/-göttin
Es zwingt sie auch niemand "nur" mit einer fetten APU alle Features implantieren zu müssen.
Schlechte Yields wären natürlich sehr bitter, wenn das der Grund ist wieso man eine elegante Lösung in zwei Teile splittet.
Der einzige richtige Miesepeter könnte 28nm Bulk sein. 32nm SOI sollte zufriedenstellend laufen und immerhin hat man früher immer so schön behauptet das 28nm Bulk ganz leicht umzusetzen wäre, wobei bis heute glaube ich kein Produkt für den Massenmarkt dort von Band gelaufen ist.
Schlechte Yields wären natürlich sehr bitter, wenn das der Grund ist wieso man eine elegante Lösung in zwei Teile splittet.
Der einzige richtige Miesepeter könnte 28nm Bulk sein. 32nm SOI sollte zufriedenstellend laufen und immerhin hat man früher immer so schön behauptet das 28nm Bulk ganz leicht umzusetzen wäre, wobei bis heute glaube ich kein Produkt für den Massenmarkt dort von Band gelaufen ist.
Hier, ich poste es gerne noch mal (Seite 13 und Seite 20): GPGPU algorithms in games
Wenn in der PS4 keine 4th Gen HSA zum Einsatz kommt sondern eine 3rd Gen HSA, dann kann GPGPU mit einer einzelnen APU nicht in dem Maße genutzt werden wie mit der Kombination aus APU und dedizierte GPU. Der Leistungsvorteile durch den einzelnen Chip wäre dahin.
Entweder man hat eine dicke APU mit Graphics Pre-Emption und Context-Switching, also Features, die erst für die HD9000er Volcanic Islands Architektur angedacht sind, oder man nutzt die HD8000er Sea Islands Architektur mit einer Kombination aus APU und dedizierter GPU, dann hat man den gleichen Effekt.
Wenn in der PS4 keine 4th Gen HSA zum Einsatz kommt sondern eine 3rd Gen HSA, dann kann GPGPU mit einer einzelnen APU nicht in dem Maße genutzt werden wie mit der Kombination aus APU und dedizierte GPU. Der Leistungsvorteile durch den einzelnen Chip wäre dahin.
Entweder man hat eine dicke APU mit Graphics Pre-Emption und Context-Switching, also Features, die erst für die HD9000er Volcanic Islands Architektur angedacht sind, oder man nutzt die HD8000er Sea Islands Architektur mit einer Kombination aus APU und dedizierter GPU, dann hat man den gleichen Effekt.
Locuza
Lötkolbengott/-göttin
Hevioso ich kann die Slides mittlerweile nicht mehr sehen.
3rd Generation sollte das ganze als APU sicherstellen und die vierte Generation sollte das auch mit einer dedizierten ermöglichen.
Die Features zu realisieren ist auf einer APU viel leichter, als die Northbridge und die Controller noch an eine dedizierte GPU zu führen.
Pre-emption ist ein Hardware Feature, dass ist keine Sachen die man per "Kombination" "emulieren" kann bzw. erreichen.
3rd Generation sollte das ganze als APU sicherstellen und die vierte Generation sollte das auch mit einer dedizierten ermöglichen.
Die Features zu realisieren ist auf einer APU viel leichter, als die Northbridge und die Controller noch an eine dedizierte GPU zu führen.
Pre-emption ist ein Hardware Feature, dass ist keine Sachen die man per "Kombination" "emulieren" kann bzw. erreichen.
Zuletzt bearbeitet:
Ich glaube du verstehst mich immer noch nicht:
Es geht nicht um Emulation, sondern um die Tatsache, dass die iGPs der ersten, zweiten und dritten HSA Generation in Videospielen nicht die GPGPU Leistung abliefern können wie eine iGP der vierten HSA Generation, weil diese iGPs nicht über die dafür so wichtigen Features Graphics Pre-Emption und Context Switching verfügen. Die vierte HSA Generation ist GPU-seitig aber 20nm Volcanic Islands und ob sowas Ende 2013 in einer PS4 stecken wird, darf man doch ernsthaft bezweifeln.
AMD nennt als (anscheinend) ebenbürtige Alternative die Verwendung einer APU der dritten HSA Generation zusammen mit einer dedizierten Grafik (AMD nennt ausserdem die Ähnlichkeiten zur PS3 und empfiehlt dieses Setup für Hardcore Gaming). Deine Argumentation, dass ein einzelne APU schneller sei als APU+GPU gilt daher nur unter der Vorraussetzung, dass die einzelne APU eine Grafik der vierten HSA Generation (= 22nm HD9000) beinhaltet. Tut sie das nicht, ist die APU+GPU Lösung die schnellere.
Der Sinn hinter der HSA ist, wie der Begriff "heterogen" bereits sagt, die Verwendung von unterschiedlichen Recheneinheiten je nach Einsatzgebiet. Im diesem Fall sind das die x86-Kerne für laufzeitintensive Tasks und die Streamprozessoren für GPGPU. Um den maximalen Nutzen aus dieser Architektur zu ziehen, muss man GPGPU also auch ohne Verlust in Videospielen anwenden können und das geht nur mit einer 4th Gen HSA APU oder mit APU+GPU der 3rd Gen HSA. Ich wollte dir nur noch mal klar machen, dass Sony auf das 20nm Volcanic Islands Featureset zurückgreifen müsste, damit deine Argumentation (eine große, schnelle APU) zutrifft.
Es geht nicht um Emulation, sondern um die Tatsache, dass die iGPs der ersten, zweiten und dritten HSA Generation in Videospielen nicht die GPGPU Leistung abliefern können wie eine iGP der vierten HSA Generation, weil diese iGPs nicht über die dafür so wichtigen Features Graphics Pre-Emption und Context Switching verfügen. Die vierte HSA Generation ist GPU-seitig aber 20nm Volcanic Islands und ob sowas Ende 2013 in einer PS4 stecken wird, darf man doch ernsthaft bezweifeln.
AMD nennt als (anscheinend) ebenbürtige Alternative die Verwendung einer APU der dritten HSA Generation zusammen mit einer dedizierten Grafik (AMD nennt ausserdem die Ähnlichkeiten zur PS3 und empfiehlt dieses Setup für Hardcore Gaming). Deine Argumentation, dass ein einzelne APU schneller sei als APU+GPU gilt daher nur unter der Vorraussetzung, dass die einzelne APU eine Grafik der vierten HSA Generation (= 22nm HD9000) beinhaltet. Tut sie das nicht, ist die APU+GPU Lösung die schnellere.
Der Sinn hinter der HSA ist, wie der Begriff "heterogen" bereits sagt, die Verwendung von unterschiedlichen Recheneinheiten je nach Einsatzgebiet. Im diesem Fall sind das die x86-Kerne für laufzeitintensive Tasks und die Streamprozessoren für GPGPU. Um den maximalen Nutzen aus dieser Architektur zu ziehen, muss man GPGPU also auch ohne Verlust in Videospielen anwenden können und das geht nur mit einer 4th Gen HSA APU oder mit APU+GPU der 3rd Gen HSA. Ich wollte dir nur noch mal klar machen, dass Sony auf das 20nm Volcanic Islands Featureset zurückgreifen müsste, damit deine Argumentation (eine große, schnelle APU) zutrifft.
Locuza
Lötkolbengott/-göttin
Emulation war das Wort was ich gefunden habe, für deine Annahme das man mit IGPU+DGPU mehr für HSA vorgesehene Features erreicht, als nur mit einer APU was nicht unbedingt stimmen muss.
GCN ist schon heute in der Lage Context-Switching zu vollführen, dass erledigen die ACEs, AMD sagt bloß nicht aus wie viele Tasks damit von den CUs bearbeitet werden können, wenn die Anzahl limitiert ist, dann könnte AMD hier auch problemlos Sony "einfach" in die GPU mehr ACEs verbauen.
Nvidia schafft auch Grafik und PhysX auch auf einer einzelnen Grafikkarte mit annehmbarer Performance zu berechnen.
Ich würde mich auch von der Idee fernhalten von der Roadmap alles direkt auf irgendeine bestimmte Technologie ableiten zu müssen.
AMD kann hier nur ihre APUs meinen oder notwendige Treiber für das direkte Ansprechen für irgendwelche Hardwarefähigkeiten, um allgemein Software beschleunigen zu können oder anzupassen. Wohl möglich ist genau so einfach der PC-Markt gemeint, wo auf einer Konsole Treiber und DX nicht limitieren und der Programmierer die Hardware mehr oder weniger direkt ansprechen könnte.
Es wird ja auch kaum verraten wie man das direkt realisieren möchte und was dafür notwendig ist.
GCN ist schon heute in der Lage Context-Switching zu vollführen, dass erledigen die ACEs, AMD sagt bloß nicht aus wie viele Tasks damit von den CUs bearbeitet werden können, wenn die Anzahl limitiert ist, dann könnte AMD hier auch problemlos Sony "einfach" in die GPU mehr ACEs verbauen.
Nvidia schafft auch Grafik und PhysX auch auf einer einzelnen Grafikkarte mit annehmbarer Performance zu berechnen.
Ich würde mich auch von der Idee fernhalten von der Roadmap alles direkt auf irgendeine bestimmte Technologie ableiten zu müssen.
AMD kann hier nur ihre APUs meinen oder notwendige Treiber für das direkte Ansprechen für irgendwelche Hardwarefähigkeiten, um allgemein Software beschleunigen zu können oder anzupassen. Wohl möglich ist genau so einfach der PC-Markt gemeint, wo auf einer Konsole Treiber und DX nicht limitieren und der Programmierer die Hardware mehr oder weniger direkt ansprechen könnte.
Es wird ja auch kaum verraten wie man das direkt realisieren möchte und was dafür notwendig ist.
Zuletzt bearbeitet:
Es geht nicht darum was man kann und was nicht. Man kann auch heute schon GPGPU in Videospielen nutzen, siehe Direct Compute in zahlreichen DX11 Spielen, und das mit Hardware von AMD und von Nvidia. In der Präsentation geht es ausschließlich darum, wie man die maximale GPGPU-Performance in Videospielen erreicht ohne das man dabei Abstriche bei der Grafikrendering Performance machen muss und hier empfiehlt AMD explizit eine Kombination aus APU (für GPGPU) und GPU (für Grafikrendering), sofern man keine 4th Gen HSA APU hat.
Natürlich sind Lösungen möglich, bei denen AMD in die Zukunft greift, aber die hierfür benötigten HSA Features sind ziemlich weit entfert und auf 2014/2015 terminiert. Solche Custom-Chips, die aufgrund 32/28nm Fertigung zusätzlich auch noch riesengroß werden und schlechte Yields liefern, halte ich einfach für sehr, sehr unwahrscheinlich. Zumindest für einen 2013 Release kann man das ausschließen.
Release 2013: HSA APU der dritten Generation + dedizierte GPU
Release 2014: große HSA APU der vierten Generation
Natürlich sind Lösungen möglich, bei denen AMD in die Zukunft greift, aber die hierfür benötigten HSA Features sind ziemlich weit entfert und auf 2014/2015 terminiert. Solche Custom-Chips, die aufgrund 32/28nm Fertigung zusätzlich auch noch riesengroß werden und schlechte Yields liefern, halte ich einfach für sehr, sehr unwahrscheinlich. Zumindest für einen 2013 Release kann man das ausschließen.
Release 2013: HSA APU der dritten Generation + dedizierte GPU
Release 2014: große HSA APU der vierten Generation
Locuza
Lötkolbengott/-göttin
Explizit steht da wohl nur bei dir etwas.
Es steht dort als erweiterte Möglichkeit, was man mit der APU anfangen könnte.
Diese Möglichkeiten würde auch schon Pitcairn liefern können, wenn man general compute von den Shadern per ACE übernimmt und den Rest für die Grafik reserviert.
Wo ist der Unterschied das von einer IGPU zu übernehmen, außer das die Abstufungen mit der zusätzlichen GPU wohl weniger flexibler wären.
Die ACEs verbrauchen auch wenig die-size, falls mehr davon benötigt werden.
Es steht dort als erweiterte Möglichkeit, was man mit der APU anfangen könnte.
Diese Möglichkeiten würde auch schon Pitcairn liefern können, wenn man general compute von den Shadern per ACE übernimmt und den Rest für die Grafik reserviert.
Wo ist der Unterschied das von einer IGPU zu übernehmen, außer das die Abstufungen mit der zusätzlichen GPU wohl weniger flexibler wären.
Die ACEs verbrauchen auch wenig die-size, falls mehr davon benötigt werden.
beercarrier
Software-Overclocker(in)
würd auch gern noch was in den pot werfen, meine prognose ist, das der limitierende faktor für die ps4 die caches für die instruktionen werden, vorallem bei einer apu+gpu variante. eine reine apu variante halte ich für unwahrscheinlich da dort die x86 kerne extrem beschnitten werden müssten, größer als eine hd7000 bei 28nm wird die-fläche bestimmt nicht was ca 350mm² entspricht, und da passen nunmal keine 2 vollwertigen module sowie ausreichend shader hinein.
Locuza
Lötkolbengott/-göttin
Pitcairn ist bei 28nm gate last bei TSMC ~212 mm² groß
Gate First soll einen Flächenvorteil gegenüber gate last haben, da ich aber der Meinung bin dass GloFo eh nichts auf die Reihe bekommt, schätze ich eher ungefähr das gleiche Ergebnis.
Trinity mit 2 Modulen ist bei 32nm 246mm² groß, grob 40% verschlingt die CPU was ungefähr 100mm² sind.
Das alles auf 350mm² bei 28nm ist machbar, vor allem da man an den Controllern und anderen Sachen gut abspecken kann.
Die Xbox 360 hat zum Beispiel beim Launch für die Einheiten so viel gebraucht:
CPU: 176mm2
GPU: 182mm²
EDRAM (+Back-End?): 80mm²
Alles zusammen: 438mm² die-size Verbrauch.
Bei GloFo ist aber ein Bulldozer mit 4 Modulen und ~300mm² aber auch das größte was vom Band läuft.
Wenn ein gemeinsames Ding aus Yield-Gründen nicht in Betracht gezogen wird, dann sehe ich auch eher eine klassische Bauweise vor mir.
2 Module + z.B. 7750 ~200mm² + Pitcairn ~200mm² sehe ich als oversized an und hätte weitere Anforderungen an die Verbindungslogik.
Aber auszuschließen ist es nicht unbedingt, mich würde es aber überraschen.
Gate First soll einen Flächenvorteil gegenüber gate last haben, da ich aber der Meinung bin dass GloFo eh nichts auf die Reihe bekommt, schätze ich eher ungefähr das gleiche Ergebnis.
Trinity mit 2 Modulen ist bei 32nm 246mm² groß, grob 40% verschlingt die CPU was ungefähr 100mm² sind.
Das alles auf 350mm² bei 28nm ist machbar, vor allem da man an den Controllern und anderen Sachen gut abspecken kann.
Die Xbox 360 hat zum Beispiel beim Launch für die Einheiten so viel gebraucht:
CPU: 176mm2
GPU: 182mm²
EDRAM (+Back-End?): 80mm²
Alles zusammen: 438mm² die-size Verbrauch.
Bei GloFo ist aber ein Bulldozer mit 4 Modulen und ~300mm² aber auch das größte was vom Band läuft.
Wenn ein gemeinsames Ding aus Yield-Gründen nicht in Betracht gezogen wird, dann sehe ich auch eher eine klassische Bauweise vor mir.
2 Module + z.B. 7750 ~200mm² + Pitcairn ~200mm² sehe ich als oversized an und hätte weitere Anforderungen an die Verbindungslogik.
Aber auszuschließen ist es nicht unbedingt, mich würde es aber überraschen.
beercarrier
Software-Overclocker(in)
joah hab da ein fehler drin. steamroler war glaub ich für die nächste box angedacht aber da wär dann zumindest eine fpu mehr. wäre die anbindung von apu und gpu nicht ein modifizierter controller-hub?
aber bei 2 dies könnte man wirklich so ziemlich alles nehmen was so vom band läuft, einfach zugunsten der tpd ein paar schader abschalten die speicheranbindung verringern und die taktzahl senken, gut der ram wird teurer, aber die stückzahlen könnten das ausgleichen und in einer späteren slim revision könnte man einen soc designen.
aber bei 2 dies könnte man wirklich so ziemlich alles nehmen was so vom band läuft, einfach zugunsten der tpd ein paar schader abschalten die speicheranbindung verringern und die taktzahl senken, gut der ram wird teurer, aber die stückzahlen könnten das ausgleichen und in einer späteren slim revision könnte man einen soc designen.
Zuletzt bearbeitet:
Locuza
Lötkolbengott/-göttin
Ich glaube nicht das Steamroller größer ist, als Bulldozer bzw. Piledriver.
Steamroller hat auch keine 2 FPUs pro Modul, wobei bei einem Custom-Ding man das natürlich machen könnte.
Das mit der Verbindung wäre natürlich interessant, da muss ja auch die Kommunikation untereinander mit viel Durchsatz geschehen, da müssen viele Lanes zueinander geführt werden, dann muss das alles mit der South und Northbridge irgendwie gesteuert werden, die CPU und GPU untereinander kommunizieren usw.
Keine Ahnung wie das später genau realisiert werden soll.
Am PC hat AMD das durch die IOMMU im Chipsatz lösen wollen, welche schon seit längerem verbaut wird, bei Trinity findet sich Version 2.0.
Ab Kaveri hätte es dann wohl auch sogar funktioniert.
Für eine Konsole bieten sich hier ja ganz andere Möglichkeiten das zu lösen.
Auch hier lasse ich mich gerne überraschen.
Steamroller hat auch keine 2 FPUs pro Modul, wobei bei einem Custom-Ding man das natürlich machen könnte.
Das mit der Verbindung wäre natürlich interessant, da muss ja auch die Kommunikation untereinander mit viel Durchsatz geschehen, da müssen viele Lanes zueinander geführt werden, dann muss das alles mit der South und Northbridge irgendwie gesteuert werden, die CPU und GPU untereinander kommunizieren usw.
Keine Ahnung wie das später genau realisiert werden soll.
Am PC hat AMD das durch die IOMMU im Chipsatz lösen wollen, welche schon seit längerem verbaut wird, bei Trinity findet sich Version 2.0.
Ab Kaveri hätte es dann wohl auch sogar funktioniert.
Für eine Konsole bieten sich hier ja ganz andere Möglichkeiten das zu lösen.
Auch hier lasse ich mich gerne überraschen.
beercarrier
Software-Overclocker(in)
sry bin auch echt nicht mehr ganz fit. steamroller 2 decoder pro fpu, iwie so. is für heute dann auch mein letzter beitrag.das mit der verbindung interessiert mich aber auch, ohne den hsa-teil hätte ja crossfire oder oder eine art sli bridge gereicht. so muss ja auf fast alle cpu komponenten zugegriffen werden was mir imm so erscheint als bräuchte es einen extremen last level cache ring cache um apu und gpu, aber irgendwie kein plan wie das funktionieren soll. am ehesten könnte ich mir noch einen co prozessor wie zu 386 486 zeiten denken der prioritäten managment und cache zuweißung übernimmt, aber der macht das ganze ja auch nicht unaufwendiger, ansonsten muss man die anbindung ja soweit ausbauen das ein großteil der in fragmenten berechneten daten extrem schnell zum jeweiligen ort verschoben werden und dann im llc wieder zussamengefügt werden kann, denn ansonsten bremst es sich doch selber aus soweit ich das richtig verstanden habe?
Ähnliche Themen
