AW: AMD Navi: Fragwürdige Gerüchte um schlechte Taktraten und weitere Probleme
Die einzigen(??) Stellen aus dem Text bzgl. einer verbesserten Architektur:
* HasNoDataDepHazard: "That could be from better interlocking of the pipeline or reduced forwarding latency in some" places.
* HasVscnt: "There may be a differentiation in writes versus reads to memory, and the writes may be linked more closely to the export/system message path."
HasVOP3Literal: " GFX10 has altered the pattern for instruction+immediate so that the 64-bit VOP3 operations can have an immediate"
* "no SRAM ECC, which seems expected for a gaming architecture"
Sieht das für dich nach einem "Rundumschlag" aus?
Die ISA und auch das Arbeitsmodel scheint größtenteils gleich zu bleiben, aber die Änderungen deuten darauf hin, dass AMD an einigen Eckstellen zum ersten mal seit GCN etwas Grundlegendes verändert.
Da würde ich das Augenmerk auf das Register-File, den Register-Destination-Cache und extra Latenzen setzen.
Das Register-File ist groß und verbraucht viel Strom, da gibt es einige Patente und Untersuchen, wie man das effizienter gestalten könnte, weil viele Werte selten mehrfach gelesen werden und man im Schnitt auch selten die vorhandene Bandbreite benötigt.
Ein anderes Design mit einem Register/Operand$ könnte im Schnitt viel effizienter ausfallen, ohne deutlich weniger zu leisten.
Eine andere Stelle die interessant klingt ist Workgroup-Mode/CuMode/Workgroup-ID in Wavefront.
AMD verwendet seit mindestens R600 eine Wavefront-Size von 64 Work-Items, was im Schnitt zu mehr idle-units führt, größeren Kosten bei Divergenz und auch dazu das Geometry-Shader langsam sind.
AMD hat ein Patent was eine variablen Wavefront-Arbeitsmodus beschreibt, wo es zwei Arbeitsmodi gibt, ein klassisches mit 64 Work-Items von einer Arbeitsgruppe, wo eine Instruktion auf alle 64 Work-Items angewendet wird und einen zweiten Arbeitsmodus, wo eine Wavefront aus unterschiedlichen Arbeitsgruppen erstellt werden kann und für eine Portion eine Instruktion für die entsprechenden Work-Items ausgeführt wird und bei der nächsten Portion eine andere Instruktion.
Ich glaube da wurden gar unterschiedliche Implementierungen beschrieben.
Es gibt auch seit längerem Treiber-Patches die in Bezug auf GFX10 Stichwörter wie Wave-Break genannt haben.
Jedenfalls erwecken die Stichwörter auf mich den Eindruck, dass Navi etwas entsprechendes umgesetzt hat.
Bei den älteren Treiber-Patches (Es war glaub PAL (Platform Abstraction Layer)), wurde auch öffentlicht gemacht, dass Navis Delta Color Compression in Zukunft auch bei Unordered Access Views funktionieren wird, dass wird zu etwas höherer Bandbreiteneffizienz führen.
Eine andere Sache die relativ klar ist, dass NGG/Primitive Shader für Geometry Culling und weiteres endlich funktionieren werden, nachdem da aus welchen Gründen auch immer bei Vega nicht geklappt hat.