Nvidia Kepler

[Gipsel]

Dies hier ist der Technologie-Thread über nvidias Kepler. Im Speku-Forum gibt es einen Thread für die anderen Aspekte (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=492112).

Mal eine Sache, die ich schon im GCN-Thread (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8796923#post8796923) gepostet habe, ist vielleicht ein Fingerzeig, wie nvidia das Problem des Stromverbrauchs etwas lindern will (wahrscheinlich eher Maxwell als Kepler). Es gibt ein Paper von nvidia (http://cva.stanford.edu/publications/2011/gebhart-isca-2011.pdf), wie man mit einer Art kleinem Cache für die Registerfiles den Zugriff lokaler gestalten (was ich als Vorteil von GCN gegenüber AMDs alter VLIW-Architektur und auch Fermi sehe) und ihn dadurch beschleunigen bzw. den Stromverbrauch senken kann. Da sind ganz interessante Informationen enthalten, z.B. daß die Berechnung eines FMA weniger Energie kostet als das Lesen der Operanden aus dem Registerfile.
Our own estimates show that the access and wire energy required to read an instruction's operands is twice that of actually performing a fused multiply-add.
Dies zeigt, daß das ein durchaus wichtiges Thema ist.

Ganz interessant ist auch, daß nvidia dort (ebenfalls zum Stromsparen) ein anderes Scheduling (zweistufig) vorschlägt. Beides zusammen bringt übrigens nur Vorteile, solange die Instruktionslatenz nicht zu hoch ist. In dem Paper wird mit einer Latenz von 8 Takten (inklusive Lesen und Schreiben des RF wahrscheinlich 12 Takte, die Fermi-Pipeline hat 18 Takte Latenz) gerechnet. Ein Hinweis für die Zukunft bei nv? Ich finde das ganz interessant im Vergleich zu den Änderungen bei GCN.

[Skysnake]

Das ist auch recht klar mit dem FMA. Du leitest das Ergebnis ja einfach nur weiter durch, was halt normal weniger Strecke beudetet + keinen Wert speichern etc. Musst halt nur das Signal treiben das wars.

Geht wohl alles auch in die Richtung, den SIMD Einheiten der GPU einen "Coprozesoor" zur Seite zu stellen, der die Aufgaben der CPU übernimmt, und so die GPU halt flexibler und unabhängiger wird, da vieles direkt auf ihr komplett abläuft.

Zumindest ist mir dies zu Ohren gekommen.

[Gipsel]

Das ist auch recht klar mit dem FMA. Du leitest das Ergebnis ja einfach nur weiter durch, was halt normal weniger Strecke beudetet + keinen Wert speichern etc. Musst halt nur das Signal treiben das wars.Na, das FMA muß man schon noch ausrechnen. Da werden schon ein wenig mehr als nur eine Handvoll Transistoren für schalten müssen, was natürlich auch Energie kostet. Das erstmal Überraschende ist doch, daß das nur etwa die Hälfte der Energie kostet, die man für das bloße Lesen der Ausgangswerte aus den Registerfiles benötigt (und die sind ja nicht gerade am anderen Ende des Chips).

[Skysnake]

Wieso? Die Alternative wäre halt ein MAD. Da muss man halt wieder aus dem Register lesen, bzw es muss halt durch mehr Stufen durch, da halt gerundet wird etc.

Mich wundert es jetzt nicht sooo arg, dass ein FMA Energieeffizienter ist. Genau wie halt bei Sachen, bei denen man innerhalb der Register/Caches bleiben kann. Man muss halt das Signal nicht (plakativ) übern halben Chip treiben.

Allein die drecks Clock aufm gesamten Chip zu halten macht ja rund 10-40% des Energiebedarfs aus, wenn ich mich recht erinnere. (glaub waren eher 40-50% bin mir da jetzt allerdings auch im Moment nicht mehr 100% sicher, daher die 10-40%. Ist auf jeden Fall ein relevanter Anteil)

[hell_bird]

Cache für ein Registerfile? Verrückte Welt. Wieviel Cache wäre das für und Wieviele Register gibt es pro Einheit?

[Skysnake]

Naja, ein altbekanntes Verfahren, halt auf eine neue Situation angewendet mit dem Cacheing.

Wenn man halt einfach nur den aktuell ausgeführten Kontext cached, kann man auch deutlich effizienter auf die Daten dort zugreifen, da eben deutlich kleinere und schnellere Auswahllogik verwendet werden kann. Wenn man es sogar richtig geschickt macht, kann man eventuell an Teilen der großen Registerfiles die Clock abschalten, und DAS spart richtig Power :D

EDIT:

Man erkauft sich solche Verbesserungen und Einsparungen halt mit zusätzlicher Logik, die wieder Platz braucht, welchen man dann nicht für eine erhöhte Anzahl an Recheneinheiten verwenden kann. In der Zeit vor dem GPGPU war das halt uninteressant und man hat lieber mehr Einheiten genommen. Das ändert sich jetzt. Hat man ja schon an Fermi gesehen, und wird sich auch weiterhin fortführen.

Naja, mal schauen was da noch kommt. Wenn ich die Sache auf dem FDS richtig verstanden habe, setzt AMD auch so etwas wie ein Multilvl Sheduler ein.

Der sollte nämlich auch selbst priorisieren können, welcher Tasks denn nun ausgeführt wird. Da erscheint es logisch, die Registerfiles auch auf ähnliche Weise anzuordnen. Mal schauen was da noch kommt.

Spannend wird sein, wie lange sich die "Gamer" das noch gefallen lassen, das man so stark auf GPGPU setzt. Die Leuts aus dem HPC Bereich (wo ich mich auch mal dazu zähle) freuts wie noch was, dass man ihren Wünschen und Bedürfnissen nach kommt, und die Gamer dies absolut quer finanzieren. Ich hoffe mal das hält noch lange an, denn für Gamer gibts wohl nicht wirklich sehr viel Neues. Braucht ja auch kaum einer, da die Hardwareanforderungen kaum steigen im Vergleich zur Leistungsfähigkeit der Hardware.

Im CPU Bereich kann man ja von solchen Entwicklungen nur träumen -.- Da wird ja oft gespart wos nur geht, weil ja "keiner" Mehr ram braucht als man mit 40 Bits adressieren kann und lauter so Späße.... Dabei gibts auch einige Leute, bei denen die CPUs nicht ausreichend skalieren

[Gipsel]

Cache für ein Registerfile? Verrückte Welt. Wieviel Cache wäre das für und Wieviele Register gibt es pro Einheit?
Nvidias paper spricht wohl von lediglich 6 Werten. Aber wenn man sich mal x86/x64 ansieht, sind 8 (meist 6 effektiv nutzbar) bzw. 16 ja auch schon halbwegs effizient. X64 hat ja auch deswegen auf mehr als 16 Register verzichtet, weil das zu kaum merklicher Mehrperformance bei höheren Kosten geführt hätte.

[Coda]

Den Vergleich verstehe ich jetzt nicht? Was hat die Anzahl der Register der ISA mit einem Cache vor dem Registerfile zu tun?

Das physikalische Registerfile bzw. die Reservation-Station-Buffer der CPUs sind ja auch deutlich größer um Register Renaming durchführen zu können. Mit dem physikalischen Registerfile von Pentium 4, Sandy Bridge, Bulldozer und Bobcat handelte man sich das Problem dort auch überhaupt erst ein, denn früher wurden die Werte direkt in den Reservation Stations bei den Ausführungseinheiten gehalten.

[Skysnake]

Ich glaub er meint, dass durch die größere Anzahl an Registern eben auch die Arbiter größer und komplizierter werden, womit Sie auch zwangsläufig schnell langsamer werden. Das ist ja aber etwas was man überhaupt nicht gebrauchen kann.

Daher ist es ja auch sinnvoll, sich sozusagen nicht mit allen Registern zu beschäftigen, da man dann die Logik schlanker und schneller machen kann.

[Nighthawk13]

Interessantes Paper!

Ich frage mich allerdings, in wie weit sich das Paper direkt auf Kepler bezieht oder es mehr um allgemeine "was-wäre-wenn" Forschung für zukünftige Architekturen geht. Diese Formulierung hat mich etwas gewundert:
From a Fermi die photo, we estimate the area of a single SM to be 16 mm2 and assume that operands must travel 1 mm from a MRF bank to the ALUs.
Innerhalb von Nvidia müsste man sowas ja wissen;) Oder ist das nur eine Floskel um Daten unter NDA zu kommunizieren?

@Skysnake:
Dass man auf Performance/Watt und nicht Transistorenanzahl optimiert macht Sinn, da die GPUs schon jetzt thermisch limitiert sind. Davon profitieren alle User, auch die Zocker.

Zu den Anzahl der Register: Im Paper die Grafik 7c, ab 6 Register flachen die Kurven ab.
Ausserdem muss der RegisterCache in das MainRegisterFile zurückgeschrieben werden, wenn ein Warp aus dem inneren Pool des Doppelschedulers herausfällt(z.B. Texturzugriff).
Grösserer Cache -> Mehr Overhead an dieser Stelle

[Skysnake]

Ja, das musst du zurückschreiben, aber das kannst du recht einfach machen durch einen write Through Cache.

Den kleinen Cache kann man auch recht breit anbinden. Also ich seh da jetzt keine unüberwindlichen Probleme.

[Gipsel]

Den Vergleich verstehe ich jetzt nicht? Was hat die Anzahl der Register der ISA mit einem Cache vor dem Registerfile zu tun?

Das physikalische Registerfile bzw. die Reservation-Station-Buffer der CPUs sind ja auch deutlich größer um Register Renaming durchführen zu können.
Nur hilft das Register-Renaming nur bei Instruktionen in flight, um falsche Abhängigkeiten zwischen Befehlen, die das gleiche "architectural" Register benutzen, aufzulösen. Praktisch versteckt man damit den Einfluß der Pipeline-Länge auf das Ganze und ermöglicht OoOE. Es hat aber nichts mit dem Mangel an der Menge der im Code nutzbaren (bei x86 auf 8 oder 16 festgelegten) Register zu tun.
Wenn diese 8 oder 16 Register nicht ausreichen, werden Werte auf den Stack (L1-Cache) ausgelagert (da hift das Renaming null gegen). Heutige CPUs haben sogar "Sideband Stack Engines" oder wie auch immer die gerade heißen, die das teilweise nebenläufig zum eigentlichen Instruktionsstrom managen. Das hilft gegen die mangelnde Registermenge, da doch nun praktisch die x86 architectural Register lediglich eine Art Cache für die im L1 liegende Gesamtmenge an aktiven Daten darstellt.

Mir ist klar, daß das von der Handhabung im Code und auch der Realisierung in Hardware anders ausieht, aber es dient beides im Prinzip ganz grob einem ähnlichen praktischen Zweck.

[Coda]

Es hat aber nichts mit dem Mangel an der Menge der im Code nutzbaren (bei x86 auf 8 oder 16 festgelegten) Register zu tun.
Das stimmt so nicht ganz. Durch mehr Register Register kann der Prozessor virtuelle Abhängigkeiten ignorieren (WAR), welche durch die geringe Register-Zahl vom Compiler nicht vermieden werden konnten.

Es können so also auch tatsächlich intern mehr Register ausgenutzt werden als festgelegt durch die ISA.

[Skysnake]

Klar, aber dass geht dann entweder in die Richtung eines Caches, oder aber in die Richtung von SMT/HT, wo man mehrere Threads parallel abarbeitet.

[Gipsel]

Das stimmt so nicht ganz. Durch mehr Register Register kann der Prozessor virtuelle Abhängigkeiten ignorieren (WAR), welche durch die geringe Register-Zahl vom Compiler nicht vermieden werden konnten.

Es können so also auch tatsächlich intern mehr Register ausgenutzt werden als festgelegt durch die ISA.
Ja na klar, genau das meinte ich ja hiermit:
Nur hilft das Register-Renaming nur bei Instruktionen in flight, um falsche Abhängigkeiten zwischen Befehlen, die das gleiche "architectural" Register benutzen, aufzulösen. Praktisch versteckt man damit den Einfluß der Pipeline-Länge auf das Ganze und ermöglicht OoOE.
Der Compiler ist aber an die Erzeugung von Code gebunden, der mit der Anzahl der Architektur-Register auskommt (und der von der CPU so ausgefuehrt werden muss, als wenn sie das strikt in order machen wuerde). Wenn also ein Programm mehr Daten aktiv benoetigt, als in die Register passen, lagert der Compiler die traditionell auf den Stack aus (liegt ja normalerweise im L1). Und dann helfen noch so viele Rename Register nicht, da werden dann wirklich Speichertransaktionen gestartet.