AW: PCGH Raw & Uncut - Erster Benchmarktest mit Vega Frontier Edition im Video
^^ so so
Du schreibst selbst viel im 3dcenter, und liest alle wichtigen Threads mit.
Die große Mehrheit dort ist selbst der Meinung, dass Vega 10 irgendwie ausgebremst wird, und durch (hoffentlich bald) aktiviertes Draw Stream Binning Rasterizer und HBCC deutlich mehr Leistung bei der RX Vega haben wird.
Wenn du das anders siehst, hättest du dich doch schon längst mit Gipsel und Co. fetzen können (müssen).
Torsten hat meine Frage noch nicht beantwortet. Was ist denn dein Ansatz warum die RV-FE aktuell so extrem schlecht performt?
Ich möchte das etwas genauer auftrennen.
Dein erster Beitrag hat die effektive Verschiebung von Vega thematisiert und das nicht der HBM, sondern die Treiberentwicklung dafür verantwortlich ist.
Daraufhin habe ich gefragt, ob du konkreter werden kannst, denn worauf beziehst du dich beim Treiber, auf den DSBR und/oder HBCC alleine oder einfach alles?
Mir geht es hauptsächlich darum, wie viele Gründe wir uns denn genau bei so einer Spekulation anschauen.
Der Treiber selber ist natürlich gewaltig, selbst nachdem Launch wird AMD sehr wahrscheinlich noch viele Optimierungsstellen für Vega besitzen, aber ob Vega nur deswegen verschoben wurde bzw. nur wegen einzelnen Features?
Aktuell ist es schwer etwas Vernünftiges aus der Frontiers Edition mit ihrem Pro-Treiber heraus zu extrahieren.
Im Gegensatz zu Torsten bzw. der Formulierung gehe ich nicht von bewussten Beschneidungen aus, sondern von unfertiger Arbeit, die man meistens nicht veröffentlicht, außer es läuft meistens stabil im produktiven Einsatz.
Offensichtlich funktioniert der DSBR nicht, dass kann effektiv viel Bandbreite gewinnen, auch die Delta-Color-Compression könnte effektiver funktionieren.
Das neue Pixel-Backend, wo die ROPs ihre Daten im L2$ kohärent halten wird sicherlich auch nicht ohne Treiberoptimierungen perfekt funktionieren.
Ohne ein optimiertes Energiemanagement könnte Vega auch einige % an Leistung und Effizienz verlieren, bei Polaris hat AMD bis zu mehr Mhz dank AVFS angegeben:
The Polaris Architecture |
14
Figure 10:
AMD’s adaptive clocking technology mitigates voltage droop events, which enablesup to 140MHz higher frequency in the Radeon™ RX 400 Series GPUs based on the Polaris architecture.
http://radeon.wpengine.netdna-cdn.com/wp-content/uploads/2016/08/Polaris-Architecture-Whitepaper-Final-08042016.pdf
Das kann jetzt ein best-case darstellen, aber im Paper wird gesagt, dass dank der Alterung der Chips im Laufe der Zeit bis zu 6% mehr Spannung benötigt werden kann und als Designer man das früher als Sicherheitsmarge angelegt hat.
Oder das die Versorgungspannung ungefähr 9-10% höher lag, als die GPU unbedingt benötigt.
Entsprechend kann sich hier ein paar % vorstellen und noch mehr, wenn ACG (Wofür auch immer die Abkürzung steht, Hübie schlag Advanced Clock Gating vor) eine weitere Trickkiste darstellt.
Dann kommt es darauf an, wie viel AMD bei ihren Shadern verändert hat, intern hat Vega zwei Shader-Stages weniger, als die früheren GPUs, hier muss der Treiber für Vega anders funktionieren.
Laut 3dilettante im beyond3D kann Vega bis zu vier mal soviele Load-Operationen durchführen (Abgeleitet von dem Linux Kerneltreiber), dass kann eine ganze Reihe von unterschiedlichen Dingen bedeuten, es ist aber auch etwas, wo man unter Umständen einen besseren Treiber-Compiler dafür schreiben kann:
AMD Vega 10, Vega 11 and Vega 20 Rumors and Discussion | Page 138 | Beyond3D Forum
Das sind viele Spekulationen, ohne einen genauen Zahlenraum zu kennen, möglicherweise funktioniert schon eine Menge ganz anständig unter Vega und die Hardwarefortschritte liegen einfach deutlich unter den Erwartungen.
Das letzte ist ja meine Theorie und ich esse lieber Torte (oder sind die Cookies mit so grüner Butter gemacht?).
[...]
Die Kekse passen sich der gewünschten Realität an, sodass sie immer gut schmecken, denn wer Recht hat, hat es verdient.
