AW: AMD Radeon RX Vega 64 und Vega RX 56 im Test: Heiße Vega?
[...]
Das muss AMD vielleicht auch gar nicht, denn dass sie es können hat man bei Hawai bereits gesehen.
Ein Klasse Allrounder mit DP der auch heute noch super performt.
Und jetzt kommt die Frage: Wieso den Hawai Chip nicht einfach shrinken und bisschen mehr Takt draufgeben? Für was Polaris entwickeln?
Ein 200 Watt Hawai mit 1200mhz und eine Nano Variante mit 150 Watt und 1050 Mhz bei vielleicht ~260mm² hätte AMD´s Polaris alt aussehen lassen und gegen die GTX 1060 locker gewonnen.
Man hätte mit OC Versionen sicherlich auch mal in die Nähe der GTX 1070 kommen können. Aber nein man baut Polaris und nachher Vega, letzterer der durch einen aufgeblasenen Polaris locker zu erreichen gewesen wäre.
[...]
Um Produktionskosten zu sparen, die Effizienz zu erhöhen und schwache Eckstellen auszubessern.
Nur um es mal ins Gedächtnis zu rufen, zum Launch war eine 390 und RX 480 gleich schnell, erstere hat aber 62% mehr Strom konsumiert:
AMD Radeon RX 480 im Test: Schnell und effizient mit 8 GByte fur 260 Euro (Seite 9) - ComputerBase
Eine 390X ist 8% schneller, bei 86% mehr Stromverbrauch. (Falls der Verbrauch unter 1440p gemessen wurde, zieht man ein paar % ab).
Der Graben ist ein wenig zu groß, um durch 14nm alleine kompensiert zu werden und der Chip wäre am Ende ein wenig größer gewesen und AMD und die Boardpartner müssten GDDR5 an einem 512-Bit breiten Interface anschließen.
Was ich nicht verstehe ist die Explosion an Transistorzahlen die angeblich hauptsächlich für den höheren Takt benötigt werden sowie die Änderungen an der Architektur. Ersteres braucht die Konkurrenz scheinbar nicht für den hohen Takt und letzteres füjrt zu keiner höheren Leistung oder Effizienz. Mit einem Fiji @ Vega Takrt wöre man wohl auch auf dem Leistungsniveau - ganz ohne die Architekturänderungen an denen man anscheinend 5 (!) Jahre gearbeitet hat
@ Jim Keller.. und ich hab mal ein Interview gelesen in welchem rauskam, dass Keller eigentlich an AMDs ARM Projekt gearbeitet hat und nicht an der x86 Architektur
Die Konkurrenz ist ja bei einem ähnlichen Transistor/mm² Verhältnis.
Die Änderungen an der Architektur bringen eine höhere Leistung oder Effizienz, soweit wir das isoliert begutachten können.
Die Tessellation-Leistung ist besser und laut dem White-Paper erhöht der DSBR die Performance um bis zu 10% bei gleichem Stromverbrauch (Best-Case vermutlich, aber ganz nutzlos ist er nicht).
Aber wenn man das abzieht, dann wundert man sich natürlich umso mehr wohin die Rohleistung vom Chip verpufft, die Skalierung ist jämmerlich.
Ich bin auf den Q4-Treiber gespannt, da müssen noch mehrere % irgendwo unter der Couch liegen.
----
Bei K12 und Zen gab es ein gemeinsames Core-Team, vermutlich hat ein Großteil der Entwickler an beiden Projekten mitgewirkt.
Das Keller mehr zu K12 beigesteuert hat bzw. dem ARM-Design könnte ja sein, aber mitbekommen habe ich nichts.
Das ist aber nur der Vergleich gegen ihren eigenen Treiber. NV tut sich aber auch heute bereits leichter wenn die Karten weniger VRAM haben und der Treiber an sich scheint das Nachladen besser zu handeln, selbst bei konservativer Speichernutzung. Abgesehen davon nutzt HBCC momentan kein unified Memory-System - AMD reserviert sich schlicht einen Teil des System-RAMs exklusiv für die Nutzung der GPU. Was NV unter CUDA anstrebt ist eine gemeinsame Nutzung des RAMs und der darin vorhandenen Daten von CPU und GPU.
Es ist ein Vergleich zwischen HBCC on/off bei einem 4K Benchmark, wo sicherlich kein VRAM-Überlauf stattfindet, was heißt dass die Verwaltung vom lokalen VRAM schon zu besseren Frametimes führen kann.
Bezüglich Unified Memory werden auch allgemein technische Mechanismen genannt, die über PCIe laufen, wie auch der HBCC vom AMD.