PCGamer haben im Gespräch mit AMD genauere Informationen zu den Taktraten der Radeon VII erhalten, welche bislang nur ungenau auf ~1800/1000 MHz angegeben wurden. Nach AMD-Aussage soll der Basetakt der kommenden HighEnd-Grafikkarte bei 1450 MHz liegen, der durchschnittliche Boosttakt dann bei 1750 MHz – was etwas unterhalb der vorab genannten 1800 MHz liegt, welche nunmehr eher nur einen Peak-Wert darstellen sollen. Zudem wird sich die Karten-TDP auf exakt 300 Watt belaufen – was in unmittelbarer Nähe zur Radeon RX Vega 64 (295W) rangiert, so wie es angekündigt wurde. Mit den genannten Taktraten ist man zwischen +13-16% höher unterwegs als auf der Radeon RX Vega 64, hat allerdings auch -6% weniger Shader-Cluster zur Verfügung, so das es rein nominell somit gerade einmal noch zu +6,1% mehr theoretischer Rechenleistung reicht. So gesehen sind die praktisch erreichten +28,5% Performancegewinn gegenüber der Radeon RX Vega 64 schon richtig gut – was aber auch bedeutet, das viel mehr nicht zu erwarten ist, zu einer höheren Performance fehlt dann schlicht ein größeres Plus an Rechenleistung.

Normalerweise würde man AMD natürlich an dieser Stelle empfehlen, noch eine weitere Gamer-Grafikkarte auf Vega-20-Basis aufzulegen – dann mit den vollen 64 Shader-Clustern und taktmäßig derart hochgeprügelt, das dann die GeForce RTX 2080 auch wirklich erreicht wird. Gut möglich allerdings, das die Radeon VII beim Chiptakt bereits derart ausgereizt ist, so das sich diese Idee kaum noch realisieren läßt. Hier werden die kommenden Übertaktungstests zur Radeon VII einen Hinweis darauf geben, ob da noch weiteres Taktraten-Potential im Vega-20-Chip schlummert – was ja auch wichtig ist für werksübertaktete Kartenversionen, welche sich nicht bei einer +20 MHz "Spaß"-Übertaktung aufhalten wollen. Viel eher denkbar wäre im übrigen, das sich später hergestellte Vega-20-Chips automatisch besser takten lassen, weil dann mit der Zeit die 7nm-Fertigung von TSMC für große PC-Chips einfach solider werden dürfte als jetzt, wo Vega 20 ganz eindeutig den 7nm-Vorkämpfer gibt. Zu einem deutlich späteren Zeitpunkt dürfte AMD diesen Taktraten-Gewinn dann allerdings kaum noch in neue Produkte überführen wollen, da ab Sommer/Herbst dann die Navi-Generation ansteht und selbige die Vega-Generation in allen Punkten ersetzen können sollte.

Aus unserem Forum kommt ein schöner Vergleich zur erreichten Packdichte verschiedener Halbleiterprodukte – welcher klar darauf hinweist, das die 7nm-Fertigung bei AMDs Vega-20-Chip der Radeon VII vollkommen unterdurchschnittliche Ergebnisse abliefert. So konnte Apple zwischen seinen SoCs A10 (16nm) und A12 (7nm) die Packdichte auf über das Dreifache steigern – während AMDs Sprung zwischen den Grafikchips Vega 10 (14nm) und Vega 20 (7nm) nur bei (vergleichsweise) mageren +60% liegt. Vermutlich ist dieser Wert aber nicht maßgeblich für die Möglichkeiten der 7nm-Fertigung – Vega 20 ist diesbezüglich wohl eher die Ausnahme von der Regel, da hierbei eine auf die 14nm-Fertigung konzipierte Architektur einfach nur auf die 7nm-Fertigung geshrinkt wurde. Dies ergibt heutzutage augenscheinlich nur noch unterdurchschnittliche Ergebnisse – ohne eine echte Architektur-Arbeit zugunsten der kleineren Fertigung geht es wohl nicht mehr. Selbiges dürften dann die weiteren antretenden PC-Chips in der 7nm-Fertigung durchaus aufbieten – und somit bessere Packdichten-Ergebnisse erreichen können als der Vega-20-Chip.

Die PC Games Hardware bringt eine interessante Argumentation entgegen dem Linux-Support von PC-Spielen, welche aus dem Mund eines Spieleentwicklers auch einigermaßen gewichtig klingt. So wurde seinerzeit "Planetary Annihilation" für Windows, MacOS und Linux aufgelegt, nachdem in der Kickstarter-Phase die Linux-Community lautstark für diesen Support geworben hatte. Nach der Realisierung des Spiels standen allerdings Linux-Verkäufen von anteilig nur 0,1% eine Menge an gemeldeten Bugs der Linux-Version von 20% (samt entsprechender Arbeitszeit zum Fixen dieser) gegenüber. Die Linux-Version aufzulegen, war also für den Spieleentwickler maßgeblich ineffektiv – nicht bezüglich des extra Aufwands bei der Spielentwicklung, sondern wegen des enorm größeren Support-Aufwandes. Jener resultiert natürlich primär daraus, das die Bedingungen unter Linux bei weitem nicht so einfach sind wie unter Windows: Unter Linux existiert eine extreme Fragmentierung auf verschiedene Linux-Distributionen, hinzu ist die Güte der Grafikkarten-Treiber augenscheinlich bei weitem noch nicht so hoch wie unter Windows – typische Probleme einer vergleichsweise kleinen Community also.

So etwas könnte sich von alleine legen, sofern Linux auf größere Nutzeranteile bzw. vor allem auf mehr Spieler unter Linux kommen würde. Dann sollten sich die wichtigsten für Gamer geeigneten Distributionen besser herauskristallisieren, zudem würden die Grafikchip-Entwickler wohl auch mehr Arbeitszeit in ihre Linux-Treiber investieren (können). Doch der Weg dahin bedingt womöglich einen Zwischenschritt, welcher bei den Spieleentwickler nicht zu einer derart ineffizienten Arbeitsweise führt. Denkbar wäre hierzu vielleicht die Idee, anstatt einen offiziellen Linux-Support anzubieten (was wie zu sehen in hohem Supportaufwand resultiert), seine Spiele einfach nur "Linux-tauglich" zu gestalten. Viele Linux-Titel sind schließlich über Wine oder Proton letztlich auf Linux lauffähig, den Aufwand hierfür übernimmt dann aber die Community bzw. an Linux direkt interessierte Dritte (wie Valve) – und es ist damit auch kein Supportaufwand für Linux-Nutzer seitens des Spieleentwicklers vonnöten. Was hierfür konkret vonnöten ist, können die Spieleentwickler sicherlich selber besser (anhand der vorliegenden Beispiele) erkennen – in jedem Fall wäre dies ein Mittelweg, wie man ohne größere eigene Anstregungen Linux-Gaming seitens der Spieleentwickler letztlich doch fördern kann.