PS-Nachfolge: Sony setzt auf AMD - nur was steckt drin?

Wie schon erwähnt, ist das etwas, was GCN so jeher theoretisch bietet - bei GCN1 wurden aber nur zwei ACEs mit je einem Queue verbaut, wie viele es bei GCN2 sind, ist offen. So gesehen ist es nach aktuellem Stand custom, es gilt GCN2 abzuwarten.
 
Wie gesagt, die erwähnten Sachen sehen nicht nach etwas total neuem aus.
Im C.I PDF waren 8 ACEs mit je 8 Schlangen aufgeführt.
Den volatile tag sollte schon GCN1 haben und der bypass hört sich nach genau dem an, was auch Llano und Trinity schon haben oder Kaveri in seiner Form haben wird.
Generell wird nicht direkt verglichen und häufig liest es sich so, als würde man AMDs APUs gerade ausklammern, ebenso hat Intel ja auch "APUs" im Angebot mit gemeinsamen LLC, so etwas kann ja auch einige Cache-Inhalte teilen.
Wirkt eher wie bisschen Marketing Blabla, verglichen mit einem klassischem PC-System.
 
Locuza schrieb:
FGCN 2 hat laut PDF 8 ACEs, wobei jeder 8-Queues verschicken kann.
Zum Vergrößern anklicken....
Na wenn das stimmt ist das ein deutlicher Unterschied zu GCN2.
@Locuza
Hast du einen Link zu diesem PDF?

Laut der Beschreibung der ACE bei GCN hier bei Anand:
http://www.anandtech.com/show/4455/amds-graphics-core-next-preview-amd-architects-for-compute/5
scheint es nicht unbedingt automatisch Vorteile zu bringen die Anzahl der ACEs von 2 auf 8 zu erhöhen. Andererseits hat der PS4 Chip ja reichlich CUs um massiv zu parelellisieren und muss auch nicht mit Strom haushalten. Es fragt sich ob Spiele Code tatsächlich so massiv paralell programmierbar ist, da mehr ACEs nur dann sinnvoll sind. Ein Queue von 64 hingegen verbessert das optimieren von Multithreading und hilft der in-Order Architektur von GCN beim reordering der Befehle und bringt sie näher an die Effizienz von OoO Architekturen, trotz vieler paraleller CUs.
 
Locuza schrieb:
Den volatile tag sollte schon GCN1 haben und der bypass hört sich nach genau dem an, was auch Llano und Trinity schon haben oder Kaveri in seiner Form haben wird.
Zum Vergrößern anklicken....
Also wenn du den Bypass mit Onion (aka FCL) oder Garlic (aka RMB) gleichsetzt liegst du falsch.

Siehe: http://amddevcentral.com/afds/assets/presentations/1004_final.pdf
Seite 4

Der Fusion Controll Link (FCL/Onion) ermöglicht der GPU im CPU Cache zu lesen
Der Radeom Memory Bus (RMB/Garlic) ist nicht koherent und liest direkt aus dem RAM mit zusätzlichen 12 MB/s Bandbreite zur normalen DDR-Bandbreite (Seite 27)

Alleine die 20 MB/s sind eine Verbesserung, und könnten einen verbesserten RMB bedeuten der einfach aufgebohrt ist. Allerdings hat man diese Bandbreite bisher nicht sinnvoll zum schreiben in den RAM genutzt, da der Zugriff der CPU auf den RAM, und dort geschriebene Daten, deutlich langsamer als auf den Cache ist. Hier werden CPU-affine Daten besser mit den FCL geschickt und in den Cache geschrieben.

Folgende Tabelle zeigt die gemessenen Geschwindigkeiten bei Llano:
attachment.php


Nun darf man nicht vegessen dass es keinen Local memory mehr gibt bei einer Unified Memory Architektur, und somit auch hier die Datenraten schneller werden. Im Prinzip fällt die Spalte "UNcached" weg und es gibt nur noch Local und Cachable.

Fazit:
Ich denke, dass hier durchaus ein zusätzlicher Bus mit 20 MB/s zum Einsatz kommt der eben die reinen Compute Daten, die ja unabhängig von der Grafikberechnung paralell stattfinden sollen, hier transportiert.
 
1. Die PDF hat AMD runter genommen, weil sie nicht sauber getrennt haben.
Aber hier ein Zitat von der Stelle:

Important differences between S.I. and C.I. GPUs

•Multi queue compute
Lets multiple user-level queues of compute workloads be bound to the device and processed simultaneous. Hardware supports up to eight compute pipelines with up to eight queues bound to each pipeline.
•System unified addressing
Allows GPU access to process coherent address space.
•Device unified addressing
Lets a kernel view LDS and video memory as a single addressable memory. It also adds shader instructions, which provide access to “flat” memory space.
•Memory address watch
Lets a shader determine if a region of memory has been accessed.
•Conditional debug
Adds the ability to execute or skip a section of code based on state bits under control of debugger software. This feature adds two bits of state to each wavefront; these bits are initialized by the state register values set by the debugger, and they can be used in conditional branch instructions to skip or execute debug-only code in the kernel.
•Support for unaligned memory accesses
•Detection and reporting of violations in memory accesses

Summary of kernel instruction change from S.I. to C.I.


New instruction formats:
•FLAT

New instructions:
•FLAT_* (entire family of operations)
•S_CBRANCH_CDBGUSER
•S_CBRANCH_CDBGSYS
•S_CBRANCH_CDBGSYS_OR_USER
•S_CBRANCH_CDBGSYS_AND_USER
•S_DCACHE_INV_VOL
•V_TRUNC_F64
•V_CEIL_F64
•V_FLOOR_F64
•V_RNDNE_F64

AMD SEA ISLANDS SE R IES TECHNOLOGY
xiv Preface
Copyright © 2013 Advanced Micro Devices, Inc. All rights reserved.
•V_QSAD_PK_U16_U8
•V_MQSAD_U16_U8
•V_MQSAD_U32_U8
•V_MAD_U64_U32
•V_MAD_I64_I32
•V_EXP_LEGACY_F32
•V_LOG_LEGACY_F32
•DS_NOP
•DS_GWS_SEMA_RELEASE_ALL
•DS_WRAP_RTN_B32
•DS_CNDXCHG32_RTN_B64
•DS_WRITE_B96
•DS_WRITE_B128
•DS_CONDXCHG32_RTN_B128
•DS_READ_B96
•DS_READ_B128
•BUFFER_LOAD_DWORDX3
•BUFFER_STORE_DWORDX3

Removed instructions:
•V_QSAD_U8
•V_MQSAD_U8
•BUFFER_ATOMIC_RSUB, _X2
•IMAGE_ATOMIC_RSUB, _X2
Zum Vergrößern anklicken....

Dazu addieren wir noch vgleaks Infos, die meinen die PS4 hätte 8 Compute Pipelines mit je 8 Queues pro Pipeline und das ganze ist einfach GCN1.1 oder GCN2, you name it.

http://www.vgleaks.com/orbis-gpu-compute-queues-and-pipelines/

Custom scheint wie gesagt der HP3D Command-Processor zu sein.

2. Ich setze das ganze System der PS4 nicht gleich mit Llano oder Trinity, aber der Grundaufbau ist aus meiner Sicht gleich und halt wie bei Kaveri erweitert/verbessert.
Ich erwarte geringe Unterschiede beim Vergleich PS4 vs. Kaveri.

Goto hat mal gezeichnet:
Trinity:
http://pc.watch.impress.co.jp/img/pcw/docs/591/173/html/13.jpg.html

PS4:
http://pc.watch.impress.co.jp/img/pcw/docs/596/857/html/04.png.html

Übrigens hat ja BSN geleaked, dass bei Kaveri der Onion/FCL auf 256-Bit erweitert wurde, also kann man bei Kaveri bei diesem Bus eine theoretisch doppelt so hohe Bandbreite erwarten oder irgendwo in der Richtung.
 
Danke für die Links.
Kaveri hat aber keine Jaguar Cores wie Kabini und die PS4. Ich denke du verwechselst diese beiden Codenamen.

Dein vgleaks Link schreibt auch 10 piplines mit 64 queue.
Diese seinen aufgeteilt in 8 pipelines mit je 8 queues nur für compute, 1 Gfx ring und pipeline für Grafik und Compute und eine HP3D ring und pipeline die nur Grafik kann.

Ich weiss nicht ob das wirklich Sinn ergibt so viel Compute Bandbreite im Verhältnis zu GPU Rechenleistung zur Verfügung zu stellen bei einer Konsole. Mal gespannt ob das die Jaguar Kerne so stark unterstützen kann damit diese Desktop CPUs egalisieren. Das würde aber auch heissen, dass Code von der PS4 nicht so leicht portiert werden kann auf PCs wie bisher angenommen. Ausser AMDs GPUs/APUs bekommen hier eine kleine "DNA-Transplantation". Doch das ist recht viel Computing Ressource für Desktops, die ja teilweise schnelle Intel CPUs oder FX-CPUs verbaut haben, welche ja ihre vorhandenen Ressourcen noch gar nicht abrufen können mit derzeitigem Code.
 
Mir ging es nur um den FCL, ich weiß das Kaveri Steamroller-Kerne hat.
War im Kontext auch nicht von Belang, da es um den "speziellen Bus" ging und ich meine, dass bei Kaveri das gleich oder ähnlich aufgebaut sein wird.

/

Beispiel Tahiti:
Der Command-Processor erstellt Work-Groups für Graphics- und Compute-Shader,
die zwei ACEs können allerdings unabhängig davon, Compute Work-Groups erstellen und damit den effektiven Durchsatz stark erhöhen, der GFX-Code muss glaube ich pausiert werden, falls man Compute-Code durchschleusen will bzw. maximale compute-performance haben will.
Jedenfalls ist es dank ACEs möglich simultan Compute- und GFX-Code laufen zu lassen, ohne gibt es Konflikte oder Pausen.
ACEs sind am PC bisher nutzlos, keine API zum ansprechen.
HyperQ von Nvidia ist ähnlich, da kann die CPU dann dank der Grid-Managment-Units auch mehr Calls parallel abarbeiten, da es sonst seriell übertragen wird.
Performance Faktor bei irgend einer Anwendung war glaube ich Faktor 2-3 besser mit dem Feature.

Die PS4 wird jetzt 8 Compute-Pipelines haben, also kann auch jeder Jaguar-Core die Compute-Calls an jede Compute-Pipeline schicken.
Noch einmal flexibler und mehr gleichzeitig.
Zusätzlich zum komplexen Command-Processor von Tahiti der beide Aufgaben erledigen kann, gibt es bei Liverpool einen GFX-Ring (HP3D) der nur sich um Grafik-Verwaltung kümmert und deren Calls eine höhere Priorität genießen, die vom OS kommen, hilft dann wohl beim Overlay.

Die ganzen "Pipelines" (Compute-Pipeline/GFX-Pipeline) haben ja nichts mit Rechenkernen zu tun, sondern fördern die Verwaltung, indem parallel mehr adressiert werden kann an die Rechenwerke.
Am PC kommt der Code dann halt in einer Linie, bzw. der Command-Processor muss alles erledigen.

Da AMD das bei C.I angegeben hat, eben dieses up to 8, was vielleicht auch nur beim Tahiti-Nachfolger zum Einsatz kommt, wäre es schon nicht schlecht, wenn es mal eine API zu programmieren der Einheiten gebe.
Also ein OpenCL-Pfad sollte dann schon stehen.
Aber PS4-Gaming Code wird wahrscheinlich nicht gewinnbringend bei AMDs GCN1.1 portiert werden können.
 
Locuza schrieb:
Mir ging es nur um den FCL, ich weiß das Kaveri Steamroller-Kerne hat.
Zum Vergrößern anklicken....
Ja aber gerade FCL greift auf den Cache zu und ist kein bypass direkt in den RAM. Wenn dann kommt nur der RMB in Frage.
.
EDIT :
.
Siehe
Complicated schrieb:
Siehe: http://amddevcentral.com/afds/assets/presentations/1004_final.pdf
Seite 4

Der Fusion Controll Link (FCL/Onion) ermöglicht der GPU im CPU Cache zu lesen
Der Radeom Memory Bus (RMB/Garlic) ist nicht koherent und liest direkt aus dem RAM mit zusätzlichen 12 MB/s Bandbreite zur normalen DDR-Bandbreite (Seite 27)
Zum Vergrößern anklicken....
 
y33H@ schrieb:
Ist wohl eher so, dass AMD für Sony die GCN2 vorgegriffen hat, denn weder n ACEs noch n Queues pro ACE ist wirklich neu - beide hat AMD schon 2011 in der Präsentation von GCN in den Slides als möglich eingezeichnet. Sony hat vermutlich einfach gesagt, japp, wollen wir.
Zum Vergrößern anklicken....

...oder AMD hats mit Blick auf und in Absprache mit Sony, eventuell sogar mit entsprechenden Schutzfristen, ins Design eingebracht.
 
Interessant finde ich diese Aussage aus dem Link:
Alternativ hätte man laut Cerny auch nur 128 Datenleitungen in Verbindung mit einem zusätzlichen, extrem schnellen eDRAM für den Framebuffer nutzen können; das wäre einfacher zu produzieren, hätte jedoch den Programmieraufwand für Entwickler erhöht.
Zum Vergrößern anklicken....
Heisst das hier muss Software extra für den kommenden eDRAM auf Intels Haswell CPUs angepasst werden?
 
Markus Everson schrieb:
...oder AMD hats mit Blick auf und in Absprache mit Sony, eventuell sogar mit entsprechenden Schutzfristen, ins Design eingebracht.
Zum Vergrößern anklicken....
Würde ich nicht vermuten, GCN war laut AMD Aussage das erste Design das in starker Gemeinschaft mit ATI und AMD Ingenieuren entstand.
Wann wurde daran herum gemacht 2006/2007?
Irgendwo habe ich mal eine Jahresangabe gelesen.
Es sieht eher so aus, als ob Sony und MS preisgünstige Lösungen von AMDs Baukasten bestellt haben.
Würde mich eher wundern, wenn es bei irgendwelchen Hardware-Features im CPU/GPU-Design ein spezielles Feature geben würde, welches in Kooperation mit Sony entstand.
Außer jetzt so Custom-Zeug wie second-chip, HP3D Command-Processor in der GPU usw.
 
@Markus
Ich denke er meint, ob man für Haswells-GPU im PC-Bereich extra (im Sinne von ausschließlich für Haswell) programmieren muss, um die zusätzliche Bandbreite auch in mehr Bilder pro Sekunde bei den Spielen umzusetzen.

Dass man bei einer Konsole immer extra programmieren wird, um das Maximum herauszuholen sollte klar sein. Dagegen ist es ja im PC-Bereich eine gewisse Standardisierung, die dafür sorgt, dass wir überhaupt von PCs sprechen.

128MB Cache frisst ein modernes Spiel ja schon vor dem Frühstück. Viel vorhalten kann man da nicht und dann muss man wahrscheinlich ganz bewusst festlegen, was in den Cache soll und was nicht.
ist der eDRAM bei Haswell eigentlich nur für die GPU oder für CPU und GPU gemeinsam?
 
hmm laut dem Konferenzcall sollte das wohl die Software bestimmen können:
http://www.heise.de/newsticker/meld...rgieeffizienz-fuer-Kaveri-und-Co-1850975.html
Außerdem sei hUMA kompatibel zu embedded DRAM, wie er etwa in Spielekonsolen genutzt wird: er lässt sich in den gemeinsamen Speicherbereich einblenden oder als Cache einbinden.
Zum Vergrößern anklicken....
Aber wie es scheint eben mit zusätzlichem Programmieraufwand. würde heissen Software die für PS4 geschrieben wird, müsste eine zusätzliche Portierung für die Nutzung der eDRAMs in Haswell durchlaufen, die für AMDs APUs nicht notwendig wäre.
.
EDIT :
.
Markus Everson schrieb:
Ja, die Software einer auf Haswell basierenden Spielekonsole müssten extra auf Haswell zugeschnitten werden. Überrascht?
Zum Vergrößern anklicken....
Du solltest erst einen zweiten Kaffe trinken vor dem schreiben ;)
Es geht um Portierungen von PS4 zu PC
 
isigrim schrieb:
@Markus
Ich denke er meint, ob man für Haswells-GPU im PC-Bereich extra (im Sinne von ausschließlich für Haswell) programmieren muss, um die zusätzliche Bandbreite auch in mehr Bilder pro Sekunde bei den Spielen umzusetzen.
Zum Vergrößern anklicken....

So hab ichs auch verstanden. Ich sehe nur nicht wo der Unterschied liegen soll zwischen

extra (im Sinne von ausschließlich für [...]) programmieren [...] um die zusätzliche Bandbreite auch in mehr Bilder pro Sekunde bei den Spielen umzusetzen
Zum Vergrößern anklicken....
und
extra programmieren [...] um das Maximum herauszuholen
Zum Vergrößern anklicken....

Das ist das selbe in grün.

eine gewisse Standardisierung, die dafür sorgt, dass wir überhaupt von PCs sprechen
Zum Vergrößern anklicken....

betrifft dagegen den kleinsten gemeinsamen Nenner. Der ist zwar immer größer geworden, aber immer noch der kgN. Betrachte in Gedanken Programme für AMDs APUs vs. Programme für Haswell, vielleicht verdeutlicht das was ich meine.
.
EDIT :
.
Complicated schrieb:
Du solltest erst einen zweiten Kaffe trinken vor dem schreiben ;)
Zum Vergrößern anklicken....

Das kann nie schaden ;-)

Es geht um Portierungen von PS4 zu PC
Zum Vergrößern anklicken....

Na im Kontext war aber doch klar das es um Programme geht die auf die Eigenheiten einer Architektur eingehen. Haswell kann natürlich "normale" Programme/Shader ausführen, Intel kann sich keinen Bruch mit der x86 Kompatiblität leisten nachdem sie mit der Itanic so fürchterlich aufs Maul bekommen haben. Aber Haswell so wie jeder andere Prozessor von Intel vorher und jede CPU und APU von AMD wird natürlich mehr, teilweise deutlich mehr, Leistung bringen wenn die Programme an seine Besonderheiten angepasst werden. Ich wiederhole also (nach dem ungefähr 8ten Kaffee): Überrascht Dich das etwa?
 
Ist denn auch klar, was Sony für ein Betriebssytem in der PS4 drin hat?

Die Diskussion beschränkt sich in diesem Thread (zu sehr) auf die AMD Hardware - ein Teil der Funktionalität von AMDs integrierter APU-Hardware liegt ja auch in dem genutztem OS und deren Ökosystem.

Neben den NDAs erklärt das auch gewisse Lücken zur HSA-Verschwiegenheit zur PS4.

MFG Bobo(2013)
 
Markus Everson schrieb:
Na im Kontext war aber doch klar das es um Programme geht die auf die Eigenheiten einer Architektur eingehen. Haswell kann natürlich "normale" Programme/Shader ausführen, Intel kann sich keinen Bruch mit der x86 Kompatiblität leisten nachdem sie mit der Itanic so fürchterlich aufs Maul bekommen haben. Aber Haswell so wie jeder andere Prozessor von Intel vorher und jede CPU und APU von AMD wird natürlich mehr, teilweise deutlich mehr, Leistung bringen wenn die Programme an seine Besonderheiten angepasst werden. Ich wiederhole also (nach dem ungefähr 8ten Kaffee): Überrascht Dich das etwa?
Zum Vergrößern anklicken....
Es ging ja lediglich um den Mehraufwand der Programmierung bei Verwendung von stacked eDRAM. Den benutzt ja Haswell. Sony hat sich bewusst dagegen entschieden aus diesem Grund laut Interview von Herrn Cerny:
http://www.gamasutra.com/view/feature/191007/inside_the_playstation_4_with_mark_.php?page=1
"One thing we could have done is drop it down to 128-bit bus, which would drop the bandwidth to 88 gigabytes per second, and then have eDRAM on chip to bring the performance back up again," said Cerny. While that solution initially looked appealing to the team due to its ease of manufacturability, it was abandoned thanks to the complexity it would add for developers. "We did not want to create some kind of puzzle that the development community would have to solve in order to create their games. And so we stayed true to the philosophy of unified memory."

In fact, said Cerny, when he toured development studios asking what they wanted from the PlayStation 4, the "largest piece of feedback that we got is they wanted unified memory."
Zum Vergrößern anklicken....
Hier stellt sich eben die Frage ob anstatt wie bisher eine einheitliche Portierung für den x86-PC, Intels Haswells wegen dem eDRAM noch zusätzliche Anpassungen erfordert um daraus überhaupt Nutzen zu ziehen. Wäre dem so, würde der eDRAM für Intel basierenden Gaming-PC keinen zusätzlichen Nutzen bringen.
 
Wir drehen uns im Kreis. Ich habe Deine Frage genau so verstanden wie Du sie eben nochmal wiederholt hast und ich stehe dazu das die Antwort meiner Meinung nach zu genau dieser Frage passt.
 
Also irgendwie blick ich es grade nicht. Es ging um diesen Satz von dir:
Markus Everson schrieb:
Ja, die Software einer auf Haswell basierenden Spielekonsole müssten extra auf Haswell zugeschnitten werden. Überrascht?
Zum Vergrößern anklicken....
Welche Spielkonsole auf Haswellbasis?

Die Software wird vorher auf AMD basierende Spielkonsolen optimiert. Dannach wird portiert auf den PC. Nun kommt mit Haswell der erste Chip mit eDRAM.
Sony wollte keine eDRAM basierende Konsole wegen dem erhöhten Entwicklungsaufwand.
Erstmals sind AMD und Intel, trotz gemeinsamer x86 Architektur, deutlich andere Konzepte gefahren in Hardware, abseits der Unterschiede in Instruktionen.
Dies wird IMHO dazu führen, dass eDRAM keine Berücksichtigung finden wird bei der Optimierung für den PC.
 
Kommt halt immer darauf an, ob es sich für die Entwickler rentiert. Vorerst werden Prozessoren mit eDRAM eine untergeordnete Rolle spielen werden. Sollte sich der Ansatz aber bei Intel breit durchsetzen, dann könnte das durchaus dazu führen, dass die Spieleentwickler gerne den Aufwand betreiben und optimieren. Leibt abwzuwarten, wie sich der Markt da weiterentwickelt.

Das Gute für AMD ist aber nun einerseits, dass durch die PS4 (und vielleicht auch für die nächste XBox) HSA und GPGPU deutlich attraktiver für die Entwickler werden, was genau AMDs Strategie entspricht, nicht aber der von Intel (weil dadurch die x86-Performance an Relevanz verliert).
Andererseits dürfte die breite Unterstützung für die HSA-Foundation auch dafür sorgen, dass das Konzept eines breit angebundenen einheitlichen Hauptspeichers auch im Bereich ARM eher genutzt wird, als L4-Cache-artiger eDRAM vor dem Hauptspeicher.

Hier sollte auch mal erwähnt werden, dass die vielen Kritiker der Nutzung von eDRAM bei AMD, die erwähnt hatten, dass das für den Fusion-Ansatz hinderlich wäre, bestätigt werden.
 
Das Sony-Männchen erklärte im Interview die Design Entscheidungen für seine Konsole. Ein Bestandteil dieser Entscheidungen war das die Entwickler sich wünschen auf solche Schweinereien wie spezielles RAM zu verzichten weil sie Klimmzüge machen müssen um daraus das maximum an leistung raus zu holen.
Im Gegensatz dazu

a) die X86-Welt verwendet generelle Treiber die "Schweinereien wie spezielles RAM" für die einzelne Anwendung unsichtbar machen, dabei aber einen Teil der Leistung verschenken
b) Main RAM mit ausreichender Bandbreite macht "Schweinereien wie spezielles RAM" überflüssig

Jetzt klar? Natürlich muss sich Intel beim Treiber und im Compiler um die Eigenheiten des Haswell kümmern. Aber in einem Feld-Wald-Wiesen-Lapotop bei weitem nicht so intensiv wie das in einer Spielekonsole notwendig wäre.

Und nun der Bogen: Genau das gleiche Problem hat AMD. Seine Treiber abstrahieren die Eigenschaften des FX soweit das jeder PC damit einigermaßen schnell ist. Um näher an das Maximum heran zu kommen muss der Entwickler aber trotzdem wieder Aufwand treiben und sein Programm speziell an FX und seine Eigenheiten anpassen.

Ist nun klarer was ich meine? Hab ich mir meinen dritten Kaffee verdient?
 
Wie kommt man überhaupt auf den schmalen Ast, das sich das die Entwickler extra um irgendwelche Intelfaxen kümmern müssen, wenn es doch schon auf x86 vor optimiert ist und läuft?
 
Zurück
Oben Unten