Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie erfolgt die "Zuordnung" der Unified Shader des G80 bei DX9?
Vertigo
2006-11-20, 10:32:49
Siehe Titel. Wie wird das geregelt? Dynamisch? Mir ist nämlich beim Beobachten des 3DMark05 (auf einer 8800GTS) etwas Merkwürdiges aufgefallen. In der ersten Szene, in der die Soldaten hinter dem verschlossenen Tor warten, änderte sich die fps-Zahl (nach einer bestimmten Zeit und reproduzierbar) sprunghaft von ~55 auf ~80, obwohl sich praktisch nichts am Renderaufwand geändert haben dürfte. Mit meiner "alten" Radeon X1900XT blieben die fps in der Szene bis zum Öffnen des Tors nämlich weitestgehend konstant. Wie ist das zu erklären?
Laut Nvidia's Folien geschiehe dies dynamisch.
The GPU dispatch and control logic can dynamically assign vertex, geometry, physics, or pixel operations to available SPs without worrying about fixed numbers of specific types of shader units. In fact, this feature is just as important to developers, who need not worry as much that certain aspects of their code might be too pixel-shader intensive or too vertex-shader intensive.
Aus der "Overview" PDF - Datei.
LovesuckZ
=Floi=
2006-11-20, 14:15:23
auf computerbase stand was von 8 blöcken a 16 recheneinheiten
DrumDub
2006-11-20, 16:15:03
auf computerbase stand was von 8 blöcken a 16 recheneinheiten ist korrekt. 8 cluster á 16 streamprozessoren. es gibt eine hauptscheduler, der die aufgaben auf die 8 cluster verteilt und innerhalb jedes clusters gibts noch mal eine scheduler, der die aufgaben auf alle 16 streamprozessoren verteilt.
die lastverteilung erfolgt auch unter dx9 vollautomatisch. dx9 selber sieht davon nichts. inwieweit man unter dx10 einzelne streamprozessoren direkt ansprechen kann, weiß ich nicht.
tokugawa
2006-11-20, 16:53:39
ist korrekt. 8 cluster á 16 streamprozessoren. es gibt eine hauptscheduler, der die aufgaben auf die 8 cluster verteilt und innerhalb jedes clusters gibts noch mal eine scheduler, der die aufgaben verteilt innerhalb des cluster auf alle 16 streamprozessoren verteilt.
die lastverteilung erfolgt auch unter dx9 vollautomatisch. dx9 selber sieht davon nichts. inwieweit man unter dx10 einzelne streamprozessoren direkt ansprechen kann, weiß ich nicht.
Ich hab damals bei der Eurographics 2006 Peter-Pike Sloan von Microsoft nach seinem D3D10-Vortrag direkt darüber gefragt, ob es eine Möglichkeit der Allokation von Hardware-Einheiten zu Vertex/Pixel-Tasks gibt, aber die Antwort war dass dies in der D3D10-API nicht vorgesehen ist. Über D3D10 geht es also nicht.
Demirug
2006-11-20, 16:55:20
Ich hab damals bei der Eurographics 2006 Peter-Pike Sloan von Microsoft nach seinem D3D10-Vortrag direkt darüber gefragt, ob es eine Möglichkeit der Allokation von Hardware-Einheiten zu Vertex/Pixel-Tasks gibt, aber die Antwort war dass dies in der D3D10-API nicht vorgesehen ist. Über D3D10 geht es also nicht.
Das wäre ja auch total wiedersinnings. Man abstrahiert ja um sich um sowas keine Gedanken mehr machen zu müssen.
DrumDub
2006-11-20, 17:04:35
Das wäre ja auch total wiedersinnings. Man abstrahiert ja um sich um sowas keine Gedanken mehr machen zu müssen. ist die lastverteilung denn allein eine sache der hardware oder kann da noch etwas über den treiber oprimiert werden? kann die vs/ps-last nur pro cluster zugewiesen werden oder auch pro sp?
tokugawa
2006-11-20, 17:19:25
ist die lastverteilung denn allein eine sache der hardware oder kann da noch etwas über den treiber oprimiert werden? kann die vs/ps-last nur pro cluster zugewiesen werden oder auch pro sp?
Ich denk mal sowohl als auch.
Vorstellen könnt ich mir dass die Lastverteilung abhängig von den Performance-Countern ist, die man auch im NVPerfKit verwendet (das gibt ja ziemlich klar an welcher Teil der Pipeline welche Last hat).
Widersinnig schreibt man übrigens ohne "ie".
Es wär halt meiner Ansicht nach interessant gewesen ob der Programmierer hier noch einen Einfluß hat, oder ob man wirklich auf den GPU-Hersteller und seine Lastverteilungs-Maßnahmen angewiesen ist. Zumindest für einige eher akademisch-orientierte Tasks wäre das vielliecht gar nicht übel gewesen - und sei es einfach dafür, um zu sehen wie ein Algorithmus skaliert in Relation zur Anzahl der vertexverarbeitenden und fragmentverarbeitenden Einheiten, also eine Messungsaufgabe.
Demirug
2006-11-20, 17:34:48
Es wär halt meiner Ansicht nach interessant gewesen ob der Programmierer hier noch einen Einfluß hat, oder ob man wirklich auf den GPU-Hersteller und seine Lastverteilungs-Maßnahmen angewiesen ist. Zumindest für einige eher akademisch-orientierte Tasks wäre das vielliecht gar nicht übel gewesen - und sei es einfach dafür, um zu sehen wie ein Algorithmus skaliert in Relation zur Anzahl der vertexverarbeitenden und fragmentverarbeitenden Einheiten, also eine Messungsaufgabe.
Das ist dann aber eher was für herstellerspezifische Tools.
Siehe Titel. Wie wird das geregelt? Dynamisch?
da gibt es keine großartige zuteilung, die streamprozessoren sind einfach dinger die multiplizieren, addieren, subtrahieren, und was weis ich noch für rechenaufgaben übernehmen.
diese rechnen mit zahlen, wobei ihnen egal ist ob diese zahl nun in teil eines pixels, eines vertices oder sonstwas repräsentiert.
ist die lastverteilung denn allein eine sache der hardware oder kann da noch etwas über den treiber oprimiert werden?
das sollte eigentlich "automatisch" mehr oder weniger "optimal" laufen. prinzipiell wäre es vielleicht möglich dass der treiber die hardware so programmiert, dass gewisse SP-gruppen nur pixel- oder vertexshader rechnen dürfen, nur wäre das relativ sinnlos und würde das unified-shader-design ad-absurdum führen.
kann die vs/ps-last nur pro cluster zugewiesen werden oder auch pro sp?
wenn ich es richtig verstanden habe rechnet ein cluster zum zeitpunkt x immer an genau einem (pixel, vertex, wasauchimmer) programm.
wenn der thread-prozessor im nächsten takt den nächsten befehl losschickt kann dieser aber natürlich auch aus einem anderen programm sein (wobei der vorhergehende befehl aus dem vorhergehenden programm natürlich noch in einer anderen stufe in der pipeline ist und demzufolge auch mehrere befehle gleichzeitig in verschiedenen pipelinestufen sein können)
Siehe Titel. Wie wird das geregelt? Dynamisch? Mir ist nämlich beim Beobachten des 3DMark05 (auf einer 8800GTS) etwas Merkwürdiges aufgefallen. In der ersten Szene, in der die Soldaten hinter dem verschlossenen Tor warten, änderte sich die fps-Zahl (nach einer bestimmten Zeit und reproduzierbar) sprunghaft von ~55 auf ~80, obwohl sich praktisch nichts am Renderaufwand geändert haben dürfte. Mit meiner "alten" Radeon X1900XT blieben die fps in der Szene bis zum Öffnen des Tors nämlich weitestgehend konstant. Wie ist das zu erklären?
Meine Vermutung ist eher dass da das Hier-Z der Radeon besser funktioniert oder aber irgend was bei der Radeon schon vorher limitiert die ganze Zeit über.
=Floi=
2006-11-20, 19:17:54
könnte aber auch dazu genutzt werden dass software bewusst oder unbewusst ausgebremst wird und wenn es komplett geschlossen ist finde ich es so am besten
solange nur der kartenhersteller zugriff auf die hardware über den treiber hat und wenn das ganze noch komplett in hardware läuft dürfte es so auch am schnellsten laufen
575Mhz immerhin
SavageX
2006-11-20, 20:12:59
Hmm... ich liege vermutlich voll daneben... aber wann wird denn gleichzeitig an Vertex- und Fragmentdaten herumgerechnet?
In meiner simplen Vorstellung geschieht das hübsch hintereinander. Zuerst mit den Streamprozessoren die Vertexdaten bearbeiten, dann umkonfigurieren und mit denselben Dingern danach Fragments berechnen.
Dann würden zu einem gegebenen Zeitpunkt alle Einheiten das gleiche Zeug tun.
Oder wird auf den Karten schonmal mehr als ein Frame berechnet? (Wäre mir neu...)
Es gibt doch nicht nur einen Vertex und ein Fragment in einer Szene..
SavageX
2006-11-20, 20:19:45
Es gibt doch nicht nur einen Vertex und ein Fragment in einer Szene..
Aber wie kann man den Frame rendern, wenn die Geometrie noch nicht endgültig steht?
Ich glaub du hast da ein Vorstellungsproblem. Es wird nicht nicht alles transformiert bevor die GPU anfängt was zu füllen ;)
SavageX
2006-11-20, 20:31:47
Err... doch? Muss doch alles in den Blickwinkel der Kamera gerückt werden?
Jeder Vertex wird angefasst (edit: Hmm... wenn er nicht über die Display List eingefütter wird...) - und sei es mit der ganz normalen Transformation, die die fixed-function Transformation nachbildet, wie man sie "von früher" kannte.
Mal ein Blick ins Flussdiagramm aus der OpenGL Spezifikation...
http://img503.imageshack.us/img503/548/pipelinely0.png
Erst müssen die Vertices transformiert werden, dann erst (nachdem die Position aller Vertices festgetackert ist) kann man sich um Rasterisierung - und dann erst um die Fragments kümmern.
Okay... wo liege ich hier falsch?
tokugawa
2006-11-20, 20:40:58
Err... doch? Muss doch alles in den Blickwinkel der Kamera gerückt werden?
Jeder Vertex wird angefasst - und sei es mit der ganz normalen Transformation, die die fixed-function Transformation nachbildet, wie man sie "von früher" kannte.
Mal ein Blick ins Flussdiagramm aus der OpenGL Spezifikation...
http://img503.imageshack.us/img503/548/pipelinely0.png
Erst müssen die Vertices transformiert werden, dann erst (nachdem die Position aller Vertices festgetackert ist) kann man sich um Rasterisierung - und dann erst um die Fragments kümmern.
Okay... wo liege ich hier falsch?
Es müssen nicht _alle_ Vertizes einer Szene oder eines Objektes voll transformiert werden um sie an den Rasterizer/Interpolator zu schicken.
Wenn du eine Liste an Vertizes hast, als Primitive-Liste, arbeitet die Vertex-Pipeline ja erst mal die Vertizes durch, und fertige Primitive können dann bereits rasterisiert werden.
Das ist das typische an massiv-parallelen Pipelines: während spätere Stufen noch an irgendwas arbeiten, können die früheren Stufen schon die nächsten Arbeitsbrocken angehen.
Ansonsten hättest du ja lauter Pipeline-Stalls wenn du erst dann rasterisierst, wenn alle Vertizes fertig wären.
SavageX
2006-11-20, 20:50:40
Okay, ich bin mal bereit, das so zu akzeptieren (sonst würde es ja gar kein Problem mit der Zuordnung geben - gibt es aber dem Vernehmen nach). Man nehme eine Gruppe von Vertices, transformiere sie (wenn nötig) und rasterisiere und rendere sie schonmal... und füttere vorne die Pipeline mit neuem Kram.
Wäre natürlich ärgerlich, wenn 99% schon transformiert und gerastert sind... und dann die letzen Vertices die ganze Szene bedecken...
Bei mir hängt immer noch Quer, wie man die Szene effizient rendern kann, wenn man noch nicht über die endgültige Geometrie der ganzen Szene bescheid weiß.
Bei mir hängt immer noch Quer, wie man die Szene effizient rendern kann, wenn man noch nicht über die endgültige Geometrie der ganzen Szene bescheid weiß.
Tja, so ist das halt seit der Voodoo 1. Das machen nur die PowerVR-Chips anders ;)
Die Polygone werden wirklich eines nach dem anderen auf den Bildschirm gemalt.
tokugawa
2006-11-20, 22:01:52
Okay, ich bin mal bereit, das so zu akzeptieren (sonst würde es ja gar kein Problem mit der Zuordnung geben - gibt es aber dem Vernehmen nach). Man nehme eine Gruppe von Vertices, transformiere sie (wenn nötig) und rasterisiere und rendere sie schonmal... und füttere vorne die Pipeline mit neuem Kram.
Wäre natürlich ärgerlich, wenn 99% schon transformiert und gerastert sind... und dann die letzen Vertices die ganze Szene bedecken...
Bei mir hängt immer noch Quer, wie man die Szene effizient rendern kann, wenn man noch nicht über die endgültige Geometrie der ganzen Szene bescheid weiß.
Dafür gibt es Mittel wie Early-Z.
Außerdem reden wir hier von einzelnen Batches, also einen Drawcall an sich. Innerhalb eines Batches wird es statistisch gesehen nicht so viele Überlappungen geben (bei konvexen Objekten gibt es z.B. gar keine). Bedenke dass es Backface-Culling gibt, rückwärtig gerichtete Primitive werden gar nicht rasterisiert.
Ansonsten kann da die Engine vieles machen (auf der CPU). Visibility eben.
Demirug
2006-11-20, 22:04:08
Tja, so ist das halt seit der Voodoo 1. Das machen nur die PowerVR-Chips anders ;)
Die Polygone werden wirklich eines nach dem anderen auf den Bildschirm gemalt.
Um Korrekt zu sein in den Backbuffer. Sonst wundert sich Savage X noch warum er davon nichts sieht.
In meiner simplen Vorstellung geschieht das hübsch hintereinander. Zuerst mit den Streamprozessoren die Vertexdaten bearbeiten, dann umkonfigurieren und mit denselben Dingern danach Fragments berechnen.
es muss da nichts umkonfiguriert werden intern rechnen die shader-alus lediglich mit zahlen, wobei ihnen vollkommen egal ist was die zahlen repräsentieren.
für die alu ist es vollkommen egal ob die zahl nun zu einem pixel, vertex, oder gar zu irgendeiner GPGPU-anwendung gehört.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.