26

Hardware- und Nachrichten-Links des 26. Juli 2021

Intel hat mit seinem "Intel Accelerated" Event eine gravierende Veränderung der Benennung der Intel-Fertigungsverfahren angekündigt. Wie bekannt, sind jene seit einiger Zeit nicht deckungsgleich zu technologisch ähnlich leistungsfähigen Fertigungsverfahren von Samsung und TSMC, beispielsweise entspricht Intels 10nm grob TSMCs 7nm. Vermutlich auch wegen Intels neuer Foundry-Strategie (bei welcher man als Auftragsfertiger für andere Chipentwickler mitmischen will), aber auch aus reinen Marketing-Gründen benennt Intel seine Fertigungsnodes nunmehr um, damit sich jene eher gleichartig zu den Angaben von Samsung & TSMC anhören. Die neuen Intel-Nodes lauten damit auf "Intel 7", "Intel 4", "Intel 3", "Intel 20A" sowie (am Horizont) "Intel 18A". Intel vermeidet dabei die Benennung als "nm", da man dies vorher so benannt hatte. In der Praxis dürfte sich vermutlich trotzdem durchsetzen, das Kind als "Intel 7nm" zu titulieren – weil wirklich viele Chipteile mit 7nm Größe findet man auch in den entsprechenden Fertigungen von Samsung & TSMC nicht.

Damit geht natürlich ein gewisser Bruch gegenüber dem bisherigen Node-Schema bei Intel einher: So wird die aktuelle 10nm-Fertigung von Tiger Lake weiterhin als "10nm SuperFin" geführt, das nur wenig veränderte nachfolgende "10nm Enhanced SuperFin" für Alder Lake, Raptor Lake & Sapphire Rapids hingegen zukünftig als "Intel 7". Ein so großer technologischer Sprung, wie diese Titel-Wahl verheißt, liegt allerdings keineswegs vor – technologisch korrekt wäre es gewesen, die gesamte 10nm-Fertigung in "Intel 7" umzubenennen. Aber dies läßt sich nachträglich natürlich nicht mehr machen, mit dieser Unsauberkeit muß man leben. Perspektivisch ist Intels Schritt – wenngleich sich die Benennung hiermit immer weiter von den realen physikalischen Gegebenheiten entfernt – sogar eher gutzuheißen, weil somit eine (weitgehende) namenstechnische Waffengleichheit zu Samsung & TSMC hergestellt wird. Weiterführende Hintergründe zu den Intel-Produkten unter allen kommenden Fertigungsverfahren sowie zur Vergleichbarkeit mit Samsung & TSMC liefert ein Artikel bei AnandTech.

VideoCardz weisen zudem darauf hin, dass Intel mit dem Event-Material auch eine neue Aussage zur im Jahr 2023 unter dem Fertigungsverfahren "Intel 4" anstehenden "Meteor Lake" Prozessoren-Generation getroffen hat. So wird erstens die Wattage dieser als 14. Core-Generation zu erwartenden Consumer-Prozessoren mit 5-125 Watt angegeben – was in der Spitze dem entspricht, was Intel bislang im Consumer-Bereich ansetzt. Dieser Punkt könnte allerdings auch noch Änderungen unterworfen sein, denn die TDP-Festsetzung liegt im Bereich der Produktgestaltung und nicht im Bereich der zugrundeliegenden Hardware. Zweitens wird hiermit der künftige Aufbau von Intel-Prozessoren klarer, wo CPU, SoC und iGPU als extra Chiplets gefertigt und dann mittels der "Foveros"-Technologie verbunden werden.

Und drittens verfügt Meteor Lake über eine iGPU mit bis zu 192 EU – sprich der doppelten Anzahl von Alder Lake. Auf AMD/nVidia-Verhältnisse umgerechnet sind dies immerhin schon 1536 FP32-Einheiten – sprich die Leistungsklasse der Radeon RX 5500 Serie. Möglicherweise gibt es die dickste Meteor-Lake-iGPU aber wieder nur im Mobile-Segment, wo dann Stromverbrauchs-Limit und natürlich auch der Effekt des gesharten Speicherinterfaces Performance-mindernd wirken. Nichtsdestotrotz geht Intel hiermit deutlich voran bei der iGPU-Performance – womit sich AMD dann auch mal wieder bewegen muß, nachdem die letzten AMD-iGPUs immer nur kleinere bis maximal mittlere Performance-Fortschritte gebracht hatten. Selbst AMDs nächste iGPU bei der Rembrandt-APU ist mit 12 Shader-Clustern nach RDNA2 (ergibt 768 FP32-Einheiten) deutlich kleiner angesetzt – ist allerdings auch ein Produkt des Jahresanfangs 2022 und nicht des Jahresendes 2023, wie bei Meteor Lake.

Bei Igor's Lab hat man sich nochmals mit dem Problem der Grafikkarten-Ausfälle unter "New World" beschäftigt. Dabei konnte man herausarbeiten, dass in der Lüftersteuerung der hauptsächlich betroffenen EVGA-Karten wohl ein gravierender Fehler enthalten ist – welcher auch außerhalb von Amazons "New World" feststellbar ist und sich in einem wild laufenden Lüfter und teilweise daraus resultierenden Abstürzen äußert. Allerdings wurde auch nicht gänzlich geklärt, wieso die nVidia-eigenen Schutzschaltungen (wenigstens zum Schutz vor Karten-Zerstörung) versagen können – zudem ist das ganze keine Auflösung für eventuell andere zerstörte Grafikkarten außerhalb von EVGAs 3090er Modellen. Hierzu werden AMD, EVGA & nVidia in ihren Laboren nachforschen und eine Antwort finden müssen.

'Bondrewd' hat im Beyond3D-Forum die Sache des Hardware-Aufbaus von Navi 31 noch einmal klar gemacht mittels der kurzen Statusmeldung "32 * 8 * 10 * 3 * 2". Dies ist zu lesen als "SIMD-Breite x Anzahl SIMD x WGP x Shader-Engines x GCD" (bestätigt durch Bondrewd), wobei es umgedreht vielleicht einfacher verständlich ist: Zwei Einzelchips mit jeweils 3 Shader-Engines, jeweils 10 WGPs, jeweils 8 SIMD auf SIMD-Breite 32. Alles hübsch miteinander multipliziert ergibt dies zum einen 15360 SIMD- aka FP32-Einheiten, verteilt auf zwei GCDs á 7680 SIMD/FP32-Einheiten. Der Einzelchip bietet dann jeweils 3 Shader-Engines und 30 WGP auf, für den gesamten Navi 31 Chip sind es 6 Shader-Engines und 60 WGP.

it's 32 * 8 * 10 * 3 * 2
Quelle:  Bondrewd @ Beyond3D-Forum am 26. Juli 2021

Navi 21 Navi 31 GCD Navi 31 komplett
4 Shader-Engine (SE)
40 Workgroup Processor (WGP)
80 Compute Unit (CU)
64 FP32 per CU (128 FP32 per WGP)
5'120 FP32-Einheiten
3 Shader-Engine (SE)
30 Workgroup Processor (WGP)
256 FP32 per WGP
7'680 FP32-Einheiten
2 GCD
6 Shader-Engine (SE)
60 Workgroup Processor (WGP)
256 FP32 per WGP
15'360 FP32-Einheiten
Anmerkung: reine Wiedergabe von Gerüchten – keine offiziellen Daten

Damit erübrigen sich dann auch alle Überlegungen in andere Richtungen hin (größere Anzahl an Einzelchips, abweichende Anzahl an WGPs), denn aufgrund der vorliegenden Details führt somit nunmehr nur noch eine einzige Logik zum Ziel. Die bis vor kurzem breit angenommenen 80 Shader-Cluster (CU) als Grundlage eines GCDs von Navi 31 sind damit nicht korrekt. In dieser Frage hat man sich möglicherweise zu sehr von den Einträgen in einem früheren MacOS-Treiber beeinflussen lassen, welche sich nunmehr als schlichte Platzhalter-Daten ohne Bedeutung herausstellen. Olrak29 @ Twitter hat jenen Hardware-Ansatz von Navi 31 letztlich auch noch in ein (eigenerstelltes) Blockdiagramm gegossen: