AMD APUs (Strix Halo, Strix Point, Hawk Point, Phoenix, Rembrandt, Cezanne, Renoir, Mendocino)

naja, Cache ist ein "dummes" Stück Silizium, kostengünstig zu produzieren aber effektiv. Klarerweise muss ich gleichzeitig sagen, Anbindung, Nutzung,... muss auch berücksichtigt werden (hebt des Kostenvorteil zumindest teilweise wieder auf....)
 
"dummes" Stück Silizium, kostengünstig zu produzieren aber effektiv. Klarerweise muss ich gleichzeitig sagen, Anbindung, Nutzung,
Ohne den zweiten Teil ist der Cache in der Tat ziemlich ueberfluessig wieso vieles in einer CPU. }
Aufbau, Verwaltung und Anbindung sind die Zutaten, die es braucht IMHO.

Gruss,
TNT
 
Frage mich wieso AMD den 3D-IF$ so schön bei den 3D-APUs und 3D-CPUs einbaut und so geizt bei den dGPUs?

Bei den dGPUs gab's ne starke Regression:
6900XT 128MB -> 7900XTX 96MB
6800XT 128MB -> 7900XT 80MB
6800 128MB -> 7900GRE 64MB
6700XT 96MB -> 7800XT 64MB
6700 80MB -> 7700XT 48MB

Anscheinend wurde der IF$ nur leistungskritisch für die APUs und CPUs gesehen: 5800X -> 5800X3D, 7700X -> 7800X3D, 7900X -> 7900X3D use.

Bei den dGPUs gab's gar keine Reaktion mit dem 3D-IF$. Wurde komplett vernachlässigt.

Im APU Bereich scheinen 16MB zu 32MB IF$ extrem effizient und lukrativ zu sein.

Im High-End Bereich anscheinend nicht, deswegen der harte IF$-Cut im dGPUs Bereich von 128MB auf 96MB bzw. dafür VRAM Bandbreite erhöht von 512GB/s auf 960GB/s (6900XT -> 7900XTX).

80CU / 128MB -> 1CU / 1,6MB
96CU / 96MB -> 1CU / 1MB

Auf dem ersten Blick sieht man nicht viel, nur 32MB cut. Aber tiefer reingeschaut sind das +60% IF$ pro CU für RDNA2 dGPUs ggü. RDNA3 uArch.

Der Erfolg für CPUs und APUs durch den IF$ schlug im High-End dGPU Bereich nicht durch, auch weil AMD den harten IF$ Cut machte für die MCM-Fertigung.
 
Meines Wissens hat AMD die Bandbreite vom Cache verdoppelt, daher hat man unterm Strich trotzdem 50% höhere Datenrate bei den 7000ern.

Interessant wäre dahingehend auch wie stark sich SAM hier auswirkt. Da kenne ich keine Benchmarks..
 
Bei Navi21 taktet der Fclk mit 1940Mhz bis 2000Mhz.
Die 16 Kanäle mal 64 mal Fclk:
16 * 64 * 1940Mhz ~ 1984,56 GB /s Bandbreite für die Radeon W6800 (Navi21 XL).
16 * 64 * 2000Mhz ~ 2048,00 GB/s
1024 byte / Clk bei RDNA2 IF$.

Geworben wird auch mit 2,17x Fachen Bandbreite im Vergleich zu einem klassischen 384bit SI ohne IF$.

"AMD Infiinity Cache
A revolutionary new memory level in RDNA 2 architecture. 128mb of AMD Infinity Cache enables high bandwidth performance at low power and low latency, with 2.17x the bandwidth/power compared to 384-bit GDDR6."


512bit SI GDDR6 20GBps ohne IF$ ~ 1024 GB/s bei höherem Wattverbrauch.
384bit SI GDDR6 20GBps ohne IF$ ~ 768 GB/s bei gleichem Wattverbrauch.
256bit SI GDDR6 20GBps mit 128MB IF$ ~ 1666 GB/s bei gleichem Wattverbrauch.

Bei Navi31 sind es nach AMD 3,5 TB/s, wovon 2,5 TB/s auf den IF$ fallen Plus 960GB/s Bandbreite vom VRAM. Allerdings auch mit hungrigen 384bit SI.

Der Sprung von 1,66 TB/s effektive Bandbreite auf 3,5 TB/s effektive Bandbreite sind +100%, aber eben auch höherem Energieverbrauch und damit Verbunden schlechtere Hitrates.

Das theoretisch. Der Effizienzsprung von 7nm auf 5nm bei den CUs wurde aufgefressen vom cut des IF$ und Ausweitung des SI. Dafür wurde wieder Fläche (Silizium/Geld) eingespart. 520mm Chip auf 304mm^2 GCD.

Man merkt bei RDNA3 das Korsett schon stark, insbesondere bei begrenztem Budged von 999 USD Verkaufspreis.

Für 100 USD mehr hätte AMD durchaus eine 7900XTX-3D bringen können als Sonderedition mit 192MB, drei 8xPin Strom und 2,8-2,9Ghz Shader-Takt und 3,2-3,4Ghz CP-Takt.

Die wäre noch viel Näher an der Konkurrenz gewesen als die OEM Sparversion mit 355W 2x8Pin Version, die durch den niedrigen Energiebudged auf 2,3-2,5Ghz limitiert ist.

Erst die 192MB Version mit ~3,0Ghz kulmulierten Takt hätte der Konkurrenz tiefe Stiche versetzt und dem technologischen Vorsprung von AMD aufgezeigt.

So im engen Korsett muss die sehr gute RDNA3 uArch (Annahme ~3Ghz, ~192MB IF$) wieder den Umweg über die APUs (u.a. PS5-Pro) und iGPUs gehen um in den Volume-Markt zu kommen.

Die alten von ATI hätten sofort die 192MB und 3,0-3,2Ghz bei 450-500W gebaut und jedes Mhz, sowie 4nm mitgenommen. Also RX 7950XTX "refresh" wie einst 1900XTX zu X1950XTX oder X800XT zu X850XT.

Bei AMD bissel viel Funkstille seit 2022 Stagnation im dGPU.

Nicht dass ich APUs nicht geil finde, aber am Desktop gibs für mich nur dGPUs und CPUs, wo AMD ja u.a mit dem 5800X3D, 7800X3D, 9800X3D quasi das Gaming-Monopol hat bei den CPUs.

Stagnation bei den dGPUs seit 2022 führt halt auch zum massiven Marktverlust. Das ist zwar nicht schlimm mit Blick auf den MI300X im HPC / KI und deren Verkäufen aktuell.

Für den harten 3D-Core und Gaming-Rechner Typen wie mich aber schon hart anzusehen wie der dGPU Markt von der miesen (überteuerten) Konkurrenz dominiert wird.
 
Bitte nicht den 3D Cache der CPUs mit dem Infinity Cache der GPUs gleich setzen denn das führt zu nichts.
Weder wäre es sinnvoll ihn auf die GPU zu stacken (Höhenunterschied, Verschlechterung der Wärmeableitung), noch hätte er die erforderliche Bandbreite. Am Ende bleibt nur die Erweiterung des Infinity Cache übrig damit dieser mehr Daten speichern könnte und die Frage wieviel davon überhaupt für eine Leistungssteigerung benötigt würde denn was darüber hinaus geht bringt primär nur noch Kosten.
Alles Fragen die wir nicht beantworten können.
 
Wir wissen nur, dass AMD sich bei den CPUs sich gerne den billigen IF$ bedient um auch die low-Core Dies zu pimpen: 5600X3D, 7600X3D, 7900X3D. Alles 6C (8C physisch) Dies. Dafür werden nur minimal Takt geopfert. In reinem Compute bringt das nichts, aber in Cache intensiven Single-Core Apps (wie viele Spiele) bringt das viel.

Bei den GPUs (auch für Spiele) trotz höherem Energiebudged geschah dies nicht.

Bei der APU mit 40CU RDNA3? Strix Halo samt 16C/32T CPU ist der IF$ womöglich kohärent zum IF$ der dGPUs als "unified IF$".

Vielleicht schafft AMD mit der Strix Halo APU + Navi31 XTX dGPUs einen größeren "unified IF$", sozusagen über die APU gesteuert virtuelle zu schaffen.
96MB + 32MB = 128MB schafft deutlich bessere Hitrates für 4k @ 240hz.

Dazu kommen die 40CU der APU + 96CU N31XTX = 136CU sind virtuell / physisch verfügbar.

Eine virtuelle "RX 7950XTX" mit 128MB unified IF$ und 72WGP mit RDNA3 / RDNA3.5 uArch wäre physisch und theoretisch verfügbar. Dazu noch der Zugriff auf 960GB/s GDDR6 Bandbreite und DDR-5 8000 Bandbreite von 128GB/s ~ 1088 GB/s (V)RAM Gesamtbandbreite.

Wäre echt geil wenn die APU auch am Desktop für AM5 kommt und sich so kombinieren lässt.

Der Shadertakt der Strix Halo ließe sich asynchron betreiben per ACE (asynchronous Compute engine) und der Shadertakt der Navi31 XTX kann eigenständig takten.

Selbst eine Mittelklasse 7800XT käme mit Strix Halo gepimpt auf 60CU + 40CU = 100CU somit in die Oberklasse. Dazu noch mit massiven 16C/32T Zen5 Cores. Das ist vielleicht übertrieben.
Wer sparen möchte, kann auch 8C/16T und 32CU kombinieren. Das wären 92CU, 96MB IF$, also Oberklasse Leistung für mittleres Geld.

Eine Solche Technologie seitens AMD würde einiges an Volumes in der Mittelklasse verursachen.

Selbst Leute mit Kombis wie AM4 Ryzen 5 5600X + RX 7900GRE würden auf AM5 umsteigen und von einem cutted down Strix Halo 12C/24T + 40CU profitieren. 120CU bei 96MB IF$ lockt viele an aufzurüsten.

Strix Halo kann bis zu 96GB VRAM verwalten. Bei einem 128GB AM5 Build wären 32GB für das Betriebssystem verfügbar und 24GB (7900XTX) + 96GB an VRAM zugewiesen, also 120GB Grafikkarte + 32GB Systemram.

Das alles in einem "MIDI-Tower" für zu Hause 🥰
 
Zuletzt bearbeitet:
Bei den dGPUs gab's ne starke Regression:
Die Begruendung war doch, dass AMD einen Weg gefunden habe mit weniger mehr zu erreichen effektiv.
Aber das ist Infinity Cache also wirklich etwas extra. X3D Cache dagegen vermehrt ohnehin den schon vorhandenen L3 Cache.

Da gibt es schon Unterschiede IMHO. Das Design ist voellig anders. Falls aber auch ein separates Die fuer den Infinity Cache auf einer GPU landet, warum sollte es AMD nicht auch XXX 3D nennen? Es sind ja schliesslich 3D Grafikkarten ;-) !
Das Namenschema waere dann erwartbar.

Was diese berechneten Werte der 'effektiven' Bandbreite angeht von AMD, kann man sie glauben auch der auch nicht.

Gruss,
TNT
[automerge]1731055012[/automerge]
Weder wäre es sinnvoll ihn auf die GPU zu stacken (Höhenunterschied, Verschlechterung der Wärmeableitung), noch hätte er die erforderliche Bandbreite.
Warum klappt das dann bei CPUs? Hoehenunterschiede, Thermals etc. wurden dort gemeistert.
Natuerlich kann es nicht eine 1:1 Kopie des CPU Verfahrens sein IMHO.

Wir wissen nur, dass AMD sich bei den CPUs sich gerne den billigen IF$ bedient um auch die low-Core Dies zu pimpen: 5600X3D, 7600X3D, 7900X3D. Alles 6C (8C physisch) Dies.
Gutes Argument. Es auch klar, dass AMD an dieser Stelle das Verfahren gut und kosteneffizient beherrscht.
Ob man die Erfahrungen bei der CPU 1:1 auf einen aehnlichen Ansatz bei GPUs uebertragen kann, weiss ich allerdings nicht.
Aber wertvolle Erfahrungen sind das allemal.

Selbst eine Mittelklasse 7800XT käme mit Strix Halo gepimpt auf 60CU + 40CU = 100CU somit in die Oberklasse
Das isrt der ewige Traum, dass sowas problemlos und gut skaliert. Leider hat sich das bislang nicht durchsetzen koennen.
Crossfire anyone?

Gruss,
TNT
 
Zuletzt bearbeitet:
Wir wissen nur, dass AMD sich bei den CPUs sich gerne den billigen IF$ bedient um auch die low-Core Dies zu pimpen: 5600X3D, 7600X3D, 7900X3D. Alles 6C (8C physisch) Dies. Dafür werden nur minimal Takt geopfert. In reinem Compute bringt das nichts, aber in Cache intensiven Single-Core Apps (wie viele Spiele) bringt das viel.
Der Maximaltakt des 7900X3D richtet sich nach dem ungestackten Chiplet und die beiden 6 Kerner haben lediglich eine TDP von 65W was Problemen mit der Wärmeableitung sehr entgegen kommt und der Taktverlußt entsprechend kleiner ausfallen kann. Was du aber vergißt ist das mit der Deaktivierung der 2 Kerne entsprechend viel tote Waferfläche hinzu kommt und in die Rechnung mit einbezogen werden muss. Das ist eben nicht umsonst Resteverwertung.

Im besten Fall kann man nur sagen dass der 3D Cache für die CPU das ist was der Infinity Cache für die GPU ist, sie dienen zur Entlastung des jeweiligen Speicherinterfaces aber genau deshalb ist der Traum von einer Verbindung der beiden Caches ist eben nur genau das, ein Traum. Das müßte zwangsläufig über das PCIe Interface erfolgen und das ist dafür ganz einfach zu lahm.
[automerge]1731056328[/automerge]
Warum klappt das dann bei CPUs? Hoehenunterschiede, Thermals etc. wurden dort gemeistert.
Natuerlich kann es nicht eine 1:1 Kopie des CPU Verfahrens sein IMHO.
Weil es um physisch getrennte Chiplets geht die in den ersten beiden Generationen auch noch für einen Höhenausgleich runtergeschliffen wurden. Wiederhole das man bei der GPU und es wird ungleich teurer, verschlechtert ebenso den Wärmetransport und verteuert die Produktion vermutlich deutlich mehr als gleich den Infinity Cache der GPU zu vergrößern.
 
Zuletzt bearbeitet:
Weil es um physisch getrennte Chiplets geht die in den ersten beiden Generationen auch noch für einen Höhenausgleich runtergeschliffen wurden. Wiederhole das man bei der GPU und es wird ungleich teurer, verschlechtert ebenso den Wärmetransport und verteuert die Produktion vermutlich deutlich mehr als gleich den Infinity Cache der GPU zu vergrößern.
Nochmal - bei CPUs hat man es gemeistert, warum soll das nicht bei GPU gelingen koennen? Warum sollte man eine GPU nicht schleifen koennen usw.
Einfach ist sicherlich anders aber unmoeglich?
Die genannten Argumente sind allesamt nicht neu und gibt es bei den CPU X3D Chips ebenso; dennoch ist es dort gelungen.
Auf diese Erfahrungen kann man aufbauen IMHO.

Stacked Cache unterhalb oder oberhalb hat sicher nicht nur positive Aspekte, aber wenn wir in 1 bis 3 Generationen dann auch bei Chiplets fuer GPUs landen, sehe ich das durchaus als gute Moeglichkeit einen Unterschied zu machen.

Gruss und Danke,
TNT
 
Bei Strix Halo kommt ein 6-Kerner dazu: Ryzen AI 380 Max mit 16 CUs. Die Namen der IGPs werden an die Grafikkarten angepasst:
- 40 CUs = Radeon 8060S
- 32 CUs = Radeon 8050S

Laut dem Leaker Golden Pig Upgrade sollen angeblich 2025 + 26 (bis auf Refreshes) keine neuen APUs erscheinen. Er zeigt eine praktisch leere Roadmap.

Nun ist Strix Point noch neu und das Programm für 2025 bekannt, aber dass auch 2026 keine neuen Produkte in einem sich schnell ändernden Markt (Thema AI) erscheinen, kann ich mir nicht vorstellen. Entsprechend würde ich den Satz "Ob nichts kommt, oder nur noch nichts bekannt ist, bleibt abzuwarten." durchaus wörtlich nehmen.

Neben Strix Halo bringt nächstes Jahr Krackan Point ZEN 5 in günstigere Notebooks.
 
Zuletzt bearbeitet:

CP2077 1080p low min fps / avg fps 30W
Ryzen Z1 Extreme iGPU-780m 12CU
45,1 / 52,6 100%
Ryzen AI 9 365 iGPU-880m 12CU
50,5 / 60,1 112%-114%
Ryzen AI 9 370 iGPU-890m 16CU
53,7 / 64,2 119%-122%

Alle haben LPDDR5X-7500, also die gleiche Bandbreite. Der IPC Sprung von RDNA3 zu RDNA3.5 scheint doch was zu bewirken.
Erfreulich ist der höhere Takt von ~2,9Ghz für die RDNA3+ CUs (Ryzen AI 365/370). Bei RDNA3 (Z1 Extreme, R9 8945HS) sind es ja ~2,8Ghz RDNA3 CU. Der "cut down" von 8C Zen4 auf 4C Zen5 + 4C Zen5c scheint hier zu wirken (Z1 Extreme vs AI 9 365).
Der Ryzen AI 9 370 ist wohl noch stärker Bandbreitenbeschränkt mit 4C Zen5 + 8C Zen5c und der iGPU Radeon 890m 16CU. Der Sprung von 12CU auf 16CU entspricht eigentlich +33% raw compute power. Von 50,5fps auf 53,7fps sind aber nur +6,34% bei den min. fps. Auch beim avg sind es 60,1fps auf 64,2fps nur +6,82%. Die vier CUs extra mehr bei der 890m scheinen da irgendwie nicht so durchzuschlagen.
 
Die APUs sind bei iGPU immer recht schnell in der Bandbreite zum Speicher beschränkt. Mehr CUs bringen dann nur noch minim extra Cache mit und sind sonst eher für niedrigeren Takt im Effizienz-Sweetspot gut.
Deshalb sind die Designes von AMD so fragwürdig in Bezug auf L3 Cache bei APUs, den die iGPU nicht lesen kann, afaik. Wenn das nicht shared ist müsste für Gamer wenigstens mehr IF Cache für GPU vorhanden sein. Ich vermute dass dafür notwendige Treiberoptimierungen gescheut werden. *noahnung*
Die Halo-APUs werden bei Erfolg den bisherigen Ansatz hinterfragen helfen.
 
Die APUs sind bei iGPU immer recht schnell in der Bandbreite zum Speicher beschränkt.
Richtig und RDNA 3.5 zeigt sich breitband hungrig im Vergleich z.B. zu Intels IGPUs z.B.
Daran kann man aber arbeiten, aber noch wichtiger ist, dass die regulaere Bandbreite im Moment im Markt zunimmt auch ohne DDR6 (u.a. CUDIMMs und auch bei AMD hoehere offiziell unterstuetze Memory Speeds bzw. DDR5 6000Mhz ist auf dem Weg zum besseren Standard alsbald).

Es steht also mittelfristig mehr Bandbreite im Desktop zur Verfuegung als wir kennen. AM5's 6000Mhz wird langsam aber sicher das neue AM4 3200Mhz+.
Natuerlich bringt blindes Anflanschen von weiteren CUs nicht viel bzw. der Benefit wird schnell gering.
Es wird immer Szenarien geben, in den man an Bandbreitenlimits stoesst das ist nicht neu. Mal frueher mal spaeter.

Aber es entsteht ein wenig mehr Spielraum als bislang; dennoch ist mehr Bandbreite immer besser, keine Frage.
Konkurrierend um Bandbreite allerdings - wenn nicht embedded in neuen IGPUs - werden NPUs sein.
Aber wie oft wird das kollidieren?
Aktuell sind die NPUs im Alltag noch underutilizied IMHO. Das mag sich aber aendern.

Gruss,
TNT
 
Der L3 der APUs ist dafür ganz einfach zu klein. Dafür müßte man ihn wohl erheblich aufblasen (128 MB?) und könnte dennoch Gefahr laufen dass die GPU den Cache so vollschaufelt das für den Datenaustausch der CPU Kerne nicht genug übrig bleibt. Dann wäre es ganz einfach sinnvoller die Daten wie seinerzeit bei Intel in einen separaten Cache auszulagern. Das Problem dabei ist allerdings dass es das nicht umsonst gibt. Der zusätzliche Cache benötigt zusätzliche Waferfläche was wiederum das Produkt verteuert. Das bedeutet aber auch dass das Produkt weniger Massentauglich wird. Kleinere Zielgruppe bei höheren Produktions- und Entwicklungskosten, da wird ein Produkt schnell unrentabel.
[automerge]1731486262[/automerge]
Richtig und RDNA 3.5 zeigt sich breitband hungrig im Vergleich z.B. zu Intels IGPUs z.B.
Was auch nicht verwunderlich ist wenn sie erheblich schneller ist.
 

ich denke: AMD machte bei APUs generell den Fehler unterschiedliche SKUs auch durch unterschiedliche Anzahl CUs zu begründen. Eine APU sollte immer knapp mehr CU-Leistung fürs Gaming bieten als die BGA/Sockel-Generation in Bandbreite liefern kann. Meinetwegen kann man dann mit Salvage CUs genau auf den Punkt kommen. Die nächste APU Generation folgt aufs Jahr, dazu müsste man die CUs je nach RAM-Standards entsprechend aufstocken. Jetzt ab der AI 300 Serie ist das hoffentlich der Fall, damit das Image aufpoliert werden kann: "Das sinnvoll Mögliche zum besten Preis". Die Bandbreite für die anderen Cores muss man da ignorieren, dort kann man auf Ziellmärkte hin anpassen. Nur bei Grafik und Gaming ist in APUs nie genug Leistung da, da darf man einfach nicht nach unten segmentieren, denn das hat nur Kunden unnötig enttäuscht und Optimierungen der Game-Developer von vorn herein uninteressant gemacht. SteamDeck hat da schon Umdenken ermöglicht, für PC/Laptop allgemein fehlt da noch die Motivation. Besser wäre AMD würde für APUs generell mit iGPU Cache den Bottleneck entschärfen und günstige mit mini iGPU nur als "CPU" vertreiben, so wie die Desktop Ryzen mit 2CUs ja auch. Finde ohnehin AMD würde besser immer mindestens ein ganzes Shader Array mit shared L1 in gleicher Grösse verbauen, auch im Desktop I/O. Das würde Optimierung doch deutlich vereinfachen. Also RDNA3.5 immer 8DCUs bzw. 4WGPs (naja, oder wenigstens 2WGPs). Und in APUs eben mindestens das doppelte oder dreifache mit Salvage-Option. Aber man hat den Eindruck die Produktmanager von AMD und der RTG wollen nicht dass man für deren iGPUs Software optimiert.
 
Zuletzt bearbeitet:
Ab 20CUs kannste selbst optimieren wie die
XboX Series S mit 20CU, 2MB $, 8GB VRAM, 224 GB/s für 720p und 1080p FSR-Q-B
PlayStation 5 mit 36CU, 4MB $, 16GB VRAM, 448 GB/s für 1080p und 1080p FSR-Q und 2160p FSR-B-P
Jede Firma, die Spiele entwickeln will, muss dem Optimierer die Hardware geben.
Bei 2160p Optimierung kommt schon neue Hardware hinzu:
XboX Series X 52CU, 5MB $, 10GB VRAM, 560 GB/s für 1080p und 2160p FSR-Q-B
Playstation 5 Pro 60CU, ?? MB $, 16GB VRAM, 576 GB/s für 1080p und 2160p PSSR-Q-P und FSR-Q-P.

Für jede einzelne Konsole da optimieren auf 60fps ist ne Menge Arbeit erstmal.
Das sind alles iGPUs in den APUs.

Im mobilen Segment gibs die Radeon 760m, 780m, 880m, 890m mit 8CU bis 16CU. 2MB $ Also 5,3 Tflop/s bis 8,2 Tflop/s.
Da bewegen wir uns im Bereich RX580 GPU ~ 6,175 Tflop/s und RX5700XT 40CU ~ 9,75 Tflop/s

Oberon liegt bei ~10,3 Tflop/s Rechenleistung. Microsoft hat genug Kohle für Optimierung und Sony kocht mit PSSR eine eigenen proprietäre Suppe.

Am Desktop kann der Entwickler noch mehr optimieren und die Workstation Karten einzeln e CUs deaktivieren und sein Game und Settings optimieren. Geht schon alles, ist aber auch ein haufen Arbeit die Bibliotheken zu verwalten.

Für Mobile sind 8CU bis 16CU Optimierung nötig mit kleinem $ 2MB und sehr begrenztem Budget bspw. 15W für die APU. 15-35W bewegen sich auch viele Geräte, dann auch für ARM CPU und diverse mobile Spiele. Da ist noch so viel Arbeit nötig. Insbesondere Upscaling von 360p auf 720p in brauchbarer Qualität und schneller Geschwindigkeit ~ 60fps @ 720p. Schade, dass Sony das PSSR da geclosed hat, würde gerne wissen mit welchem Modell und wie die ihr Inferencing machen. Aber das ist ja top secret :-P

Das sind ganz andere Bedingungen als eine 175W Desktop mit 64CU oder 400W mit 96CU.
 
Ähm....Hardware wird nicht an die Software angepasst sondern die Software an die Hardware.
Die Softwareoptimierung bei den Konsolen hat 2 ziemlich einfache Gründe. Zum einen ist deren Leistung begrenzt wodurch man aus der Hardware möglichst viel rausholen will und zum anderen gibt es für die jeweilige Konsole exakt eine Hardware Konfiguration die zu berücksichtigen ist und nicht unzählige wie bei den PCs. Der Aufwand ist also nicht größer sondern kleiner wodurch man auch deutlich mehr in die Tiefe gehen kann.
Hinzu kommt noch das der Fokus der Spieleentwicklung schon seit Jahren bei den Konsolen liegt weil dort ganz einfach deutlich mehr Spiele abgesetzt werden. Wie wenig man in die Optimierung der PC Versionen investiert sieht man ja auch anhand der teils lausigen Qualität mit der sie auf den Markt geworfen werden. Der User kann den Leistungsverlußt durch fehlende/mangelhafte Optimierung ja mit stärkerer Hardware "ausgleichen" oder die Arbeiten werden auf die Hardware Hersteller abgewälzt und fällt dann entsprechend einseiztig aus.
 
Interessantes Produkt. Bin gespannt auf die finalen Preise.

Gruss,
TNT
 
Die Zen 6-APU Medusa Point soll aus einem 12-Kern-CCD bestehen. Neben der Mehrleistung womöglich auch aus dem Grund, dass ein 8-Kern-CCD in der 3-nm-Fertigung zu klein werden könnte, um die Wärme vernünftig abzuleiten. Bei einem Tapeout im Q2 kann man im Sommer / Herbst 2026 damit rechnen.

Das würde auch für die X3D-Gaming-CPUs 12 Kerne auf einem Die plus 3DV-Cache bedeuten.

 
ich glaube nicht dass man mehr Cores nutzt um ein Wärmeproblem in den Griff zu bekommen.
Man möchte sicherlich endlich mehr Kerne ohne Nachteile im Gaming vermarkten aber 16 könnten für die Segmentierung zu viele auf einmal sein.
Die These ist ja statt mehrere Monolithen nur noch ein Core-Chiplet mit mehreren Varianten von I/O Dies zu kombinieren. Dann spräche einiges eher für 12 statt 16 Cores
  • kleinere Dies
  • höherer Takt
  • kleinerer IF Link
  • salvage Binning bis 8 Cores vertretbar
  • 12C mit V-Cache für Gaming mehr als genug
  • 24C im Desktop wäre erstmal genug für DualChannel AM5
  • bessere EPYC Segmentierung mit Basis 12 und 32C Cores
 
Damit wäre die APU quasi immer eine größere/teuerer Variante als eine entsprechende CPU mit kleinem IO-Die (vor allem wegen der größeren GPU).

Stellt sich nur die Frage ob es für mobile noch ein kleineres CPU chiplet geben wird, das wieder große und dense-cores kombiniert. Nur 12 und 32 Core Dies dürften für den Low-Cost Markt etwas zu viel sein. Für Epyc aber natürlich umso besser.

Ein 12 Kern CCX dürfte aber vor allem auch im consumer CPU Bereich einige Vorteile bringen, wenn der L3 Cache entsprechend mitwächst.

Im Endeffekt bräuchte es dann so 5 IO-Dies:
- kleine APU
- große APU
- Halo APU
- CPU
- Server
Plus wohl dann 3 CPU Chiplets. Wenn die kleinen APUs monolithisch bleiben könnte man sich entsprechend aber auch 2 Chiplets sparen.
Für den 3D Cache wird es jetzt aber erst richtig interessant. Entweder der schaut aus wie bisher oder ist direkt im Interposer unter den IO und CPU chiplets integriert.
Zen 6 bleibt auf alle Fälle spannend.
 
Ich würde nicht ausschließen dass das Pinout des Chiplets ganz einfach ein Minimum an Flächenbedarf besitzt und man deshalb auf 12 Kerne gehen könnte.
 
Wenn man auf ein Interposer Design mit TSVs und Hybrid Bonding wechselt, dann wird das Fanout wohl eher weniger zu einem Problem im Vergleich zu zuvor.
 
Zurück
Oben Unten