Diskussion zu: News des 17. Juni 2025

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/news-des-17-juni-2025

[Gast]

Hmm sollten Rentable Units tatsächlich kommen wäre das schon ein massiver Gamechanger. Vor allem wenn spätere Software besser damit umgehen kann, ich nehme mal nicht an, dass das gleich anstandslos perfekt funktioniert.

Allerdings hätte ich eher erwartet, dass man in Zukunft dann auch eine andere Konfiguration wählt, auch bei den Chiplets. Statt eigene P/E COre Chiplets zu bauen hätte ich erwartet, dass man das Abarbeiten von einzelnen oder zusätzlichen Threads über die E-Cores abwickelt. Und diese dann direkt an den P Core angebunden sind.

Also etwa so, dass ein P Core 2-4 E Cores hat mit dem es sich den Cache teilt. Die E-Cores müssen nicht voll funktionale Cores sein, aber ähnlich wie damals bei Bulldozer Cores mit bestimmten Funktionen, die dann ausgelagert werden können.

DIe E Cores könnten dann quasi das "Hyperthreading 2.0" sein und sowohl "zerlegte" einzelne Threads mithelfen abzuarbeiten, als auch wie bislang zusätzliche Threads.

Was das "zerlegen" betrifft wirds halt spannend wie man das umsetzt. Sowohl im Compiler/Code als auch eben vom Scheduler.
Es gibt hierzu schon viele Jahre Konzepte, es hat halt noch niemand etwas massentaugliches gebracht.

[Raff]

Da auch hier die berechtigte Frage nach Nvidias Treiber-Boosts aufkommt: Die habe ich natürlich ebenfalls im Blick – derzeit gibt es schlicht keine weltbewegenden Unterschiede. Die PCGH-Benchmarks sind durch ständige Nachtests immer so aktuell wie menschenmöglich. Bei den 9070er waren die Unterschiede derart gehäuft (aufgefallen bei den 9060-Tests), dass ich das dediziert herausarbeiten wollte (spread the word! =)). Und das nächste große Ding steht auch schon an: die Mid-Year-Revision der GPU-Benchmarks 2025. Dabei werden grundverschiedene Dinge herauskommen. Mal sehen, welche ...

MfG
Raff

[Zossel]

Hmm sollten Rentable Units tatsächlich kommen wäre das schon ein massiver Gamechanger. Vor allem wenn spätere Software besser damit umgehen kann, ich nehme mal nicht an, dass das gleich anstandslos perfekt funktioniert.

Von einem geteilten L2 als Vorstufe zu Rentable Units zu spekulieren klingt gewagt.

[Leonidas]

Generell geht es wohl eher in die Richtung, dass es derzeit noch keine RUs gibt. Womöglich ist der gesharte L2 einfach nur eine Rest dieser Entwicklung. Für RU hätte man das gebraucht, nun ist es geblieben.

Interessant wäre, ob Intel wirklich noch einmal in diese (intelligente) Richtung denkt - oder uns einfach nur mit Kernen zuspammen will.

[Exxtreme]

Diese "rentable units" sind womöglich technisch so nicht machbar. Man kann zwei Kerne nicht so zusammenschalten, dass sie sich wie einer verhalten und sich die IPC dabei verdoppeln. Wenn soetwas möglich wäre dann hätte man das längst. Das Einzige, was ich mir da so vorstellen kann, ist dass man mit diesen zusammengefassten Kernen versucht Hotspots zu entschärfen, indem man die Kerne abwechselnd mit Arbeit/Daten versorgt. Dann könnten die Kerne länger mit einer Boostfrequenz laufen.

[Leonidas]

Jein. Etwas mehr IPC ist da durchaus drin. Selbst +20% sind ja schon viel heutzutage. Und das erreicht man schlicht dadurch, dass die normalen Kerne eher klein sind - sprich, wenige Ausführungseinheiten haben. Schlicht weniger INT & FP pro normalem Kern. Zwei davon zusammengefasst wären dann jedoch wieder ganz dick.

[Zossel]

Jein. Etwas mehr IPC ist da durchaus drin. Selbst +20% sind ja schon viel heutzutage. Und das erreicht man schlicht dadurch, dass die normalen Kerne eher klein sind - sprich, wenige Ausführungseinheiten haben. Schlicht weniger INT & FP pro normalem Kern. Zwei davon zusammengefasst wären dann jedoch wieder ganz dick.

Du hast Papers die dieses Konzept und mögliche Implementierungen genauer ausführen?

[X.Perry_Mental]

Zur Radeon RX 9070 GRE: laut Tabelle 48 CU @ 292-bit

[Gast]

Das Einzige, was ich mir da so vorstellen kann, ist dass man mit diesen zusammengefassten Kernen versucht Hotspots zu entschärfen, indem man die Kerne abwechselnd mit Arbeit/Daten versorgt. Dann könnten die Kerne länger mit einer Boostfrequenz laufen.
Da die Kerne bedingt durch den Cache nebeneinander liegen müssen, wird der Abstand so klein sein, dass das kaum bis gar nichts bringt.Ob die Hitze jetzt 1mm weiter rechts oder links entsteht, ist im Heatspreader dann schon wieder egal...

[davidzo]

Link zur News:
https://www.3dcenter.org/news/news-des-17-juni-2025


Ob AMD jene 1-2% überhaupt gegenüber nVidia hinzugewonnen hat, ist dabei nicht einmal sicher, denn auch nVidia könnte natürlich in ähnlicher Höhe hinzugewonnen haben.


Du tust so als wenn Raff nur einen Gesamtindex veröffentlicht hat.
Raff hat aber ein differenziertes Bild gezeigt mit einzelnen Spieletests insbesondere mit viel RT und Pathtracing die bis zu 30% mehr Performance zeigen. Logischerweise geht sowas in der Masse unter, aber das war eben auch nicht der Punkt von dem Test.

Das übliche Bild: Zwar können wir deutliche Leistungszuwächse in einzelnen Spielen nachweisen, in einem derart breiten Benchmark-Parcours wie von PCGH gehen diese Errungenschaften jedoch beinahe unter - Pathtracing ausgenommen, denn von den acht getesteten Spielen legen drei zu, sodass der Index klar klettert.

Es ist durchaus spannend zu sehen dass AMD vor allem bei RT und PT aufholt, was bedeutet dass AMDs Rückstand bei RT zum Launch nun noch kleiner geworden ist.


Deine Suggestion dass nvidia ja in genau diesen Spielen (in denen AMD eine eindeutige Schwäche hatte) ebenfalls zugelegt haben könnte ist total unglaubwürdig. Das hier sind klare Fälle von Treiberoptimierung auf einzelne Spiele. Nvidia tut dies auch in der Regel, hat aber in den letzten Releases für Blackwell ausschließlich bugs gefixt. Ein Nachtest von nvidia in diesen Spielen erübrigt sich also es sei denn es gab crashes die einen Test vorher verhindert haben.

Die 576.80 Release notes enthalten keinerlei performanceoptimierungen:
Dune: Awakening: stability issues [5273568]
EA Sports FC 25: stability issues [5251937]
Dragons Dogma 2: displays shadow flicker [5252205]
Clair Obscur: Expedition 33: stability issues [5283401]
Enshrouded: crashes after launching game [5279848]
Monster Hunter World: stability issues when playing in DX12 mode [5305302]
Gray Zone Warfare: stability issues [5284518]
Marvel Rivals: stability issues [5273681]
Ghost of Tsushima Directors Cut: Flickering/corruption around light sources [5138067]
GTA V Enhanced: stability issues [5302755]
Honor of Kings: World: stability issues [5304344]
Forza Horizon 5: stability issues [5131160]
Indiana Jones and The Great Circle: Image corruption [5326122]


Und der vorherige Hotfix 576.26, 576.40 und 576.52 auch nicht:
[RTX 50-Serie] [Black Myth]: Das Spiel stürzt zufällig ab, wenn Wukong sich verwandelt
[RTX 50-Serie] [LG 27GX790A/45GX950A/32GX870A/40WT95UF/27G850A]: Bildschirm bleibt schwarz, wenn im DisplayPort 2.1-Modus mit HDR ausgeführt wird
[Forza Horizon 5]: Lichter flackern nachts
[Forza Motorsport]: Streuung von Streckenfehlern tritt bei Benchmark- oder Nachtrennen auf
[RTX 50-Serie] [Red Dead Redemption 2]: Das Spiel stürzt kurz nach dem Start im DX12-Modus ab. Kein Problem im Vulkan-Modus
[RTX 50-Serie] [Horizon Forbidden West]: Das Spiel friert nach dem Laden eines Speicherstands ein
[RTX 50-Serie] Grauer Bildschirmabsturz bei mehreren Monitoren
[RTX 50-Serie] [Dead Island 2]: Das Spiel stürzt nach dem Update auf GRD 576.02 ab
[RTX 50-Serie] [Resident Evil 4 Remake]: Flackernde Hintergrundtexturen
[RTX 50-Serie] Momentanes Flackern des Displays tritt auf, wenn im DisplayPort 2.1-Modus mit hoher Bildwiederholrate ausgeführt wird



Fixed Gaming Bugs

[F1 23/F1 24] Game crashes at the end of a race [5240429]
[Diablo II Resurrected] Game displays black screen corruption when using DLSS [5264112]
[SCUM] Game may crash after updating to R575 drivers [5257319]
Shader disk cache will not be created with certain games if OS username contains unicode characters [5274587]

Fixed General Bugs

Flickering/corruption around light sources in Ghost of Tsushima Directors Cut [5138067]
Cyberpunk 2077 will crash when using Photo Mode to take a screenshot with path tracing enabled [5076545]
EA Sports FC 25 may crash during gameplay [5251937]
[Forza Horizon 5] Game may crash after extended gameplay [5131160]

Fixed Gaming Bugs

[Monster Hunter Wilds] Random stability issues [5204023]
[RTX 50 series] Dead Space Remake displays shadow flicker [5241013]

Fixed General Bugs

[RTX 50 series] Colors may appear slightly saturated in games when in game-resolution is below the native resolution of the monitor [5158681]
[RTX 50 series] ASUS PG32UQXR/Asus ROG PG248QP/Asus ROG PG32UCDM display may boot to black screen [5088957]
Slight stutter may be observed on certain LG TVs at lower refresh rates when G-SYNC is enabled [5198025]




Interessant zu sehen dass man Monsterhunter anscheinend mehrfach fixen musste.

[Leonidas]

Du hast Papers die dieses Konzept und mögliche Implementierungen genauer ausführen?

Nada. Das ist nur eine (unprofessionelle) These zur Erklärung von RU.


Zur Radeon RX 9070 GRE: laut Tabelle 48 CU @ 292-bit

Gefixt ;)

[Hochzeit2]

Wie wäre es mit einer 8 o. 10 o. 12 P Core CPU die den gazen anderen Elektromüll gewlässt?!

[Platos]

Das vorhandensein von RU wäre aber (in diesem Kontext) sehr schlecht: Wenn nämlich diese 16 Kerne von der IPC überhaupt nicht vergleichbar sind, mit arrowlake-big cores, dann kann man fürchten, dass die perfomance nicht entsprechenden der gesteigerten Perfomancezahl steigt.

Abgesehen davon: gibt es überhaupt noch grosse und kleine kerne bei RU? Ist der Sinn nicht gerade, dass es keine Kernunterscheidung mehr gibt? Weil dann spräche die Kernspezifikation gegen das Vorhandensein von RU ( es werden ja explizit kleine und grosse kerne erwähnt)

[konkretor]

Da auch hier die berechtigte Frage nach Nvidias Treiber-Boosts aufkommt: Die habe ich natürlich ebenfalls im Blick – derzeit gibt es schlicht keine weltbewegenden Unterschiede. Die PCGH-Benchmarks sind durch ständige Nachtests immer so aktuell wie menschenmöglich. Bei den 9070er waren die Unterschiede derart gehäuft (aufgefallen bei den 9060-Tests), dass ich das dediziert herausarbeiten wollte (spread the word! =)). Und das nächste große Ding steht auch schon an: die Mid-Year-Revision der GPU-Benchmarks 2025. Dabei werden grundverschiedene Dinge herauskommen. Mal sehen, welche ...

MfG
Raff


9070 GRE Benchmark, hust hust :wink:

[Gast]

Hmm sollten Rentable Units tatsächlich kommen wäre das schon ein massiver Gamechanger. Vor allem wenn spätere Software besser damit umgehen kann, ich nehme mal nicht an, dass das gleich anstandslos perfekt funktioniert.


Wenn das tatsächlich funktionieren sollte, ist es gerade das umgekehrte die Verantwortung Parallelität zu finden und auszunutzen wird wieder in die Hardware übertragen, sozusagen ein Schritt zurück.

In Zeiten von In-Order war es ja reine Aufgabe der Software Abhängigkeiten zu vermindern und aufzulösen. VLIW/EPIC war dann ein extremer Schritt in dem man die Parallelität und Abhängigkeiten zu 100% in Software abbilden wollte. Superskalares Out-Of-Order hat dann die Verantwortung in Richtung der Hardware verschoben, nun war diese dafür zuständig Abhängigkeiten aufzulösen und Parallelität zu finden. SMT/Multicore ging wieder in die andere Richtung, allerdings aufgesetzt auf Superskalares Out-Of-Order, darüber hinausgehende Parallelität zu finden inklusive aller Abhängigkeiten ist wieder Aufgabe der Software. Alles was man von diesen „Rentable Units“ weiß deutet wieder in die andere Richtung. Die Hardware findet wieder selbst weitere Parallelität zur Beschleunigung.

Allerdings frage ich mich was daran so besonders sein soll, für mich hört sich das mehr nach einem Marketing-Schachzug an um auf dem Papier mehr Kerne zu haben so ähnlich wie damals bei Bulldozer. Man könnte die „2 Kerne“ die anscheinend auch an 1 Thread zusammenarbeiteten können auch einfach als 1 Fetten Kern + SMT bezeichnen.

[crnkoj]

Bei diesem gemeinsamen L2 cache, kann man es aber auch so sehen, wenn 16 P kerne zur Verfügung stehen, aber es nur 8 Threads gibt, dann wird nur jeder zweite P Kern mit Arbeit beauftragt und die 8, die Arbeit haben, können 4MB cache nutzen, also nochmal mehr als 1 P Kern bei Arrow Lake. Andererseits, aber bei vielen Threads, die sich womöglich daten teilen, beide P Kerne aus dem Verbund auf die Daten zugreifen können, was die Latenzen und Effizienz ja verbessern sollte.
Oder sehe ich das falsch?

[Zossel]

Wenn das tatsächlich funktionieren sollte, ist es gerade das umgekehrte die Verantwortung Parallelität zu finden und auszunutzen wird wieder in die Hardware übertragen, sozusagen ein Schritt zurück.

In Zeiten von In-Order war es ja reine Aufgabe der Software Abhängigkeiten zu vermindern und aufzulösen. VLIW/EPIC war dann ein extremer Schritt in dem man die Parallelität und Abhängigkeiten zu 100% in Software abbilden wollte

Und warum das jetzt so gemacht wird hast du dich nicht gefragt?

[Gast]

Bei diesem gemeinsamen L2 cache, kann man es aber auch so sehen, wenn 16 P kerne zur Verfügung stehen, aber es nur 8 Threads gibt, dann wird nur jeder zweite P Kern mit Arbeit beauftragt und die 8, die Arbeit haben, können 4MB cache nutzen, also nochmal mehr als 1 P Kern bei Arrow Lake. Andererseits, aber bei vielen Threads, die sich womöglich daten teilen, beide P Kerne aus dem Verbund auf die Daten zugreifen können, was die Latenzen und Effizienz ja verbessern sollte.
Oder sehe ich das falsch?
Genau so ist es. Von daher ist die Aussage von Leonidas auch quatsch, dass der L3-Cache schrumpft, weil man beim Arrow Lake übertrieben hätte. Der effektiv genutzte L3-Cache wird im Durchschnitt durch das zusammenlegen eher steigen, weil der Cache einfach effektiver zwischen zwei Kernen genutzt werden kann.

Generell geht es wohl eher in die Richtung, dass es derzeit noch keine RUs gibt. Womöglich ist der gesharte L2 einfach nur eine Rest dieser Entwicklung. Für RU hätte man das gebraucht, nun ist es geblieben.

gemeinsam genutzter L2-Cache. Wo gab es das schon? Core 2 Duo ;) Ist also ein alter Hut bei Intel, aber schon beim Core 2 Duo sehr effizient.

Ironie der Geschichte?: Auch damals war AMD mit ihren Prozessoren Intel voraus, bevor Core Duo und Core 2 Duo auf den Markt kam.

Da gab es übrigens auch einige, recht spät gefundene Sicherheitslücken, wo dann mit der Anwendung auf einem Kern der Cache des anderen Kerns ausgelesen werden konnte und man so an sensible Daten wie etwa Passwörter/Kreditnummer eingaben, etc. kommen könnte. Das ist insbesondere bei Cloud-Einsatz mit verschiedenen Anwendungen auf den verschiedenen Kernen sehr problematisch. Neu wäre also nur, diese Sicherheitslücken geschlossen zu haben.

[Gast]

Und warum das jetzt so gemacht wird hast du dich nicht gefragt?

Ob jetzt in 2 Jahren oder vor 2 Jahren ist mir eigentlich ziemlich egal. Die Frage die ich mir viel mehr stelle ist, was soll daran so viel mehr bringen als die Techniken die CPUs heute schon einsetzen.

Mich interessiert das wie, nicht das wann.

[Lehdro]

Neu wäre also nur, diese Sicherheitslücken geschlossen zu haben.
In dem Fall ist die Lösung sehr simpel: Die zwei Kerne die sich den L2 teilen, bleiben auch immer zusammen, werden also immer als Duo zugewiesen.