News AMD Zen 6: Erster Linux-Patch adressiert neue Architektur

PCGH_Sven

PCGH-Autor
AMD hat mit den Vorbereitungen für seine kommenden CPU-Mikroarchitekturen Zen 6 ("Morpheus") und Zen 6c ("Monarch") begonnen, wie ein erster Patch für das freie Betriebssystem Linux jetzt belegt.

Was sagt die PCGH-X-Community zu AMD Zen 6: Erster Linux-Patch adressiert neue Architektur

Bitte beachten: Thema dieses Kommentar-Threads ist der Inhalt der Meldung. Kritik und allgemeine Fragen zu Online-Artikeln von PC Games Hardware werden hier gemäß der Forenregeln ohne Nachfrage entfernt, sie sind im Feedback-Thread besser aufgehoben.
 
Zen6 werde ich mir wohl den 800x3D kaufen, wenn er zu einem fairen Preis zu haben ist. Also direkt zum Start Glück haben und zur UVP bekommen oder halbes Jahr warten. Wäre mit beiden Szenarios einverstanden, bevorzuge eigentlich sogar die 6 Monate Wartezeit.
 
Ich freue mich schon auf die CPUs mit 12 Kerne pro CCD.
Dann gibt es keine Kommunikationsprobleme mehr dazwischen.
Wie beim jetztigen 12 Kerner. Welcher zwei 6 Core CCDs hat.
 
Zuletzt bearbeitet:
Ich freue mich schon auf die CPUs mit 12 Kerne pro CCD.
Dann gibt es keine Kommunikationsprobleme mehr dazwischen.
Wie beim jetztigen 12 Kerner. Welcher zwei 6 Core CCDs hat.
Und es sind dann auch 24 Kerner möglich.
Problem?
Du meinst die CCD Interconnect Latency?
Die ist ja logisch und nicht wirklich ein riesen Probelm. Kann man mit besseren Schedulern entgegnen, die die Work-Tasks sinnvoller auf die CCD's verteilen.
  1. Scheduler Improvements: The Linux kernel has seen various updates to its scheduler that aim to optimize task placement across CCDs. The goal is to keep threads that frequently communicate on the same CCD to minimize interconnect latency. The Completely Fair Scheduler (CFS) and the Real-Time (RT) scheduler have been tuned to better handle multi-threaded workloads, which is crucial for gaming.
  2. NUMA Awareness: AMD's architecture is based on a Non-Uniform Memory Access (NUMA) model. Improvements in the Linux kernel have enhanced NUMA awareness, allowing the scheduler to make more informed decisions about where to place processes and threads. This can help reduce latency by ensuring that threads access memory that is local to their CCD.
  3. Thread Affinity: Developers can set thread affinity to bind specific threads to particular cores or CCDs. This can be done through tools like taskset or by using specific APIs in applications. By controlling thread placement, developers can reduce the overhead of inter-CCD communication.
  4. Game-Specific Optimizations: Some game developers are optimizing their engines to be more aware of AMD's architecture. This includes better thread management and load balancing across cores and CCDs, which can lead to improved performance and reduced latency.
  5. Kernel Parameters and Tuning: Advanced users can tweak kernel parameters related to scheduling and memory management to optimize performance for specific workloads. This includes adjusting settings for CPU frequency scaling, power management, and scheduler behavior.
  6. Driver and Firmware Updates: Regular updates to the AMD GPU and CPU drivers, as well as firmware updates, can include optimizations that reduce latency and improve performance in gaming scenarios.
  7. Community Contributions: The open-source community often contributes patches and improvements to the Linux kernel that can enhance performance on AMD hardware. Keeping the kernel up to date with the latest releases can help users benefit from these improvements.
 
Zuletzt bearbeitet:
Problem?
Du meinst die CCD Interconnect Latency?
Die ist ja logisch und nicht wirklich ein riesen Probelm. Kann man mit besseren Schedulern entgegnen, die die Work-Tasks sinnvoller auf die CCD's verteilen.

  1. Scheduler Improvements: The Linux kernel has seen various updates to its scheduler that aim to optimize task placement across CCDs. The goal is to keep threads that frequently communicate on the same CCD to minimize interconnect latency. The Completely Fair Scheduler (CFS) and the Real-Time (RT) scheduler have been tuned to better handle multi-threaded workloads, which is crucial for gaming.
  2. NUMA Awareness: AMD's architecture is based on a Non-Uniform Memory Access (NUMA) model. Improvements in the Linux kernel have enhanced NUMA awareness, allowing the scheduler to make more informed decisions about where to place processes and threads. This can help reduce latency by ensuring that threads access memory that is local to their CCD.
  3. Thread Affinity: Developers can set thread affinity to bind specific threads to particular cores or CCDs. This can be done through tools like taskset or by using specific APIs in applications. By controlling thread placement, developers can reduce the overhead of inter-CCD communication.
  4. Game-Specific Optimizations: Some game developers are optimizing their engines to be more aware of AMD's architecture. This includes better thread management and load balancing across cores and CCDs, which can lead to improved performance and reduced latency.
  5. Kernel Parameters and Tuning: Advanced users can tweak kernel parameters related to scheduling and memory management to optimize performance for specific workloads. This includes adjusting settings for CPU frequency scaling, power management, and scheduler behavior.
  6. Driver and Firmware Updates: Regular updates to the AMD GPU and CPU drivers, as well as firmware updates, can include optimizations that reduce latency and improve performance in gaming scenarios.
  7. Community Contributions: The open-source community often contributes patches and improvements to the Linux kernel that can enhance performance on AMD hardware. Keeping the kernel up to date with the latest releases can help users benefit from these improvements.
Naja, ich zitiere mal @PCGH_Dave :

"Leute, nehmt es mir nicht übel, aber es kann nicht euer Ernst sein, dass nach über zwei Jahren von Ryzen-X3Ds mit zwei CCDs das Core Scheduling weiterhin nicht korrekt funktioniert. Nur diesem Umstand ist es zu "verdanken", dass ich sämtliche Ryzen-CPUs mit zwei CCDs nicht ohne Weiteres empfehlen kann. Ich muss in jedem CPU-Test darauf hinweisen. Immer wieder erscheinen Spiele, die fehlerhaft auf dem zweiten CCD laufen, mit vergleichsweise unterirdischer Performance. Die Lösung sollte einfach lauten: Kauft nur Ryzen mit einem CCD. Aber leider erhalten nun mal die Ryzen 9 die besten Kerne, auf die es Enthusiasten (wie ich einer bin) abgesehen haben. AMD, bekomm das endlich auf die Reihe, meine Güte!"
Quelle: Test 9900X3D

Anscheinend scheint das doch ein Problem zu sein. ;)
 
Naja, ich zitiere mal @PCGH_Dave :

Quelle: Test 9900X3D

Anscheinend scheint das doch ein Problem zu sein. ;)

Ich hatte auch den Eindruck dass da Windows etwas weniger hinterher war.
Ob das nun am Fokus und der Hardwareverbreitung und Interessen an Abwärtskompatibilität oder dem Hoheitsgebiet und schwieriger Kommunikation und Durchsetzung zwischen Microsoft und AMD lag? :ka:

Von außen ist nur soviel beobachtbar: es gibt Unterschiede im Scheduling zwischen Windows und Linux. Linux hat erhebliche Fortschritte bei der Optimierung seines Schedulers für die AMD-Architektur gemacht, insbesondere in Bezug auf NUMA-Bewusstsein und Thread-Platzierung. Während Windows ebenfalls seine Scheduling-Algorithmen verbessert hat, berichten einige Benutzer und Entwickler, dass Linux tendenziell mehr Effizienz bei der Handhabung von Multi-Thread-Workloads auf AMD-CPUs zeigt, insbesondere in Spielszenarien.

Dagegen ist dann wieder die Optimierung von Parallelisierungen in Spielen sehr Windows-lastig. Viele Spielentwickler optimieren ihre Titel hauptsächlich für Windows, da es einen größeren Marktanteil im Gaming-Bereich hat.
In Linux wird dies dann durch Translation-layer-tweaks und die Community addressiert.

Die Treiberunterstützung von AMD ist dank des OpenSource-Ansatzes sehr sehr gut und AMD arbeitet sehr aktiv daran auch für Linux die Treiber und Firmware zu verbessern.

User-Berichte deuten darauf hin, dass die Benutzererfahrung in Spielen auf AMD-Hardware unter Linux aufgrund der oben genannten Verbesserungen im Scheduler und der besseren Handhabung von Multi-Thread-Aufgaben reibungsloser zu sein scheint.
Dies variiert natürlich je nach Spiel, Betriebssystemversionen und -Updates, sowie Hardwarekonfiguration.


Was sagt denn der @PCGH_Sven dazu? Kannst Du gravierende Einbrüche auch in Linux-Benchmarks ausmachen oder hält es sich da in Grenzen?
 
Zuletzt bearbeitet:
Ja unter Linux mag das anders sein. Das kann ich nicht beurteilen.
Aber die meisten Spieler zocken nach wie vor mit Windows.

Auf jeden Fall sind 12 Kerne/CCD besser als 6+6.
 
@RyzA ich versuch gerade in Dave's Bericht zu entdecken, warum er so konsterniert ist. Übersehe ich was oder reden wir hier von teils ein paar Frames besser, teils ein paar frames schlechter, je nach Spiel und Skalierung?

Mir springt nichts signifikantes ins Auge wo ich sagen würde: "aua-ha ... das ist ein wirkliches Problem" das das Spiel ungenießbar macht.

Ja unter Linux mag das anders sein. Das kann ich nicht beurteilen.
Aber die meisten Spieler zocken nach wie vor mit Windows.

Auf jeden Fall sind 12 Kerne/CCD besser als 6+6.
Nagut ...
Ich war davon ausgegangen, dass wir gerade eh Linux-fokused unterwegs sind, weil sich auch der Artikel um ein Linux-finding drehte
:kaffee:

Vielleicht ist es ja mehr ein "Windows-Probem"?

Speaking of wich ... ich darf jetzt erst mal wieder zum IT-Point schlappen, weil der Windows-Geschäftslaptop mich gestern ausgesperrt hat. Auch das Syncing, Einrichten und Konfigurieren des Austauschgerätes geht nicht easy. Entweder muss ich tief in die Registry, um hässliches Verhalten zu countern oder Admin-Rechte müssen her ...

*Nerv*

Ich bin mehr damit beschäftigt, den Rechner zu fixen und an Windows zu schrauben, als zu arbeiten.
Freut sich dann wieder die Firma über die "gestiegene Effektivität" :wall:

In Dave's Sinne: "Ist das Euer Ernst, Microsoft, HP !?!?! Macht endlich Eure Hausaufgaben!"
 
Zuletzt bearbeitet:
@RyzA ich versuch gerade in Dave's Bericht zu entdecken, warum er so konsterniert ist. Übersehe ich was oder reden wir hier von teils ein paar Frames besser, teils ein paar frames schlechter, je nach Spiel und Skalierung?

Mir springt nichts signifikantes ins Auge wo ich sagen würde: "aua-ha ... das ist ein wirkliches Problem" das das Spiel ungenießbar macht.
Ungenießbar nicht aber auch nicht optimal.
Nagut ...
Ich war davon ausgegangen, dass wir gerade eh Linux-fokused unterwegs sind, weil sich auch der Artikel um ein Linux-finding drehte
:kaffee:
Schon. Aber die Hardware kommt ja nicht nur für Linux raus.:D
Vielleicht ist es ja mehr ein "Windows-Probem"?
Ja möglich.
 
Ungenießbar nicht aber auch nicht optimal.
Nicht Optimal ist noch kein Problem ;)

Schon. Aber die Hardware kommt ja nicht nur für Linux raus.:D
Da es unter Linux besser zu funktionieren scheint, sehe ich jetzt da nicht unbedingt den Buh-Mann bei der Hardware.
Die Hardware tut, was die Hardware tut und einigermaßen genau wie sie soll.

"Auaaaaa! Ich hab mir mit dem Hammer auf den Zah gehauen!!! Sch**ß HAMMER!" :-P
 
Nicht Optimal ist noch kein Problem ;)


Da es unter Linux besser zu funktionieren scheint, sehe ich jetzt da nicht unbedingt den Buh-Mann bei der Hardware.
Die Hardware tut, was die Hardware tut und einigermaßen genau wie sie soll.
Naja, aber das es besser wäre, wenn es nur einen CCD für 12 Kerne gibt als zwei 6 Kern CCDs da stimmst du doch zu, oder? :ugly:
 
Naja, aber das es besser wäre, wenn es nur einen CCD für 12 Kerne gibt als zwei 6 Kern CCDs da stimmst du doch zu, oder? :ugly:
Das kann "helfen", wenn man nicht mehr, als 12 Kerne haben möchte/braucht.

Grundsätzlich ist die Chiplet-Architektur und der Ansatz ja nicht schlecht (regelrecht genialer Kunstgriff).
Jetzt muss man nur gescheit damit umgehen und den Unterbau adressieren und nutzen.

Dass "alles aus einem Guss" seine anderen Probleme hat (Energie, Hitze, Produktionsausschuss und Fehlerquote, Kommunikationsstrecken etc.) und bei steigender Kernzahl und Aufgaben-Diversifizierung nicht mehr rechtfertigbar wird, ist auch klar.


Dave könnte sich ja auch mal bei den Spieleentwicklern beschweren, warum die nach so vielen Jahren es immer noch nicht hinbekommen, gescheiter zu skalieren und ihre Workload sinnvoller zu verteilen.

Immer die Frage, welchen "Schuldigen" man beklagen möchte.
:ugly:
 
Zuletzt bearbeitet:
Dave hat schon Recht: kauft zum reinen Spielen einfach eine CPU mit nur einem CCD, weil besser bzw. weniger nervig ist das.
Vor allem die 12 Kerner sind ja in der Situation blöde, wenn Spiele möglichst 8 Kerne haben wollen, aber 6 zu wenig und 12 dann die CCD-Latenzen mit sich bringen.
Sogar AMD hat das ja per Software so hingetüdelt, dass dann ggf. einfach der 2te CCD abgeschaltet wird, um das Spielen weniger stressig zu machen.
Aber es ist schon richtig, dass AMD seit Ryzen 1000 sehr viel Zeit und Geduld in die Problematik gesteckt hat, um die Latenzen zu verringern und die Kommunikation der Recheneinheiten, auch mit dem Betriebssystem, wesentlich zu verbessern.
Die Probleme hat Intel ja nun auch mit seiner neuen Prozessortechnologie, den 200ern, da müssen ja gleich 6 oder 7 Einzelteile miteinander verbunden werden, was aber ein anderer Ansatz ist als bei AMD.
Und AMD hat ja nicht umsonst bei den Grafikkarten keinen 4090 Killer mit 6 Chiplets auf den Markt gebracht, weil dazu viel Strom nötig gewesen wäre, um den Leistungsverlust der stark erhöhten Latenzbremse auszugleichen.
Ich finde den Übergang zu einem 12er CCD bei AMD also auf jeden Fall als sehr gut und auch notwendig an, um jetzt mit Intel weiterhin auf Augenhöhe bleiben zu können.
Denn auch wenn man es nicht hören mag, die letzten JAhre hat Intel genutzt, um von seinen 4+4 Kernen auf bis zu 24 Kerne hochzupimpen, während AMD jetzt nach dem letzten Upgrade von Ryzen 1000 auf von 4 dann 8 Einheiten pro CCD schon mehrere Nullrunden hingelegt hat, und man noch immer max. 16 Kerne im System sitzen hat..
Vielen Nutzern könnte man also schon bald einen 265K als Rundumsorglospaket empfehlen, wenn auch Anwendungen im Spiel sind, die massig Kerne wollen.
Vor allem nach den diversen Patches, die einen Teil der brachliegenden Leistung wieder zurückgebracht haben.
AMD's Strategie einfach 8 Kerne mit 3D Speicher für reine Spieler und 16 Kerne für die Anwendungsleute ist halt so langsam ausgelutscht, auch weil da die eigenen guten Alternativen nicht wirklich existieren, ich spreche da jetzt von Interpolation.
 
[...] um jetzt mit Intel weiterhin auf Augenhöhe bleiben zu können.
Wie jetzt? Soll sich AMD auch noch bücken? :ugly:

Denn auch wenn man es nicht hören mag, die letzten JAhre hat Intel genutzt, um von seinen 4+4 Kernen auf bis zu 24 Kerne hochzupimpen,
Notgedrungen. Nachdem ihnen ihr "4-cores sind mehr als ganug"-Ansatz um die Ohren flog.
Und dann die Frage: 24 Kerne? Was für welche - Power, efficiency, ultra-efficiency? Und wieviele Threads sind das dann?
Der Scheduler wird gleich 3x komplexer.
 
Zuletzt bearbeitet:
Mir springt nichts signifikantes ins Auge wo ich sagen würde: "aua-ha ... das ist ein wirkliches Problem" das das Spiel ungenießbar macht.
Naja, wenn man mehr ausgibt und dafür dann weniger bekommt oder die erhoffte zukünftige Mehrspieleleistung in Spielen dadurch aufgefressen wird, ist das schon blöd. Heißt aber natürlich nicht, dass man nicht z.B. auch einen 9950X kaufen kann, wenn man zocken will, aber eben auch viele Kerne braucht.

Abgesehen von den doch erheblichen Mehrkosten hat mich das asymmetrische Design bei den 2-CCD-X3Ds und das ganze Thema Core-Parking davon abgebracht, in einen 12- oder 16-Kerner zu investieren. Du scheinst da halbwegs drinzustecken. Wird Core-Parking unter Linux überhaupt praktiziert? Ich empfinde das nämlich als irgendwo zwischen totalem Antifeature und einem ziemlich grottigen Workaround.
 
Wie jetzt? Soll sich AMD auch noch bücken? :ugly:

Ich hätte es nicht besser sagen können!

Wie war dieses Zitat von Pat Gelsinger? "AMD in the real view mirror" ? Klar, als er mit Intel rückwärts fahren übte...

Und dann die Frage: 24 Kerne? Was für welche - Pweor, efficiency, ultra-efficiency? Und wieviele Threads sind das dann?
Der Scheduler wird gleich 3x komplexer.

Den Thread Director nicht zu vergessen. Zusätzliche Transistoren, welche bei einer homogenen ISA auf unterschiedlich ausgelegten Kernen keiner braucht. Wie Linux schön zeigt: Alles eine Frage sinnvoll ausgeklügelter Software.

Al kleiner Nachsatz @PCGH_Sven :

[...] und Epyc 9005 ("Venice") an den Start gehen.

Das werden Epyc 9006 - Zen 6 und so...
 
Naja, ich zitiere mal @PCGH_Dave :


Quelle: Test 9900X3D

Anscheinend scheint das doch ein Problem zu sein. ;)
Ist eines und wird eines bleiben solange die Cores nicht anders miteinander verbunden werden, wegen Latenz und Bandbreite.

Genau deshalb hab ich ja immer gehofft von Zen 6 kommt gleich ein 16 Kern CCD.
Leider sind nur 12 :/

Man nehme an Zen 6 legt wieder IPC drauf (sagen wir 8-15%) und vielleicht nähert man sich auch den 6 GHz, so hätte man schon ein beträchtliches Leistungsplus.

Gäbe es dann auch statt einem 2*8 Chip einen 1*16 Chip würde selbst ich als männlicher Mann feucht im Schritt werden.

Deshalb hoffe ich, dass von den angeblichen in N2 gefertigten 16 Core CCDs für Server ein paar für die normalen Consumer abfallen.

Dann würde sich auch der Mehrverbrauch in Grenzen halten können
 
Da kommen doch genug spannende Sachen auf uns zu. EIn Zen6 mit zwei Speicher Controller wäre doch super, jeder CCD bekommt einen eigenen.

Ich muss sagen der 7950x3d macht seine Sache sehr gut, bei Spielen werden die 8 Kerne genutzt und bei Anwendung alle. Man könnte ja auch Sachen im Hintergrund auf den normalen Kernen laufen lassen.

Wenn Intel gekonnt hätte, dann gebe es längst eine 16 Kerner ohne E-Cores.

Aber deren Arthitektur gibt das nicht her.

Wenn man den 285K wieder übertraktet ist er schnell genug. Hier hat man die Brechstange dem Stromvebrauch und Effizients geopfert. Unter dem Strich war nicht viel anders.
 
Zurück