deekey777
2006-12-16, 23:35:25
Wie funktioniert USA,
Or why Homer Simpson was right to keep shouting “U.S.A.”
Richard “7 of 5” Huddy
RHuddy@ati.com (RHuddy@ati.com)
Prolog:
Ich glaube, dieses Posting (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=4739997#post4739997) ist sehr wichtig:
Wieso Zustände? Die Shader verarbeiten Daten. Denen ist es doch Wurscht, was das für Daten sind, und woher sie kommen und wohin sie gehen. Die "Fütterung" und den "Abfluss" der Pipes muss man nur umleiten, aber die Pipe bzw. ALUs in keinen anderen Zustand versetzen.
Seit dem 8. November haben wir mit dem G80 den ersten Desktop-Grafikchip, der die Bezeichnung "unified" stolz auf der Brust trägt. Eine Überraschung war und ist dieser Chip allemal, einerseits wegen der Täuschungspolitik von nVidia und andererseits weil er so anders ist.
Und jetzt stellt sich die Frage: Wie funktioniert dieser G80 mit seinen vereinigten Einheiten? Und damit es noch komplizierter wird, reduziere ich den G80 bzw. seine 8 „Thread Processing Cluster“ auf einen, da sich meiner Meinung nach die Fragen nach der Thread-Verwaltung und der Funktionsweise so eines TCP besser erklären lässt, insbesondere im Hinblick auf das Load-Balancing.
Wenn man dem einen oder anderen Artikel glauben kann, so kann jeder Cluster unterschiedliche Thread-Arten berechnen und das in einem Takt:
Each cluster can process threads of three different types (vertex, geometry, pixel), independently and in the same clock cycle (and infact it's likely more granular than that), and that's the crux of how the shading core works. With a scheduler per cluster and processing of all thread types, you have yourself a unified shading architecture, no clusters specifically tied to vertex, geometry or pixel data for the duration of the chip's operation, and the ability to perform the necessary work whenever it's needed. That almost self-scheduling, dynamically balanced, independant shading is what defines G80 from a data processing perspective. That means that in any given cycle, all 128 SPs may be working on the same thread type, but conversely and as a function of the thread schedulers running each cluster, working on vertex, geometry and pixel data in the same cycle.
Wie oben erwähnt, für die Einheiten an sich ist es egal, was gerade berechnet wird, denn sie berechnen nur Zahlen. Auch meinem Taschenrechner ist es egal, was ich berechnen will.
Die Frage ist: Wie gut ist das Load-Balancing des G80 wirklich? Können pro Cluster wirklich alle Shader-Typen in einem Takt berechnen oder sind sie doch auf einen Shader-Typ beschränkt?
Der erste Fall ist ideal, selbst wenn es 50:50 ist. Auch wird es nicht passieren, dass die TMUs irgendwie auf die einzelnen ALU-Quads aufgeteilt werden (wie komme ich überhaupt auf sowas?), denn sie sind ja nicht an den Shader-Typ gebunden, den gerade die ALUs berechnen. Aber hier stellt sich die nächste Frage: Wie sieht es mit der Verwaltung aus?
Der Fall der Limitierung auf einen Shader-Typ pro Takt hätte den Vorteil, dass der Verwaltungsaufwand geringer ist. Andererseits (was das Verständnisproblem von mir ist): Kann hier eine Latenz entstehen? Schließlich müssen die frischberechneten 16 Vertizen raus (um dann zu Dreiecken zusammengefasst zu werden, in Fragmente gesplittet, unsichtbare Fragmente müssen weg, unsichtbare Quads müssen weg, unsichtbare Pixel müssen als unsichtbar markiert werden). Hier wird doch einfach ein weiterer Thread nachgeschoben?
Weitere Fragen: Wie große Caches hat dann so ein USA-Chip? Werden die einzelnen Thread dahin verteilt, wo gerade (Rechen-)Platz ist?
Or why Homer Simpson was right to keep shouting “U.S.A.”
Richard “7 of 5” Huddy
RHuddy@ati.com (RHuddy@ati.com)
Prolog:
Ich glaube, dieses Posting (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=4739997#post4739997) ist sehr wichtig:
Wieso Zustände? Die Shader verarbeiten Daten. Denen ist es doch Wurscht, was das für Daten sind, und woher sie kommen und wohin sie gehen. Die "Fütterung" und den "Abfluss" der Pipes muss man nur umleiten, aber die Pipe bzw. ALUs in keinen anderen Zustand versetzen.
Seit dem 8. November haben wir mit dem G80 den ersten Desktop-Grafikchip, der die Bezeichnung "unified" stolz auf der Brust trägt. Eine Überraschung war und ist dieser Chip allemal, einerseits wegen der Täuschungspolitik von nVidia und andererseits weil er so anders ist.
Und jetzt stellt sich die Frage: Wie funktioniert dieser G80 mit seinen vereinigten Einheiten? Und damit es noch komplizierter wird, reduziere ich den G80 bzw. seine 8 „Thread Processing Cluster“ auf einen, da sich meiner Meinung nach die Fragen nach der Thread-Verwaltung und der Funktionsweise so eines TCP besser erklären lässt, insbesondere im Hinblick auf das Load-Balancing.
Wenn man dem einen oder anderen Artikel glauben kann, so kann jeder Cluster unterschiedliche Thread-Arten berechnen und das in einem Takt:
Each cluster can process threads of three different types (vertex, geometry, pixel), independently and in the same clock cycle (and infact it's likely more granular than that), and that's the crux of how the shading core works. With a scheduler per cluster and processing of all thread types, you have yourself a unified shading architecture, no clusters specifically tied to vertex, geometry or pixel data for the duration of the chip's operation, and the ability to perform the necessary work whenever it's needed. That almost self-scheduling, dynamically balanced, independant shading is what defines G80 from a data processing perspective. That means that in any given cycle, all 128 SPs may be working on the same thread type, but conversely and as a function of the thread schedulers running each cluster, working on vertex, geometry and pixel data in the same cycle.
Wie oben erwähnt, für die Einheiten an sich ist es egal, was gerade berechnet wird, denn sie berechnen nur Zahlen. Auch meinem Taschenrechner ist es egal, was ich berechnen will.
Die Frage ist: Wie gut ist das Load-Balancing des G80 wirklich? Können pro Cluster wirklich alle Shader-Typen in einem Takt berechnen oder sind sie doch auf einen Shader-Typ beschränkt?
Der erste Fall ist ideal, selbst wenn es 50:50 ist. Auch wird es nicht passieren, dass die TMUs irgendwie auf die einzelnen ALU-Quads aufgeteilt werden (wie komme ich überhaupt auf sowas?), denn sie sind ja nicht an den Shader-Typ gebunden, den gerade die ALUs berechnen. Aber hier stellt sich die nächste Frage: Wie sieht es mit der Verwaltung aus?
Der Fall der Limitierung auf einen Shader-Typ pro Takt hätte den Vorteil, dass der Verwaltungsaufwand geringer ist. Andererseits (was das Verständnisproblem von mir ist): Kann hier eine Latenz entstehen? Schließlich müssen die frischberechneten 16 Vertizen raus (um dann zu Dreiecken zusammengefasst zu werden, in Fragmente gesplittet, unsichtbare Fragmente müssen weg, unsichtbare Quads müssen weg, unsichtbare Pixel müssen als unsichtbar markiert werden). Hier wird doch einfach ein weiterer Thread nachgeschoben?
Weitere Fragen: Wie große Caches hat dann so ein USA-Chip? Werden die einzelnen Thread dahin verteilt, wo gerade (Rechen-)Platz ist?