Die PC Games Hardware hat sich eingehend mit der RayTracing-Performance unter Diablo IV beschäftigt, für welche sich vor allem eine Klassifizierung anbietet – extrem Hardware-fressend. Aus dem bisherigen High-fps-Titel wird unter Hinzunahme von RayTracing eine enge Angelegenheit, selbst die GeForce RTX 4090 erreicht bei bestem RayTracing unter der 4K-Auflösung (knapp) keine 60 fps mehr. Upscaler sind hierzu natürlich die Lösung, jene verschieben den Frameraten-Verlust in einen gangbaren Bereich – was aber bislang unter Diablo IV abseits von LowCost-Hardware nie wirklich notwendig war. Aber auch mit Upscalern ergeben sich zumeist noch größere Frameraten-Rückschritte, RayTracing samt Upscaler kostet unter Diablo IV grob die Hälfte der originalen Framerate.

Mit Upscaler ist der Frameraten-Verlust bei der GeForce RTX 4090 deutlich geringer, während Intels Grafikkarten mit RayTracing unter Diablo IV gar nicht zurechtkommen wollen, egal mit oder ohne Upscaler. Dabei sind der wirklich leistungsfressende Teil weniger die RT-Reflektionen, sondern ganz klar die RT-Schatten. Dummerweise stellen jene auch den größeren Teil des Gewinns an Bildqualität dar. Selbige soll durch RayTracing durchaus hinzugewinnen, wirklich effektiv ist dies angesichts der hohen Frameraten-Verluste allerdings nicht. Sinnvoll ist das ganze wohl nur in solchen Fällen, wo sowieso zu viel Framerate vorhanden ist. Beachtbar ist daneben der enorme wie ungewöhnliche Einfluß von RayTracing auf die Prozessoren-Performance: Hier geht es mit RayTracing gleich einmal um 60-70% nach unten. Allerdings bleiben die absoluten Frameraten zumindest mit modernen Prozessoren weiterhin in einem spielbaren Bereich, ausgehend von extrem hohen Frameraten unter Rasterizer-Grafik.

Twitter Kepler_L2 weist auf die Namensnennung "Nv48" in AMDs ROCm Validierungs-Suite auf, somit also die erste semi-offizielle Nennung von "Navi 48". Dies bestätigt zugleich diesen Grafikchip-Codenamen bzw. den Wechsel der ursprünglichen AMD-Planung, welche offenbar Navi 41 & 42 an der Leistungsspitze sah. Jene Chips im augenscheinlichen MultiChip-Ansatz wurden jedoch gestrichen, aus der ursprünglichen Planung nur "Navi 44" behalten und als neue Konstruktion dann "Navi 48" aus der Taufe gehoben. Hieran ergibt sich auch die ungewöhnliche Nummern-Abfolge, nach welcher Navi 48 der (klar) größere Chip als Navi 44 ist. Auch wenn sich die Gerüchteküche nicht zu selten irrt, wurde in diesem Fall jener Codename schon letzten Herbst korrekt vorhergesagt.

Twitterer Everest gibt in einem der allgemein beliebten kryptischen Tweets höchstwahrscheinlich die Kern-Konfigurationen von AMDs Strix Point wieder. Die Zuordnung von 4 Performance-Kernen mit 8 Effizienz/Dense-Kernen passt augenscheinlich zu "Strix Point", andere bekannte Prozessoren-Projekte haben eine andere maximale Kern-Anzahl/Konfiguration. Trifft dies zu, dann würde AMD somit aus der Strix-Point-APU drei im Verkauf verwendete Kern-Konfigurationen ableiten: Wahrscheinlich als "Ryzen 7" laufend den Vollausbau, wahrscheinlich als "Ryzen 5" laufend eine abgespeckte Variante mit 4 Performance- und 4 Dense-Kerne – und wahrscheinlich als "Ryzen 3" laufend eine total abgespeckte Variante ohne jede Performance-Kerne und mit nur noch 4 Dense-Kernen.

4 + 8
4 + 4
0 + 4
Quelle:  Everest @ Twitter am 5. April 2024

Letzteres ist derart heftig abgespeckt, dass man jene Prozessoren eigentlich besser separat (mit dann kleinerer Chipfläche) herstellen sollte. Allerdings ist dies immer auch eine Frage der abgesetzten Stückzahlen. Intel kann sich so etwas mit seinen Abermillionen-Stückzahlen an OEM-Aufträgen leisten, AMD muß hingegen eher aufpassen, dass man sein Portfolio effizient in Bezug auf die Anzahl der insgesamt aufgelegten Chips hinbekommt – weil bei kleineren Stückzahlen die Entwicklungs-, Tape-Out- und Validierungskosten bedeutsamer werden, nicht nur die reinen Fertigungskosten eine Rolle spielen. Zudem könnte man einen extra Chip mit (physikalisch) geringerer Kern-Anzahl immer noch nachschieben, so wie bei Phoenix1 und Phoenix2 passiert. Andere Auflösungen jenes kleinen "Rätsels" sind natürlich genauso nicht auszuschließen.

Aufreger des Tages war sicherlich der Fall "Moore's Law Is Dead", welcher mit seinem jüngsten Video auf einen vorgeblichen Leak zu AMDs Zen 5 hereingefallen ist. Vornehmlich geht es dabei um eine im ursprünglichen Video abgebildete AMD-Folie mit einem Blockschalt-Bild zu Zen 5 – welche jedoch fabriziert und als anonyme Quelle MLID zugestellt wurde (inzwischen aus dem MLID-Video entfernt). Allerdings muß an dieser Stelle auch gesagt werden, dass jenes Blockschalt-Bild keine unwahrscheinlichen Sachen verspricht und sich grundsätzlich an das hält, was GCC-Patches im Februar bereits offengelegt hatten (6 ALUs, 4 AGUs, 512-bit FPU). Sofern jene GCC-Patches zutreffend sind, könnte das reale Blockschalt-Bild zu Zen 5 jenem fabrizierten sogar recht ähnlich sehen. Somit kann man auch sagen: Auf dieses (fabrizierte) Blockschalt-Bild hereinzufallen, könnte wohl jedem passieren.

Eher interessant sind somit die weiteren Ausführungen, nach welcher MLID die textlichen Aussagen des vorgeblichen Leakers im Video-Bericht in zwei unterschiedliche "Quellen" (mit zudem unterschiedlicher Glaubwürdigkeit) aufgesplittet hat. Trifft dies zu, hätte MLID somit vorgegeben, die Video-Aussagen über unterschiedliche Quellen abgesichert zu haben, obwohl nur eine Quelle vorlag (betrifft die Blöcke "Source 1" und "Source 2"). Natürlich läßt sich nicht 100%ig sicher sagen, inwiefern MLID nicht eventuell doch weitere Quellen hinzugezogen hat, aber für den Augenblick sieht dies sehr wohl nach einer eigen-fabrizierten Glaubwürdigkeit innerhalb des MLID-Videos aus. Und dies würde letztlich bedeuten, dass man den MLID-Videos in dieser Frage generell nicht mehr trauen kann.

Vor finalen Statements in dieser Angelegenheit wäre allerdings zu warnen. Dass MLID auf einen gefälschten, aber inhaltlich glaubwürdigen "Leak" hereinfallen, ist medial lustig, aber eigentlich das geringere Übel. Dass MLID ihre Videos "aufwerten" über das Erfinden von gar nicht vorhandenen Zweit- und Dritt-Quellen, fällt unter "Verdacht mit vorhandenem Indiz", ist hiermit jedoch keineswegs zweifelsfrei belegt. Und da sich das ganze wohl kaum jemals zweifelsfrei belegen läßt, sollte man aus dieser Geschichte eher den generellen Hinweis mitnehmen, dass Webseiten & YouTuber, welche primär von Leaks leben, per se anfällig auf unsaubere Arbeitsmethoden sind – von der Aufhübschung von Quellenangaben über das Ausschmücken von Details bis hin vielleicht sogar zum puren Erfinden von Leaks. Letzteres ist hoffentlich die (seltene) Ausnahme von der Regel, da grundsätzlich falsche Leaks letztlich immer später nachprüfbar sind.