Zen 5 (3/4 nm, 2024)

[mocad_tom]

Fällt das Embargo für 9900X und 9950X morgen 15:00Uhr?

[robbitop]

Jepp, ein Referenzpunkt wäre noch sinnvoll. Jetzt weiss man nicht, ob das einfach Linux ist oder etwas was mit Zen 5 zusammenhängt.

Es scheint dass im Heft ein Artikel zu Linux vs Win11 gibt. Wahrscheinlich dann mit den Referenzpunkten die hier interessant wäre . ^^
So wer auch immer das Heft hat (09/2024) kann ja mal reinschauen um zu schauen ob Zen 4 oder Intel CPUs in Linux Gaming auch schneller sind und wenn ja auch im gleichen Maße?

[][immy]

Ich frage mich immer noch wo AMD die Werte in Horizon herbekommen haben will. 40% gegenüber einem 14700k sehe ich da bislang nicht ansatzweise. Entweder da ist wirklich was mit Windows, oder da hat jemand eine Szene mit starken Hang zum Cherrypicking raus gesucht.

[basix]

Es scheint dass im Heft ein Artikel zu Linux vs Win11 gibt. Wahrscheinlich dann mit den Referenzpunkten die hier interessant wäre . ^^
So wer auch immer das Heft hat (09/2024) kann ja mal reinschauen um zu schauen ob Zen 4 oder Intel CPUs in Linux Gaming auch schneller sind und wenn ja auch im gleichen Maße?

Zufällig habe ich das Heft ;) Habe es noch gar nicht angeschaut gehabt.

Bei den Spielen (CP2077, HFW, WoW, RDR2) ist das Scaling Windows vs. Linux auf eine 5600X fast identisch wie beim 9700X. Zumindest scheint der Grossteil eher wegen Linux zu kommen und nicht weil etwas an Zen 5 super speziell ist

Zen 3 im Heft (9700X im Online Artikel)
- CP2077 +6% (+6%)
- RDR2 +11% (+13%)
- WoW -4% (-2%)
- HFW +3% (+9%)

[robbitop]

Gaming auf Linux wird immer interessanter. ^^

[aufkrawall]

D3D12 + der Nvidia D3D12-Treiber scheinen einfach Schrott zu sein. VKD3D-Proton wird von ~1-3 Leuten entwickelt, es ist so absurd...

[dildo4u]

Ist das wirklich der GPU Treiber die Linux CPU Benches sind auch massiv besser als Windows.

9600x besser als 14600k in Multithreading.

https://www.phoronix.com/review/ryzen-9600x-9700x/16

Windows massiv langsamer

https://www.computerbase.de/2024-08/amd-ryzen-5-9600x-ryzen-7-9700x-test/3/#abschnitt_multicoreanwendungen


Der Windows Sheduler ist kaputt für Zen 5 anders ist das nicht zu erklären.

[aufkrawall]

Wie soll das mit 1xCCD und selbst ohne HT (TPU-Test) kaputt sein können?
Gibts schon Tests mit cleanen Windows-Neuinstallationen? Windows ist extrem unzuverlässig bei Plattform-Wechseln, warum auch immer.
Der Installer vom AMD-Chipsatztreiber pfuscht btw. auch in den Windows-Defaults rum und deaktiviert etwa Core Parking. Was im konkreten Fall gut ist. Aber wer weiß, was da noch passieren kann. Unter Linux ist halt alles zu 100% transparent bzw. man installiert keine undurchsichtigen Treiber-Pakete etc. ...

[Der_Korken]

Ist das wirklich der GPU Treiber die Linux CPU Benches sind auch massiv besser als Windows.

9600x besser als 14600k in Multithreading.

https://www.phoronix.com/review/ryzen-9600x-9700x/16

Windows massiv langsamer

https://www.computerbase.de/2024-08/amd-ryzen-5-9600x-ryzen-7-9700x-test/3/#abschnitt_multicoreanwendungen


Der Windows Sheduler ist kaputt für Zen 5 anders ist das nicht zu erklären.

So ein Quatsch. Man sieht doch an den Relationen zwischen 8-, 12- und 16-Kernern, dass die meisten Phoronix-Benches offensichtlich nicht mit Kernen skalieren und die ST-Performance somit einen großen Anteil am Rating hat und dass die Auswahl generell AMD gut schmeckt. Ansonsten wäre der 7700X ja auch schneller als der 5950X. Wie kann der 7700X sonst schneller als der 5950X sein?

[HOT]

Verdächtig war, dass AMD deutlich höhere Werte bei der Präsentation vorher hatte und diese Präsi nach dem Launch herunterkorrigierte. Irgendwas muss zwischenzeitlich passiert sein. Warum das passierte, ist nicht zu sagen, aber ich tippe auf einen Hardware-Bug, der in der CPU-Firmware gefixt wurde und der nur bei Windows auftritt oder ähnliches - der wäre dann auch nicht fixbar mMn. Irgendwas ist da jedenfalls Oberfaul.

[Oddzz]

Es scheint dass im Heft ein Artikel zu Linux vs Win11 gibt. Wahrscheinlich dann mit den Referenzpunkten die hier interessant wäre . ^^
So wer auch immer das Heft hat (09/2024) kann ja mal reinschauen um zu schauen ob Zen 4 oder Intel CPUs in Linux Gaming auch schneller sind und wenn ja auch im gleichen Maße?

Genau den Gedanken hatte ich heute auch, als ich das Heft gesehen habe. Leider wird im Heft ein 5600X mit 16 GB DDR4 RAM und einer RX 6800 XT verwendet. Zudem noch auch Nobara 39 und nicht 40.

Somit lassen sich die FPS leider nicht auf den Test mit dem 9700X übertragen :(

[Der_Korken]

Verdächtig war, dass AMD deutlich höhere Werte bei der Präsentation vorher hatte und diese Präsi nach dem Launch herunterkorrigierte. Irgendwas muss zwischenzeitlich passiert sein. Warum das passierte, ist nicht zu sagen, aber ich tippe auf einen Hardware-Bug, der in der CPU-Firmware gefixt wurde und der nur bei Windows auftritt oder ähnliches - der wäre dann auch nicht fixbar mMn. Irgendwas ist da jedenfalls Oberfaul.

AMD hat von Beginn an 16% IPC-Gewinn propagiert bei gleichbleibenden Boost-Taktraten. Damit ist irgendeine Wunder-Performance ausgeschlossen, die zufällig durch einen 4 Wochen vor Launch gefundenen Bug gekillt werden musste. Bei RDNA3 hat AMD auch schon falsche Versprechungen gemacht. Ich vermute hier einfach ein generell schlechteres und unehrlicheres Marketing. Im Gegensatz zu den Anfangszeiten von Zen braucht man die kritische DIY-Community halt nicht mehr, da löst man die Tech-People eben nach und nach durch Sales-People ab. Bei RDNA3 gibt es aber zumindest handfeste Hinweise auf Design-Bugs, während bei Zen 5 für mich erstmal vieles schlüssig aussieht.

[dildo4u]

Verdächtig war, dass AMD deutlich höhere Werte bei der Präsentation vorher hatte und diese Präsi nach dem Launch herunterkorrigierte. Irgendwas muss zwischenzeitlich passiert sein. Warum das passierte, ist nicht zu sagen, aber ich tippe auf einen Hardware-Bug, der in der CPU-Firmware gefixt wurde und der nur bei Windows auftritt oder ähnliches - der wäre dann auch nicht fixbar mMn. Irgendwas ist da jedenfalls Oberfaul.
AMD hat sich nur die passenden Games ausgesucht Toms Hardware hat 9700x über 14700k.(egal ob mit oder ohne PBO)

https://www.tomshardware.com/pc-components/cpus/amd-ryzen-5-9600x-cpu-review/5

[Badesalz]

Man weiß wie das Ding läuft. Ist das jetzt interessant wo THW jetzt was für die Platzierung hingebogen hat?

Und dann avg. Ernsthaft? :rolleyes:

[latiose88]

@badesalz
Was meinst du denn THW. Wie heißt das denn ausgeschrieben und was beusetrt das denn so?

[OgrEGT]

THW = Tomshardware
Siehe den Link von dildo4u davor...

[Badesalz]

Was mich überigens grad so bisschen nervt Leute - bei dem eigentlich massiven Erfahrungsschatz hier mit dem Thema "Themen" :wink:, ist, daß jetzt eine Sache auf 2 Threads WILD verteilt wird. Da wir ja einen 9000er Thread haben...

Irgendwie so... Hühnerhaufen-like :uup:

[OgrEGT]

Solange es noch nicht released Zen5 Modelle gibt wird halt noch im Speku Thread spekuliert :)

[Badesalz]

Oh... Da ist mir jetzt peinlich. Hab mich wohl vertan. Dachte 9700 und 9600 (X) sind schon Zen5 und müssen hier nicht mehr theorisiert werden :redface:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13596040#post13596040

[latiose88]

Ja doch aber erschiener Zen 5 und das ist genau der unterschied bei den Threads hier so.

[Badesalz]

@latiose88
Ah so. Ah so.

D.h. über die Zen5 die bereits erschienen sind wir hier im Thread nicht mehr diskutiert und berichtet, sondern in den entsprechenden Threads und hier nur noch über die, die anstehen?

Ah so. Ah so. Da muss ich meinen Scharfsinn wohl noch ein Stück nachschärfen. Danke dir für die Aufklärung.

[Altehardware]

Die neue Gerüchte basis ist zen5 x3d da erwarte ich grob +10% in games in Anwendungen kein unterschied da der taktidentisch ist. von 4,4-5,1ghz effektiv
zen4 erreicht 4,9-5,5ghz
Der kleine unterschied macht aus +25% fps nur noch +11% daher ungefähr die 10%
kann leicht mehr oder weniger werden. zen4 non x3d vs x3d waren +25%

[Badesalz]

Die neue Gerüchte basis ist zen5 x3d da erwarte ich grob +10% in games Den neuen Gerüchten nach ist der X3D da? Ja top :usweet:

in Anwendungen kein unterschied da der taktidentisch istDir ist schon klar, daß es zwar nicht die überwiegende Mehrheit ist, es aber auch so einigen Anwendungen gibt die relevant positiv auf V-Cache reagieren?

[OgrEGT]

@latiose88
D.h. über die Zen5 die bereits erschienen sind wir hier im Thread nicht mehr diskutiert und berichtet, sondern in den entsprechenden Threads und hier nur noch über die, die anstehen?

So in etwa... auch über die Technik kann weiter spekuliert werden... im Review Thread werden die Reviews und Ergebnisse etc. diskutiert... so die Theorie... manchmal geht's auch ein wenig durcheinander da das eine mit dem anderen zusammenhängt... ist aber eigentlich nicht schlimm...

[Lyka]

keine Ahnung, ob es hier reingehört

AMD Ryzen 7 9700X & Ryzen 5 9600X “Zen 5” CPUs To Receive New “105W” TDP In AGESA 1.2.0.1a BIOS Update

https://wccftech.com/amd-ryzen-7-9700x-ryzen-5-9600x-zen-5-cpus-105w-tdp-ageda-1-2-0-1-a-bios-update/

:uclap:

kann ggf auch Fake sein.

[Der_Korken]

AMD Ryzen 7 9700X & Ryzen 5 9600X “Zen 5” CPUs To Receive New “105W” TDP In AGESA 1.2.0.1a BIOS Update

:facepalm:

[Tesseract]

würde viel mehr sinn machen so.

[][immy]

Das wäre schon Lustig, da man die gesteigerte Effizienz dann über Bord wirft gegen minimale Leistungssteigerungen.
Finde es aber nach wie vor seltsam. Einmal geht die single core performance hoch, aber bei multicore ist davon nichts mehr zu sehen und geht gar ins Gegenteil über.

Unter Linux dann doch nicht, was auf Probleme mit dem Windows scheduler hinweist, aber auch das hätten die AMD eigenen Tester doch vorher schon feststellen können. Zumal die 34% Vorsprung bei Horizon sahen, wovon man in den Tests nichts mehr sieht.

[Lehdro]

würde viel mehr sinn machen so.
Nein. Du kannst nicht CPUs mit "65W TDP" verkaufen und dann daraus "105W TDP" im AGESA machen. Das kann der User gerne selber machen, PBO mit den Settings (PPT/TDC/EDC) steht jedem frei. Was AMD machen könnte: Analog zum vorgefertigten Eco-Mode halt einen "ich scheiß auf die W"-Mode einbauen als Option. Analog zum Radeon Setting gerne auch "Rage-Mode" nennen :freak:

[Wuge]

Interessant, wie Intel nur umgekehrt :D

[mczak]

Interessanterweise zeigen die dual-CCD Zen5 ebenfalls die superhohen Inter-CCX Latenzen mit denen schon Strix Point aufgefallen ist:
https://www.anandtech.com/show/21524/the-amd-ryzen-9-9950x-and-ryzen-9-9900x-review/3
Da wird vermutet dass es mit Core Parking zusammenhängen könnte, so wie der Test funktioniert. In dem Fall würde da eben nicht bloss die Latenz der Kommunikation gemessen, sondern auch noch die Zeit um den Kern aufzuwecken.
Auch dass 2 Threads innerhalb eines Kerns kaum bessere Latenz aufweisen als 2 Threads im selben CCX ist schon von Strix Point bekannt (das konnte man so natürlich erwarten, ich warte aber immer noch auf eine Erklärung wieso das anders ist als bei den früheren Chips).

[w0mbat]

"Ladder-Cache" :ugly:

[dargo]

keine Ahnung, ob es hier reingehört

AMD Ryzen 7 9700X & Ryzen 5 9600X “Zen 5” CPUs To Receive New “105W” TDP In AGESA 1.2.0.1a BIOS Update

https://wccftech.com/amd-ryzen-7-9700x-ryzen-5-9600x-zen-5-cpus-105w-tdp-ageda-1-2-0-1-a-bios-update/

:uclap:
.
;D

Was ein Chaos.

[Lehdro]

Interessanterweise zeigen die dual-CCD Zen5 ebenfalls die superhohen Inter-CCX Latenzen mit denen schon Strix Point aufgefallen ist:
https://www.anandtech.com/show/21524/the-amd-ryzen-9-9950x-and-ryzen-9-9900x-review/3
Da wird vermutet dass es mit Core Parking zusammenhängen könnte, so wie der Test funktioniert. In dem Fall würde da eben nicht bloss die Latenz der Kommunikation gemessen, sondern auch noch die Zeit um den Kern aufzuwecken.
Auch dass 2 Threads innerhalb eines Kerns kaum bessere Latenz aufweisen als 2 Threads im selben CCX ist schon von Strix Point bekannt (das konnte man so natürlich erwarten, ich warte aber immer noch auf eine Erklärung wieso das anders ist als bei den früheren Chips).
Alter Schwede, diese miesen Inter-CCD Latenzen hatte ich zuletzt bei Whitehaven (TR1000) gesehen, abartig.

Wenn es wirklich an Core Parking liegen sollte: Warum nicht mal mit Core Parking disabled testen?

[aufkrawall]

Der Chipsatztreiber-Installer sollte Core Parking abschalten. Und beim 8C sollte bei vielen Spielen genug Last auf den Kernen sein, dass keiner geparkt wird.

[Lehdro]

Der Chipsatztreiber-Installer sollte Core Parking abschalten.
Nein. Laut AMD gibt es bei Zen 5 wieder Core Parking. Und zusätzlich sogar das 2-CCD-X3D Treiberklimmbimm. Zen 5 wird immer wilder.
Unfortunately, sometimes Windows does not apply the correct provisioning after the CPU installed has changed. You can try uninstalling then re-installing the AMD Chipset Driver as a workaround, but a fresh install of Windows is ideal. Please make sure to restart then wait for the system to idle so that the provisioning installation may complete.

For the review purposes we highly recommend performing a clean Windows installation to ensure the provisioning is applied correctly. It may save time to have a separate SSD/image for the 9950X/9900X, and 9700X/9600X, so you don't have to reinstall windows every time you switch between a single CCD and dual CCD configuration while benchmarking.
Quelle (https://www.computerbase.de/2024-08/amd-ryzen-9-9900x-9950x-test/#abschnitt_alte_windows_und_softwareprobleme_neu_aufgelegt)
AMD’s dual-CCD (compute chiplet) Ryzen 7000X3D models introduced an innovation — a new core parking technique that automatically engages during gaming to boost performance. AMD has now implemented that feature with its Ryzen 9 9000-series models, too. AMD says it chose to enable the feature on the Ryzen 9000 series due to notable performance improvements.
Quelle (https://www.tomshardware.com/pc-components/cpus/amd-ryzen-9-9950x-cpu-review)

Und beim 8C sollte bei vielen Spielen genug Last auf den Kernen sein, dass keiner geparkt wird.
Mir ging es hier primär um die Inter-CCD Latenzen, nicht um die Performance.

[aufkrawall]

Nein. Laut AMD gibt es bei Zen 5 wieder Core Parking.
Das klingt aber nach einem Feature auf der CPU, und nicht nach dem Schwachsinn, den Windows macht?
Gibt btw. unter Linux gar kein Core Parking-Äquivalent zu Windows, außer ggf. auf Umwegen.

Eh, kann natürlich sein, dass der Windows-Scheduler damit dann wirklich nicht klar kommt. wtf...

[Zossel]

Gibt btw. unter Linux gar kein Core Parking-Äquivalent zu Windows, außer ggf. auf Umwegen.

echo 0 > /sys/devices/system/cpu/cpuX/online

:-)

[aufkrawall]

Das Problem bei Windows ist wohl weniger, dass die Kerne schlafen, sondern dass der Scheduler je nach festgelegter Schwelle ständig versucht, Threads mit wenig CPU-Zeit noch irgendwie auf aktiven Kernen mit unterzubringen, nur um sie dann irgendwann doch wieder auf die schlafenden Kerne zu legen.
Das ist ein komplett behinderter Default (wenn nicht etwas wie der Chipsatz-Installer das ändert, was bei Intel nicht der Fall ist) und ich kann damit zu 100% reproduzierbar extrem schwere Frame Time Spikes in Spielen mit extrem niedriger CPU-Last provozieren. Es ist unfassbar, wie komplett dämlich Microsoft ist. Ich hab noch nicht geprüft, ob das bei 11 24H2 immer noch so ist, aber würd ich mal von ausgehen...

[HOT]

@AMD, bitte komplette Marketingabteilung feuern, alle Dokumente vebrennen und alle Festplatten wegschmeißen, neue Leute einstellen und bitte von 0 auf neu anfangen. Das kann nicht schlimmer werden...
und um himmels willen, lasst doch einen Softwaremenschen nochmal über so ein System gucken und den das System testen, bevor man das dem Pöbel zum Fraß vorwirft, das wär doch sicherlich schnell aufgefallen.

[Nightspider]

Die aktuellen Fehler zu vermeiden kann nicht schwer sein.

Das bestätigt für mich einfach das bei AMD der Fokus gerade zu 99% auf AI und HPC liegt.

Gamer und Windows Systeme? Werden nebenbei mitgenommen mit minimalem Aufwand.

MI350 und MI375 haben gerade die höchste Priorität. Da fließen die Millionen bzw. potentiell Milliarden.
Jede Woche, jeder Monat Verzögerung dort kostet viele hundert Millionen Gewinn.

[MSABK]

Viele Reviewer schreiben, dass die Speicherbandbreite der Flaschenhals ist. Bin da umso gespannter auf x3d.

[Der_Korken]

Viele Reviewer schreiben, dass die Speicherbandbreite der Flaschenhals ist. Bin da umso gespannter auf x3d.

Das halte ich für totalen Quatsch. CB hat bis DDR5-8000 getestet und es hat in Spielen quasi nichts gebracht. Wenn dann könnte die Speicherlatenz ein Problem sein, aber das ist nur Spekulation, solange niemand Zen 4 und 5 bei starkem RAM-Tuning (inkl. Subtimings) vergleicht. Ich habe aber das Gefühl, dass bei Zen 5 intern irgendwo klemmt und der X3D sich nur genauso knapp absetzen wird wie normalen X-Modelle.

[latiose88]

Das Problem bei Windows ist wohl weniger, dass die Kerne schlafen, sondern dass der Scheduler je nach festgelegter Schwelle ständig versucht, Threads mit wenig CPU-Zeit noch irgendwie auf aktiven Kernen mit unterzubringen, nur um sie dann irgendwann doch wieder auf die schlafenden Kerne zu legen.
Das ist ein komplett behinderter Default (wenn nicht etwas wie der Chipsatz-Installer das ändert, was bei Intel nicht der Fall ist) und ich kann damit zu 100% reproduzierbar extrem schwere Frame Time Spikes in Spielen mit extrem niedriger CPU-Last provozieren. Es ist unfassbar, wie komplett dämlich Microsoft ist. Ich hab noch nicht geprüft, ob das bei 11 24H2 immer noch so ist, aber würd ich mal von ausgehen...

Hm interessant das Problem hatte ja AMD schon mit Zen 4 auch schon gehabt.Dachte das hätte AMD in den griff bekommen aber scheint es jedoch nicht zu haben.Es war bei meinen Tests so gewesen das nur einer der Chiplet voll zu 100 % Ausgelastet worden ist,der zweite Chiplet beim 7950x nur die hälfte also nicht smt Einheiten.So das es am Ende nur 24 der 32 Threads voll ausgelastet worden sind.Die restlichen mit 0%.
Unter Windows 10 wurden allerdings alle Threads ausgelastet.Die Leistung ist gleich gewesen.Anscheinend hat auch Windows 10 auch Probleme damit wirklich alle Einheiten da voll Auszulasten.Wusste nicht das es da auch Core Parking Probleme eben würde.Das erklärt auch warum diese CPU nur bis 200 Watt gegangen ist,obwohl es auch höher geht und der Allcore geht eigentlich auch höher.Ich sah in den Tests 5,4 ghz aber bei mir waren es nur 5,1 ghz.

Naja hier stimmt was gewaltig nicht und ich finde es echt schade,leider kann man da nix machen und AMD kriegt das irgendwie nicht in den Griff,echt schade.

[reaperrr]

Das halte ich für totalen Quatsch. CB hat bis DDR5-8000 getestet und es hat in Spielen quasi nichts gebracht. Wenn dann könnte die Speicherlatenz ein Problem sein, aber das ist nur Spekulation, solange niemand Zen 4 und 5 bei starkem RAM-Tuning (inkl. Subtimings) vergleicht.
Alles oberhalb DDR5-6000 läuft nur noch mit 2:1, und prompt schneidet DDR5-8000 teils schlechter als DDR5-6000 ab, also ja, natürlich spielt Latenz eine Rolle.
DDR5-6000 mit den niedrigsten stabil lauffähigen Timings ist wohl RAM-seitig der Sweetspot momentan.
Trotzdem kann es sein, dass Zen5 etwas stärker als Zen4 durch die nicht gestiegene Cachemenge ausgebremst wird.
Ich rechne zwar auch nicht mit nennenswert stärkerer IPC-Steigerung durch X3D, aber möglich wär's schon.

Ich habe aber das Gefühl, dass bei Zen 5 intern irgendwo klemmt und der X3D sich nur genauso knapp absetzen wird wie normalen X-Modelle.
Ich denke, dass der X3D diesmal zumindest etwas höhere Taktraten bieten könnte, aber Wunder würde ich ansonsten auch nicht erwarten. Außer, sie verdoppeln den X3D auf 128MB, was aber vermutlich thermisch problematisch wäre (die Kosten würde man aber durch die Mehrleistung über den Preis reinholen können).

[basix]

Chips & Cheese Artikel zu Zen 5:
- APU: https://chipsandcheese.com/2024/08/10/amds-strix-point-zen-5-hits-mobile/
- Desktop: https://chipsandcheese.com/2024/08/14/amds-ryzen-9950x-zen-5-on-desktop/

[HOT]

MLID sagt, dass der µCode ein Chaos ist und das Zen5 vom Zen2-Team gestartet wurde und deren Codebasis als Anfang diente, danach lief die Entwicklung durch verschiedene Teams. Dabei ist zwar ein tragfähiges Design herausgekommen aber eben keine tragfähige Codebasis sondern übelstes Flickwerk. Also muss sich bei AMD jemand dahinsetzen und die gesamte Codebasis neu schreiben.

[Radeonfreak]

Alles oberhalb DDR5-6000 läuft nur noch mit 2:1

Nuja, 6200 oder 6400 kann schon noch 1:1 laufen, hab ich ja auch so.

[latiose88]

Danke dir dafür.Ja das ist ja kein Wunder das es nicht mehr zu höhere steigerung mehr führt.
Ich führe zwar zwei gleiche Programme aus,aber aufgrund der geringen Daten weil je kleiner eine Auflösung eines videos ist,desto weniger Cache abhängig ist das. Da helfen dann zwei davon auch nix mehr weiter.Durch das verringert sich massiv die Cache misses auf nahe null.Durch das verringert sich auch die Auslastung der Einheiten.Nun weis ich auch das X264 Backend ist.Das erklärt auch warum AVX nicht so ne wirklung hat.

Ich kann also nicht viel tuen um dies weiter zu steigern.Je kleiner die Daten desto weniger ist die CPU gefodert.Ich dachte immer ne Verbreiterung würde bei 2 gleichzeitig helfen.Aber der Cache limitert 0 bei mir.Der ram führt auch zu einer kleineren Steigerung.

Also kann man sagen ne breitere CPU führt nicht zwangsweise zu mehr Leistung.Es müssen ja alle Einheiten gefüttert werden.Ist dies nicht der Fall so bleibt die Leistungssteigerung freilich aus.
Das ist nun mal die IPC steigerung.Die fällt eben bei jedem Programm anderst aus.Und bei manchen bleibt sie bei 0.Vielleicht wird das ja in Zukunft besser.Wobei noch breiter nicht unbedingt besser ist.Vielleicht wird es mal zeit für mehr Kerne,damit das ganze besser ausgelastet wird.16 Kerne scheint wohl zu wenig für die hohe breite zu sein.

[HOT]

Nuja, 6200 oder 6400 kann schon noch 1:1 laufen, hab ich ja auch so.

6400 ist bei den 7000ern nicht in allen Fällen stabil, aber bei den 9000ern dürfte das im unteren Promillebereich sein. Daher würd ich immer 6400 empfehlen beim 9000er.

[fondness]

Kraken und Strix Halo sollen zur CES gelauncht werden
https://videocardz.com/newz/amd-plans-october-10-launch-for-ryzen-ai-300-pro-epyc-turin-instinct-mi325x-and-strix-halo-preview-at-ces-2025

[HOT]

Damit hätte man Halo früher als ich gedacht hätte fertig. Sehr gut. Kein Wort von X3D - beunruhigend.

[horn 12]

Womöglich schiebt man Zen 6 und RDNA 5 vor, und Mitte bis Ende 2025 Releast man beides.
Ist man nur knapp hinter/ Minimal über einem 7800X3D kann man sich die 3D Modelle wirklich sparen.

[dildo4u]

Womöglich schiebt man Zen 6 und RDNA 5 vor, und Mitte bis Ende 2025 Releast man beides.
Ist man nur knapp hinter/ Minimal über einem 7800X3D kann man sich die 3D Modelle wirklich sparen.
TSMC wird irgendwann alle 5nm Fertigung auf 4nm umstellen damit kann man sich Zen5 nicht sparen Sony musste z.b den PS5 Chip ändern obwohl die Performance genau gleich geblieben ist.

[MSABK]

Es kann auch sein, dass 7800x3d auch nach dem Launch der neuen Intel CPUs die schnellste Gaming CPU bleibt und deshalb AMD Anpassungen am Plan vornimmt.

Strix Halo soll ja nur eine Preview sein.

[dildo4u]

Halo muss imo zur CES kommen nach Blackwell ist die Lauft raus Gegner ist die 4070.

[][immy]

TSMC wird irgendwann alle 5nm Fertigung auf 4nm umstellen damit kann man sich Zen5 nicht sparen Sony musste z.b den PS5 Chip ändern obwohl die Performance genau gleich geblieben ist.
Natürlich kann eine kleinere Fertigung ein redesign erforderlich machen. Schließlich rücken dadurch teile näher zusammen, was dann ggfs. nah genug ist um Fehlströme zu ermöglichen. Einfach dadurch das etwas näher aneinander ist. Ist ja nicht so das in einem Chip alles absolut isoliert ist, so das es da nicht zu Quereffekten kommen kann.
Bei Verbesserung innerhalb eines Prozesses ist das noch unwahrscheinlich, aber wenn es darum geht das Dinge sich näher kommen wird es auch schwieriger.

[maximus_hertus]

Man zieht nicht mal eben eine komplette CPU bzw. GPU Gen um ein (ganzes) Jahr vor.

Gerade CPUs haben eine sehr lange Validierungsphase und das Tapeout ist in der Regel deutlich über 1 Jahr vor dem eigentlichen Launch, ergo müsste das dann quasi jetzt erfolgen oder schon erfolgt sein, wenn man in 2025 launchen möchte (Zen 6).


Wenn man alles zusammenzählt, dann macht dieser "rushed launch" ein Stück weit Sinn:

AMD hat wohl gemerkt, dass sie mit Zen 5 im Desktop nicht dort sein werden, wo sie hin möchten und wollten wohl so viel früher wie möglich als Arrowlake launchen. On Top hat die ganze Intel Instabilitätssache AMD in die "Karten" gespielt, getreu dem Motto: Hier Zen 5, bestes Feature: It is not Intel!

Selbst wenn man nun am Microcode arbeitet und das ein oder andere noch ausmerzt / verbessert, würde ich jetzt keinen signifikanten Geschwindikeitsschub erwarten. Hier und da mal 2-3%, Einzelbenches mit +5-6% und gut ist. Wenn überhaupt.


Ich habe mittlerweile das Gefühl, dass der große "Retter", die X3D CPUs, auch eher enttäuschend sein werden. Vielleicht ist der Microcode bis dahin deutlich "polierter" und die Latenzen auch nicht mehr teils desaströs. Auch wenn der Cache natürlich hilft, kann er nicht alles abfangen und nicht alles profitiert gleichermaßen vom Cache. Ergo könnte es bei den 9000X3D eine größere Schwankung bei der Performance geben (als bei Ryzen 7000X3D).


Leider, so ehrlich muss man sein, hat AMD den LAunch so ziemlich komplett in den Sand gesetzt.

Anfang Juni Ankündigung für Juli, dann lange Stille, Mitte Juli dann das LAunchdatum: 31.7.
Technisch zwar Juli, aber irgendwie schon ziemlich "meh". Zusätzlich werden keine PReise genannt, was eher kein gutes Zeichen ist.

Eine Woche vor Launch wird jener auf einmal nach hinten gelegt und zweigeteilt. Dazu ziemlich kryptische Aussagen.

Dann die Infos von den Reviewern mit teils extrem instabilen Systemen und das sie sehr lange keine Testsamples erhalten haben.


Von A-Z ein schlechter Launch. Quasi ein Abziehbild für "ich mache in JEDEM Schritt bis zum Launch Fehler".

So oder so sehe ich nicht, wie Zen 5 positiv herausstechen möchte, selbst wenn die X3D vernünftig laufen. AMD wollte zu früh zu viel und hat jetzt eine "kaputte" Generation, zumindest im Desktop.

Wie es im Datacenter aussieht wird man sehen. Mich würde es nicht wundern, wenn es dort besser läuft.


Lange Rede, kurzer Sinn: imosollte AMD überlegen, ob sie mit dem Launch der X3D Chips nicht das Lineup anpassen:

9950X3D: 699 USD
9950X: 599 USD
9900X3D: weg lassen
9900X: 449 USD
9800X3D: 399 USD
9800X = 9700X mit 105W: 299 USD
9650X = 9600X mit 105W: 249 USD
9600 = 65W 6C: 199 USD

9700X und 9600X laufen langsam aus, 9900X3D kommt gar nicht.


Ich würde jedoch eher nicht erwarten, dass AMD das so lösen würde.

Aktuell gleube ich sogar, dass sie wirklich per AGESA Update die TDP beim 9700X und 9600X erhöhen, was meiner Meinung nach komplett den Vogel abschießen würde. 65W auf der Verpackung drauf schreiben und 105W dann real liefern.

[Käsetoast]

Aktuell gleube ich sogar, dass sie wirklich per AGESA Update die TDP beim 9700X und 9600X erhöhen, was meiner Meinung nach komplett den Vogel abschießen würde. 65W auf der Verpackung drauf schreiben und 105W dann real liefern.
Kann ich mir einfach nicht vorstellen und halte das bis es was Handfestes gibt für Twitter Klickbait. Man stelle sich vor ein OEM hat schon eingekauft und hat nen Kühler, der für 65 Watt ausgelegt ist eingeplant. Das gäbe doch nen Schwall an (wahrscheinlich auch rechtlicher) Probleme, wenn plötzlich die Rahmenbedingungen ganz andere sind. Meiner Meinung nach sind das keine Angaben die man einfach als bunten Text auf die Verpackung druckt, sondern auch ein bindendes Kommitment.

Was höchstens ginge wäre wenn man sich mit den Mainboard Anbietern einigt da sowas wie einen offiziellen "Turbo Modus" anzubieten. Das die per Default einfach mal in ne ganz andere Verbrauchskategorie gehoben werden glaube ich aus oben genannten Gründen aber nicht. Bringt nur Verwirrung und ggf. sogar rechtliche Konsequenzen...

[x-force]

Das halte ich für totalen Quatsch. CB hat bis DDR5-8000 getestet und es hat in Spielen quasi nichts gebracht. Wenn dann könnte die Speicherlatenz ein Problem sein, aber das ist nur Spekulation, solange niemand Zen 4 und 5 bei starkem RAM-Tuning (inkl. Subtimings) vergleicht. Ich habe aber das Gefühl, dass bei Zen 5 intern irgendwo klemmt und der X3D sich nur genauso knapp absetzen wird wie normalen X-Modelle.

was viele nicht verstehen:
es ist nicht die speicherbandbreite, sondern die anbindung über infinity fabric, also der maximale if takt von 2066 bis 2200 ist bei zen4 das nadelöhr!
deshalb skaliert ein test mit 8000 so schlecht. abgesehen davon ist 8000 in den seltenstens fällen, wenn überhaupt stabil und beim if takt läuft man in die fehlerkorrektur, bevor es crasht, was ebenfalls zu verzerrungen führt.

latenzen helfen immer und überall, sobald speicherzugriffe nötig sind, auch beim x3d!

[Der_Korken]

was viele nicht verstehen:
es ist nicht die speicherbandbreite, sondern die anbindung über infinity fabric, also der maximale if takt von 2066 bis 2200 ist bei zen4 das nadelöhr!

Zumindest bzw. vor allem bei den Single-CCD-Modellen. Ein CCD hat bei 2000Mhz IF-Takt einen Lesedurchsatz von 64GB/s und Schreibdurchsatz von 32GB/s. Dieser wäre bereits bei einem RAM-Takt von 4000Mhz (Lesen) bzw. 2000Mhz (Schreiben) gesättigt. Mit 2 CCDs verschiebt sich die Grenze auf 8000Mhz (Lesen) und 4000Mhz (Schreiben), wobei dazu dann aber auch beide CCDs arbeiten müssen.

[Duplex]

MLID sagt, dass der µCode ein Chaos ist und das Zen5 vom Zen2-Team gestartet wurde und deren Codebasis als Anfang diente, danach lief die Entwicklung durch verschiedene Teams. Dabei ist zwar ein tragfähiges Design herausgekommen aber eben keine tragfähige Codebasis sondern übelstes Flickwerk. Also muss sich bei AMD jemand dahinsetzen und die gesamte Codebasis neu schreiben.
Das kannst du vergessen, das wird nicht viel bringen, wenn beim nächsten Design keine +>30% IPC rauskommt, dann wird man sich kaum noch absetzen können.

[latiose88]

bei intel wird das selbe problem haben,setzt sich intel nicht stark ab,dann wird da auch kaum einer kaufen.So kleine Sprünge das macht die breite Masse nicht mit.Also da muss schon bei egal oder Intel oder AMD was gutes kommen.Das sehe ich aktuell aber nicht,also bleiben die Verkaufszahlen eher geringer.Für Intel kommen neben dem auch noch hohe kosten dazu.
Also wird das ganze alle schaden.Mir kann das ja egal sein,aber auf dauer nicht so gut.Hoffen wir mal das zumindest Zen 6 was wird,der Zug hier ist schon längst abgefahren und holt man nicht mehr ein.

[ChaosTM]

D1INvx9ca9M


hmm


cmd (als admin)

net.exe user administrator /active:yes

done


sollte man aber nicht wirklich machen..

[Relex]

War mir auch völlig neu, dass das was bringt. Zwar schon öfter mal gehört, aber als Schlangenöl abgestempelt.

Aber es bringt tatsächlich was. Habs eben getestet.
Das funktioniert auch, wenn man das Spiel einfach per rechtsklick als Admin startet.


Hier meine Ergebnisse aus dem Cyberpunk Benchmark auf dem 5800X3D @65W unter Windows 11:


Mit Pathtracing @ 720p @ DLSS Ultra Performance

Mit Standardrechten gestartet:
123,88 FPS
125,91 FPS
123,14 FPS
122,93 FPS
____________________
Durchschnitt: 123,97 FPS


Mit Adminrechten gestartet:
129,59 FPS
131,73 FPS
131,12 FPS
130,20 FPS
____________________
Durchschnitt: 130,66 FPS -> +5,4%





Mit Rastergrafik @ 720p @ DLSS Ultra Performance

Mit Standardrechten gestartet:
167,86 FPS
164,05 FPS
164,14 FPS
165,70 FPS
____________________
Durchschnitt: 165,44 FPS


Mit Adminrechten gestartet:
177,48 FPS
175,22 FPS
176,34 FPS
174,73 FPS
____________________
Durchschnitt: 175,94 FPS -> +6,35%


Frametimes hab ich jetzt nicht geprüft, wenn da aber unter Windows irgend was aktiv und reproduzierbar bremst, kann das ja durchaus auch mal für ungleichmäßigere Framtimes, Varianzen, microruckler usw. sorgen.


Bin mir nur nicht sicher, ob das wirklich so einfach zu fixen ist bzw. überhaupt ein Bug ist. Wahrscheinlich kostet das aktive Einschränken der Systemrechte bei Ausführung ohne Admin Rechte einfach grundsätzlich Performance?

[MSABK]

[

hmm


cmd (als admin)

net.exe user administrator /active:yes

done


sollte man aber nicht wirklich machen..

Assetto Corsa Competizione legt aber allgemein sehr gut zu. Warum ist das so ein Ausreißer?

[HPVD]

Hab da mal ne Frage:

Hat hier irgendjemand eine Übersicht welche Epyc Varianten es mit Zen 5 denn nun geben wird?

je nach Quelle hat Turin aber auch mal "5" und mal "5c" Kerne und dann gab es ja auch mal noch den Prometheus...
bei Golem klingt es konventionell logisch:
https://www.golem.de/news/amd-epyc-9005-zen-5-fuer-server-bringt-riesigen-l3-cache-2407-187439.html
bei Heise schon wirrer https://www.heise.de/news/Server-Prozessor-Epyc-Turin-AMD-will-Intel-noch-weiter-uebertrumpfen-9745307.html
und bei... wie man will :-)

Wieviel Kerne hat der Max Ausbau? Welche Sockel werden genutzt? Wird es den Threadripper noch geben oder ist der wirklich tot? Oder nur der Pro?

Wann ist für welche der Varianten mit einem Release zu rechnen?

Fragen über Fragen :-)

[amdfanuwe]

Wird doch wieder genauso laufen wie bei ZEN4, nur mit mehr Kernen.
https://www.amd.com/de/products/processors/server/epyc/4th-generation-9004-and-8004-series.html#specs

Alles auf gleichen Sockel wie ZEN4.
Nur für 128 Core ZEN5 mit 16 IF Links wird ein neuer I/O benötigt. Ob der dann auch für die anderen verwendet wird und was sonst noch daran anders ist????

Also FP5
196 Core 12x16 ZEN5c
180 Core 12x16 ZEN5c
128 Core 16x8 ZEN5
96 Core 12x8 ZEN5
etc, eventuell alle Varianten mit salvage und unterschiedlicher Chiplet Bestückung.
ZEN5 Varianten mit X3D.
Siena SP6 ZEN5c bis 96Core.
Threadripper ZEN5 entsprechend. Wohl auch nur PRO.

Es wird reingepackt, was die TDP hergibt.
Warum sollte AMD etwas am bewährtem Schema ändern?

[Ramius]

Das kannst du vergessen, das wird nicht viel bringen, wenn beim nächsten Design keine +>30% IPC rauskommt, dann wird man sich kaum noch absetzen können.

+30% IPC - Verbesserungen sind nicht mehr möglich.
Wir sind jetzt in der Phase bei der durch die Prozesse und die Verbesserungen am Design vielleicht noch 10% - 15% IPC - Verbesserungen möglich sind. Und auch dies wird in Zukunft noch weniger werden.

[robbitop]

Das haben wir auch schon vor 10 Jahren angenommen. Unmöglich ist das sicher nicht. Macht aber überproportional mehr Aufwand.

[Altehardware]

Eben doch aber das ist stark abhängig mit welchem node produziert wird
amd hat sich für n4e entschieden bei zen5 das ist ungünstig da der node bur bis 5,0ghz optimal läuft darüber kann man oc wie man will es bringt keine Leistung mehr
Die kommende zen6 gen wird n3e haben +10% Takt die sind sicher. Zen6 wird ein refresh der arch ohne Änderungen.
zen7 dürfte n2 oder a18 node sein+25% Takt eher n2 +15% Takt
Da aber amd alle desktop cpu apu werden wird man cowos nutzen und das Si unter der cpu setzen was den Takt nochmal senkt auf aktuelle werte was dann 5,5ghz sein wird mit n2 node aber wahrscheinlicher a18 mit dann 6,6ghz

Hätte amd auf n4x gesetzt wär der taktsweetspot bei 5,5ghz gewesen das ist bedauerlich das gute der n4e ist effizient was man anhand der temps auch sehen kann.
Das wird amd auf n3e übernehmen da kompatibel.
Dort steigt der Takt nur marginal auf 10% höher eher weniger und man kann noch mehr Strom einsparen etwa daher wird zen 6 grob 70w ppt oder die gleiche ppt haben(88w) aber um 5-10% höher Takten.
Das gute wenn mehr Takt nix bringt sind die cpu dann bei 65w ppt und 45w tdp Architektur Verbesserungen bringt hier nix
Takt wäre der einfachste Weg müsste aber dann n3p min sein +15% Takt. neuer sweetspot bei 4,8ghz base -6,0ghz boost bei 105w ppt gleiche temps wie beim zen5
zen7 wird ei sprung werden da man von planar cpu auf cowos wechselt ud alle cpu quasi apu sind mit min 2 renderengines (48cu) an einen 256bit si
Daher bin ich sicher das zen7 auf am6 kommt mit neuen ram standard camm2 2*128bit dualchannel
ab a18 node dürfte dann zusätzlich gaa für doppelte alu per cu sorgen und bis zu 4 renderengie haben (96cu*128alu)

Derzeit könnte amd auch auf planar bleiben mit cpu Modellen dann sind sogar cpu mit 9,0ghz drin
aber die chance alle cpu mit igp zu versehen 256 bis 512bit Si zu verbauen ist zu verlockend als das man nur den Takt Weg gehen würde. das st zwar möglich aber unwahrscheinlich
Ein i/o hub mit n3 node planar mit einen ccx 8kern später 16kern bis zu 9,0ghz Takt die frage die sich stellt ist lohnt es sich für desktop 8 corer ccx zu halten was bei gaa grob 30mm² wären
Die dann bei aktuellen Takt was dann 6,6ghz wäre 44w hat oder 9,0ghz bei 88w
Letztere wird sicherlich umgesetzt da bliebe die frage der wärmestau da die Fläche des chips zu klein ist daher dürfte dann in eine ccx 16 kerne werden was den chip auf etwa 60mm² bringt

Derzeitige zen5 ccd 70mm² 8kern cpu 4 fpu bei grob 4,6-5,0ghz Takt.
zen4 71mm 8kern 4fpu bei grob 5,3-5,6ghz Takt
Zen 6 wird ne reine Taktsteigerung sein.
zen 7 unklar ob es desktpp cpu geben wird apu Weg ist Wahrscheinlicher.

[Complicated]

Eben doch aber das ist stark abhängig mit welchem node produziert wird

Hat alles halt nichts mit IPC sondern mit Takt zu tun.
Daher ist dein "eben doch" nicht nachvollziehbar. Der Node ändert absolut nichts an der Anzahl der Instruktionen die ein Chip-Design pro Takt verarbeiteten kann.

[x-force]

amd hat sich für n4e entschieden bei zen5 das ist ungünstig da der node bur bis 5,0ghz optimal läuft darüber kann man oc wie man will es bringt keine Leistung mehr

selten so ein quatsch gelesen :freak:

du sagst: rechnet zen5 nur schnell genug, wird er langsamer.
und daran soll auch noch der prozess schuld sein... herrlich;D

[Altehardware]

Nodes haben ei nnen Taktsweetspot bevor man zum quadrat mehr Strom hinzufügen mus um ein Prozent mehr perf. zu bekommen.
Siehe zen5 bei zen4 war dieser etwa 1ghz darüber
5,6 vs 4,6ghz
ich bin fast davon überzeugt das die Singlecore Taktangabe nicht stimmt. ne agesa Sache
Das belegt auch die komische taktangaben in den r9 cpu in multicore Differenz bis zu 400mhz
8 kerne 5,0ghz 8kerne 4,6ghz
Das macht kein Sinn letztere nehme ich an das dies der reale Takt ist und der singlecore Takt einfach völlig falsch Ausgelesen wird.

Das kann man mit pbo auf maxed 5,2ghz erste ccd zu 4,8ghz zweite ccd puschen und das mit doppelten verbrauch für mal 200mhz mehr.

Die alternative wäre wenn amd in den ccx zwei kern Sorten verbaut also zen5 und zen5c das aber ist widerlegt da der chip zu groß wäre für diese Idee

[reaperrr]

Siehe zen5 bei zen4 war dieser etwa 1ghz darüber
5,6 vs 4,6ghz
Was für ein Quatsch :rolleyes:

Der Sweet Spot ist bei Zen4 auch nicht viel höher.
Das ist auch völlig normal, dass die letzten paar hundert Mhz unverhältnismäßig viel Strom kosten.

Dass der 9700X in 65W manchmal einige Hundert MHz niedriger taktet als bspw. der 7700 liegt einfach daran, dass Zen5 satte ~30% mehr Transistoren je Kern hat, und deshalb trotz N4P und Taktoptimierungen bei identischen Takt/Spannungs-Einstellungen halt bei voller Auslastung auch etwas mehr Strom zieht, die höhere IPC gibt es halt nicht komplett umsonst und N4P ist nur ein relativ kleines Upgrade gegenüber dem N5P von Zen4.

[Nightspider]

...

9Ghz ??

Zen7 ??

Zu viel gesoffen?

[Zossel]

Nodes haben ei nnen Taktsweetspot bevor man zum quadrat mehr Strom hinzufügen mus um ein Prozent mehr perf. zu bekommen.

https://www.computerbase.de/2017-09/oracle-sparc-m8-32-kerne-256-threads-5-ghz/
https://en.wikipedia.org/wiki/POWER6

[Altehardware]

Andere arch als x86 daher ist der Takt dort sehr variable und kann sogar 100ghz betragen
Das war nie ein problem
achja die 9,0ghz sind möglich wenn man den n4x und n3x sowie a18 nutzen würde und nix am design ändert.
Das hat amd nicht getan sie haben n4e genommen das zwingt amd zu n3e +10% zu a18 wo erstmals cowos bei cpu angewendet wird mit ner dicken igp
Da die chips gestapelt werden wird man die wärme dichte erhöhen sprich der Takt reduziert sich bis zu 25% was den Vorteil von a18 zunichte macht.
zen3 war auf n6p
zen4 auf n5p was den hohe Takt erklärt von 5,2-5,6ghz man war lediglich thermisch limitiert
zen5 ist n4e alles andere macht kein Sinn bei den benchmark Ergebnissen.

[Nightspider]

Wie kann man nur so viel Müll schreiben?

[latiose88]

also die 9 Ghz sehe ich als zu unrealistisch.Das ist wenn dann nur Wunsch denken.Die 6 ghz die könnten wir in der Tat übersteigen,aber nur wenn alles andere so weit angepasst worden ist das der Stromverbrauch nicht massiv Steigt und damit auch die Abwärme Probleme damit.

[Altehardware]

Das passiert nur dann wenn die chips entsprechend auch kleiner werden was bei cpu unsinnig ist
amd hätte auch die 40% vom n6 auf n5 nehmen können haben sie nicht gemacht es wurden 5%
dasselbe beim n4e -6% mehr dense auch nicht genutzt demzufolge dürfet n3 kein schrink heißen und der a18 ist bei gaa die halbierte Größe haben das ist unausweichlich
Da aber mit a18 auch die Stromzufuhr direkt in die kernen geht und keine Wärmebrücken mehr gibt reduziert sich die Abwärme um 80%
Darum komme ich ja auf 9,0ghz cpu das würde nur nicht mehr gehen wenn amd die cpu in cowos baut ab zen7 dann sind es nur 6,6ghz

[Neurosphere]

Hmm, gab es eigentlich schon neue Spekus zum Release von den X3D? Wäre ein teaser oder irgendwas zur Gamescom völlig unrealistisch?

Mich wundern halt die doch Recht niedrigen Preise für Zen5 wenn man nicht gleich die X3D nachschiebt. Einzige andere Begründung wäre sonst nur das AMD selbst nicht so ganz mit Zen5 zufrieden ist und gleich die Preisschraube angezogen hat.

[dildo4u]

Der Juli Launch ist rein für OEM damit sie endlich neue Systeme bauen können für AMD macht es kein Unterschied ob du als Bastler Zen4 oder 5 kaufst die Herstellungskosten werden sich kaum Unterscheiden.

Wann wir X3D bekommen hängt davon ab ob AMD genug Server Chips produziert hat erst danach landet der Rest im Gameing Modell.

[basix]

Es gibt Gerüchte über einen X3D Teaser an der Gamescom und Release im September. X870 und Co. sollen afaik am 30. September kommen, würde auch passen.

[fondness]

IMO kommt da vor 2025 gar nichts. Das hat immer ~6 Monate gedauert, warum sollte es diesmal schneller gehen?

[dildo4u]

Naja Zumindest ein Modell mit positiver Presse zum Intel Launch im Oktober?

[amdfanuwe]

Wann wir X3D bekommen hängt davon ab ob AMD genug Server Chips produziert hat erst danach landet der Rest im Gameing Modell.
Also einen Tag später. Für Server braucht es erst nur ein paar Muster. Erst nach deren Validierung trudeln ein paar Monate später dann Bestellungen ein.
Gaming verkauft sich direkt.

[dildo4u]

Oh ich dachte Server ist deutlich wichtiger da dort die Intel Modelle nicht abrauchen?
Am Desktop gibt es auch ohne Zen 5 keine Alternative wenn man ein DDR5 System bauen will.

[basix]

IMO kommt da vor 2025 gar nichts. Das hat immer ~6 Monate gedauert, warum sollte es diesmal schneller gehen?

Nur weil es so war, muss es nicht so bleiben ;)

Und für AMD wäre es ja nicht schlecht, wenn man vor Arrow Lake und vor der Holiday Season einen Gaming King releasen würde.

Und sonst: Sind Gerüchte. Kann so sein, muss aber nicht. Für X870 und Co. zu pushen wäre X3D aber ein gutes Zugpferd.

[M4xw0lf]

IMO kommt da vor 2025 gar nichts. Das hat immer ~6 Monate gedauert, warum sollte es diesmal schneller gehen?

Mobile vor Desktop und/oder Server gabs ja auch noch nie, wenn ich mich nicht ganz irre.

[amdfanuwe]

Oh ich dachte Server ist deutlich wichtiger da dort die Intel Modelle nicht abrauchen?
Am Desktop gibt es auch ohne Zen 5 keine Alternative wenn man ein DDR5 System bauen will.
Server ist wichtig, es wird aber kein Serverhersteller/Betreiber riskieren, das nach einem CPU Tausch etwas nicht funktioniert. Daher hat Server immer einen Versatz drin zwischen CPU Vorstellung und Einsatz im System.
Bevor ein Server mit neuen CPUs bestückt wird, wird die CPU also erst mal vom Serverhersteller ordentlich getestet, Skripte angepasst, geprüft ob die bestehende Software auch ordentlich läuft. Das dauert halt ein paar Monate wenn nicht gar über ein Jahr. Erst dann gehen die Massen Bestellungen raus und man kann die Server umstellen auf das neue System.
Ist doch logisch. Stell dir mal vor Google wäre down mit der Meldung" Sorry, wir haben die CPUs getauscht, leider trat dabei ein Problem auf"

DIY reichen die Tests von AMD, der Rest reift dann beim Kunden, wie wir aktuell wieder sehen.

[reaperrr]

IMO kommt da vor 2025 gar nichts. Das hat immer ~6 Monate gedauert, warum sollte es diesmal schneller gehen?
Vielleicht, weil sich GR durch ein neues Stepping und die bis zuletzt andauernde Werkelei am Microcode um mindestens 3-4 Monate verspätet hat und deshalb die X3D-Modelle schon fast fertig sind?

Außerdem kommt im Oktober Arrow Lake, und AMD wird sicherstellen wollen, dass sie die Gaming-Krone behalten und Intel den Launch vermiesen, da wäre neben inoffiziellen Preissenkungen für 9600X/9700X vor allem ein 9800X3D-Launch hilfreich.

[HOT]

Am 30. Semptember ist ja nur Launch der neuen Mobos, da gibts ja keine Keynote oder irgendwas IIRC, da wird der X3D sicher nicht erscheinen. Die 2 Keynotes, die es noch gibt sind klar und da gibts auch keinen X3D. Ich bin da bei fondness, frühestens 6 Monate später. Bis dahin hat man auch die Probleme aus dem µCode rausgepatcht, ist wahrscheinlich besser so. Wie der dann konkret aussieht sehen wir dann.

[horn 12]

Ne, denke Ende Oktober bis Anfang November wird man jenen X3D bringen
um das Weihnachtsgeschäft mitzunehmen.
Wird man sehen wie gut jener wird, rechne selbst aber mit vielleicht ca. 10 bis max. 15% über einem 7800X3D.
Ist man aber darunter, oder max. Gleichauf +3% wird man die X3D Modelle canceln.

[Lehdro]

X3D nicht dieses Jahr zu bringen würde bedeuten dass man sich das Jahresendgeschäft komplett in die Haare schmieren kann. Zen 5 wird nie überzeugend sein, solange Zen 4 preislich so kompetitiv dasteht (was die Margen drückt). Zen 5 verliert im DIY noch mehr an Attraktivität solange ein Zen 4 X3D existiert. Und Zen 4 X3D steht und fällt mit ARL-S im Oktober...

Ich hoffe das Zen 5 tatsächlich "Verspätung" in den letzten Stadien hatte (lt. den alten Roadmaps stand Zen 5 für 1H/2024 an, geworden ist es Q3/2024), unabhängig von der tatsächlichen Verschiebung um 1-2 Wochen. Demzufolge könnte X3D deutlich früher kommen, wenn die Verzögerung keine Auswirkung auf das Cache Chiplet bzw. dessen Implementierung hatte. Denn nur dann haben wir ARL-S vs Zen 5 X3D und damit zumindest ein bisschen Konkurrenzkampf im Herbst/Winter 2024.

[HOT]

Der kam als B0 ca. ein Jahr nach Tape Out, der hatte keine Verspätung. Es gab nie ne Roadmap, bei der Zen5 in 23 stand oder ähnliches, der war immer für diesen Zeitpunkt geplant, das wusste man schon damals, wenn man halbwegs realistisch war.
Und das mit ARL sehe ich nicht als echte Gefahr, es sieht ja vielmehr so aus, als würde ARL im Durchschnitt eher einstellig mehr Leistung bringen als Raptor Lake, nur bei heftiger MT-Last dürfe er besser sein.

[Lehdro]

Es gab nie ne Roadmap, bei der Zen5 in 23 stand oder ähnliches, der war immer für diesen Zeitpunkt geplant, das wusste man schon damals, wenn man halbwegs realistisch war.

Wer redet denn von 2023? Ich rede von 1H/2024 (also bis 30.06.2024) anstatt 31.07.2024 was es nun geworden ist. Da sind 1-2 Monate durchaus drin, die man für die übliche X3D Verzögerung evtl. abrechnen kann, was vielleicht auf einen Novemberlaunch hoffen lässt.

[robbitop]

Die Gerüchte waren zumindest dass X3D dieses Mal eigentlich deutlich eher kommen sollte. Was dran ist? Wer weiß…

[iamthebear]

Eben doch aber das ist stark abhängig mit welchem node produziert wird
amd hat sich für n4e entschieden bei zen5 das ist ungünstig da der node bur bis 5,0ghz optimal läuft darüber kann man oc wie man will es bringt keine Leistung mehr

Das war bei Zen4 der Fall. Dieser war zwar sehr sparsam aber ab einem gewissen Punjt ist mit zusätzlicher VCore kaum mehr Performance raus gekommen.

Bei Zen5 ist das anders. Dieser skaliert nach oben hin sehr gut mit zusätzlicher VCore, hat aber das Problem, dass er generell mehr Energie braucht da eben auxh um die 30% größer und dass je nach Anwendung von der theoretischen Leistung nicht viel ankommt.

Einmalk abgesehen davon:
Was ist N4E? Meines Wissens verwendet Zen5 N4P.

Die kommende zen6 gen wird n3e haben +10% Takt die sind sicher. Zen6 wird ein refresh der arch ohne Änderungen.

Im niedrigeren Taktbereich ist dies dank niedriger Verlustleistung so aber bei der Maximaltaktrate bin ich mir da nicht so sicher.
Ja mit N3E 3-2 Fin ist man schneller als N5 2 Fin (siehe Apple A17). Aber gegenüber N5 3 Fin sieht es wieder anders aus.

zen7 dürfte n2 oder a18 node sein+25% Takt eher n2 +15% Takt
Da aber amd alle desktop cpu apu werden wird man cowos nutzen und das Si unter der cpu setzen was den Takt nochmal senkt auf aktuelle werte was dann 5,5ghz sein wird mit n2 node aber wahrscheinlicher a18 mit dann 6,6ghz

25% Spitzentaktrate wohl kaum. 10-15% kann ich mir vorstellen aber da reden wir von einer CPU die noch 4 Jahre entfernt ist.

Hätte amd auf n4x gesetzt wär der taktsweetspot bei 5,5ghz gewesen das ist bedauerlich das gute der n4e ist effizient was man anhand der temps auch sehen kann.

Zen5 ist ein Datacenter Chip und wird dort selten über 1V gefahren. N4X ist für > 1.2V gedacht. Das macht im Serverbereich wenig Sinn und der Desktop bekommt eben nur mehr Abfallprodukte aus anderen Sparten. So groß ist der Markt nicht mehr.
Abgesehen davon: Viel übwer 1.2V wird der 9800X3D im MT Betrieb kaum laufen. Der wird nicht wie ein 14900K auf 1.5V geprügelt

[Der_Korken]

Bei Zen5 ist das anders. Dieser skaliert nach oben hin sehr gut mit zusätzlicher VCore, hat aber das Problem, dass er generell mehr Energie braucht da eben auxh um die 30% größer und dass je nach Anwendung von der theoretischen Leistung nicht viel ankommt.

[...]

Zen5 ist ein Datacenter Chip und wird dort selten über 1V gefahren.

Eigentlich sind das zwei Eigenschaften, die nicht gut zusammenpassen. Ein Design, dass ewig lange mit niedriger Spannung und kleinem Verbrauch läuft und dann plötzlich zumacht, ist für Mobile und Server doch perfekt. Es läuft nur der Arbeitspunkt schlecht, den man eh nicht braucht. Starke Skalierung nach oben wäre bei einer reinen Gaming-Architektur interessant, aber ausgerechnet da bringt Zen 5 mal so gar nichts von seinem IPC+ auf die Straße.

[iamthebear]

Grundsätzlich hast du hier Recht. Grundsätzlich skaliert Zen5 jedoch so wie alle anderen Nodes. Es war lediglich Zen4, der da einiges liegen gelassen hat. Ich denke das war eher ein Problem mit dem Custom Node.

[Gipsel]

Das Verhalten hat prinzipiell weniger mit dem Prozeß und mehr mit dem physischen Design des Chips zu tun. Es gibt da zwar gewisse Berührungspunkte, aber letztendlich entscheidet das Design des Chips da mehr als der Prozeß.

[Sweepi]

Chips & Cheese Artikel zu Zen 5:
- APU: https://chipsandcheese.com/2024/08/10/amds-strix-point-zen-5-hits-mobile/
- Desktop: https://chipsandcheese.com/2024/08/14/amds-ryzen-9950x-zen-5-on-desktop/


(AVX 512 focused) Zen5 vs Zen4 deep dive, mit spannenden Ergebnissen:
http://www.numberworld.org/blogs/2024_8_7_zen5_avx512_teardown/

z.B. AVX-512 1T:
Zen4 | 1139 s | +93 % | 5.46 GHz | +6.2 %| 70.0 W | +20 %
Zen5 | 590 s | -48 %| 5.14 GHz | -5.8 %| 58.5 W | -16 %


Money Quotes:
IPC
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=89221

So we can see that Zen5's biggest gains are in scalar integer and AVX512. Everything else is mediocre to disappointing. The improvement to x87 is an interesting surprise though. I don't know what the relevant architectural improvement is, but I doubt it is specific to x87 since nobody besides SuperPi benchmarkers care about x87 anymore. The slight performance regression in pure 128-bit SSE is surprising, but likely the result of some latency regressions which will be covered later.

The popular benchmarks Cinebench and CPU-Z showed disappointing gains of 10-15%. But that's because they both happen to hit Zen5's weakest categories:


Cinebench is a mix of scalar SSE and 256-bit AVX.
CPU-Z is almost exclusively scalar SSE.


A 10-15% IPC improvement in these categories is still larger than what I observed in my own tests. I will touch on this later.
The 40% IPC improvement in SpecInt (an early leak) is consistent with my tests showing 30-35% improvement in raw scalar integer that isn't memory-bound. (this leak has since been debunked as a fake)
The leaks of 2x improvement in AVX512 were spot on. This is huge, but comes as no surprise since AMD already revealed it in their GCC patch in February.

For y-cruncher:


The regular Pi benchmarks and computations gain almost nothing (1-3%) on Zen5 due to being bottlenecked by memory bandwidth.
If you run single-threaded, you remove the memory bottleneck and get a ~50% IPC improvement on Zen5 thanks to AVX512. (less than 2x due to Amdahl's Law)
y-cruncher's BBP test (now a benchmark) shows 98% IPC improvement due to the pure AVX512 without any memory access.

In fact, the AVX512 improvement on Zen5 created a memory bottleneck so large that it became the primary reason why I promoted the BBP mini-program from a tool for verifying Pi records to a formal benchmark. The regular benchmarks wouldn't do Zen5 (and future processors) any justice. At least until someone can figure out how to get DDR5-20000 on AM5...




AVX512 is Impressive, Memory Bandwidth is not

[...]
AIDA64 measures Zen5's memory bandwidth to be about 60 GB/s. To the untrained eye, this may seem like a lot. But when you break it down, it becomes clear that it is suffocatingly insufficient for Zen5's computational power.


60 GB/s divided across 16 cores becomes 3.75 GB/s per core.
3.75 GB/s divided by ~5 GHz CPU clock becomes 0.75 bytes/cycle.
0.75 bytes/cycle divided by 512-bit load becomes 0.0117 loads/cycle.
1/0.117 loads/cycle = 85.3 cycles per load.
Zen5's 4 x 512-bit execution width means 4 x 85.3 = ~340 instructions/load.


In plain English:

A loop that streams data from memory must do at least 340 AVX512 instructions for every 512-bit load from memory to not bottleneck on memory bandwidth.


[...] For the 16-core 9950X to not be bottlenecked by memory here, it needs DDR5-20000. And y-cruncher is probably one of the better memory-optimized programs on this side of dense matrix. Common workloads like FFT, and BLAS levels 1 and 2 stand no chance.

Does Zen5 throttle under AVX512?

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=89220

Yes it does. Intel couldn't get away from this, and neither can AMD. Laws of physics are the laws of physics.

The difference is how AMD does the throttling, as it's very different from Intel's approach and has virtually no negative side-effects.


[...] Intel Processors:
For Intel processors, these transitions are handled in two phases:

Upon transition from low-intensity code to higher-intensity, the high-intensity code runs at drastically reduced throughput to reduce its intensity.
After a long period (~50,000 cycles), the higher intensity code will finally switch to full throughput.


As mentioned before, Intel processors cannot run AVX512 at full speed since they will crash. So before it can run AVX512, it first needs to lower the clock speed.


AMD Processors:
So Zen5 can go from low-intensity integer code to 4 x 512-bit floating-point almost instantly*. There is no 50,000 cycle delay where 512-bit code runs at reduced throughput. Therefore, this behavior is consistent with the earlier observation that Zen5 can run AVX512 at full clock speed provided there is thermal headroom. Somehow Zen5 manages to keep all that extra hardware on standby and can wake it up instantly. [...]

*I say "almost" instantly because there is a semi-consistent delay of around ~50 cycles for the most extreme transition (scalar integer to 4 x 512-bit) which does not happen as consistently with the other transitions. But it is difficult to tell if this stall is real or just an artifact of the test. The serializing effect of the RDTSCP instruction for clock measurement implies a heisenberg uncertainty of also around 50 cycles. If this delay is real, we can speculate if this is caused by clock-stretching or something else. Either way, it doesn't sound easy to test.


Final Thoughts
To say that Zen5's full AVX512 is impressive is an understatement. In a world where every % of performance matters and is hard fought for, we rarely see performance gains measured in "2x" instead of the usual "N%". And when this does happen, it's usually for very specific applications where a new instruction was added for them. Here, we see 2x across the entire vector stack.

While this isn't the first time AMD has doubled up their vector unit (they also did it in Zen2), this time hits different. When Zen2 doubled up the SIMD width from 128 to 256 bits, it was just a single step in a hopelessly long road to catching up to Intel's massive advantage with AVX512.

But this time, Zen5's improvement from 256 to 512 comes when Intel's struggles has forced them to backtrack on SIMD. The result is that not only has AMD surpassed Intel in their (formerly) strongest area, they have completely flipped the script on them. AMD's advantage over Intel today in SIMD is comparable to Intel's advantage over AMD in 2017 when it was Zen1 vs. Skylake X or the dark days of Bulldozer vs. Haswell.

But that only applies to the full Zen5 core on Granite Ridge. Meanwhile, Strix Point is somewhat of a mess. The nerfing of the vector unit goes beyond the 512-bit datapaths as the FADD latency and vector register file are also worse. And there's probably more that I missed. It's almost as if AMD took the full Zen5 design and decided to randomly knock things out until they met a certain silicon and power budget. Hybrid architectures are also undesirable for most HPC workloads, but of course HPC was never the intended market for Strix Point.

The biggest achilles heel of Zen5 is the memory bandwidth and the limited adoption of AVX512 itself. There simply isn't enough memory bandwidth to feed such an overpowered vector unit. And the amount of people who use AVX512 is rounding error from zero - thus leaving the new capability largely unutilized.

Memory bandwidth will not be easy to solve. We can expect Zen6 to improve things here with the new I/O and packaging improvements. But the bottleneck on AM5 and dual-channel DDR5 will remain. Perhaps a future platform with bigger caches (dual CCD X3D?) and 4-8 channels of CAMM memory will we see some light at the end of the tunnel.

As far as the adoption of AVX512 itself. The reason why it's low right now is largely because of Intel's fumbles. You can't introduce a shiny new instruction set, stack a ton barriers to using it, and expect people to quickly adopt it. And by the time AMD was able to do their implementation, Intel had already given up and bailed out.

So at no point in AVX512's history did both x86 CPU vendors support it at the same time. That sounds like a pretty big disincentive to developing for AVX512 right?

With Zen5, AMD finally delivers what Intel could not. A quality AVX512 implementation that not only bring substantial performance gains, but also avoids all the negatives that plagued Intel's early implementations.

Will that be enough to save AVX512? Will developers bite on that 2x performance? Only time will tell.

In an ideal world, Intel will support AVX512 on all their CPUs even if they need to nerf it on some of chips the same way AMD has done with Strix Point. But as of today, Intel seems committed to killing off AVX512 for the consumer market. Thus they are playing a game of whether they can hold out long enough for AVX512 to die.

However, Intel's ability to do this may be jeopardized by their recent (company-wide) problems which are almost certain to shed market share to AMD. And this does not bode well for trying to kill off AVX512. Regardless of what happens, I wish Intel luck. Competition is good for consumers.

[latiose88]

ah OK danke dir für das auflisten. Bei mir stellt sich eher wohl die Frage ist es x87 fpu oder 128bit SSE.
Das erklärt auch warum der 7950x nur bis 5,1 GHz allcore takt ging. Da ist halt dann Ende. Und da verhält sich auch Zen 5 genauso. Wird dennoch interessant sein wie die Ergebnisse ausfallen werden. Ich darf das selbst testen und es wird mir ne Freude sein den Unterschied festzustellen.

[RitterRost]

Sweepi: danke für die Zusammenfassungen.
Das erklärt auch ein bisschen, warum Zen5 unter Linux so viel besser aussieht - Software, die AVX nutzt und Compiler, die auch Zen CPUs kennen...
Die HPC Leute (unter Linux) werden sicher die Zen5 Performance nicht mit alten Compilern liegen lassen.

[Exxtreme]

Interessant ist, dass AMD mit AVX512 den umgekehrten Weg von Intel geht. Intel hat es wieder abgeschaltet, AMD lässt das drin und verbessert es laufend.

[fondness]

Intel hat es wegen der little-Cores abschalten müssen. Wobei es auch bei AMD Gerüchte gibt, dass Zen5 die letzten Gen ist, wo der Desktop Server-Material bekommt und in Zukunft APUs herhalten müssen. Und Strix hat ja auch "nur" eine 256bit FPU (allerdings zumindest mit AVX512 support).

[HOT]

AMD hat ja schon unterschiedliche Kerne, sowohl c als auch Standard mit AVX512 enabled (CCDs) und ohne AVX512 (Strix Point, Kraken Point, wahrscheinlich Sonoma Valley). Solange im Desktop die gleichen CCDs verbaut werden, wird AVX512 auch im Desktop bleiben. Mobil gibts das aber nicht.

[basix]

Zen 5 Epyc 96C mit 2.6 GHz Base und 4.5 GHz Boost: https://x.com/9550pro/status/1825832221678383376

Massiv höherer Boost als bei Zen 4 (3.7 GHz bei 96C Modell), die Dinger werden Server rocken. Damit ist auch die Gerüchte-Geschichte von +40% SpecInt pro Core deutlich wahrscheinlicher, da die Dinger einfach viel höher boosten.

[Mordekai2009]

Sehr interessant über AMD's AVX512. Vielen Dank für den Beitrag.

[Lehdro]

Eigentlich sind das zwei Eigenschaften, die nicht gut zusammenpassen. Ein Design, dass ewig lange mit niedriger Spannung und kleinem Verbrauch läuft und dann plötzlich zumacht, ist für Mobile und Server doch perfekt. Es läuft nur der Arbeitspunkt schlecht, den man eh nicht braucht. Starke Skalierung nach oben wäre bei einer reinen Gaming-Architektur interessant, aber ausgerechnet da bringt Zen 5 mal so gar nichts von seinem IPC+ auf die Straße.
Du siehst das zu klein. Bei anderen Server SKUs kannst du bei guter Skalierung nach oben im gewissen Maße Kerne gegen Takt opfern. Bei einer schlechten Skalierung geht das aber gar nicht.

Ich erinnere an die F Modelle von AMD, die auf hohe Taktraten und weniger Kernschwemme optimiert sind. Die sind durchaus gefragt. Wichtig für Server ist nur dass du das Kern-Topmodell im Sweetspot betreibst, also dass du nicht sinnlos Watt für paar MHz verballerst, wo mehr Kerne hätten sein können.

[latiose88]

Also ich habe nun bei wem der einen 9950x als CPU hat testen dürfen.Leistung hat seinen Preis und das hat es in sich.Meine Software ist dafür bekannt die CPUS richtig ins Korn zu nehmen.Ich weis nicht was ich davon halten sollte Leistung auf kosten von Temperatur und Stromverbrauch zu Opfern,aber scheint wohl heutzutage in zu sein.In der Tat ist diese CPU für Anwendung bekannt,aber es spielt keine Rolle ob mit oder ohne AVX der hohe Stromverbrauch kommt richtig durch.
Bei meiner Anwendung waren es 5,4 ghz Allcore Takt gewesen.Temperatur 95 Grad auf alle beiden Chiplet ,was wohl normal ist wenn die CPU zu 100 % Ausgelastet wird.
Stromverbrauch kletterte auf 270 Watt nach oben.Scheint ein gutes Modell zu sein.Spannung war so bei 1,212 V rum gewesen.Was ich nicht verstehe ist bei Windows 11 dieser Effizienz Modus. Ich habe 2 gleich Starke Programme gestartet und das bisher bei Windows 11 noch nie zuvor gesehen gehabt.
Die Leistung stieg um 10 % an.Das ist das was ich daraus zusammen fassen kann.

Aber erst noch zum Vergleich:
Ryzen 9 7950x Allcore Takt 5,1 Ghz,200 Watt Temperatur ist so bei 85 Grad warm gewesen.
Alles also ob Avx 1 &2 an war oder nicht scheint keine Wirkung zu haben.Haben das wie bei so mancher Vorschau genau dieses Verhalten.Ich nutze gewiss AVX 128 Bit.

Wenn ihr wollt kann ich bei der Person auch alles andere Testen wenn ich will.Ich kann es per Teamview alles Testen.Ich habe bei Teillast beim 9950x rund 160 Watt gemessen.
Das die neuen CPUS nicht sparsam sein würden,das hätte ich mir gleich denken können.Ich finde das sind nicht ohne.Er nutzt eine Mora als Kühlung.Das es klar ist der eine Luftkühlung betreibt weit weniger Leistung erhält,das ist klar.

Ich vergleiche also ein 7950x mit Luftkühlung gegen einen 9950x mit extrem starker Wasserkühlung.
Wer also Zen 5 betreiben will,braucht ne extrem starke Kühlung.Ich jedenfalls will bei Luftkühlung bleiben.Wie viel Taktverlust das bedeuten würde kann ich leider nicht sagen weil ich mich mit ner Wasserkühlung nicht wirklich auskenne.Ich schätze mal mindestens 15 Grad heißer wird es unter Luftkühlung schon sein.Damit Herrscht dann Temperatur drosseln.Um wie viel Takt dieser runter gehen muss um wieder bei 95 Grad zu sein,kann ich nicht sagen.Ich dachte mir das passt hier gut rein.

Gut Finde ich die Temperatur und Stromverbrauch Entwicklung nicht.Das ist das was ich überhaupt so nicht erwartet hatte.Vermutlich betreibt es auch keiner so das die 100 % im Taskmanager anzeigt.Und ich habe wirklich alle 16 Kerne ausgelastet. Also selbst der 9950x leidet unter Temperatur Probleme.Er könnte bestimmt noch mehr,aber ich denke mal die 300 Watt will man auf keinen Fall sprengen.

[Nightspider]

Wenn ihr wollt kann ich bei der Person auch alles andere Testen wenn ich will.

Kannst du bei ihm mal Word und Rechtschreibkorrektur über deinen letzten Beitrag laufen lassen? :biggrin:

Mach eine Tabelle. Irgendwelche Werte in einen verschwurbelten Text zu setzen liest sich grauenhaft.
Andere Tester bescheinigen Ryzen 9000 bessere Temperaturen und gute Effizienz zu haben.

[latiose88]

ja ok wie soll ich das denn machen.So nach mit oder ohne AVX und alles auf einen blick damit der direkt Vergleich sein kann.Ich weis nur leider nicht mehr wie viel Volt der 7950x gehabt hatte.Darum wird ein direkt Vergleich nicht ganz einfach.Aber zumindest das was ich weis als Tabelle wenn gewünscht kann ich das gerne machen.Und wo soll ich die Tabelle setzen,mitten drin?


Aber gut ich versuchs mal:


Modell Takt Temperatur Stromverbrauch Art der Kühlung Auslastung Betriebsystem Verwendete Programm Einstellungen und Code
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ryzen 9 7950x 5,1 Ghz 85 Grad 200 Watt Luftkühung NH D15 92% Windows 11 Xmedia Recode 3.4.3.0 32 Bit Medium Custom H264
Ryzen 9 9950x 5,4 ghz 95 Grad 270 Watt Mora 100 % Windows 11 Xmedia Recode 3.4.3.0 32 Bit Medium Custom H264
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------




Zeit Anzahl der Instanzen in Zahl gleichzeitig nebeneinander AVX 1+2
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ryzen 9 7950x 1:12Mx2(72 Sekunden) 2 Nope



Ryzen 9 9950x 1:10 & 1:14(70 Sekunden & 74 Sekunden) 2 Nope

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Ergebnis
Es gabe nur durch andere Parameter leichte Verbesserung.Diese kann man auch unter dem 7950x produzieren.Einen richtigen Vorteil gab es nicht.AVX 1+2 ergab 2 Sekunden weniger Zeit.Angepasste Bitrate brachte rund 5 Sekunden beschleunigung.Ich habe nur nicht aufgepasst und das Falsche Ergebnis genommen.Das verfälschte Das Ergebnis Leider.
Es gab also keine 10% Mehrleistung.Wenn man es genau nimmt ohne diese ist es ein gleichstand.Die CPU braucht dennoch mehr Strom und wird heißer.Also nur Negatives Ergebnis.
Ich scheine wohl durch die kleinen Optimierungen mich gefreut zu haben.Also das war wohl ein falsches,ich habe mir nur was vor gemacht.
Damit bin ich sogar noch weiter abgeschlagen als es die Games es sind.Damit ist bewiesen das es unter nicht Games auch ein eher schlechtes Ergebnis gibt.Nun wird mal geschaut wie es ohne PBO aussieht.Ich erahne nix gutes,aber meine Neugier treibt mich voran.

[vinacis_vivids]

So was fehlt denn noch?

Deutsch - Integrationskurs von einem ordentlich ausgebildeten Lehrer.

[Lyka]

Wen von euch soll ich jetzt wegen Trolling sperren? :cool: Ich erwarte vernünftigen Umgang, hier ist nicht die Lounge oder das Powi.

[ashantus]

Latiose, danke für deinen Bericht. Es ist gut, Werte aus realen Anwendungen zu haben.

Anmerkung: es gibt Menschen, die Deutsch als Fremdsprache lernen! Da ist so ein langer Text schon anspruchsvoll.

[Lyka]

Anmerkung: flamebait entfernt. Sowas wie Linguistik soll gerne im eigenen Thread besprochen werden. oder auf https://new.reddit.com/r/ich_iel/

[Gipsel]

@latiose:
Sag' mal Deinem Kumpel, er soll PBO ausmachen! Dann zieht ein 9950X nie mehr als 200W (also maximal so viel wie der 7950X in dem Test) und dürfte auch etwas kühler bleiben als mit 270W.
Und was in Deiner Tabelle noch fehlt ist eine Performanceangabe für irgendeine Benchmark-Last. ;)

[latiose88]

@Gipsel

Hast du das so etwa gemeint gehabt oder anderst? Es dürfte nun alles Vollständig sein.Weitere Tests werden folgen,nur wann kann ich nicht sagen.Geplant war mal ohne SMT und dann mal ohne PBO .Das letzte wird mal als erstes gemacht.Wird interessant sein wie sich so die CPU Verhalten wird.Wird mit Takt,Temperatur usw dann nach geliefert.Denke mal Leistung wird sinken,das ist wohl zu erwarten.Ist ein normales Verhalten der CPU.Ich erwarte dann höchstens 5,1 -5,2 ghz aber könnte auch im Negativen überrascht sein,wie auch immer.Das sehen wir dann.Infos werden dann hier nach gereicht sobald ich mehr weis.Sollte im laufenden Interessiert sein dann notfalls auch mit Videos.Wie auch immer.Wunder erwarten ich nicht.Aber vielleicht geht ja ohne SMT noch 100-200 mhz mehr Takt.Aber sicher bin ich mir da nicht.

[Altehardware]

Die test der 9950x sind doch draußen und mit dem limit von 230w bei 95°c temp limit komt and a nicht höher als 4,8ghz allcore und partial bis 5,2ghz mehr gibt der node nicht her.
mag seind as der singlecore bis 5,6ghz takstet aber aucn nur in Singletrhead der geht aber willkürlich wandern was am windows shedulöer liegt.
So das die hohe Singlecoretakt sich nicht auswirken lässt. Da man zu hohe latenzen hat zwischen den ccd
Nahezu jedes neue spiel ist dx12 und die Zeiten von reinen singlecore spielen sind vorbei (dx9 und älter)
Latenzne sind viel wichtiger als hoher Takt.
PBO hilft kaum bis gar nicht da man in ein thermal limit rennt. und das geht deutlich schneller als mit einen ccd in MT Arbeit wie encoden dafür hilft avx512 was ein offset hat bis -400mhz
In ganzen ist der r9 9950x ein sehr gutes Arbeitstier und deutliche Effizinetr als der Vorgänger bei geringerem Takt
Großes plus bei avx Instruktionen sofern der code es auch nutzt
mit limit von 230w kommt die cpu nie in der näher von 90°c mit nenn lukü
Wenn braucht es da provozierte wärmequelle was aktuell kaum ein programm provoziert womit man was mit angfangen kann.
Encoder könnten das sein.

Als gamer kommt sowieso als bestes der x3d infrage

Erst zen6 2025 in n3 node wird die eprf auf +10% steigen lassen bei gleichem verbrauch. Udn wieder die realen 5,5ghz erreichen

Der schritt mit zen7 wird extrem da man auf nenn fullnode a18 wechselt und cowos apu baut keine cpu mehr.
Wahrscheinlich 2 ccd+ igp auf nenn SI chip bei 6,6ghz und 3,1ghz igp Takt und nenn 256bit Si auf n4 node

Der Nachfolger kommt erst 2029 im a12 node aber doppelte cu

konfig für den maxed chip
16 cores ohne smt 96cu 128alu per cu 3,1ghz grob 270w ppt auf am6
gut möglich das amd ein dual Si baut wo ddr5 und ddr6 laufen beides camm2 module
Sogar bis 512bit sind drin
Das ist nebenbei doppelt so schnell wie die aktuelle rtx4080
Das kommt q3 2027 und wird komplett die mid class bei amd auflösen. Womit nvidia vorn problem steht.
nebenbei die ps6 ist langsamer bei grob 67tf etwa rtx4090 perf 2027
Die kommende rtx5090 wird in etwa so schnell wie die igp von am6 high end apu
Annahme von aktuell 140sm bei 2,8ghz 104fp32 per sm grob 450w tbp

Die nächsten drei Jahre werden große Sprünge geben in allen gpu Klassen
entry sowie mid class ab 2027 nicht mehr als dgpu geben und nur noch high end 2028 an
Der Übergang wird alte gen rdna5 blackwell bis 2030 und wieder ne neue gen wo alle Klassen wieder gibt
Das hängt von intel ab ob die es schaffen ne neue arch zu designen wonach aktuell nicht aussieht und es am desktop nur noch apu geben wird.
dgpu wird es weiterhin geben aber nur noch high end bzw quadro Ableger. gpu ab 2000$

zuallererst muss intel mit arrow-lake liefern und wenn das nicht klappt ist Schicht im Schacht und der apu Weg ist sicher.
chips bis dahin

blackwell 2 gb202 bis gb207 von 300$ chip bis 40$ chip n4 node sf4 node(2024/2025) bis 100tf
blackwell 3 gb302 bis gb306 refresh in n3 250$ chip bis 50$ chip n3 node sf3 node (2026) bis 110tf
rubin 2 gr202 bis gr 205 von 300$ chip bis 150$ chip a18 node 2027 bis 223tf
Nachfolger gx202 gx203 nur 400$ chip a12 node 2029 bis 335tf bei 500w

amd
rdna4 2024 bis 64cu 29tf 240w tbp sf4 node
rdna5 2025 bis 192cu 3 gcd 90tf 450w
rdna6 2027 bis 216cu mit doppelte alu per cu 3gcd 190tf 290w tbp
rdna7 2029 bis 432cu 6 gcd 320tf 450w tbp

Wenn das so eintritt kauft keiner ab 2028 ne dgpu mehr am desktop abseits high end .
letzte 60 class vermutlich rtx6060 2026 grob 25tf 2026 450€
letzte 600 class rx9600xt 22tf 2026 unklar 400€

am6
zen7 wird apu ab 48cu bis 96cu von 44-81tf
zen8 doppelte cu 96-192cu von 80-160tf

Wie es weitergeht hängt dann von tsmc ab sicher ist das igp per die 160tf Marke bis zum so am7 bleiben wird was etwa 2032 sein wird
vermutlich bei a10 node auf nur noch 170w ppt sinken somit oc seitens amd auf 3,7ghz kommt bei 270w 190tf

Man kauft also am6 2028 mit 70tf und rüstet dann 2032 auf 150tf auf.
nvidia ist quasi raus.
Das mal der DIY markt quasi Konsolen Pc wird hätt ich nie gedacht aber danach sieht es aus.

[latiose88]

@altehardware.
also ich durfte das ja selbst testen. Ich gebe zu es gab Momente da stand nicht 5,4 GHz sondern kurz mal 5,3 GHz und auch mal kurz 5,2 GHz.
das die Leistung trotz 5,4 GHz nicht besser ist gehe ich mal davon aus das es an Temperatur Probleme liegt.
Ab wann drosselt denn AMD wirklich schon vor den erreichen von 95 Grad?
es reicht also schon aus wenn es 92 oder 93 grad heiß wird aus?
ich habe leider nur die ccx Temperatur gesehen nicht die einzelnen Kerne.
Das heißt es könnte schon sein das einzelne Kerne über die 95 Grad warm wurden also so im Inneren.
Es wird also Pbo wirklich als nächstes abgeschaltet als test. Ich habe einfach getestet bei dem und wusste nicht das Pbo ein war. Er wusste es wohl auch nicht. Gleich nach dem zuamen bauen und Windows 11 installieren durfte ich schon bei ihm es testen. Er hat bei den BIOS nix eingestellt.

Das es ohne was zu tuen mit aktiviert wäre das wundert mich doch sehr.

sicher ist auch meine Anwendung ist kein avx bei rund 3 % insgesamt avx ist das nix wo man stolz drauf sein sollte.
Wäre meine ne avx Anwendung würde das Ergebnis besser aussehen.
was mich wunder ist das bei mir Avx sogar Leistung kostet also beim 5950x. das zeigt durchaus das auch avx 1 und 2 bei AMD mit optimiert worden sind.
Nun ja das eigentliche Problem ist also nicht nur die Temperatur sondern auch die der sehr hohe Stromverbrauch. Der dürfte eigentlich nicht so hoch sein. Und naja stimmt eigentlich sollte eine luftkühlung ausreichen. Bei dem Ergebnis sehe ich aber schwarz das dieser es packen wird.

der Rest von dir ist nur raten. Wir wissen für die Zukunft nur sehr wenig.
Und nur noch Apu cpu das wäre schlecht für mich. Die ist deutlich schlechter als die jetzigen CPUs.
Für einen kleinen old-school Zocker wo ne nicht mehr aktuelle gpu.wustekfht und ne moderne Apu overpower gpu hätte bringt das dann leider nix weil ich mehr cpu Power als gpu Power brauchen werde.

Nun ja schau ma mal wie es in Zukunft aussehen wird.

Bei fehlender. Konkurrenz denke ich mal das wir bei den 16 kerner sitzen bleiben werden. AMD wird nur noch das nötigste tuen. ne weitere Optimierung bei den 16 Kernen sehe ich sehr wohl. Dann gibt es halt nur noch mongolische 16 kerner ohne chiplet. Mehr werden wir nicht serviert bekommen.

[Altehardware]

Für eine Monolithischen ccx mit 16 kerne ist die cache Struktur von zen ungeeignet
Das maxed sind eben 8 kerne daher erwarte ich da keine Änderung aber amd wird die 5c und später die 6c kerne bringen die kleinere fpu haben was die last am cache reduziert speziell designt für Effizienz
Dafür schwächer bei avx load.

Und ja raten ist das nur bedingt ich weis was amd an apu plant sicher ist nur das es sich nicht mehr lohnt amd desktop cpu only zu bringen da man zwangsweise auf cowos gehen wird und die server mehrere chiplets stapeln wird auf dem i/o die
Daher wird die planar chip design ab zen7 vorbei sein
Es hat nenn Grund warum amd am5 auf 2027 verlängert hat
Ob es dann auch zen7 auf am5 gibt ist offen wenn ja kann das die ersten 7,50ghz cpu sein. Dank a18 node inklusive x3d

Es steht und fällt mit intel core utra gen im okt.

[basix]

Und was ist dann bitte das 16C CCX von Zen 5c für Server? Ist ein "monolithisches" CCX. Und bei Zen 6 soll es auf max. 32C anwachsen. AMD hat hier mit Zen 5 anscheinend schon die Architektur-Grundlage gelegt, dass man auf mehr Cores pro CCX skalieren kann. Zen 1 & 2 waren auf 4 Cores limitiert. Zen 3 hat es auf 8C erhöht. Zen 5 wird es auf 16C erhöhen. Alles OK. Dabei wird bei Zen 5 sicher was an der Cache-Struktur verändert worden sein, was auch immer genau das ist (dazu haben wir momentan leider keine Infos).

[fondness]

Sowas ist immer ein Kompromiss zwischen Latenzen, Skalierung, Performance. Auch eine Sterntopologie skaliert nicht unendlich. Bei 128P Cores wie aktuell im Server-Bereich und 8-Core-CCX hat AMD bereits 16 CCX am Stern hängen. Durch die 16-Core-CCX bei den c-Cores kann man damit 192 Kerne mit nur 12 Teilnehmer realisieren. Bringt also vermutlich eine bessere Skalierung zwischen den CCX, kostet aber an Latenz und Performance innerhalb des CCX. Interessant wird die Topologie innerhalb des 16-Core-CCX, ob man 16 Cores auch noch mit Ringbus realisiert?

[robbitop]

AMD hat hier mit Zen 5 anscheinend schon die Architektur-Grundlage gelegt, dass man auf mehr Cores pro CCX skalieren kann.
Woran siehst du das?
So oder so stimme ich fondness da zu. Mehr geht immer - aber mehr Teilnehmer führen auch immer zu höheren Latenzen. Bei Hyperscalern wo Zen 5c zum Einsatz kommen wird, sollte das weniger ein Problem sein. Aber im Desktop kann das Performance kosten.

[basix]

Um ein CCX grösser zu machen wird man vermutlich Latenz-Regressionen haben (zumindest zum entfernten Teil des Caches) und allenfalls noch die Bandbreite pro Core reduzieren (damit die L3$ Daten-Busse nicht extrem breit werden müssen). There is no free lunch ;)

Aber man kann so viele Cores sicher nicht mit einem direkten Core-to-Core Interface realisieren wie damals noch bei den 4C CCX. Doch das wird AMD schon irgendwie lösen.

Woran siehst du das?
So oder so stimme ich fondness da zu. Mehr geht immer - aber mehr Teilnehmer führen auch immer zu höheren Latenzen. Bei Hyperscalern wo Zen 5c zum Einsatz kommen wird, sollte das weniger ein Problem sein. Aber im Desktop kann das Performance kosten.

Ich sehe das an gar nix ausser dass es 16C CCX für die Zen 5c Server Die geben wird. Ergo wird man eine Lösung für das Problem haben. Wie auch immer die Lösung aussieht. Das kann Performance kosten, klar. Das habe ich oben beschrieben.

Fakt ist aber, dass man hier den Ring oder was auch immer es bei Zen 5 ist ("Ladder" blabla) erweitert & skaliert werden kann. Ich nehme nicht an, dass dies bei Zen 3 & 4 bereits vorgesehen war (zumindest nicht in dem Ausmass, dass es anscheinend bei Zen 6 auf 32C hoch-skalieren kann).
Vielleicht ist es wie bei Intels früheren fetten Server-CPUs ein Dual-Ring. Oder ein Mesh. Beides halte ich für unwahrscheinlich. Vielleicht ist es ein partitionierter Cache wie bei Ampere und Blackwell (2-Segment LLC). Auch eher unwahrscheinlich. Vielleicht ist es eine Double-Butterfly oder (misaligned) Butter-Donut oder what not Struktur. Gibt viele potentielle Lösungen und auch massig Research dazu.
https://www.anandtech.com/show/16930/does-an-amd-chiplet-have-a-core-count-limit
https://www.eecg.utoronto.ca/~enright/micro14-interposer.pdf
https://www.eecg.toronto.edu/~enright/Kannan_MICRO48.pdf

Lustigerweise sind es im letzten Paper bis zu 64 Teilnehmer bei der Studie. Merh als genug für Zen 6 und wohl auch Zen 7+. Und dort braucht man beim Misaligned Butter-Donut nur 36 Links, hat eine hohe Bisection Bandwith und nur gerade mal 2.32 Hops im Durchschnitt. Wenn ich meine Karten auf etwas setzen müsste, wäre es wohl sowas in diese Richtung.

[Der_Korken]

Es gab Gerüchte, dass die Desktop-Modelle ab Zen 6 sich mit den mobilen Chips die Plattform bzw. Hardware teilen. Eventuell sind die unterschiedlichen Anforderungen an Topologien mit ein Grund dafür. Im Servern steigt der Core-Count unaufhaltsam weiter an, während wir im Desktop seit Zen 2 eine Stagnation bei 16 Kernen im Maximalausbau haben mit bisher wenig Nachfrage nach mehr. Dafür sind Latenzen dort sehr wichtig und zu gewissen Teilen auch Effizienz bei Teillast (spätestens bei Mobile). Ein großes CCX mit 2x8 Kernen könnte man natürlich bauen, aber da sind die Latenzen nochmal deutlich schlechter und sobald ein Kern arbeitet, muss der gesamte L3 mit befeuert werden.

Ich hatte schon, als Zen 4 gerade raus war, spekuliert ob wir nicht irgendwann sogar wieder kleinere CCXs sehen werden. Es könnten wie bei Apple jeweils vier Kerne einen mittelgroßen gemeinsamen L2 bekommen (so 8-16MB) und der L3 ist dann ein großer Offchip-LLC (oder gar SLC), auf den die 4er Cluster per Stacking draufgesetzt werden, um die physische Distanz zu verringern. Die Latenz des großen L3 wäre dann natürlich deutlich schlechter als beim jetzigen 3D-Cache, aber dafür hätte man eine massivst schnellere Kommunikation zwischen den CCXs, eine deutlich progressivere Skalierung möglicher Produkte (siehe das Dilemma von 7800X3D vs 7900X3D) und mehr Möglichkeiten fürs Power Management, z.B. indem man bei wenig Last immer nur ein 4er Cluster überhaupt aktiv hat und den L3 unabhängig von den Clustern runtertakten oder gar abschalten kann. Die einzelnen Cluster können zudem auch heterogen sein wie bei Strix Point, nur dass diesem der LLC/SLC unten drunter fehlt.

[robbitop]

Ich sehe den Nutzen von größeren CCX irgendwie nicht. Man kann doch mittels mehr CCX mehr Kerne haben und bei einem überschauhbaren CCX hat man dann gute Latenzen. Das beste aus beiden Welten.
Bei Zen5C für Hyperscaler macht es irgendwie schon Sinn, da man den L3 Cache dann weniger oft verbauen muss und man so pro mm² noch mehr Kerne hat und Latenzen kaum Nachteile haben.

Für die NonC bzw Desktop/Notebook CPUs/APUs bin ich aber noch nicht überzeugt, dass das der Weg ist.

[fondness]

https://www.eecg.toronto.edu/~enright/Kannan_MICRO48.pdf

Lustigerweise sind es im letzten Paper bis zu 64 Teilnehmer bei der Studie. Merh als genug für Zen 6 und wohl auch Zen 7+. Und dort braucht man beim Misaligned Butter-Donut nur 36 Links, hat eine hohe Bisection Bandwith und nur gerade mal 2.32 Hops im Durchschnitt. Wenn ich meine Karten auf etwas setzen müsste, wäre es wohl sowas in diese Richtung.

Ja, das Paper hab ich auch schon gesehen. Nachdem da ja sogar AMD mitgearbeitet hat nicht unwahrscheinlich.

[latiose88]

Der strix point mag zwar der naheliegende schritt sein aber schaut man sich die Leistung an diese ist deutlich schlechter als die Desktop CPU. Also die Leistung erinnert mich eher an ein 4 Kerner als von mehr und das obwohl stid point 12 Kerne hat. Klar so ne Anwendung wie ich es verwende reagiert allergisch auf weniger cache und der allcore takt ist auch noch ne Sache. beides zusammen wenn es nicht passt reduziert massiv die leistung. Die große der Cache nach oben brachte jedoch keine Steigerung mehr an. Ich denke mal nach oben hin reicht der Speicher für die CPU völlig aus. Und so skaliert es nicht mehr nach oben durch noch mehr cache.
würde es einen massiven plus geben,wären die x3d auch bei nicht games massiv angestiegen. Dem ist halt leider nicht der Fall. Kann man eben nix machen.

[basix]

Ich sehe den Nutzen von größeren CCX irgendwie nicht. Man kann doch mittels mehr CCX mehr Kerne haben und bei einem überschauhbaren CCX hat man dann gute Latenzen. Das beste aus beiden Welten.
Bei Zen5C für Hyperscaler macht es irgendwie schon Sinn, da man den L3 Cache dann weniger oft verbauen muss und man so pro mm² noch mehr Kerne hat und Latenzen kaum Nachteile haben.

Für die NonC bzw Desktop/Notebook CPUs/APUs bin ich aber noch nicht überzeugt, dass das der Weg ist.

Grössere CCX reduzieren den CCX <-> IOD Traffic und die Anzahl Infinity Fabric Teilnehmer (was fondness hier bereits gesagt hat (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13600386#post13600386)). Man entlastet damit also das IOD und den ganzen Fabric. Irgendwo ist auch der Fabric an der Skalierungsgrenze, dann macht man besser die CCX wieder grösser.

Ein weiterer Vorteil ist der grössere L3$ Pool. Das bringt für wissentschaftliche & HPC Zwecke was (siehe Milan/Genoa-X) und natürlich was für Games. Und zudem für das momentan "wichtigste", nämlich ML/AI (siehe z.B. Phoronix (https://www.phoronix.com/review/amd-epyc-9684x-benchmarks) Zitat unten). Man kann das je nach Workload als "Mini V-Cache" ansehen, wenn sich die L3-Kapazität verdoppelt. Ist natürlich nicht Sortenrein, da man auch doppelt so viele Cores füttern muss. Aber gibt bestimmt Workloads, wo es sich positiv auswirken wird.
Of the benchmarks run focused on the HPC/AI workloads, the EPYC 9684X processor easily stole the show.

Games, ML/AI usw. ist für Desktop & Notebook relevant. Nicht nur Server werden ML/AI Workloads befeuern. Und für vieles Business Zeugs & Workstation ist ein grosser LLC ebenfalls relevant (Simulation wie CFD, CAD, ML/AI, ...).

Für Notebooks wird das mit mehr L3-Cache aber nur was, wenn man die CCD Chiplets verwendet. Sobald es monolithisch wird, wird AMD die Cache-Grösse wohl wieder reduzieren / pro Core halbieren. Wäre unter dem Strich aber dann dennoch 24-32 MB LLC bei 12-16C anstatt heute 16MB für das "Haupt-CCX".
Für Notebooks und generell einen sehr grossen L3-Cache wäre auch ein partielles Clock-Gating ideal. Also dass man z.B. 1MByte Blöcke des Caches abschalten kann und somit je nach Workload Energie sparen kann (Idle, Background, Low Intensity, 1-2T Workloads).

[Altehardware]

Ai ist ne dicke Blase die sehr bald platzen wird
Ja es hat nenn nutzen wird aber wegen der kaum nützlichen Anwendungen eher in Richtung Berater bei cloud Anwendungen genutzt werden.
Lokal am eigenen pc macht das kaum bis keinen Sinn und ob sich die Ai PC durchsetzen ist stark anzuzweifeln

[robbitop]

Grössere CCX reduzieren den CCX <-> IOD Traffic und die Anzahl Infinity Fabric Teilnehmer (was fondness hier bereits gesagt hat (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13600386#post13600386)). Man entlastet damit also das IOD und den ganzen Fabric. Irgendwo ist auch der Fabric an der Skalierungsgrenze, dann macht man besser die CCX wieder grösser.

Ein weiterer Vorteil ist der grössere L3$ Pool. Das bringt für wissentschaftliche & HPC Zwecke was (siehe Milan/Genoa-X) und natürlich was für Games. Und zudem für das momentan "wichtigste", nämlich ML/AI (siehe z.B. Phoronix (https://www.phoronix.com/review/amd-epyc-9684x-benchmarks) Zitat unten). Man kann das je nach Workload als "Mini V-Cache" ansehen, wenn sich die L3-Kapazität verdoppelt. Ist natürlich nicht Sortenrein, da man auch doppelt so viele Cores füttern muss. Aber gibt bestimmt Workloads, wo es sich positiv auswirken wird.


Irgendeinen Tod muss man sterben. Für mich gibt es da keinen offensichtliches Auskommen (überwiegende Vorteile ggü den Nachteilen einer der Lösungsvarianten), aus dem folgt, dass CCX bei allen CCD Konfigurationen größer werden müssen. Und solange das CCX groß genug ist, gibt es für viele Anwendungen ja gar nicht so viel inter CCX traffic. Und zumindest am PC scheint es aktuell kaum bis keine Anwendung zu geben, wo die CCX Größe großartig zu limitieren scheint. Mit den damaligen 4C CCX clustern war das der Fall. Das kann sich natürlich ändern, wenn Software mehr und mehr Threads nutzt (die viele Abhängigkeiten voneinander haben - ansonsten ist es auch wieder irrelevant).

IMO sieht es so wie es jetzt ist schon ziemlich gut balanciert aus. Man bezahlt zwar mit dem IOD und dem Mehfachen L3 für die Skalierbarkeit hat aber eine hervorragende mittlere effektive Speicherlatenz (insbesondere mit den VCachemodellen - gemeint mit Speicherlatenz ist im Mittel wie lange es dauert aus dem Speicher Daten zu holen inkl der Cachehitrate).
Will man jetzt die CCX größer machen ohne Performance in vielen Anwendungen zu verlieren, müsste zum Ausgleich der L3 wieder deutlich größer werden und wahrscheinlich auch kleinere Cache Stufen. Und SRAM skaliert leider kaum noch mit Shrinks - also das ist etwas was man nicht unbedingt weiter vergrößern muss. Der IOD hingegen kann legacy Prozesse nutzen und da ist es weniger dramatisch mm² zu investieren für IF Links.

Hinzu kommt: am PC profitiert man jetzt auch nicht gerade großartig von deutlich mehr als 16C/32T. Entsprechend ist auch gar nicht der Bedarf unbedingt da mehr IF links zu verbauen.

[basix]

Ai ist ne dicke Blase die sehr bald platzen wird
Ja es hat nenn nutzen wird aber wegen der kaum nützlichen Anwendungen eher in Richtung Berater bei cloud Anwendungen genutzt werden.
Lokal am eigenen pc macht das kaum bis keinen Sinn und ob sich die Ai PC durchsetzen ist stark anzuzweifeln
AI wird kommen und bleiben. Auch lokal. Das sind nicht die riesigen LLM Geschichten sondern relativ kleine "Helfer-Netzwerke", die gewisse Dienste anbieten oder verbessern. Du kannst dir das wie DLSS vorstellen: Ein Teil einer Anwendung wird durch ML/AI "augmentiert", womit man die Gesamtlösung verbessert. Und wenn ich sehe, wie viel schneller dadurch zum Teil Simulationen im wissentschaftlichen und CAD Bereich werden (mit relativ kompakten Netzwerken da Narrow-Target und entsprechend geringen TOPS- und Speichermengen-Anforderungen, physical informed DNN usw.) ist das auch sehr bald monetär im Business-Bereich ein No-Brainer. Dito bei Software-Coding, wenn es da mal was kompakteres als die heutigen LLM gibt.

Irgendeinen Tod muss man sterben. Für mich gibt es da keinen offensichtliches Auskommen (überwiegende Vorteile ggü den Nachteilen einer der Lösungsvarianten), aus dem folgt, dass CCX bei allen CCD Konfigurationen größer werden müssen. Und solange das CCX groß genug ist, gibt es für viele Anwendungen ja gar nicht so viel inter CCX traffic. Und zumindest am PC scheint es aktuell kaum bis keine Anwendung zu geben, wo die CCX Größe großartig zu limitieren scheint. Mit den damaligen 4C CCX clustern war das der Fall. Das kann sich natürlich ändern, wenn Software mehr und mehr Threads nutzt (die viele Abhängigkeiten voneinander haben - ansonsten ist es auch wieder irrelevant).

IMO sieht es so wie es jetzt ist schon ziemlich gut balanciert aus. Man bezahlt zwar mit dem IOD und dem Mehfachen L3 für die Skalierbarkeit hat aber eine hervorragende mittlere effektive Speicherlatenz (insbesondere mit den VCachemodellen - gemeint mit Speicherlatenz ist im Mittel wie lange es dauert aus dem Speicher Daten zu holen inkl der Cachehitrate).
Will man jetzt die CCX größer machen ohne Performance in vielen Anwendungen zu verlieren, müsste zum Ausgleich der L3 wieder deutlich größer werden und wahrscheinlich auch kleinere Cache Stufen. Und SRAM skaliert leider kaum noch mit Shrinks - also das ist etwas was man nicht unbedingt weiter vergrößern muss. Der IOD hingegen kann legacy Prozesse nutzen und da ist es weniger dramatisch mm² zu investieren für IF Links.

Hinzu kommt: am PC profitiert man jetzt auch nicht gerade großartig von deutlich mehr als 16C/32T. Entsprechend ist auch gar nicht der Bedarf unbedingt da mehr IF links zu verbauen.
8C ist für Client sicher eine gute Grösse. Aber wir reden hier von den nächsten 5+ Jahren oder so. Da wird sich das Anforderungsprofil auch bei Client ändern. Ich denke es macht sogar Sinn, bei Zen 6 & 7 bei max. 16C zu bleiben aber dafür ist das CCX Unified. Dann halt nur noch max. 1x CCD und nicht mehr 2x. Das wird in einigen Workloads was bringen (Games im besonderen), reduziert die Anzahl IFOP Interfaces (weniger Overhead durch Chiplets, einfacheres Packaging) und man wird bei 16C noch nicht von der DDR5 Bandbreite limitiert. Sobald man auf DDR6 wechselt (Zen 8+), kann man evtl. bis max. 32C hochskalieren, wobei das 16C Chiplet dann die Standardlösung wäre (wie heute das 8C Chiplet). Zen 8 ist ein ~2029/2030 Thema und somit +10 Jahre zu Zen 3. Eine Core-Verdopplung bei Client von gerade Mal 2x ist hier jetzt nicht so krass ;)

Noch zur Cache-Skalierung:
N3 ist schon teuer und N2 wird noch teurer. Deswege vermute ich, dass man ab Zen 7 auf 3D-Stacking wechseln wird. Base Die in evtl. N3/N4 mit IO-Interface zum IOD, L3-Cache sowie Deep Trench Capacitors (Power Delivery Decoupling, siehe Graphcores BOW IPU mit WoW Stacking) und oben drauf die Compute Chiplets in N2P, A16. Daneben noch wie gehabt ein IOD mit Speicherinterface, iGPU usw.

[Altehardware]

Und woher soll die Statistik die Daten herbekommen?
Das muss trainiert werden aktuell gibt es keine Ai die Ohne Datenpool funktioniert das marketing macht aus Mathematik ai was diese nicht ist das sind algos etwa wie das dlss
Da ist nix deep learning
Das LLM gibt die auch funktionieren sieht man anhand der Bildgeneratoren Simultanübersetzer und Video editieren was mehr meh funktioniert
Video upscaler gehen aktuell auch nicht wirklich da Bezugsmaterial fehlt worauf man das Modell trainiert.
Daher ist das mehr ein Raten welche Farbe Helligkeit und schärfe das nächste pixel hat. Da ist mehr Mathe drin als Statistik
Und so ziemlich das Sinnvollste für eine LLM.

[basix]

Wieso ist das nicht Deep Learning? Man trainiert das Netz ja im vornherein auf einer grossen Datenmenge und einer Ground Truth und appliziert das Netzwerk lokal auf einen viel kleineren Datensatz. Macht z.B. DLSS ja auch, da werdn zig Spiele und Auflösungen usw. fürs Training verwendet.

Und dann eben z.B. Physics Informed DNN, wo man physikalische Gegebenheiten via DNN viel schneller approximieren kann als z.B. mit voller Präzision zu simulieren oder auch verglichen mit Monte Carlo Sampling. Ein riesiger Gewinn für sehr viele Anwendungen, was Performance anbelangt.

Und dann gibt es noch adaptive Algorithmen, welche sich on-the-fly antrainieren können. Schon mal was von Neural Radiance Caching gehört? Das DNN passt in den L1 Cache einer Nvidia GPU (128kByte). Jetzt kann man sich darüber streiten, ob das noch ein DNN ist oder nur ein massiv parallelisiertes NN. Das Grundprozedere ist aber das selbe und die Vorteile aufs Resultat sind auch da.

[robbitop]

8C ist für Client sicher eine gute Grösse. Aber wir reden hier von den nächsten 5+ Jahren oder so. Da wird sich das Anforderungsprofil auch bei Client ändern. Ich denke es macht sogar Sinn, bei Zen 6 & 7 bei max. 16C zu bleiben aber dafür ist das CCX Unified. Dann halt nur noch max. 1x CCD und nicht mehr 2x. Das wird in einigen Workloads was bringen (Games im besonderen), reduziert die Anzahl IFOP Interfaces (weniger Overhead durch Chiplets, einfacheres Packaging) und man wird bei 16C noch nicht von der DDR5 Bandbreite limitiert. Sobald man auf DDR6 wechselt (Zen 8+), kann man evtl. bis max. 32C hochskalieren, wobei das 16C Chiplet dann die Standardlösung wäre (wie heute das 8C Chiplet). Zen 8 ist ein ~2029/2030 Thema und somit +10 Jahre zu Zen 3. Eine Core-Verdopplung bei Client von gerade Mal 2x ist hier jetzt nicht so krass ;)

Noch zur Cache-Skalierung:
N3 ist schon teuer und N2 wird noch teurer. Deswege vermute ich, dass man ab Zen 7 auf 3D-Stacking wechseln wird. Base Die in evtl. N3/N4 mit IO-Interface zum IOD, L3-Cache sowie Deep Trench Capacitors (Power Delivery Decoupling, siehe Graphcores BOW IPU mit WoW Stacking) und oben drauf die Compute Chiplets in N2P, A16. Daneben noch wie gehabt ein IOD mit Speicherinterface, iGPU usw.
Also ob man im Gaming schneller wird denke ich nicht. Die Latenz zwischen den Kernen und zum L3 wird größer. Auch die Memorylatenz wird größer (mehr hops bis zum IF link). Wo soll da der Performancegewinn herkommen? Oder meinst du man würde statt 2x 32 MiB dann 1x 64MiB verbauen? Dann wäre die Flächenersparnis aber kaum da. Und mit X3D hast du ja heute schon 96 MiB pro CCD und wesentlich mehr wird dann auch kaum noch mehr bringen (abnehmender Grenzertrag).

So schnell wird man IMO keinen Vorteil (selbst ohne intra CCX Latenzeinbußen) zwischen einem 2x CCX CCD und einem 1x CCX CCD haben.

[basix]

Die Latenz zum L3 wird vermutlich leicht grösser, ja. Aber anhand des V-Caches sieht man ja, dass die grössere Kapazität das locker kompensiert. Und ja, ich meine hier einen 1x 64MB Cache. Und dort erwarte ich keine Flächenersparnis bei Cache selber, sondern dass man anstatt 4x IFOP PHY (2x CCD, 2x IOD) nur noch 2x Interfaces benötigt (1x CCD, 1x IOD). Auf dem CCD hat es noch Teststrukturen & Power Management drauf, was man auch nur noch 1x benötigen würde. Chiplets haben immer einen gewissen Overhead zur Folge, welcher mit einem Single-CCD Ansatz verringert wird. Desktop würde dann ein 8C und 16C Chiplet verwenden, aber immer nur 1x aufs Mal. Von dort käme die Flächenersparnis.

V-Cache kann man hier dann immer noch on-top machen. Es ist nicht so, dass man das dann nicht mehr macht oder machen kann. Wie das mit dem Grenzertrag aussieht ist schwer zu sagen. Heute bringen 32 -> 96Mbyte Cache im Schnitt +30% Performance (wenn man die Taktregression rausrechnet). Von 64 -> 192MByte wären es sicher weniger, aber bestimmt >10%. Evtl. sogar immer noch +20%. Das liegt im Rahmen einer vollen CPU Generation und ist deswegen schon lohnenswert.

Das mit den mehr Hops habe ich aber nicht verstanden, wie meinst du das? Vom IF-Fabric her geht es immer zuerst in den L2$, da der L3 ein Victim Cache ist. Wüsste nicht, wieso es dort bei Speicher / DRAM-Zugriffen zu höheren Latenzen kommen sollte.

[robbitop]

Nach meinem Verständnis ist die Topologie des CCX ein bidirektionaler Ring aktuell. Dort hast du Core 0 - Core n + die L3 slices + den IFOP der die Kommunikation nach außen (zum IOD und zu anderen CCX).
Je mehr Teilnehmer im CCX, desto mehr hops vom Core bis zum IFOP. Und damit extra Latenz für den Speicherzugriff.

Für mich löst sich das CCX Konzept irgendwie auf je mehr man es verwässert. Wozu dann noch CCX wenn man Teilnehmer im CCX "hochspamt"? Der CCX wurde eingeführt um Skalierbarkeit und Latenz gleichzeitig zu bieten (auf Kosten von SRAM für viel lokalen Cache damit die mittlere Memorylatency gut wird). Ab einem bestimmten Punkt kann man die CCX dann auch sein lassen und wieder eine große Topologie für alles machen, oder?

[Der_Korken]

Und solange das CCX groß genug ist, gibt es für viele Anwendungen ja gar nicht so viel inter CCX traffic. Und zumindest am PC scheint es aktuell kaum bis keine Anwendung zu geben, wo die CCX Größe großartig zu limitieren scheint. Mit den damaligen 4C CCX clustern war das der Fall. Das kann sich natürlich ändern, wenn Software mehr und mehr Threads nutzt (die viele Abhängigkeiten voneinander haben - ansonsten ist es auch wieder irrelevant).

Für 6 Kerne ist dieser Punkt imho längst erreicht. Sowohl bei und [url=https://www.computerbase.de/2024-08/ryzen-9-9950x-ryzen-9-9900x-gaming-performance/2/#abschnitt_gamingbenchmarks_mit_einer_geforce_rtx_4090]9600X vs 9700X vs 9900X (]7800X3D vs 7900X3D[/url) sieht man, dass 6C-CCXs in Spielen bereits heute zum Nachteil werden. Zu Zen-2-Zeiten war es eher so, dass drei Kerne pro CCX zu wenig waren. Deswegen hat ein 3300X mit 4C in einem CCX damals öfter den 3600 in Spielen nass gemacht.

Irgendwann werden 8C pro CCX auch limitieren. Ob die Antwort dann 16C pro CCX sind oder eine Verschiebung der Hierachiestufen, wie ich oben vorgeschlagen habe, wird man sehen. Letzteres hätte den Vorteil, dass man auch gleich was hat, was auf 24C skaliert ohne wieder die in Nachteile der heutigen 2-CCX-Modelle zu laufen (wenn man z.B. 12+12 oder 16+16 baut).

Edit:

Für mich löst sich das CCX Konzept irgendwie auf je mehr man es verwässert. Wozu dann noch CCX wenn man Teilnehmer im CCX "hochspamt"? Der CCX wurde eingeführt um Skalierbarkeit und Latenz gleichzeitig zu bieten (auf Kosten von SRAM für viel lokalen Cache damit die mittlere Memorylatency gut wird). Ab einem bestimmten Punkt kann man die CCX dann auch sein lassen und wieder eine große Topologie für alles machen, oder?

Das Konzept ist ja nicht auf ewig in Stein gemeißelt. Intel geht ja anscheinend den Weg, dass sie einen großen LLC haben wollen aber nur wenige schnelle Cores auch direkten "VIP-Zugriff" bekommen. Die E-Cores hängen zu viert an einem Zwischencache (aus deren Sicht L2), über den sie sich einen Port am großen LLC teilen müssen. Dadurch bekommt man viele Cores ohne dass der LLC zu viele Teilnehmer bedienen muss und dadurch zu langsam wird.

[Zossel]

Irgendwann werden 8C pro CCX auch limitieren. Ob die Antwort dann 16C pro CCX sind oder eine Verschiebung der Hierachiestufen, wie ich oben vorgeschlagen habe, wird man sehen. Letzteres hätte den Vorteil, dass man auch gleich was hat, was auf 24C skaliert ohne wieder die in Nachteile der heutigen 2-CCX-Modelle zu laufen (wenn man z.B. 12+12 oder 16+16 baut).

Aus meiner Sicht wäre auch die Frage offen ob mehrere Caches/CCXs in Spielen überhaupt ein großer Nachteil sind, wenn ein Großteil der Zugriffe nur lesend sind und daher die selben Daten in mehreren Caches gleichzeitig liegen können sollten sich die Nachteile in Grenzen halten.

[basix]

Prinzipiell hast du da Recht, wenn die Threads die Daten unabhängig voneinander bearbeiten können und/oder die Daten nur lesend benötigt werden. Doch ich nehme an, dass das in Spielen nur begrenzt der Fall ist.

Ein 7950X ist nicht schneller als ein 7700X. Ein 7800X3D ist aber deutlich schneller. Das legt nahe, dass die Datenlatenz der Haupt-Hemmschuh ist (wenige Threads und/oder voneinander abhängige Tasks). Sonst müsste der 7950X schneller sein, da er theoretisch die doppelte Cache-Menge hat. Nur bringt das in Spielen gar nichts. CCD zu CCD liegt eher im Bereich von DRAM Latenz (evtl. etwas niedriger), deswegen gewinnst du dort nichts da kannst du gleich aus dem DRAM laden.

Nach meinem Verständnis ist die Topologie des CCX ein bidirektionaler Ring aktuell. Dort hast du Core 0 - Core n + die L3 slices + den IFOP der die Kommunikation nach außen (zum IOD und zu anderen CCX).
Je mehr Teilnehmer im CCX, desto mehr hops vom Core bis zum IFOP. Und damit extra Latenz für den Speicherzugriff.

Für mich löst sich das CCX Konzept irgendwie auf je mehr man es verwässert. Wozu dann noch CCX wenn man Teilnehmer im CCX "hochspamt"? Der CCX wurde eingeführt um Skalierbarkeit und Latenz gleichzeitig zu bieten (auf Kosten von SRAM für viel lokalen Cache damit die mittlere Memorylatency gut wird). Ab einem bestimmten Punkt kann man die CCX dann auch sein lassen und wieder eine große Topologie für alles machen, oder?
Technologie entwickelt sich ;)

AMD hat mit einem 4C CCX begonnen. Bei Zen 2 hat man die L3 Cache Grösse verdoppelt und keine grossen Latenznachteile gehabt. Bei Zen 3 ist man auf 8C und 32MB hoch und auch dort hat die Latenz nicht gelitten. Was ist jetzt so unmöglich, hier nochmals zu verdoppeln? Für das sind die oben verlinkten Papers mit entsprechenden Interconnect Topologien ja genau gedacht: Netzwerk mit möglichst minimaler Latenz (wenige Hops) und maximaler Bandbreite bei möglichst geringem Aufwand für Silizium-Fläche und Energieverbrauch.

Und das CCD / CCX Konzept ist wegen dem ja nicht gestorben. Man hat immer noch Chiplets im Bereich 70...100mm2 und relativ grosse LLC, um Memory Traffic zu buffern. Macht man die CCX jetzt grösser ist das mMn nur ein Skalierungs-Hebel, welchen man schon länger nicht mehr in die Hand genommen hat. Das letzte Mal bei Zen 2 zu Zen 3.
Und es entlastet das IOD. Du wirst sehen, mit so vielen Cores wird Datentransfer übers IOD und auch die Speicherbandbreite immer mehr zum Bottleneck. Mit grösseren CCX kann man dem ebenfalls entgegen wirken.

Und nochmals zum IFOP: Man hängt dort am L2-Cache. L3 ist ein Victim Cache. Also umso mehr Teilnehmer im CCX, desto mehr Ports und Bandbreite muss man beim IFOP haben. Aber die Anzahl Hops bleibt gleich, nämlich 1 (Direktverbindung). Da Zen 6 auf ein neues IFOP / Packaging Schema wechseln wird, eher sowas wie bei RDNA3 von der physischen Implementierung her zwischen GCD und MCD, wird man das Interface viel breiter machen können. Deswegen sind mehr Cores dann auch kein Problem.

Edit:
Was ausserhalb eines grösseren L3$ etwas bringen würde wäre, wenn man viel latenzärmer auf die umliegenden CCD zugreifen könnte. z.B. wenn man 20ns anstatt 50ns Zugriffszeit hätte. Dann könnte man den Cache von anderen CCD effektiver nutzen.

[HOT]

Nicht umsonst soll Zen6 je genau hier ansetzen und die heutige Träger-Verbindung durch 2,5D-Stacking ersetzen. Dann sieht die CPU nicht viel anders aus als jetzt, außer, dass die Chips alle direkt nebeneinander liegen und miteinander verbunden sind.

[basix]

Genau, bei RDNA3 nennt sich das Infinity Fanout Link.

[][immy]

Die CCXs sind doch eigentlich nur für eine einfachere Fertigung da. Einmal etwas "einfaches" designen und dann multiplizieren.
Je größer etwas wird, desto komplizierter wird das ganze. Mehr cores sind auch nicht die Dauerlösung wenn es um Latenzen zwischen den Kernen geht, denn irgendwann limitieren die Leitungen dazwischen oder die Bandbreite an den Cache etc. Das Handling wird halt immer komplizierter je mehr Teilnehmer es gibt.

Daher ist das CCXs CCD Konzept erst mal nur als Vereinfachung zu verstehen.
Intel kam auch mit seinem rimgbus an Grenzen heran, wo es neue Ideen bräuchte.

Zudem fällt das eigentlich nur ins Gewicht, wenn Aufgaben auf andere Kerne verschoben werden. Ggfs. muss sich hier in Zukunft einfach mal was ändern, das dies nicht mehr so häufig passiert. Wenn genug Kerne da sind müsste der scheduler im Grunde auch nicht ständig Aufgaben an hin und her schieben, und stattdessen dem Kern einfach weniger zu tun geben bis er wieder Zeit hat (vereinfacht ausgedrückt).

Und besonders im gaming Bereich skaliert es oberhalb von 6 Kernen kaum mehr und ab 8 quasi nicht mehr. Ausnahmen mag es geben, silber ich stelle schon lange die Sinnhaftigkeit dieser ganzen Threads in Frage, denn gameplay und ki seitig tut sich quasi kaum mehr was, da kann man sich schon fragen wofür die ganze CPU Zeit überhaupt drauf geht.

Schlussendlich scheint es heute nicht mehr möglich zu sein so etwas wie c&c zu entwickeln, ohne das da massig cores bei drauf gehen und die Gegner ki ist dann immernoch auf skripting angewiesen. Und das hab ich damals auf einem 486 SX mit 25 mhz gespielt...
Nur die Grafik scheint Fortschritte gemacht zu haben, aber auch da tut sich gefühlt nicht mehr viel seit Jahren, wobei auch die Frage ist, ob es das muss, denn Realität ist doch irgendwie langweilig auf dem Bildschirm ;)

[mczak]

AMD hat mit einem 4C CCX begonnen. Bei Zen 2 hat man die L3 Cache Grösse verdoppelt und keine grossen Latenznachteile gehabt. Bei Zen 3 ist man auf 8C und 32MB hoch und auch dort hat die Latenz nicht gelitten.
Keine Latenznachteile ist schon etwas übertrieben - Zen 2 hatte 39 Zyklen L3 Latenz, Zen 3 46 (das sind die offiziellen Zahlen, die Messungen bestätigen das auch). Zen 3 hatte im Prinzip auch eine Regression bezüglich Bandbreite - die L3 Gesamtbandbreite pro CCX blieb gleich, also nur halb so viel pro Kern.
Für Zen 1 habe ich gerade keine offizielle Latenz für den L3 gefunden, war aber laut Messungen etwa 5 Zyklen schneller als bei Zen 2.
Die Prozessoren haben aber natürlich auch Fortschritte gemacht um die Latenzen besser zu verstecken (Load-Queues, Prefetcher, ...), Vergrösserung des L2 (erst bei Zen 5 (edit: Zen 4)) hilft natürlich auch, aber die rohe Latenz leidet eben schon. Wobei intel hat bei den Coves nochmal deutlich höhere L3 Latenz als die Zens, und leidet nicht wirklich darunter, ein grösserer (und von mehr Kernen geshared) L3 könnte sich also trotzdem lohnen (wobei intel jetzt auch 2 MB L2 pro Kern hat).

[horn 12]

https://videocardz.com/newz/amd-ryzen-9000x3d-with-3d-v-cache-now-expected-to-launch-in-january

AMD X3D Launch der 9000-er Serie zur CES 2025 Frühestens
und Release Ende Jannuar - bis Anfang Februar.

[fondness]

https://videocardz.com/newz/amd-ryzen-9000x3d-with-3d-v-cache-now-expected-to-launch-in-january

AMD X3D Launch der 9000-er Serie zur CES 2025 Frühestens
und Release Ende Jannuar - bis Anfang Februar.

Überraschung....nicht.

[basix]

Keine Latenznachteile ist schon etwas übertrieben - Zen 2 hatte 39 Zyklen L3 Latenz, Zen 3 46 (das sind die offiziellen Zahlen, die Messungen bestätigen das auch). Zen 3 hatte im Prinzip auch eine Regression bezüglich Bandbreite - die L3 Gesamtbandbreite pro CCX blieb gleich, also nur halb so viel pro Kern.
Für Zen 1 habe ich gerade keine offizielle Latenz für den L3 gefunden, war aber laut Messungen etwa 5 Zyklen schneller als bei Zen 2.
Die Prozessoren haben aber natürlich auch Fortschritte gemacht um die Latenzen besser zu verstecken (Load-Queues, Prefetcher, ...), Vergrösserung des L2 (erst bei Zen 5) hilft natürlich auch, aber die rohe Latenz leidet eben schon. Wobei intel hat bei den Coves nochmal deutlich höhere L3 Latenz als die Zens, und leidet nicht wirklich darunter, ein grösserer (und von mehr Kernen geshared) L3 könnte sich also trotzdem lohnen (wobei intel jetzt auch 2 MB L2 pro Kern hat).

Ja richtig, ein paar Cycles Regression hatte man jeweils. Aber das macht der deutlich grössere Cache-Pool aber in den meisten Fällen wieder wett. Stichwort "Effektive Latenz". Man muss hier immer auch den Penalty zum DRAM im Hinterkopf behalten, wenn man aus dem L3 rausfällt. Und neuere Cores können typ. die Latenz besser verstecken. Und dann bei Zen 4 der grössere L2 und bei Zen 5 der grössere L1D. Bis jetzt sehe ich jedenfalls nirgends, dass der grössere L3$ zu wesentlichen Performance-Einbussen geführt hätte. Positive Beispiele sind eher die Regel als die Ausnahme. Deswegen kann es gut sein, dass bei 64MByte die Latenz ein paar Cycles ansteigen wird, das aber nicht wirklich negativ bemerken wird.

Aber Zen 3 hat doch gar keine Bandbreiten-Regression bei L3? Ich sehe immer noch 32Byte/Cycle zwischen L2 und L3 (für jeden Core). Und wenn ich Zen 4 anschaue stimmt es auch in etwa, wenn man den Taktunterschied zu Zen 2 rausrechnet. Seit Zen 1 ist die L2 <-> L3 Bandbreite bei 32 Byte/Cycle

[RitterRost]

Gut, dass der Zen5X3D später kommt.
Vielleicht kann AMD bis dahin etwas an der kaputten Zen5 Performance unter Windows fixen...

Wurde denn das hier schon diskutiert?
https://wccftech.com/amd-ryzen-9000-gaming-performance-update-revised-testing-parity-intel-14th-gen-cpus-optimized-branch-prediction-boost/

Ich sehe immer noch nicht, wie AMD zu ihren Zen5 Leistungswerten in der Computex 2024 Präsentation gekommen ist.

[Nuon]

Eine ähnliche Meldung gibt es bei Golem:
https://www.golem.de/news/ryzen-9000-prozessoren-windows-update-verbessert-zen-5-performance-2408-188276.html

Im Build-26100 der Insider-Version von Windows 11 ist der optimierte Code für die Sprungvorhersage für normale Nutzeraccounts implementiert, wodurch die Leistungsangaben von AMD reproduzierbar sein sollen. Laut AMD sind die Zen-5-CPUs dann im Durchschnitt 5 bis 8 Prozent schneller in Spielen, 10 Prozent in Produktivanwendungen und bis zu 25 Prozent schneller in KI-Anwendungen.

[latiose88]

anderst sieht es auch dann bei Anwendung aus wo nicht mehr so stark vom Cache abhängig sind. Wo schlechtere Latenz nicht so ne Wirkung haben.
in dem Fall hat größerer Cache ebenso keine Wirkung bei Leistung. Hat alles vor und nach Teile. Wenn das aber dann von anderen Punkten dann abhängig ist, kann das schon auf +-0 führen wenn es doof läuft.

[Der_Korken]

Überraschung....nicht.

Naja, was wäre an frühen 3D-Modellen unerwartet gewesen? Zen 5 ist in seiner jetzigen Form ein Ladenhüter und bis zur CES ist Arrow Lake draußen und hat schon Kundschaft abgegriffen. Im Gegensatz zu Zen 4 ist AMD hier in keiner Position, wo sie sandbaggen könnten.

[dildo4u]

Intel wird kein Killer Modell haben der i9 wird deutlich die beste Gameing Leistung haben aber über 600€ kosten.

Ich tippe drauf das das 300€ I5k Modell den 14900K erreicht was gut klingt aber mit dem 7800X3D abgedeckt wird.

[mczak]

Aber Zen 3 hat doch gar keine Bandbreiten-Regression bei L3? Ich sehe immer noch 32Byte/Cycle zwischen L2 und L3 (für jeden Core). Und wenn ich Zen 4 anschaue stimmt es auch in etwa, wenn man den Taktunterschied zu Zen 2 rausrechnet. Seit Zen 1 ist die L2 <-> L3 Bandbreite bei 32 Byte/Cycle
Ich hatte das so im Kopf dass der L3 nicht effektiv den Maximaldurchsatz zu allen Kernen gleichzeitig hinkriegt. Kurz gesucht, wohl wegen dem hier: https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested/4
Bin jetzt aber nicht sicher ob das wirklich korrekt ist.

[MSABK]

Naja, was wäre an frühen 3D-Modellen unerwartet gewesen? Zen 5 ist in seiner jetzigen Form ein Ladenhüter und bis zur CES ist Arrow Lake draußen und hat schon Kundschaft abgegriffen. Im Gegensatz zu Zen 4 ist AMD hier in keiner Position, wo sie sandbaggen könnten.

Der 7800x3d wird aber gegen Arrow Lake auch gut aussehen, vlt nicht gegen das Spitzenmodell, oder wer weiß, komplett nackt steht Amd nicht da.

[fondness]

Naja, was wäre an frühen 3D-Modellen unerwartet gewesen? Zen 5 ist in seiner jetzigen Form ein Ladenhüter und bis zur CES ist Arrow Lake draußen und hat schon Kundschaft abgegriffen. Im Gegensatz zu Zen 4 ist AMD hier in keiner Position, wo sie sandbaggen könnten.

Weil AMD nichts zurück hält. Der spätere launch Zeitpunkt hat technische Gründe, sieht man schön an den EPYCs, wo die 3D Cache Modelle auch stets ein halbes Jahr später kamen.

[Zossel]

Plonk:Data-side latency is a big issue too. Tackling the memory latency problem today is arguably even harder than it was in the early 2010s. Pointer chasing through a 1 GB array with 2 MB pages gives about 76 ns of latency on the Athlon II X4 651. Do the same on the Ryzen AI 9 HX 370, and you’ll see over 128 ns of latency. Even though mobile Zen 5 has more reordering capacity and better caching than Husky, both cores often find themselves very backend bound.https://chipsandcheese.com/2024/08/20/zen-5-variants-and-more-clock-for-clock/

[robbitop]

Ja wobei die memorylatency bei mobile immer schlechter ist. Der Desktop Part läuft mit gutem Speicher gut guten Latenzen in den 70er ns.
Aber ein getunter Coffeelake kommt auf 40 ns und weniger. Das hat aber mit der Latenz der Anbindung (CCX zu IOD via IF) zu tun. Das ist der Preis der Skalierbarkeit der vielen Cores und des Chipletaufbaus.
Aber: relevant ist die durchschnittliche effektive Memorylatenz. Den obigen Nachteil in dieser Metrik hat man mit modernen großen L3 Caches in den allermeisten Anwendungen mehr als ausgeglichen. Insbesondere mit den VCache Modellen.

[basix]

Ich hatte das so im Kopf dass der L3 nicht effektiv den Maximaldurchsatz zu allen Kernen gleichzeitig hinkriegt. Kurz gesucht, wohl wegen dem hier: https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested/4
Bin jetzt aber nicht sicher ob das wirklich korrekt ist.

Ah OK.

Ich sehe halt 32Byte/Cycle und auch keine L3-Bandbreitenreduktion bei AIDA64 Benches. Zumindest gibt es keine effektive Reduktion, aber man kann den Peak nicht erreichen. Das konnte Zen 2 aber anscheinend auch schon nicht (3800X wie auch 5800X liegen bei ~600GB/s). Ein einzelner Core ist wohl deutlich näher am theoretischen Maximum von 160GByte/s bei 5 GHz, aber alle Cores zusammen bringen anscheinend den Bus in Sättigung.

Zen 5 liegt hier deutlich näher am theoretischen Maximum. Ein 9700X erreicht fast 1200 GB/s. Bei immer noch 32B/Cycle pro Core: https://www.techpowerup.com/review/amd-ryzen-7-9700x/6.html

Interessant sind auch die L3-Latenzen: 7.7ns beim 9700X (https://www.techpowerup.com/review/amd-ryzen-7-9700x/6.html) und 7.3ns beim 9950X (https://www.techpowerup.com/review/amd-ryzen-9-9950x/6.html). Bei jeweils max. Boost (5.5Ghz / 5.7GHz) käme man auf ~42 Cycles Latenz.
Nimmt man die 8.2ns von Chipsandcheese wären es ~47 Cycles: https://chipsandcheese.com/2024/08/14/amds-ryzen-9950x-zen-5-on-desktop/

[Zossel]

Ja wobei die memorylatency bei mobile immer schlechter ist. Der Desktop Part läuft mit gutem Speicher gut guten Latenzen in den 70er ns.
Aber ein getunter Coffeelake kommt auf 40 ns und weniger. Das hat aber mit der Latenz der Anbindung (CCX zu IOD via IF) zu tun. Das ist der Preis der Skalierbarkeit der vielen Cores und des Chipletaufbaus.

Da dort explizit die Page-Grösse angeben ist wird es dort auch um die Zeiten gehen die durch die MMU bzw. den TLB oben drauf kommen.
Und das sind eben nicht die Zeiten die auf irgentwelchen Blink-Blink-RGB-Spielzeug-RAM stehen.

[Der_Korken]

Interessant sind auch die L3-Latenzen: 7.7ns beim 9700X (https://www.techpowerup.com/review/amd-ryzen-7-9700x/6.html) und 7.3ns beim 9950X (https://www.techpowerup.com/review/amd-ryzen-9-9950x/6.html). Bei jeweils max. Boost (5.5Ghz / 5.7GHz) käme man auf ~42 Cycles Latenz.
Nimmt man die 8.2ns von Chipsandcheese wären es ~47 Cycles: https://chipsandcheese.com/2024/08/14/amds-ryzen-9950x-zen-5-on-desktop/

Die Latenzen sehen mir viel zu niedrig aus. CB kommt auf knapp 1ns mehr als Zen 4 bzw. >10ns insgesamt:
https://www.computerbase.de/2024-08/amd-ryzen-5-9600x-ryzen-7-9700x-test/2/#abschnitt_der_cachedatendurchsatz_steigt_deutlich_an
https://www.computerbase.de/2024-08/amd-ryzen-9-9900x-9950x-test/2/#abschnitt_cache_speicher_und_avx512_beim_flaggschiff

Nominell hatte Zen 4 eine L3-Latenz von 50 Takten. Für Zen 5 hat AMD die Packdichte deutlich erhöht, da kann ich mir nicht vorstellen, dass der Cache gleichzeitig auch noch schneller geworden ist (eher das Gegenteil ...).

Edit: Chips&Cheese testet oft mit 2MB-Pages, sodass die geringere Latenz gegenüber CB durch die kürzere Adressauflösungen erklärt werden können. Der L3 passt dann komplett in den L1TLB, während bei 4K-Pages selbst der L2TLB nicht reicht und letzterer hatte bei Zen 4 allein schon 7 Takte Latenz.

[fondness]

Nominell hatte Zen 4 eine L3-Latenz von 50 Takten. Für Zen 5 hat AMD die Packdichte deutlich erhöht, da kann ich mir nicht vorstellen, dass der Cache gleichzeitig auch noch schneller geworden ist (eher das Gegenteil ...).

Naja, das ist für gewöhnlich kein Widerspruch. Beim Cache spielen tatsächlich die Signallaufzeiten eine Rolle. Engere Packdichte, kürzere Signallaufzeiten, niedrigere Latenz. Warum glaubst du schafft AMD beim 3D-Cache so niedrige Latenzen? Auf einem Die wäre das nicht möglich.

[robbitop]

Da dort explizit die Page-Grösse angeben ist wird es dort auch um die Zeiten gehen die durch die MMU bzw. den TLB oben drauf kommen.
Und das sind eben nicht die Zeiten die auf irgentwelchen Blink-Blink-RGB-Spielzeug-RAM stehen.

Die durchschnittliche Gesamtlatenz ergibt sich aus mehreren Elementen. Dazu kommt auch die Latenz der Fabric und des IMCs und die des Speichers. Je höher die Fabric und der IMC takten desto besser ist deren Anteil. Und je kleiner die Latenz des Speichers desto besser der Anteil. Bei mobile hast du oft relativ niedrige Taktraten für all das und relaxte Speicherlatenz. Im Desktop mit mit gutem Speicher auf deutlich weniger. Das ist normal und schon immer so gewesen. Im mobile kommt man bei den Messungen immer bei guten 120+ ns raus und im Desktop im Bereich 70-80 ns. Seit einigen Jahren schon. Das ist nichts neues und auch nicht irgendwie ungewöhnlich für Zen 5.

Unabhängig davon spielt in real world Anwendungen die Cachehitrate noch mit und reduziert die die durchschnittliche Latenz. Natürlich aber in obiger Messung nicht - das stimmt.

[basix]

Wow, in Games +11% Performance auf einem 9700X und +10% bei einem 7700X mit dem Windows 11 24H2 Update (vs. 23H2):
https://www.youtube.com/watch?v=rlfTHCzBnnQ¨

Wäre noch interessant, wie das bei den älteren Ryzens aussieht (Zen 2, Zen 3) sowie den X3D Varianten. Und verglichen mit Windows 10.

Zum Teil profitiert auch Raptor Lake von disem Update. Was lief da in Windows falsch? :O

[Slipknot79]

Upwarten ob die +11% von MS nicht wieder zurückgenommen werden weil "huch, wir haben unabsichtlich den Schalter der Sicherheitsfeatures der CPU off gedreht. Hier ist das Update dazu" (y)

[Zossel]

Was lief da in Windows falsch? :O

Jetzt ist nur noch die Frage offen, ob es in Linux ein vergleichbares Thema gibt.

[][immy]

Also was in Windows falsch läuft, Frage ichich auch schon lange. Vor allem bei meinem Arbeitslaptop (Intel CPU) Frage ich mich manchmal, warum Windows 11 nicht hinbekommt, manche Dialoge in Echtzeit an zu zeigen.

Fragt sich jetzt noch ob Hardware unboxed mit dem Admin Modus getestet hat, oder ob das irgendwann noch on top kommt.

[HOT]

Wow, in Games +11% Performance auf einem 9700X und +10% bei einem 7700X mit dem Windows 11 24H2 Update (vs. 23H2):
https://www.youtube.com/watch?v=rlfTHCzBnnQ¨

Wäre noch interessant, wie das bei den älteren Ryzens aussieht (Zen 2, Zen 3) sowie den X3D Varianten. Und verglichen mit Windows 10.

Zum Teil profitiert auch Raptor Lake von disem Update. Was lief da in Windows falsch? :O

Bei Gears5 scheint generell was zu klemmen mit dem alten Windows, das (und Raptor Lake) würd ich hier mal ausklammern.

Ich nehme aber an, dass das ein Mix aus Prefetching, Scheduling und Powermanangement ist, das hier zutage tritt. Ich könnt mir auch vorstellen, dass der 9700X mit AGESA 1201A (also mit gleichem Powerbudget) annähernd überall schneller sein wird als der 7700X, wenn auch nicht so irre viel.
Bin aber mal gespannt, ob es irgendwann noch einen Fix für die Inter-CCD-Latenzen gibt. Ich werde beide meine Nutzrechner mal mit 2H24 komplett neu installieren.

[Nightspider]

Rennt Win11 jetzt schneller als Win10?

Wenn ja will ich so ein Update gefälligst auch für Windows 10.

[Zossel]

Rennt Win11 jetzt schneller als Win10?

Wenn ja will ich so ein Update gefälligst auch für Windows 10.

Bei einem closed-source OS wie Windows hast du das nicht zu entscheiden.

Take it or leave it!

[basix]

Hier noch paar zusätzliche Messwerte von Kitguru zum Windows 24H2 Update:
https://www.kitguru.net/components/cpu/leo-waldock/amd-hopes-windows-11-update-can-rescue-zen-5-tested/

Die Werte tendieren in die selbe Richtung wie bei HWUB. Für mich das interessanteste: Auch X3D in Form des 7800X3D profitiert im ähnlichen Masse vom 24H2 Update. Nice :)

[robbitop]

Was interessant wäre ob Zen 2 und 3 auch profitieren.

[basix]

Afaik alles bis und mit Zen 3. Soll laut Gerüchten etwas mit Spectre und entsprechenden Scheduling / Branch Prediction Geschichten zu tun haben, wo bei Zen 2 entsprechende Mitigations noch nicht drin sein sollen.

Wir werden es in Zukunft erfahren ;) Wäre aber schon cool für Zen 2 Besitzer.

Hier frage ich mich aber schon, wie AMD das alles verschlafen hat. Das ist ein sehr grosser Sprung und hinsichtlich Konkurrenzlage zu Intel definitiv nicht vernachlässigbar.

Edit:
Noch was, aus welchem möglichen Grund GoW5 auch bei Intel profitiert:
https://forums.anandtech.com/threads/zen-5-speculation-epyc-turin-and-strix-point-granite-ridge-ryzen-9000.2607350/page-796#post-41285042
https://anandtech-data.community.forum/attachments/106/106253-3bceb5bcf7a921ae5a31813df2279570.jpg

[robbitop]

Und interessant dass das niemand mit Linux Spielebenchmarks gesehen hat. Zumindest wurde das nicht öffentlichkeitswirksam. Wenn selbst Zen 3 profitiert - dann war das 4 Jahre im Dunklen.

[fondness]

Erklärt halt auch warum Linux so gut ausgehen hat - damit dürfte es jetzt vorbei sein.

[Lehdro]

Hier frage ich mich aber schon, wie AMD das alles verschlafen hat. Das ist ein sehr grosser Sprung und hinsichtlich Konkurrenzlage zu Intel definitiv nicht vernachlässigbar.

Manchmal ist die einfachste Erklärung die richtige: Wintel.

Und AMD war halt AMD, designed geniale Hardware und spielt dann mit der Rassel wenn es um die entsprechende Software geht.

[basix]

Und die Story geht noch weiter: Hier hat einer +11% mit einem 7800X3D in Geekbench ST :D Linux hat ziemlich genau +10% verglichen mit Windows gehabt, evtl. also die Lösung aller Windows Performance-Nachteile verglichen mit Windows? Wenn ich mir die Scores von dem User auf Reddit anschaue, erscheinen mir die 24H2 Resultate nun aber normal und die 23H2 Resultate ungewöhnlich niedrig. Egal, wir werden sehen. Evtl. gibt es in 23H2 einfach ein paar Dinge, die nicht rund laufen können und 24H2 weniger anfällig auf Performance-Regressionen ist.
https://www.reddit.com/r/Amd/comments/1f21tlk/quick_tests_on_7800x3d_with_windows_11_24h2/?utm_source=embedv2&utm_medium=post_embed&utm_content=post_title&embed_host_url=https://forums.anandtech.com/threads/zen-5-speculation-epyc-turin-and-strix-point-granite-ridge-ryzen-9000.2607350/page-796

[aufkrawall]

Und interessant dass das niemand mit Linux Spielebenchmarks gesehen hat. Zumindest wurde das nicht öffentlichkeitswirksam. Wenn selbst Zen 3 profitiert - dann war das 4 Jahre im Dunklen.
Gibt ja schon kaum gute Linux vs. Windows Gaming-Tests. Fähiger Tester, der wirklich ein CPU-Limit testen will und dieses auch sicherstellt, ist dann nochmal viel unwahrscheinlicher.

[basix]

PCGH hatte doch gerade kürzlich entsprechende Tests Windows vs. Linux gemacht. Ich hoffe, sie wiederholen die Tests mit Win 10, Win 11 24H2 sowie einer aktuellen Linux Distribution. 5800X3D, 7800X3D, 9700X, 14600K/14700K als "Mindest-Teilnehmerfeld" :D

Edit:
AMD sagte in seinem Blogpost: https://community.amd.com/t5/gaming/ryzen-9000-series-community-update-gaming-performance/ba-p/704054
"Zen 5" will see the biggest boost, but this Windows update will improve performance for "Zen 4" and "Zen 3" as well. We're collaborating with Microsoft to roll out this optional update to all Windows 11 users soon.

Zen 3 wird definitiv noch profitieren. Natürlich nicht um wie viel genau. Bei Zen 2 sieht es eher nicht danach aus.

[rentex]

PCGH hatte doch gerade kürzlich entsprechende Tests Windows vs. Linux gemacht. Ich hoffe, sie wiederholen die Tests mit Win 10, Win 11 24H2 sowie einer aktuellen Linux Distribution. 5800X3D, 7800X3D, 9700X, 14600K/14700K als "Mindest-Teilnehmerfeld" :D

Edit:
AMD sagte in seinem Blogpost: https://community.amd.com/t5/gaming/ryzen-9000-series-community-update-gaming-performance/ba-p/704054


Zen 3 wird definitiv noch profitieren. Natürlich nicht um wie viel genau. Bei Zen 2 sieht es eher nicht danach aus.


Damit kommt AMD erst jetzt? :rolleyes:

[basix]

Ja das habe ich mich auch gefragt

[robbitop]

Erklärt halt auch warum Linux so gut ausgehen hat - damit dürfte es jetzt vorbei sein.
Linux ist auch hervorragend mit AMD IP ohne das. Siehe Steam Deck mit Van Gogh. Das hat noch Zen 2 IP. :)

btw: Das ROG Ally holt 22 min %(!!!) mehr Akkulaufzeit nur durch SteamOS. (dort funktioniert das Powermanagement der CPU und GPU out of the box echt gut - limitierst du die Last in dem du zB die Framerate senkst, sinken automatisch Taktraten der CPU und GPU auf das Niveau was notwendig ist die FPS zu halten. Völlig ohne TDP Limits zu setzen oder 3rd Party AutoTDP Tool) :)


Und AMD war halt AMD, designed geniale Hardware und spielt dann mit der Rassel wenn es um die entsprechende Software geht.
X-D X-D Besser kann man es nicht ausdrücken. Sowohl bei Radeon als auch bei Ryzen. Und deren Open Source ist gar kein echtes Open Source (das denen IMO bei der SW Entwicklung sogar helfen könnte!). Die dumpen einfach nur den source code auf github und das war's. Null Interaktion, kein Merge von Change Requests. Das machen selbst kleine Firmen (zB comma.ai) und sogar Solo Leute besser.

[Zossel]

Irgendwie kommt mir das bekannt vor, aber ich komme gerade nicht drauf woher :-)

https://www.phoronix.com/news/AMD-Heterogeneous-Core-Driver

[fondness]

Linux ist auch hervorragend mit AMD IP ohne das. Siehe Steam Deck mit Van Gogh. Das hat noch Zen 2 IP. :)

btw: Das ROG Ally holt 22 min mehr Akkulaufzeit nur durch SteamOS. (dort funktioniert das Powermanagement der CPU und GPU out of the box echt gut - limitierst du die Last in dem du zB die Framerate senkst, sinken automatisch Taktraten der CPU und GPU auf das Niveau was notwendig ist die FPS zu halten. Völlig ohne TDP Limits zu setzen oder 3rd Party AutoTDP Tool) :)


X-D X-D Besser kann man es nicht ausdrücken. Sowohl bei Radeon als auch bei Ryzen. Und deren Open Source ist gar kein echtes Open Source (das denen IMO bei der SW Entwicklung sogar helfen könnte!). Die dumpen einfach nur den source code auf github und das war's. Null Interaktion, kein Merge von Change Requests. Das machen selbst kleine Firmen (zB comma.ai) und sogar Solo Leute besser.

Du widersprichst dir in einem Beitrag schön selbst. X-D
AMD hat längst die besten Linux-Treiber und auch die Windows-Treiber sind wesentlich besser als ihr Ruf. Zumal man einen Windows-Bug wohl kaum AMD anlasten kann. Zumindest nicht ohne mehr Hintergründe zu wissen. Vielleicht hat es auch so lange gedauert einen nicht Performance kostenden Fix für ein Security Issue zu finden, wer weiß.

[fondness]

BTW hier bestätigt AMD ua erstmals kleinere und größere CCX für Zen5:
https://wccftech.com/amd-zen-5-core-architecture-breakdown-hot-chips-new-chapter-high-performance-computing/

[robbitop]

Du widersprichst dir in einem Beitrag schön selbst. X-D
AMD hat längst die besten Linux-Treiber und auch die Windows-Treiber sind wesentlich besser als ihr Ruf. Zumal man einen Windows-Bug wohl kaum AMD anlasten kann. Zumindest nicht ohne mehr Hintergründe zu wissen. Vielleicht hat es auch so lange gedauert einen nicht Performance kostenden Fix für ein Security Issue zu finden, wer weiß.
Der Treiber ist super aber es afaik ist nicht AMD die das open source Projekt des Treibers managen. Hier kann AMD wohl eher Valve und Co danken. Was sie managen ist zB FSR und da ist das fürchterlich. Insofern ist da kein Widerspruch ;)

[aufkrawall]

AMD hat längst die besten Linux-Treiber und auch die Windows-Treiber sind wesentlich besser als ihr Ruf.
Kannst nicht mal mit einer 7800 XT ROCm in WSL2 laufen lassen, weil der Treiber einen mit <7900 XT einfach aussperrt. Wenn sie irgendetwas anderes gut machen, ist das schön, macht die katastrophalen Fehlentscheidungen aber auch nicht besser.

[Zossel]

PCGH hatte doch gerade kürzlich entsprechende Tests Windows vs. Linux gemacht. Ich hoffe, sie wiederholen die Tests mit Win 10, Win 11 24H2 sowie einer aktuellen Linux Distribution. 5800X3D, 7800X3D, 9700X, 14600K/14700K als "Mindest-Teilnehmerfeld" :D

Bei Linux könnte man dann gleich "mitigations=off" in der Kernel Commandline mittesten.
"lscpu" liefert Infos was in der CPU kaputt ist und was dagegen aktiv ist.

[fondness]

Der Treiber ist super aber es afaik ist nicht AMD die das open source Projekt des Treibers managen. Hier kann AMD wohl eher Valve und Co danken. Was sie managen ist zB FSR und da ist das fürchterlich. Insofern ist da kein Widerspruch ;)

FSR soll jetzt das Argument sein warum die ganze AMD sw murks ist? Lol. Und natürlich "managed" AMD die Open Source Treiber. Ein Großteil des Codes kommt sogar von AMD.

[aufkrawall]

AMD managed nicht RADV. AMD managed den RadeonSI OpenGL-Treiber innerhalb der Kriterien von Mesa. Dabei kommt etwas Shared Code auch für RADV rum, trotzdem managen sie RADV nicht. ~Jede wichtige Komponente im RADV-Treiber kommt weitestgehend bis komplett von anderen Devs.
Der Kernel-Treiber amdgpu kommt hingegen ~komplett von AMD. Dabei können sie aber zum Glück auch nicht machen, was sie wollen, sondern müssen sich nach den Kernel-Kriterien und -Regeln richten.

Ich weiß nicht, was daran zu schwer zu verstehen sein soll?

[Zossel]

FSR soll jetzt das Argument sein warum die ganze AMD sw murks ist? Lol. Und natürlich "managed" AMD die Open Source Treiber. Ein Großteil des Codes kommt sogar von AMD.

Robbitop könnte natürlich auch mal vorher in den entsprechenden gits nachschauen.

[robbitop]

FSR soll jetzt das Argument sein warum die ganze AMD sw murks ist? Lol. Und natürlich "managed" AMD die Open Source Treiber. Ein Großteil des Codes kommt sogar von AMD.

Doch aber nicht RADV und genau der läuft auf dem Steam Deck und genau der ist super. Und code zur Verfügung zu stellen den dann andere nutzen ist nicht das Folgen des open source Gedanken „develop in public“.

Das gleiche gilt auch für die anderen FidelityFX Komponenten.

Und laut george hotz (Gründer von comma ai) auf für deren Kernel Treiber (den AMD selbst macht). Das Ding hatte beim Loopen der AMD AI Demos Kernel Panic. Und kein Mensch hat auf die requests auf github reagiert. Und wohl auf viele andere Requests auch nicht. Er hatte dann eine Mail an Lisa Su geschrieben die tatsächlich geantwortet hatte und dann haben die Treiberleute mit ihm Dialog gehabt. Das zieht sich anscheinend so durch. Das ist keine open source Kultur. Und dabei könnte es ihnen helfen wenn sie die leben würden weil dann auch contribution von außerhalb kommen die man nutzen kann. Gerade wenn man dünn besetzt ist macht das Sinn.

Robbitop könnte natürlich auch mal vorher in den entsprechenden gits nachschauen.
Siehe oben. RADV wird nicht von AMD gemanagt.

[fondness]

RADV ist nicht "der AMD-Linuxtreiber". Der AMD Linuxtreiber besteht aus verschiedenen Komponenten und das überhaupt soetwas wie RADV möglich ist, liegt am "Management" bzw an der Treiberarchitektur und open source Kultur von AMD. Und natürlich hat sich auch RADV an amdvlk, also dem AMD Vulkan-Modul bedient. Am AMD kernel Treiber kommen sie sowie nicht vorbei.

Aber vor allem finde ich es völlig lächerlich bis absurd AMD für ihre open source Kultur zu kritisieren. Wohl wissend, dass AMD weitaus mehr tut als jeder andere. Und vor allem steht unterm Strich der beste Linux Treiber weit und breit. Du kannst dir ja gerne den Nvidia open source Treiber installieren lol. Und nochmal vor allem hat das alles schon lange nichts mehr mit deiner ursprünglichen Aussage zu tun die ich kritisiert habe. X-D

[samm]

Bei aller Kritik an den nicht übersichtlich oder komplett kollaborativ veröffentlichten AMD Treiber-Sourcen, finde ich es wichtig, etwas zu George Hotz festzuhalten, was über die durch seine Tweets (jaja, X-Posts) generierten Headlines der Presse und B3D-Forums-Reposts durch Leute mit Agenda hinausgeht. Bezogen auf das hier:
kein Mensch hat auf die requests auf github reagiert. Und wohl auf viele andere Requests auch nicht. Er hatte dann eine Mail an Lisa Su geschrieben die tatsächlich geantwortet hatte und dann haben die Treiberleute mit ihm Dialog gehabt. Das zieht sich anscheinend so durch. Das ist keine open source Kultur.
Der Kollege Hotz hat so agiert, meiner Ansicht nach um fehlende Leverage durch Firmengrösse auszugleichen: Gebt mir paar Millionen Dollar, passt eure Blob-Offenlegungsstrategie meinen Hoffnungen an, und spendet mir Hardware, sonst (und der folgede Part war erst nur impliziert, dann in Praxis klar sichtbar durch seine öffentliche Kommunikationsstrategie via tinygrad und Twitter) gibt es schlechte Presse.

Beispiel für die Vorgehensweise und daraufhin vorgekaute Deutung für die Community:

"AMD Rejects Tiny Corp's Request" heisst es etwa auf der warum-auch-immer vielverlinkten Website WCCF-Tech (https://wccftech.com/amd-rejects-tiny-corp-request-benchmarking-mi300x-ai-accelerator-on-mlperf/). Aber: Das ganze basiert einfach auf diesem Tweet (https://x.com/__tinygrad__/status/1803111545259565400):

For $1M and two boxes, we'll get the MI300X on the next MLPerf.


Worauf AMD's Reaktion einen weiteren Rant von Hotz verursacht und den Tweet (https://x.com/__tinygrad__/status/1803867395070857447):

Our offer to get MI300X on MLPerf was declined btw.


Was aber tatsächlich passiert ist gemäss Tiny Grad's eigenem Tweet (https://x.com/__tinygrad__/status/1803870146236420326):

We weren't ignored. It's so strange, they don't even clearly say no to the offer, they sidestep it and use meaningless words like "partnership" and "collaboration"; want to have "phone calls." Would much rather a clear no.

Not, "what's your address we're sending two boxes"


Ernsthaft mal... Welche massive Riesen-Firma schenkt einem Startup Millionen wegen eines grosskotzigen Versprechens? Und obwohl AMD nicht nur innerhalb eines Tages konstruktiv auf die Forderung eines Niemands reagiert, malt man weiterhin fleissig an einem schlechtes Bild in der Open-Source-Community.

Zuvor hat Hotz auch schon diesen Rant (https://news.ycombinator.com/item?id=36193625) geboten über "Giving up on AMD", hier das ellenlange YouTube dazu (https://www.youtube.com/watch?v=Mr0rWJhv9jU)

Zusammengefasst:

Der Mann ist einfach keine stabile Quelle und Zusammenarbeit mit ihm scheint ein sehr schwieriges Thema zu sein, zumal er, nennen wir es mal so, öffentlichen Druck einem der Firma angepassten Prozess vorzieht

Deutung:

Problem mit historisch gewachsenen Autoritäten gepaart mit aufgeblähtem Ego oder so, wie der Typ von bcachefs mit dem Releaseprozess von Linux, aber ich schweife ab. Wobei es beinah on-topic ist, Linux selbst ist auch ein Open Source Vorzeigeprojekt, nicht? ;)

[basix]

So es ist nun amtlich, der L3-Cache von Zen 5 hat 3.5 Zyklen weniger Latenz als der von Zen 4:
https://www.servethehome.com/amd-zen-5-core-is-at-hot-chips-2024/

[Badesalz]

Zen 3 wird definitiv noch profitieren. Natürlich nicht um wie viel genau. Bei Zen 2 sieht es eher nicht danach aus.Bist du immer nur in einem Thread pro Tag unterwegs? :|

[fondness]

Zusammengefasst:

Der Mann ist einfach keine stabile Quelle und Zusammenarbeit mit ihm scheint ein sehr schwieriges Thema zu sein, zumal er, nennen wir es mal so, öffentlichen Druck einem der Firma angepassten Prozess vorzieht

Deutung:

Problem mit historisch gewachsenen Autoritäten gepaart mit aufgeblähtem Ego oder so, wie der Typ von bcachefs mit dem Releaseprozess von Linux, aber ich schweife ab. Wobei es beinah on-topic ist, Linux selbst ist auch ein Open Source Vorzeigeprojekt, nicht? ;)

Danke für die Klarstellung. Zeigt, wie schnell sich fake news verbreiten und wie schnell Leute auf sowas aufspringen wenn es in ihr Weltbild passt.

So es ist nun amtlich, der L3-Cache von Zen 5 hat 3.5 Zyklen weniger Latenz als der von Zen 4:
https://www.servethehome.com/amd-zen-5-core-is-at-hot-chips-2024/

Wie schon vermutet, der Grund warum man Cache so dicht wie nur irgend möglich packen will ist nicht zuletzt die Latenz 😉

[robbitop]

Er hat die Story über die E-Mail an Lisa erst nach dem abgeschlossenen Dialog und dem Bugfix veröffentlicht. Und so groß ist seine Reichweite nun lange nicht, dass er irgendwelchen Druck ausüben könnte. Nicht einmal 200.000 Abonenten. Das ist nichts. Und dazu noch sehr nieschig.
Insofern stimmt die Narrative IMO nicht und ist damit alles andere als eine "Klarstellung" und mehr eine Meinung oder Schlussfolgerung. Und wenn der Kernel Treiber panict wenn AMD eigene Demos geloopt werden (ergo dieser nicht stabil ist - da wurde null eigener Code verwendet) und darauf lange Zeit nicht reagiert wird, ist das schon fragwürdig. Denn da geht es nicht um Eigeninteresse einer spezifischen Firma (was hier auch falsch erkannt wurde). Um AI Projekte jeglicher Art umsetzen zu können, sollte der Kernel Treiber stabil sein. Und das ist auch in AMDs eigenen Interesse, damit mehr Projekte umgesetzt werden, die wiederum mehr HW verkaufen. AMD hat dank des separaten Dialogs (den sie auch über github hätten haben können - weil das da geflagt wurde) dann den Fehler gefunden und gefixt und waren selbst froh, dass der dann stabil war.

RADV ist nicht "der AMD-Linuxtreiber". Der AMD Linuxtreiber besteht aus verschiedenen Komponenten und das überhaupt soetwas wie RADV möglich ist, liegt am "Management" bzw an der Treiberarchitektur und open source Kultur von AMD. Und natürlich hat sich auch RADV an amdvlk, also dem AMD Vulkan-Modul bedient. Am AMD kernel Treiber kommen sie sowie nicht vorbei.

Das ist möglich, weil AMD source code veröffentlicht und die uArch gut dokumentiert. Das wurde auch nicht kritisiert. Und ja das ist super. Aber hier muss man unterscheiden, was kritisiert wurde und was nicht - ansonsten schreiben wir aneinander vorbei. Die Software die AMD als open source zur Verfügung stellt wird eben nicht in public entwickelt sondern es wird primär source code gedumpt. Das ist besser als closed source aber es ist eben unterhalb der Möglichkeiten und es folgt nicht wirklich dem open source Gedanken. Und dabei spielt Semantik wie RADV nun eingeordnet wird überhaupt keine Rolle. Und genau diese Komponente macht das Linuxgaming (bzw dessen rasante Fortschritte) auf der Treiberseite so gut wie es geworden ist. RADV ist ein open source Projekt was nicht von AMD gemanagt wird und das war der Punkt. Und genau dort wird der open source Gedanke gelebt. Multiple Contributors, Dialog mit der Community, Merges von bugfixes usw.

Wie gesagt: gut, dass AMD Sourcecode veröffentlicht. Das ist super. Das ist außer Frage. Aber besser wäre echtes Development in Public, wenn man damit wirbt Open Source Entwicklung zu machen. Und dazu gehört eben der Dialog.

[Badesalz]

MLID hat 185k Abonenten und den kennt jede Sau. 200.000 ist nicht mehr gering...

Aber der Typ ist gelegentlich leicht zampanohaft und das nervt zuweilen schon irgendwie...

[Exxtreme]

Wie gesagt: gut, dass AMD Sourcecode veröffentlicht. Das ist super. Das ist außer Frage. Aber besser wäre echtes Development in Public, wenn man damit wirbt Open Source Entwicklung zu machen. Und dazu gehört eben der Dialog.

Womöglich gehen sie davon aus, dass das richtige Öffnen mehr Arbeit nach sich zieht als es nützt. Das sieht man an anderen Opensource-Projekten auch sobald es nischiger wird.

Ein gutes Beispiel ist das da:
https://github.com/eclipse-openj9/openj9/graphs/contributors

98% der Commits dürften von IBM-/Redhat-Mitarbeitern stammen. Weil dieses Projekt so nischig und speziell ist, dass praktisch niemand ausserhalb von IBM irgendwas Sinnvolles beitragen kann. Ich gehe davon aus, dass das bei AMD-Treibern sehr ähnlich sein dürfte.

[fondness]

Das ist möglich, weil AMD source code veröffentlicht und die uArch gut dokumentiert. Das wurde auch nicht kritisiert. Und ja das ist super. Aber hier muss man unterscheiden, was kritisiert wurde und was nicht - ansonsten schreiben wir aneinander vorbei. Die Software die AMD als open source zur Verfügung stellt wird eben nicht in public entwickelt sondern es wird primär source code gedumpt. Das ist besser als closed source aber es ist eben unterhalb der Möglichkeiten und es folgt nicht wirklich dem open source Gedanken. Und dabei spielt Semantik wie RADV nun eingeordnet wird überhaupt keine Rolle. Und genau diese Komponente macht das Linuxgaming (bzw dessen rasante Fortschritte) auf der Treiberseite so gut wie es geworden ist. RADV ist ein open source Projekt was nicht von AMD gemanagt wird und das war der Punkt. Und genau dort wird der open source Gedanke gelebt. Multiple Contributors, Dialog mit der Community, Merges von bugfixes usw.

Wie gesagt: gut, dass AMD Sourcecode veröffentlicht. Das ist super. Das ist außer Frage. Aber besser wäre echtes Development in Public, wenn man damit wirbt Open Source Entwicklung zu machen. Und dazu gehört eben der Dialog.

Sorry robbitop, aber du hast offensichtlich keine Ahnung wie ein Open-Source-Projekt funktioniert, anders kann ich mir diese völlig naive Ansichtsweise nicht erklären. Alleine schon der Gedanke an irgendwelche romantischen Open-Source-Communities. 99% der SW-Entwickler weltweit sind nicht in der Lage einen Treiber zu schreiben, wir reden hier von hochspezialisierter Arbeit. RADV kommt von Valve und anderen Multi-Milliarden-Dollar-Konzernen. Es gibt keine Tier 1 Entwickler die aus Nächstenliebe in ihrer Freizeit AMD-Treiber schreiben oder da irgendwelche Commits machen. AMD kann nicht dutzende Entwickler einstellen die nichts anderes machen als irgendwelchen Noobs SW-Entwicklung beizubringen - denn genau auf sowas würde eine open-source-Enticklung wie du sie dir vorstellst hinauslaufen. Ganz davon abgesehen, dass man dann nie fertig werden würde.

Und hier nur mal so ein kleiner Überblick, wie der AMD Linux Grafiktreiber SW Stack aussieht (leider nicht mehr ganz aktuell): https://de.m.wikipedia.org/wiki/Datei:Linux_AMD_graphics_stack.svg

https://i.postimg.cc/3xTKGqK2/1200px-Linux-AMD-graphics-stack-svg.png (https://postimages.org/)

Alles was RADV macht ist amdvlk zu ersetzen (wo man sich zuvor sicher großzügig bedient hat).

[Badesalz]

Poliert NV nicht grad mit das Speichersubsystem von Linux auf? Auf welcher... OS-Basis läuft denn das ganze Zeug in den Rechenzentren, wenn nicht ActiveDirectory :ulol: involviert ist? Bestenfalls noch *BSD.

Ob das für Hotz jetzt einfach nur schlecht oder nicht schnell genug ist, AMD wird auf jeden Fall den eigenen Kram noch stark nachbessern. Da führt genauso kein Weg dran vorbei wie bei ROCm selbst.
Sonst würde ich meinen, daß die Prioritäten bei Soft da liegen und auch so gestaffelt sind, für was deren HW grad am meisten weggeht. Ob das die Sachen sind wegen welche Hotz rummault?

Aber ja. Bin andererseits auch bei Hotz, daß unabhängig vom Funktionsumfang und Speed, instabile Kerneltreiber keinerlei Lösung sein können.

Persönlich hätte ich mich da ggf. doch kleinwenig an ihn geklemmt und bisschen was ausgehandelt, falls er mehr als nur maulen kann (!!) Das Prob ist aber seine semipro Einstellung dabei. Es geht halt auch gegeneitige Gesichtswahrung. So ist eben das Leben. Wenn man mit fetten Rants loslegt ist man eben raus.

Nur weil man mit Linux rummacht sollte man sich nicht gleich für Torvald halten.

@fondness
keine Ahnung wie ein Open-Source-Projekt funktioniertGeht so. Das war bisschen zu pauschal ;) Kernel und Kerneltreiber sind ja nur eine Facette. Für die God-like bestimmt :rolleyes: Sonst überlebt man eh keine Woche auf der ML bzw. mit den Commits. Ist ja auch richtig so.

Alles andere ist aber auch ein "open-source-project" und ziemlich brauchbare Tools oder Anwendungen, werden halt von ziemlich brauchbaren Leuten gemacht. Micht von God-like. Oft auf die Art die du imho bisschen zu pauschal geringschätzt :wink:

[aufkrawall]

Der amdgpu-Kerneltreiber ist mittlerweile eine feine Sache. Hotz hat sich in erster Linie über die geschlossene Firmware ausgekotzt, die für einen Großteil der Crashes verantwortlich sein soll und für Entwickler eine Blackbox darstellt. AMD will hier noch mehr öffnen, und das ist natürlich schlau. Sonst hätten sie eh keine Chance, irgendwann mal wieder irgendwelche Marktanteile zu sehen.

Natürlich trotzdem lächerlich, wenn man bei Nvidia mit einer RTX 3050 CUDA in WSL2 laufen lassen kann, bei AMD ROCm aber nicht mal mit einer 6900 XT oder 7800 XT. Welcher Entwickler hat Bock auf so etwas? Sie stellen sich wie komplette Trottel leider immer selbst ein Bein, und das ist auch das Problem bei den Windows-Treibern. Einerseits super, andererseits dann wieder unfassbar vertrottelt und Anti-Consumer...
-> mehr open-source Mentalität mit Bugtrackern, wo Entwickler posten und versierte User Patches ausprobieren können etc. würde definitiv helfen. Deshalb ist die Situation unter Linux ja auch mitunter besser als unter Windows.

Wobei ROCm auch unter Linux bislang richtig kacke gemanagt ist. Natürlich ausgerechnet das Projekt, das exklusiv durch AMD selbst verwaltet wird. Zufälle gibts...

[Badesalz]

Wobei ROCm auch unter Linux bislang richtig kacke gemanagt ist. Natürlich ausgerechnet das Projekt, das exklusiv durch AMD selbst verwaltet wird. Zufälle gibts...
Das wichtigste Feature ist da erstmal der CUDA-Übersetzer :rolleyes: Der ist aber tatsächlich quasi schon ein Pfund.

Die wichtigste Baustelle nach HW ist ja jetzt die PR-Abteilung :D Danach kommt aber die Soft dran. Wenn man die Kohle hat ZT Systems zu schlucken (!), dann muss da endlich auch was mit der Finanzierung der eigenen Soft passieren.

Sie haben nahezu Jahrzehnte vom Mitleidsbonus gelebt und sich mit Sachen durchgemogelt für die NV oder auch Intel am Baum hängen würden. Und das ist jetzt vorbei. Jetzt sind sie in HW selbst groß und stark :usweet: und es wird auch mit SW nicht mehr durchgemogelt. Sonst gibts nur noch paar Mal aufs Fressbrett und dann wieder zurück nach unten, AMD.

[samm]

Er hat die Story über die E-Mail an Lisa erst nach dem abgeschlossenen Dialog und dem Bugfix veröffentlicht. Und so groß ist seine Reichweite nun lange nicht, dass er irgendwelchen Druck ausüben könnte. Nicht einmal 200.000 Abonenten. Das ist nichts. Und dazu noch sehr nieschig.Die Timeline stimmt nicht und der Masstab des Einflusses ist auch arbiträr - Torvalds hat, zumindest mit dem Namen, 215k Follower auf github und 0 auf YouTube, das macht ihn nicht zu einem irrelevanten Typ. Und andersrum, was George Hotz relevant macht ist, dass er z.B. von dir aber auch der Tech-Presse als relevanter Ansichts-Macher betrachtet wird.
Wie gesagt: gut, dass AMD Sourcecode veröffentlicht. Das ist super. Das ist außer Frage. Aber besser wäre echtes Development in Public, wenn man damit wirbt Open Source Entwicklung zu machen. Und dazu gehört eben der Dialog.
Das sehen wir gleicherseits als Ideal. Und ja, die Angemessenheit und Korrektheit eines Dialogs machen die Musik.

Da hapert es auch gerade bei AMD, deswegen die regelmässigen Bemerkungen über die mangelnde Kompetenz ihrer PR.

SW ist auf Aufholjagd - es ist aber auch hierbei mehr PR bezüglich Mindshare als von direkter finanzieller Relevanz, ob eine 6600 XT für ROCm offiziell unterstützt wird. Das direkte Geld liegt in der guten Verwendbarkeit der Instinct-Reihe, und was PR für Hinz und Kunz angeht, so werden die Fortschritte davon von den etwas technischeren Mainstream-Onlinepräsenzen wie Ian Cutress, Chips N Cheese, Level 1 Techs durchaus als okay angesehen.

Und genau solche etwas technischeren Mainstream-Onlinepräsenzen können auch Zen 5 etwas abgewinnen. Umsetzung der IPC in messbare Performancegewinne mangelt nicht zuletzt am Speicher der AMD-Mainstreamplattformen.

Deswegen werden aus meiner Sicht Threadripper und insbesondere die Epyc-Derivate interessanter sein, die massiv mehr Bandbreite pro Kern pro Takt zur Verfügung haben.

[robbitop]

Sorry robbitop, aber du hast offensichtlich keine Ahnung wie ein Open-Source-Projekt funktioniert, anders kann ich mir diese völlig naive Ansichtsweise nicht erklären. Alleine schon der Gedanke an irgendwelche romantischen Open-Source-Communities. 99% der SW-Entwickler weltweit sind nicht in der Lage einen Treiber zu schreiben, wir reden hier von hochspezialisierter Arbeit. RADV kommt von Valve und anderen Multi-Milliarden-Dollar-Konzernen. Es gibt keine Tier 1 Entwickler die aus Nächstenliebe in ihrer Freizeit AMD-Treiber schreiben oder da irgendwelche Commits machen. AMD kann nicht dutzende Entwickler einstellen die nichts anderes machen als irgendwelchen Noobs SW-Entwicklung beizubringen - denn genau auf sowas würde eine open-source-Enticklung wie du sie dir vorstellst hinauslaufen. Ganz davon abgesehen, dass man dann nie fertig werden würde.

Und hier nur mal so ein kleiner Überblick, wie der AMD Linux Grafiktreiber SW Stack aussieht (leider nicht mehr ganz aktuell): https://de.m.wikipedia.org/wiki/Datei:Linux_AMD_graphics_stack.svg

https://i.postimg.cc/3xTKGqK2/1200px-Linux-AMD-graphics-stack-svg.png (https://postimages.org/)

Alles was RADV macht ist amdvlk zu ersetzen (wo man sich zuvor sicher großzügig bedient hat).
Dass RADV codebase von AMD nutzt wurde doch nie abgestritten. Aber es läuft schneller, hat einen besseren Shadercompiler und hat eine schnellere Innovationsrate. Also wird da offenbar auch einiges dafür getan.
Und ja dass die Treibende Kraft von Valve und co bezahlte Developer machen ist nichts neues und habe ich ja bereits auch damit gemeint bei "bedank dich bei Valve". Denn dank denen ist das Niveau auf SteamOS richtig gut. Natürlich ist AMD nicht unbeteiligt in dem sie den Code veröffentlicht haben - aber ohne den Aufwand bei RADV sähe es schon ganz anders aus. Insofern war mein Post eben kein Widerspruch.

Und was sie im Mesa3D Ripository für RADV machen ist ganz klar development in public. Schau mal hier:

https://gitlab.freedesktop.org/mesa/mesa/-/commits/main?search=radv
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?scope=all&state=opened&search=radv

Da ist richtig Aktivität drin und für jedermann sichtbar und jeder kann sich da äußern und mit einbringen. Und es scheint mir auch als wenn nicht bezahlte User dort Probleme melden und ja die bezahlten Leute übernehmen das heavy lifting - aber bist du 100% sicher dass es null contribution gibt von außen? Oder reine Vermutung?

Und jetzt mal ein paar repositoriys von AMD:
https://github.com/GPUOpen-Drivers/AMDVLK
https://github.com/GPUOpen-Effects/FidelityFX-FSR2
https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK

Tote Hose da. Da wird einfach nur source code gedumpt und nichts anderes.

[robbitop]

Die Timeline stimmt nicht und der Masstab des Einflusses ist auch arbiträr - Torvalds hat, zumindest mit dem Namen, 215k Follower auf github und 0 auf YouTube, das macht ihn nicht zu einem irrelevanten Typ. Und andersrum, was George Hotz relevant macht ist, dass er z.B. von dir aber auch der Tech-Presse als relevanter Ansichts-Macher betrachtet wird.
Wie ist die Timeline denn? Alle Videos die ich gesehen hab, wo das vorkam, wurde die Mail gezeigt und er sagte Lisa hat geantwortet.
Kann natürlich trotzdem sein, dass er das mal in einem seiner vielen 8h Programmiersessionstreams (wo noch viel weniger Reichweite da ist und die sowieso kaum einer schaut) gesagt hat bevor es eine Antwort gab. Aber da ist die Reichweite wohl noch kleiner.

Ich hab mal versucht eine Quantifizierung dafür zu finden und habe mal Google Trends gefüttert. Keine Ahnung, wie aussagefähig das ist - aber es ist zumindest ein Anhaltspunkt.

Als Spektrum habe ich mal genommen:

Linus Torvalds <-> Georege Hotz -> ~Faktor 10 in den letzten 12 Monaten
Matthew McConaughey <-> Linus Torvalds ~ Faktor 25
Taylor Swift <-> Mathew McConaughey ~ Faktor 25

Jemand der wirklich bekannt ist, ist Faktor >6000 mal mehr bekannt als George Hotz.

Das ist natürlich etwas polemisch, weil Pop Kultur vs IT Bubble.

Schauen wir mal in die Influencer Bubble bei IT. LTT / Linus Sebastian und George Hotz.

Linus Sebastian <-> George Hotz ~ Faktor ~20 (habe jeweils ihre Namen und Firmen aufakkumuliert)

Und auf Linus' Beschwerden hinsichtlich der IHVs hört kein Mensch. Trotz laut der Metrik Faktor 20 an Popularität bei den Suchergebnissen. Und auch ohne die Zahl würde ich gefühlt schon annehmen, dass LTT in den Medien größere Reichweite hat. Linus beschwert sich regelmäßig über alle möglichen Aspekte bei AMD und Nvidia. Und ich habe zumindest noch gar nichts gesehen was sich darauffolgend bei denen geändert hat.

[Brillus]

Er hat die Story über die E-Mail an Lisa erst nach dem abgeschlossenen Dialog und dem Bugfix veröffentlicht. Und so groß ist seine Reichweite nun lange nicht, dass er irgendwelchen Druck ausüben könnte. Nicht einmal 200.000 Abonenten. Das ist nichts. Und dazu noch sehr nieschig.
Insofern stimmt die Narrative IMO nicht und ist damit alles andere als eine "Klarstellung" und mehr eine Meinung oder Schlussfolgerung. Und wenn der Kernel Treiber panict wenn AMD eigene Demos geloopt werden (ergo dieser nicht stabil ist - da wurde null eigener Code verwendet) und darauf lange Zeit nicht reagiert wird, ist das schon fragwürdig. Denn da geht es nicht um Eigeninteresse einer spezifischen Firma (was hier auch falsch erkannt wurde). Um AI Projekte jeglicher Art umsetzen zu können, sollte der Kernel Treiber stabil sein. Und das ist auch in AMDs eigenen Interesse, damit mehr Projekte umgesetzt werden, die wiederum mehr HW verkaufen. AMD hat dank des separaten Dialogs (den sie auch über github hätten haben können - weil das da geflagt wurde) dann den Fehler gefunden und gefixt und waren selbst froh, dass der dann stabil war.



Das ist möglich, weil AMD source code veröffentlicht und die uArch gut dokumentiert. Das wurde auch nicht kritisiert. Und ja das ist super. Aber hier muss man unterscheiden, was kritisiert wurde und was nicht - ansonsten schreiben wir aneinander vorbei. Die Software die AMD als open source zur Verfügung stellt wird eben nicht in public entwickelt sondern es wird primär source code gedumpt. Das ist besser als closed source aber es ist eben unterhalb der Möglichkeiten und es folgt nicht wirklich dem open source Gedanken. Und dabei spielt Semantik wie RADV nun eingeordnet wird überhaupt keine Rolle. Und genau diese Komponente macht das Linuxgaming (bzw dessen rasante Fortschritte) auf der Treiberseite so gut wie es geworden ist. RADV ist ein open source Projekt was nicht von AMD gemanagt wird und das war der Punkt. Und genau dort wird der open source Gedanke gelebt. Multiple Contributors, Dialog mit der Community, Merges von bugfixes usw.

Wie gesagt: gut, dass AMD Sourcecode veröffentlicht. Das ist super. Das ist außer Frage. Aber besser wäre echtes Development in Public, wenn man damit wirbt Open Source Entwicklung zu machen. Und dazu gehört eben der Dialog.

Großteil der Kerneltreiber sind Registerbeschreibungen. Da fallen aus dem RTL raus. Da kann nur AMD was dran machen.

[robbitop]

Wenn man ihn öffnen würde, wäre das anders.

[fondness]

Wenn man ihn öffnen würde, wäre das anders.

Der ist offen wie praktisch der gesamte Linux Kernel. Ganze ~5.8 Millionen Codezeilen ist der AMD GPU Linux Kernel Treiber im übrigen mittlerweile stark wie ich letztes Mal nachgesehen habe.

Aber du bist du hier schon lange OT mit deinem Feldzug.

[robbitop]

Im übrigen bist du hier schon lange OT mit deinem Feldzug gegen AMD.
Du hast die OT Diskussion angefangen (in dem du mir einen Widerspruch vorgeworfen hast) und dann folgend auch immer dagegen gehalten. Ich habe deine Posts addressiert. Also schon ziemlich ironisch, dass du (der mindestens den gleichen Anteil an dieser Debatte hatte) jetzt der Jenige bist, der um den Stop der OT Diskussion bittet.
Aber dennoch sehe ich das auch so. Ist OT hier. Aber für die Zukunft wenn du eine Diskussion nicht willst, dann beteilige dich nicht daran. Etwas nicht zu posten ist immer eine Option ;)

Ansonsten kann ich nur sagen, dass du offenbar nur schwarz und weiß zu sehen scheinst. Ich habe nur kritisiert, dass AMD die Open Source Kultur nicht lebt aber keineswegs einen "Feldzug gegen AMD" geführt.
Ich habe sogar gelobt, dass AMD source code shart und habe in vielen anderen Threads sehr positive Dinge über deren CPUs und GPUs geschrieben (die ich auch so meine). Am meisten begeistert bin ich zB über deren X3D CPUs und über Van Gogh. Ich habe überhaupt kein Problem mit AMD. Sehe aber, dass sie wenn sie in einigen Aspekten etwas geschickter wären viel viel mehr aus ihrem Potenzial (was wesentlich größer ist als das was sie auf die Straße bringen) herausholen könnten. Und das wäre besser für alle, weil ein starker Wettbewerb immer gut für uns Endkunden ist.

Warum du beim Kritisieren (und einer anschließenden Debatte - die auch nirgends persönlich wurde oder emotional) eines Aspektes (der auch legitim ist) gleich einen "Feldzug gegen AMD" siehst, kann ich nicht erkennen. Ggf. magst du das mal erklären?
Kann man jetzt nicht mehr kontrovers diskutieren?

[fondness]

Das habe ich dir eh schon gesagt. Weil ich es lächerlich finde ausgerechnet die Firma zu kritisieren die extrem viel gemacht hat für die Open-Source-Community und auch sehr viel weiter geht als jede andere vergleichbare Firma. Praktisch jedes AMD-SW-Paket ist mittlerweile OpenSource. RADV ist nur dank AMD möglich. AMDs FSR wird von Apple verwendet, wird von ARM verwendet. Wenn du auch nur annähernd so viel Energie dafür aufwenden würdest Firmen wie Nvidia zu kritisieren, die eine extreme Abschottungspolitik betreiben, wärst du glaubwürdig. Und wie schon gesagt, zu glauben, dass eine Open-Source-Entwicklung funktioniert wie du das skizziert hast halte ich außer in absoluten Ausnahmenfällen für Humbug. RADV ist ein Beispiel wo sich bezahlte Entwickler öffentlich austauschen ja, das wars aber dann auch schon.

[robbitop]

Ich empfinde, du (ver)mischt Dinge. Für das Verhalten von Nvidia fehlen mir die Worte. Leider aber sehr typisches Verhalten im Kapitalismus einer Firma. Könnte mit jeder Firma passieren, die sich ein Monopol aufbaut.
Meine Kritik ist aber unabhängig davon und sie ist nicht unlegitm - das einfach wegreden zu wollen (weil Nvidia das schlechter macht) macht aus meiner Sicht keinen Sinn und hat auch nichts mit guter Diskussionskultur zu tun. IMO sollte man wenn man von open source redet und damit wirbt (und das macht AMD ja) dann irgend wann auch mal diese Kultur leben.
Und natürlich steht AMD hier um Meilen vor Nvidia - das war ja gar nicht die Debatte. Aber sie könnten so viel mehr aus sich machen - mit dem Ziel wieder stärker zu werden um Nvidia irgendwann mal wieder die Stirn bieten zu können. Das wäre gut für uns alle.
Aber warum eine AMD spezifische Kritik dann immer gegen Nvidia ausufern muss sehe ich nicht. Die sind ihr eigenes Thema und dazu gibt es wie oben geschrieben in Bezug auf ihr Verhalten gegen den Consumer und gegen ihre Partner nicht mehr viel zu sagen. Bzw kann man da auf die LTT WAN podcasts hinweisen - da wurde stundenlang alles gesagt was dazu zu sagen ist. In einem Wort: Furchtbar

Es wäre doch viel einfacher gewesen anstatt immer dagegen zu halten zu sagen: ja stimmt sie leben die open source Kultur (noch) nicht - da ist Raum für Verbesserung. Aber: andere sharen gar nichts. Aber ersteres hast du nicht einmal eingeräumt. Daher dann auch die Diskussion.

Für mich ist das Thema dann erledigt und auch ok. :)

[fondness]

Es wäre doch viel einfacher gewesen anstatt immer dagegen zu halten zu sagen: ja stimmt sie leben die open source Kultur (noch) nicht - da ist Raum für Verbesserung. Aber: andere sharen gar nichts. Aber ersteres hast du nicht einmal eingeräumt. Daher dann auch die Diskussion.


Darauf bin ich schon eingegangen und das sehe ich halt einfach nicht so.

Und wie schon gesagt, zu glauben, dass eine Open-Source-Entwicklung funktioniert wie du das skizziert hast halte ich außer in absoluten Ausnahmenfällen für Humbug. RADV ist ein Beispiel wo sich bezahlte Entwickler öffentlich austauschen ja, das wars aber dann auch schon.

[robbitop]

Da kannst du aber nicht sicher sein, dass das Humbug ist. Es gibt genug Open Source Projekte wo das nicht so ist. Und selbst bei RADV kannst du sicher sein, dass es keine Contribution außerhalb der Entwickler gibt?
Und selbst wenn nicht ist das dennoch transparente Entwicklung wo die Tür immer offen ist, sich zu beteiligen. Außerdem hat AMD ja mehr Projekte auf github als nur den Treiber - die ganze Fidelity FX suite ist dort online. Und es gibt einige merge requests von außerhalb die ignoriert werden. Es ist nicht alles schwarz und weiß. Und da man das nicht wissen kann und da es immer ein moving target ist, ist es schade, da die Tür zuzumachen und zu sagen das sei Humbug.

[fondness]

Da kannst du aber nicht sicher sein, dass das Humbug ist.

Du kannst dir auch nicht sicher sein, dass es kein Humbug ist, so ist das Leben. :D

Es gibt genug Open Source Projekte wo das nicht so ist.

Immer her mit den Beispielen.

[robbitop]

Naja die Tür aber offen zu halten macht immer Sinn. Denn so kann sich auch Dialog entwickeln. Wie man das ablehnen kann mit "Humbug" und das auch noch gut zu finden, erschließt sich mir nicht.
Und es gibt ja gegenteilige Beispiele siehe mein Edit über die FidelityFX Suite - da gibt es einige merge requests und Vorschläge die allesamt ignoriert worden sind offenbar. Tote Hose da.

[fondness]

Naja die Tür aber offen zu halten macht immer Sinn. Denn so kann sich auch Dialog entwickeln. Wie man das ablehnen kann mit "Humbug" und das auch noch gut zu finden, erschließt sich mir nicht.
Und es gibt ja gegenteilige Beispiele siehe mein Edit über die FidelityFX Suite - da gibt es einige merge requests und Vorschläge die allesamt ignoriert worden sind offenbar. Tote Hose da.

Nur weil ein Merge Request nicht gemerged wurde, heißt das noch lange nicht, dass er "ignoriert wurde". In 99.9% der Fälle ist ein merge Request von Hinz&Kuntz halt einfach nur Schrott, so ehrlich sollte man schon sein. Und das AMD nicht die Zeit hat jedem auf Punkt und Beistrich zu erklären, warum etwas nicht verwendet werden kann sollte auch klar sein.

[robbitop]

Und das sagst du alles pauschal. Alles Humbug alles nur Hinz und Kunz Nichtskönner. Da ist also kein konstruktiver Dialog auch nur denkbar weil nichts sinnvolles kommen kann auf den Repositories. Daraus müsste man schließen dass Open Source Kultur im Generellen keinen Sinn macht. Zum Glück sehen das nicht alle so.

[aufkrawall]

Alles was RADV macht ist amdvlk zu ersetzen (wo man sich zuvor sicher großzügig bedient hat).
Das stellst du dir mit ziemlicher Sicherheit zu einfach vor. Mit mal eben Copy & Paste ist so etwas nicht getan, wenn die Treiber ziemlich unterschiedlich sind.
Ansonsten kannst du dir auch die Dateigrößen etwa unter Windows anschauen. Die Treiber für D3D12 oder Vulkan sind ähnlich groß wie der Kerneltreiber, und im Gegensatz zum Kernel dürften da auch nicht lauter Header-Files etc. drin sein.
Außerdem gab es RADV schon vor dem open-source amdvlk und hatte auch da schon ziemlich gut funktioniert.

[fondness]

Und das sagst du alles pauschal. Alles Humbug alles nur Hinz und Kunz Nichtskönner. Da ist also kein konstruktiver Dialog auch nur denkbar weil nichts sinnvolles kommen kann auf den Repositories. Daraus müsste man schließen dass Open Source Kultur im Generellen keinen Sinn macht. Zum Glück sehen das nicht alle so.

Ich habe gesagt 99.9%, das ist gerade nicht pauschal. ;) Klar in einer idealen Welt würde AMD hunderte Devs einstellen die einen "Dialog" führen mit allen Leuten die da in den Repositories herumfuhrwerken. In der Praxis muss AMD halt auch auf die Wirtschaftlichkeit und Sinnhaftigkeit schauen.

[robbitop]

Hm und warum bekommen es viele Solo Hobby Devs und kleine Firmen es hin, ordentlich Fortschritt zu erzielen trotz (oder gerade wegen der) Open Source Kultur? Das sind dann die 0,01%? Wenn das alles nichts bringen würde, gäbe es keinen Grund für Open Source. IMO bist du da deutlich zu pessimistisch.
Mit Linux gibt es ein ganzes OS was für diese Kultur steht was niemals so entstanden wäre wie wir es heute kennen, wenn diese Kultur nicht gelebt worden wäre. Klar wurde da auch viel von Firmen contributet aber nicht nur.

[amdfanuwe]

Macht doch bitte einen Open Source Thread auf. Würde hier gerne etwas zu ZEN 5 lesen.

[MSABK]

Gibt ja immer noch keine non Asus Strix Point Geräte. Kann doch nicht so lange dauern oder?

[DR.DEATH]

Sorry amdfanuwe für die nochmalige Unterbrechung.

nur noch mal als Zusammenfassung:
amdgpu == Kerneltreiber für die Hardware (von AMD entwickelt/verwaltet)
radeonsi == AMD OpenGL Treiber in Mesa (von AMD entwickelt/verwaltet)
radv == Vulkan Treiber für AMD in Mesa (community entwickelt)
amdvlk == Vulkan Treiber für AMD (von AMD entwickelt/verwaltet)

AMDVLK war zu spät dran also wurde von der community RADV "entwickelt". Nur mit dem klitzekleinen Unterschied, dass mal eben der Source von anv (Intels OSS Vulkan Treiber) geforked wurde und an AMD angepasst wurde. Ich möchte die Leistung nicht schmälern aber ohne Intels heavy lifting bezweifel ich dass es vor amdvlk einen community Vulkan Treiber gegeben hätte.

AMDVLK wird eher gedroppt weils einfach die OSS Ausgliederung ihres bestehenden Vulkan Treibers ist. Der ist auf allen OSen gleich und mit entsprechenden GlueCode/Zwischenlayer (PAL) auf jedes OS angepasst. Bei Linux halt mit LLVM statt ihres eigenen proprietären LLVMs.

Weils vorher auch noch um den ShaderCompiler (ACO) ging, für Interessierte, der anfängliche Hauptdev hat sich hier auch mal zu Wort gemeldet: https://www.forum-3dcenter.org/vbulletin/showthread.php?t=595575

Der Compiler ist auch nicht vom Baum gefallen oder lässt sich mal eben als dropin überall verwenden. Anscheinend wird mittlerweile ja auch an der Möglichkeit für radeonsi gearbeitet.

Hm und warum bekommen es viele Solo Hobby Devs und kleine Firmen es hin, ordentlich Fortschritt zu erzielen trotz (oder gerade wegen der) Open Source Kultur? Das sind dann die 0,01%? Wenn das alles nichts bringen würde, gäbe es keinen Grund für Open Source. IMO bist du da deutlich zu pessimistisch.
Mit Linux gibt es ein ganzes OS was für diese Kultur steht was niemals so entstanden wäre wie wir es heute kennen, wenn diese Kultur nicht gelebt worden wäre. Klar wurde da auch viel von Firmen contributet aber nicht nur.

Vielleicht weil es eben Hobby Devs oder kleine Firmen sind?
Wie viele davon haben denn einen Treiber (Hardware + mehrere 3D Treiber + Videozeugs) auf 3-4 Betriebssystemen mit zum Teil proprietärer Entwicklung, Großkunden mit zertifizierten Treibern/Funktionalitäten, unterschiedlichen (Shader)Compilern und versuchen das Ganze zu managen?

Dann hast du im schlimmsten Fall 4 verschiedene Entwicklungsstände und willst aber deine eigenen Anpassungen mergen und auf 2 OSen geht's nicht wegen anderer Codestruktur/funktionalität/umsetzung? Mag Koryphäen geben die bei sowas komplexen noch den Überblick behalten und Bock drauf haben von jedem OS zu jeden OS Änderungen zu mergen/zu umschiffen und ihre eigene Entwicklung über alle Stände hinweg ein zu bringen aber auf Dauer dürfte das mehr als anstrengend werden.

Kann es besser sein? Na klar. Geht das mal einfach so weil beschließen wir jetzt? Ich habe Zweifel. In deinem Beispiel mit "ich zieh mal ne Software oder whatever als OSS auf" geht das viel einfacher. Da hast du einen Bruchteil der Abhängigkeiten, geschweige denn gewachsene Strukturen. Die Änderung in einem Repo haut dir auch nicht deine 3 anderen kaputt.

Bogen zu Zen5:
Sieht man auch schön am AGESA, damals proprietär aufgezogen weil Zeit oder wegen proprietären Teilen von Zulieferern. Wird auch seit Jahren dran gearbeitet das zu OSS als OpenSIL in 2026 zu ersetzen. Dauert halt und wird wahrscheinlich auch wieder nur ein Codedrop weil sehr speziell und bestimmt auch mit genug binary Blobs wegen no OSS von den üblichen Zulieferern (DRAM Interfaces usw.).
Edit: Bzw. sagte AMD nicht mal das der Source dort auch nur fürs Auditing/Überprüfen durch User/Anbieter sein soll und nicht dass dort jeder nach belieben Änderungen einbringen kann?

[fondness]

Krakan und Strix Halo supporten angeblich bis LPDDR5X 8000 MT/s:
https://videocardz.com/newz/amd-krackan-point-to-support-up-to-lpddr5x-8000-mt-s-memory

[mocad_tom]

@MSABK


Welches hättens denn gerne?

https://geizhals.de/?cat=nb&xf=6751_31

[MSABK]

@MSABK


Welches hättens denn gerne?

https://geizhals.de/?cat=nb&xf=6751_31

Von Lenovo.

[mczak]

Krakan und Strix Halo supporten angeblich bis LPDDR5X 8000 MT/s:
https://videocardz.com/newz/amd-krackan-point-to-support-up-to-lpddr5x-8000-mt-s-memory
Wobei meines Wissens LPDDR5X-8000 kein Standard-Speed ist - solche Chips baut auch keiner. Es gibt bloss 7500, 8533 und die brandneuen 9600 und 10700. Eine Unterstützung für zumindest lpddr5x-8533 wäre daher sicher auch nicht verkehrt, der sollte auch gut verfügbar sein. Aktuelle High-End Smartphones (mit SD 8 Gen 3 z.B.) benutzen auch schon lpddr5x-9600.

[reaperrr]

Wobei meines Wissens LPDDR5X-8000 kein Standard-Speed ist - solche Chips baut auch keiner. Es gibt bloss 7500, 8533 und die brandneuen 9600 und 10700. Eine Unterstützung für zumindest lpddr5x-8533 wäre daher sicher auch nicht verkehrt, der sollte auch gut verfügbar sein. Aktuelle High-End Smartphones (mit SD 8 Gen 3 z.B.) benutzen auch schon lpddr5x-9600.
Vielleicht schafft der MemController nicht mehr, bzw. würde dann mehr (zu viel) Spannung und Saft brauchen und effektiv eher Performance kosten.

QC mussten beim X1 ja auch auf 8448 runtergehen, weil 8533 scheinbar zu viele Chips entweder garnicht oder vielleicht nur mit mehr MemController-Voltage und damit nicht innerhalb der TDP geschafft hätten.

SD8 Gen3 hat nur ein 64bit SI, und vielleicht ist Gen3 auch einfach IP-technisch neuer und weiter als X1, der ja meins Wissens primär vom ehemaligen Nuvia-Team kommt und auch bei der ARM-IP-Revision zurückhängt.

[mczak]

SD8 Gen3 hat nur ein 64bit SI, und vielleicht ist Gen3 auch einfach IP-technisch neuer und weiter als X1, der ja meins Wissens primär vom ehemaligen Nuvia-Team kommt und auch bei der ARM-IP-Revision zurückhängt.
Naja, also der Speichercontroller des SD8 Gen 3 darf vermutlich eher weniger als die Hälfte verbrauchen als der eines 128bit Notebook-Chips, von daher sollte das kein Problem sein.
Hingegen macht es das PoP Memory packaging wohl durchaus einfacher das ganze bei hohen Frequenzen zu betreiben. Nur beim Erscheinen von Strix Halo / Kraken Point wird es eben schon Smartphones mit lpddr5x-10700 geben, das ist doch ein beträchtlicher Unterschied. Wobei auch z.B. apple sich bei den M-SOCs nicht gerade durch hohe unterstützte Frequenzen auszeichnet (M3 mit bloss lppdr5-6400, M4 mit lppdr5x-7500).

[robbitop]

Die M SoCs haben allerdings noch einen ganz brauchbaren SLC um da etwas abzufedern. (relativ zu ihrer Performance und Größe)
Stricke Halo wird natürlich mit IF$ wahrscheinlich auch keine Bandbreitenprobleme bekommen. Für die normalen APUs wäre das aber auch was feines. Und wenns nur 8-16 MiB wären…

[MSABK]

Lunar Lake wurde vorgestellt. Was wird da von AMD als direkte Konkurrenz kommen? Gerade die iGPU soll ja stark sein auch mit XMX.

[Dino-Fossil]

Vermutlich erstmal nix? Evtl. könnte man Strix Halo zeigen, ist aber ein ganz anderes Segment.
Aber soweiso würden mich erstmal unabhängige Tests/Vergleiche zu den Intel Chips interessieren.

[HOT]

Warten wir mal ab, wie gut die GPU wirklich ist.

[dildo4u]

Lunar Lake wurde vorgestellt. Was wird da von AMD als direkte Konkurrenz kommen? Gerade die iGPU soll ja stark sein auch mit XMX.
Kraken Point soll 2025 kommen aber nur 8 CU IGP da Midrange.

https://www.computerbase.de/2024-03/amd-sound-wave-nach-strix-sarlak-und-kraken-eine-weitere-amd-apu


Warten wir mal ab, wie gut die GPU wirklich ist.
Intel nutzt deutlich schneller Ram da muss man nicht raten AMD hat kein IF Cache in Strix um das zu kompensieren.

[M4xw0lf]

Intel hat immer noch die eigenen Treiber als Stolperstein und Strix Point ist anders als LNL schon am Markt. Notwendigkeit für eine Reaktion spezifisch auf Lunar Lake ist eher gering.

[HOT]

[...]


Intel nutzt deutlich schneller Ram da muss man nicht raten AMD hat kein IF Cache in Strix um das zu kompensieren.

Ah, Kaffeesatzlesen ftw. Wer sagt denn, dass Intel hier so effizient ist wie AMD?

[dildo4u]

AMD ist ohne Cache nicht effizient ansonsten würden die 16 CU durchschlagen.

Best Case +22% vs Hawkpoint (51Watt)

https://www.computerbase.de/2024-09/strix-point-gaming-benchmarks/


AMD verbaut auf einer 6400 IF Cache die massiv weniger Rechenleistung hat.

[HOT]

Kann man alles hertheoretisieren, warten wir mal 24H2-Vergleiche zwischen LNL, Hawk Point und Stirx Point ab.

[dildo4u]

Z2 Serie für Handhelds ab 2025

4I6713BI1Bk

[MSABK]

Kann man die NpU nicht für die ML Upscaler nutzen? Z.B die in den mobilen Chips.

[dildo4u]

AMD sollte lieber an einer GPU Lösung arbeiten, der Punkt ist ja das man die GPU entlasten kann ohne extra Latenz einer NPU.

Hier das DF Video zur Microsoft NPU Lösung.

https://youtu.be/gmKXgdT5ZEY?si=JId6aWJ8Q7S45ljq

[robbitop]

Kann man die NpU nicht für die ML Upscaler nutzen? Z.B die in den mobilen Chips.

Wenn es richtiges upsampling auf basis von temporalen Daten sein soll (wie DLSS, FSR2/3, XeSS, PSSR, MetalFX AI und TSR), dann muss das in die GPU bzw dessen die weil die Latenz sonst zu hoch wäre. Wenn man nur mit dem fertigen Bild arbeiten will, wie das MS Verfahren, dann reicht eine externe NPU. Aber letzteres hat halt viel weniger Potenzial als ersteres.

PSSR könnte allerdings wie MetalFX AI über einen separaten IP Block außerhalb der GPU (aber im selben die) laufen. MetalFX läuft über die NPU (weil SoC ist alles im gleichen Chip). PSSR läuft gerüchteweise über XDNA2 IP (was Sony als custom AI HW bezeichnet).

[fondness]

Ein paar neue Zen5-Codenamen im LLVM-Code:

case 26:
CPU = "znver5";
*Type = AMDFAM1AH;
if (Model <= 0x77) {
// Models 00h-0Fh (Breithorn).
// Models 10h-1Fh (Breithorn-Dense).
// Models 20h-2Fh (Strix 1).
// Models 30h-37h (Strix 2).
// Models 38h-3Fh (Strix 3).
// Models 40h-4Fh (Granite Ridge).
// Models 50h-5Fh (Weisshorn).
// Models 60h-6Fh (Krackan1).
// Models 70h-77h (Sarlak).
CPU = "znver5";
*Subtype = AMDFAM1AH_ZNVER5;
break; // "znver5"
}

https://github.com/llvm/llvm-project/pull/107964/files

[Lehdro]

"Weisshorn" hatte man bisher zu Zen 6 zugeordnet und Strix 3 ist bitte was?

[mczak]

Schweizer Berge als Codenamen, gefällt mir :biggrin:.

[Mortalvision]

Hieß es nicht im frühen Sommer, dass die X3D schon Ende September kommen könnten? Oder hat sich das wieder alles mal auf den Januar und die CES verschoben?