25

Hardware- und Nachrichten-Links des 25. April 2019

Der von Phoronix entdeckte Linux-Treibercode zugunsten von AMDs Navi-Architektur wird von unserem Forum aufmerksam verfolgt und kommentiert. Danach bestätigt sich mittels dieses Treibercodes die GCN-Abstammung von Navi – was ja teilweise in einigen früheren Meldungen in Frage gezogen wurde. Allerdings sind die Änderungen durch Navi dennoch weitreichend – so etwas wie ein letztes, lautes "Halali" der GCN-Architektur also. Grob gesehen kann man von Navi somit weiterhin maximal 64 Shader-Cluster (gemäß einer Limitierung der GCN-Architektur) mit allerdings effizienterer Ausnutzung dieser Rechenkraft sowie die Freischaltung der bei der Vega-Architektur nicht funktionierenden Features erwarten, somit durchaus auch als "Vega done right" zu betrachten. Sofern AMD das alles nur einmal richtig gebacken bekommt, sind durchaus erhebliche IPC-Sprünge (auf gleicher Anzahl an Shader-Einheiten sowie gleichem Takt) möglich, insofern müssen es also noch nicht einmal mehr Shader-Einheiten werden. Da weiterhin das Limit von 64 Shader-Clustern pro Grafikchip gilt, kommt AMD auch weiterhin nicht über 4096 Shader-Einheiten hinaus – welche man wie bekannt schon mit dem seinerzeitigen Fiji-Chip der Radeon R9 Nano/Fury Serie anno 2015 geboten hatte.

AMD Navi Architektur

  • weiterhin GCN-basierend
  • weiterhin maximal 64 Shader-Cluster pro Grafikchip
  • höhere Recheneffizienz gegenüber Vega
  • Aktivierung der bei Vega nicht funktionierenden Features (siehe Meldungen No.1, No.2, No.3 & No.4)
  • wahrscheinlich durchgehend RayTracing in Hardware
  • hergestellt in der 7nm-Fertigung von TSMC
  • (passabel) sichere Navi-Grafikchips: Navi 10 (Midrange) & Navi 20 (HighEnd & Profi)
  • vakante Navi-Grafikchips: Navi 12 (Mainstream) & Navi 14 (LowCost)
  • daneben benutzt für die Playstation 5

Die einzige Ausweichmöglichkeit wäre die Aufstockung der Shader-Cluster von 64 auf 128 Shader-Einheiten – was allerdings mit Auslastungsproblemen einhergeht, normalerweise sind kleinere Shader-Cluster diesbezüglich besser als große (nVidia ist selber erst kürzlich mit der Turing-Generation von 128 auf 64 Shader-Einheiten pro Shader-Cluster gewechselt). Da der ganze Navi-Ansatz nun nicht unbedingt danach aussieht, als wolle man bei den absoluten Spitzen-Lösungen mit nVidia konkurrieren, sind 128 Shader-Einheiten pro Shader-Cluster keine besonders wahrscheinliche Auflösung: Denn (bis zu) 8192 Shader-Einheiten braucht AMD für die gewählte Zielsetzung von Midrange- und HighEnd-Beschleunigern nicht, jene läßt sich durchaus auch mit maximal 4096 Shader-Einheiten erfüllen, sofern jene ihre Arbeit einfach nur effizient verrichten. Auch hier hilft wieder der Blick zu Turing: Im vermuteten Konkurrenzfeld der 2019er Navi-Spitzenlösung tritt nVidia bei GeForce RTX 2070 & 2080 mit 2304 bzw. 2944 Shader-Einheiten an. Da muß AMD mit bis zu 4096 Shader-Einheiten einfach nur effizient genug mit der zur Verfügung stehenden Rechenleistung umgehen, um eine ähnliche Performance zu erreichen. Damit dürfte die Navi-Generation dieses alte Limit der GCN-Architektur letztlich nicht sprengen, sondern dies der nachfolgenden AMD-Grafikgeneration (möglicherweise "Arcturus") überlassen.

Nach der neuen Intel-Roadmap mit der Offenbarung von anhaltenden 10nm-Schwierigkeiten bei Intel läuft derzeit (logischerweise) eine größere Diskussion darüber, wie es Intel so weit kommen lassen hat, das man die 14nm-Fertigung (für Desktop-Prozessoren) nunmehr von 2015 bis 2021 benutzen wird – nachdem alle Intel-Fertigungsverfahren in jeweils 2-3 Jahre abgehandelt wurden. Ein Posting in unserem Forum faßt gut zusammen, welche Fehler Intel sich in den letzten Jahren geleistet hat – beachtbar sind dabei insbesondere die Milliarden-Beträge, welche in diversen Nebensparten (ohne Erfolg) verballert wurden. Andererseits muß auch angemerkt werden, das insbesondere im Mißerfolgs-Fall solcherart Fehlschläge besonders unter die Lupe genommen werden – im Erfolgsfalls existieren jene aber trotzdem, werden nur nicht so groß betrachtet. Da Intel bis zuletzt auch großartig verdient hat, kann es am Punkt der gescheiterten Nebenprojekte und deren Milliarden-Verlusten nicht wirklich gelegen haben. Insofern ist die Frage nach dem "Warum" nicht so einfach zu beantworten – und womöglich kommen hierbei auch irrational erscheinende Gründe hinzu, wie das "Nicht-wahrhaben-wollen" von Problemen und Schwierigkeiten, je höher man in der Leitungsebene nach oben geht. Denn normalerweise wäre genug Zeit gewesen, um umzusteuern – und nicht immer wieder nur kurzfristige Lösungen aufzubieten, die einem dann irgendwann auch einmal ausgehen (wie derzeit, wenn "Rocket Lake" nichts besseres bringt als "Comet Lake").

Intel hatte ja teilweise schon 14nm-Werke auf die 10nm-Fertigung umgerüstet (der Hauptgrund für die 14nm-Lieferschwäche der vergangenen Monate) – und dies zu einem Zeitpunkt, wo man die Problematik mit dem 10nm-Prozess bei realistischer Sichtweise hätte erkennen können. Sehr gut denkbar also, das primär Schwächen in der Firmenkultur bezüglich der korrekten Weiterleitung von Problemen zur Leitungsebene sowie Entscheidungsunfähigkeit in dieser Leitungsebene zu diesen Problemen bei Intel geführt haben. Auch wenn ähnliches bei mehr oder weniger jedem Großkonzern existiert, muß Intel unbedingt an diesen Schwächen in der Firmenkultur arbeiten. Vielleicht erinnert man sich auch zurück an die Zeit, wo man das letzte Mal von AMD so richtig unter Druck gesetzt wurde: Mittels der K7-Prozessoren ab dem Jahr 1999 und den nachfolgenden K8-Prozessoren mit erstmals 64-Bit hatte AMD anfangs der Nullerjahre einen dicken Fuß im Geschäft. Da damals für Intel schon absehbar war, das man jenen Kampf mit Weiterentwicklungen der seinerzeitigen Pentium-4-Prozessoren nicht gewinnen würde, stellte man die eigene Roadmap großflächig zugunsten der Core-Prozessoren um, wo aus dem früheren Pentium-III-Derivat Pentium M zuerst der Core 1 und dann der Core 2 entwickelt wurden. Die aktuelle Intel-Situation sieht dagegen übertragenerweise eher so aus, als hätte man den Pentium 4 entgegen aller Warnanzeigen immer weitergetrieben.

Derzeit noch unbekannt sind die Auswirkungen dieser 10nm-Problematik zum einen auf die Server-Prozessoren von Intel sowie zum anderen auf Intels Grafikprojekte. Eventuell hat man ja mit GPUs unter der 10nm-Fertigung mehr Glück, vielleicht sind dort die technischen Bedingungen auch ausreichend anders – das in den Dell-Roadmaps wenigstens an einer Stelle eine 10nm-Grafiklösung erwähnt wurde, deutet wenigstens darauf hin. Im entgegengesetzten Fall könnten nun auch noch Intels Grafikprojekte terminlich in Gefahr sein – und bei Grafik ist eine aktuelle Fertigungstechnologie eine Hauptbedingung, gerade wenn man als Einsteiger die beiden Platzhirsche herausfordern will. Interessanterweise wurde Intels Raja Koduri kürzlich beim Besuch von Samsungs Chipfertigung gesichtet – gut möglich, das man sich für die eigenen Grafikchips also noch mittels eines Auftragsfertigers absichert. Für die eigenen Server-Prozessoren wird dies kaum möglich sein, hier wird man einfach sehen müssen, ob Intel die geplanten 10nm-Generationen Ice Lake SP/X sowie Tiger Lake SP/X vielleicht doch noch unter der 14nm-Fertigung herausbringt. So oder so drohen Intel im Server-Geschäft die größten Verwerfungen, denn ohne 10nm-Fertigung wird man nicht mehr CPU-Kerne sowie höhere Taktraten realisieren können – und dies in einem Feld, wo AMD schon jetzt mehr CPU-Kerne und gleichwertige Taktraten anbietet. Der Server-Markt bewegt sich zwar normalerweise sehr langsam, aber ein paar Jahre ohne echte Fortschritte bei Intel dürften doch für einige Umwälzungen in diesem sorgen.

Der von Phoronix entdeckte Linux-Treibercode zugunsten von AMDs Navi-Architektur wird von unserem Forum aufmerksam verfolgt und kommentiert. Danach bestätigt sich mittels dieses Treibercodes die GCN-Abstammung von Navi - was ja teilweise in einigen früheren Meldungen in Frage gezogen wurde. Allerdings sind die Änderungen durch Navi dennoch weitreichend - so etwas wie ein letztes, lautes "Halali" der GCN-Architektur also. Grob gesehen kann man von Navi somit weiterhin maximal 64 Shader-Cluster (gemäß einer Limitierung der GCN-Architektur) mit allerdings effizienterer Ausnutzung dieser Rechenkraft sowie die Freischaltung der bei der Vega-Architektur nicht funktionierenden Features erwarten, somit durchaus auch als "Vega done right" zu betrachten. Sofern AMD das alles nur einmal richtig gebacken bekommt, sind durchaus erhebliche IPC-Sprünge (auf gleicher Anzahl an Shader-Einheiten sowie gleichem Takt) möglich, insofern müssen es also noch nicht einmal mehr Shader-Einheiten werden. Da weiterhin das Limit von 64 Shader-Clustern pro Grafikchip gilt, kommt AMD auch weiterhin nicht über 4096 Shader-Einheiten hinaus - welche man wie bekannt schon mit dem seinerzeitigen Fiji-Chip der Radeon R9 Nano/Fury Serie anno 2015 geboten hatte.




AMD Navi Architektur

weiterhin GCN-basierend
weiterhin maximal 64 Shader-Cluster pro Grafikchip
höhere Recheneffizienz gegenüber Vega
Aktivierung der bei Vega nicht funktionierenden Features (siehe Meldungen No.1, No.2, No.3 & No.4)
wahrscheinlich durchgehend RayTracing in Hardware
hergestellt in der 7nm-Fertigung von TSMC
(passabel) sichere Navi-Grafikchips: Navi 10 (Midrange) & Navi 20 (HighEnd & Profi)
vakante Navi-Grafikchips: Navi 12 (Mainstream) & Navi 14 (LowCost)
daneben benutzt für die Playstation 5