Deferred Rendering + PixelShader

[El Fantastico]

Hi!

Mal eine Frage an die Gurus:
Ich mache gerade für einen Vortrag einen Vergleich zwischen immediate und deferred Renderern. Wenn ich das Prinzip eines deferred Renderers korrekt verstanden habe, werden Texturierung,Blending etc. erst nach den Z-Vergleichen (quasi "zum Schluss" ausgeführt) nur für die sichtbaren Pixel ausgeführt.
Pixelshader funktionieren ja nun glaube ich so, dass der Shader hochgeladen wird und dann auf alle Pixel angewandt wird, die durch die Pipeline kommen. Wenn ich einen neuen Shader brauche, lade ich einen neuen Shader hoch. Wie wird das ganze dann auf deferred Renderern realisiert? Werden für alle Dreiecke die jeweiligen Shader gespeichert, die in diesem Moment ausgeführt werden sollten, damit ich später für jeden Pixel weiss, welcher Shader angewandt werden muss? Wenn ja - ist das nicht furchtbar ineffizient?

Der neue PowerVR Chip soll ja Pixelshader haben, also muss es ja irgendwie gehen ;)

Ich hoffe ich hab mich verständlich ausgedrückt. Vielen Dank schonmal!

[Demirug]

Ja, bei einem vollständigen DR wird das Berechnen der Pixelfarbe erst durchgeführt wenn genau feststeht welche Pixel den nun wirklich sichtbar sind.

Ein IMR macht es so wie du beschreiben hast. Der Pixelshader wird aktiviert dann kommen viele Pixel und dann wird mit dem nächsten Shader weitergemacht.

Bei einem DR müssen eben für jeden Pixel der am Ende sichtbar ist der richtige Shader eingeladen und ausgeführt werden. Damit das ganze nicht gar so ineffektiv wird kann man natürlich ein bischen helfen in dem man mit Caches und einem grossen Programmspeicher arbeitet und es erlaubt das jeder Pixel einen anderen Instruktion Pointer hat.

Die Information welcher Shader für welches Dreieck benutzt werden muss ist ein teil der Information welche beim Speichern der Szenedaten (Binning) mitgespeichert wird. Man speichert natürlich nicht für jedes Dreieck den Shader sondern speichert diesen nur einmal und verweisst dan darauf.

[El Fantastico]

Besten Dank! Dann lag ich ja nicht so falsch ;)

[zeckensack]

Ist eine gute Frage :D

Original geschrieben von zeckensack
Q: TBDRs can have differing render states per pixel inside a tile and must be able to switch them quickly because they process primitives somewhat out of order. This problem is amplified for pixel shaders, where a renderstate is suddenly a lot of data. Programs and constants on top of all the fixed function things like texture bindings, etc. Is this a theoretical problem only or is it something that really needs to be solved for good performance? Can it be solved? Diese Frage wurde (modifiziert) auch in einem hier verlinkten Interview (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=100648) gestellt.
... und leider nur sehr unbefriedigend beantwortet, ala "Ja, da muß man schon aufpassen" :spock:

[El Fantastico]

Danke für den Link! Auch sehr schön ist dieser Satz: "That's too specific to an unannounced product to answer" :D

Aber interessant fand ich die Anmerkung, das ja auf einem DR natürlich auch wesentlich weniger Pixelshaderoperationen ausgeführt werden, womit sich der Aufwand vielleicht wieder relativiert.

[Ailuros]

Original geschrieben von El Fantastico
Danke für den Link! Auch sehr schön ist dieser Satz: "That's too specific to an unannounced product to answer" :D

Aber interessant fand ich die Anmerkung, das ja auf einem DR natürlich auch wesentlich weniger Pixelshaderoperationen ausgeführt werden, womit sich der Aufwand vielleicht wieder relativiert.

Als "negatives" wuerde ich vielleicht noch shader task switching als Moeglichkeit hinzufuegen und als "positives" dass die PS von den VS total entkoppelt sind.

Ob ein TBDR jetzt nun bessere oder schlechtere Leistung im Durchschnitt mit Pixel shading leisten wird, ist wohl eine Frage der Zeit bis wir es herausfinden.

[loewe]

Original geschrieben von El Fantastico
Mal eine Frage an die Gurus:
Ich mache gerade für einen Vortrag einen Vergleich zwischen immediate und deferred Renderern. Wenn ich das Prinzip eines deferred Renderers korrekt verstanden habe, werden Texturierung,Blending etc. erst nach den Z-Vergleichen (quasi "zum Schluss" ausgeführt) nur für die sichtbaren Pixel ausgeführt.
Pixelshader funktionieren ja nun glaube ich so, dass der Shader hochgeladen wird und dann auf alle Pixel angewandt wird, die durch die Pipeline kommen. Wenn ich einen neuen Shader brauche, lade ich einen neuen Shader hoch. Wie wird das ganze dann auf deferred Renderern realisiert? Werden für alle Dreiecke die jeweiligen Shader gespeichert, die in diesem Moment ausgeführt werden sollten, damit ich später für jeden Pixel weiss, welcher Shader angewandt werden muss?
Du hast es schon ganz gut beschrieben. Der TBDR muss natürlich ähnlich arbeiten, die Shader werden je Tile einmal geladen auf alle Pixel angewandt, die den Shader brauchen, und dann kommt der nächste. Wenn die Tile ferig ist kommt die nächste dran, welche sicher mit einer gewissen Wahrscheinlichkeit zum Teil die gleichen Shader braucht.
Sicher müssen aber öfter Shader gewechselt werden, was die Bandbreite sicher massiv belastet.
Wenn ja - ist das nicht furchtbar ineffizient?

Ein schwer Vorwurf an PowerVR! ;) Wenn sie etwas von ihren Chips behaupten, dann ist es die Effiziens.
Also mal keine Angst, ihnen ist da schon was eingefallen und wie Ailuros sagt, wir werden es in nicht all zu langer Zeit zu sehen bekommen.

[El Fantastico]

Danke auch für Eure Antworten :)
Original geschrieben von Ailuros
...und als "positives" dass die PS von den VS total entkoppelt sind.

Inwiefern sind denn bei Immediate Renderern PS und VS gekoppelt?
Original geschrieben von loewe
Ein schwer Vorwurf an PowerVR! ;) Wenn sie etwas von ihren Chips behaupten, dann ist es die Effiziens.

Kein Vorwurf - war doch ein Fragezeichen hinter ;)
Original geschrieben von loewe
Also mal keine Angst, ihnen ist da schon was eingefallen und wie Ailuros sagt, wir werden es in nicht all zu langer Zeit zu sehen bekommen.
Den Ausdruck "in nicht all zu langer Zeit" kannst/darfst Du sicherlich nicht präzisieren, oder :D

[Demirug]

Manchmal sieht man die Lösung eines Problems nicht obwohl man direkt davor steht.

Die grosse Schwierigkeit bei einem DR ist es ja beim Shaderwechsel zu verhindern das die Pipeline leerläuft. Was eine Leere Pipeline für Auswirkungen hat haben wir ja bei den NV3X Chips gelernt. Nun kann ja in einer Tile ein bunt gemischter Haufen an Pixel sein die unterschiedliche Shader mit unterschiedlicher länge Benutzten sein. Wie bekommt man unter diesen Bedingungen die Pipeline voll und die Shader in den Chip?

Eigentlich ganz einfach.

Der Shaderspeicher wird als lineare Speicher ausgelegt in dem mehr als ein Programm gelagert werden kann. Jeder Pixel bekommt dann bei einspeisen in die Pipeline einen eigenen Instruction Pointer (kann man für PS 3.0 ja sowieso gebrauchen). Da an jeder beliebigen Stelle das Programm anfangen kann muss der Chip vor dem Einspeisen in die Pipe die entsprechenden Startaddresse für seinen Shader ermitteln. Sobald ein Programm bei der Endanweisung angekommen ist fliegt der Pixel aus der Pipeline und vorne kann der nächste übernommen werden. Die Zeit welche die Pixel vor der Pipeline warten müssen kann genutzt werden um bei Bedarf die benötigten Shaderprogramme zu laden. Hier könnte dann ein bischen Logik möglicherweise auch die Reihenfolge der Pixel etwas ändern um die Sache abzugleichen. Auf diese Weise kann jeder Pixel in der Pipeline ein anderes Programm ausführen oder im gleichen Programm an einer anderen Anweisung sein. Die Gefahr des Leerlaufens sollte so weitgehend eliminiert werden.

[Ailuros]

Inwiefern sind denn bei Immediate Renderern PS und VS gekoppelt?

Eine solche Frage wuerde natuerlich am Besten Demirug beantworten. Ich weiss nur dass es kritisch werden kann wenn ein sehr langer pixel shader mit einem sehr kurzen vertex shader kombiniert wird. In dem Fall kann es vorkommen dass der kurze shader schon einige Zeit vor dem langen gerendert wird und dann auf die Vollendung des langen shaders warten muss, was zu einem "stall" fuehren kann.

Voruebergehend wird es wohl den Entwicklern keine grosse Sorge machen da es "workarounds" dafuer schon gibt und es wird ja auch einige Zeit dauern bis wir extrem lange Shader sehen werden.


Manchmal sieht man die Lösung eines Problems nicht obwohl man direkt davor steht.

Die grosse Schwierigkeit bei einem DR ist es ja beim Shaderwechsel zu verhindern das die Pipeline leerläuft. Was eine Leere Pipeline für Auswirkungen hat haben wir ja bei den NV3X Chips gelernt. Nun kann ja in einer Tile ein bunt gemischter Haufen an Pixel sein die unterschiedliche Shader mit unterschiedlicher länge Benutzten sein. Wie bekommt man unter diesen Bedingungen die Pipeline voll und die Shader in den Chip?

Eigentlich ganz einfach.

Der Shaderspeicher wird als lineare Speicher ausgelegt in dem mehr als ein Programm gelagert werden kann. Jeder Pixel bekommt dann bei einspeisen in die Pipeline einen eigenen Instruction Pointer (kann man für PS 3.0 ja sowieso gebrauchen). Da an jeder beliebigen Stelle das Programm anfangen kann muss der Chip vor dem Einspeisen in die Pipe die entsprechenden Startaddresse für seinen Shader ermitteln. Sobald ein Programm bei der Endanweisung angekommen ist fliegt der Pixel aus der Pipeline und vorne kann der nächste übernommen werden. Die Zeit welche die Pixel vor der Pipeline warten müssen kann genutzt werden um bei Bedarf die benötigten Shaderprogramme zu laden. Hier könnte dann ein bischen Logik möglicherweise auch die Reihenfolge der Pixel etwas ändern um die Sache abzugleichen. Auf diese Weise kann jeder Pixel in der Pipeline ein anderes Programm ausführen oder im gleichen Programm an einer anderen Anweisung sein. Die Gefahr des Leerlaufens sollte so weitgehend eliminiert werden.

Der Quote kommt in mein ichhabheutewiederwasdazugelernt Archiv. Ich musste den letzten Paragraph zwar drei mal durchlesen bis ich ihn kapierte, aber es war es wohl wert.

[Demirug]

Original geschrieben von El Fantastico
Inwiefern sind denn bei Immediate Renderern PS und VS gekoppelt?

Es gibt eine gegenseitige Beeinflussung. Kann ein Chip die Verticen nicht schnell genug berechnen (VS) laufen die Pixelshader leer. Kommen dagegen die Pixelshader nicht hinterher müssen die Vertexshader blokiert werden.

In einem TBDR gibt es zwar die Verzahnung nicht dafür aber andere.

[micki]

Original geschrieben von Demirug
Manchmal sieht man die Lösung eines Problems nicht obwohl man direkt davor steht.

Die grosse Schwierigkeit bei einem DR ist es ja beim Shaderwechsel zu verhindern das die Pipeline leerläuft. Was eine Leere Pipeline für Auswirkungen hat haben wir ja bei den NV3X Chips gelernt. Nun kann ja in einer Tile ein bunt gemischter Haufen an Pixel sein die unterschiedliche Shader mit unterschiedlicher länge Benutzten sein. Wie bekommt man unter diesen Bedingungen die Pipeline voll und die Shader in den Chip?

Eigentlich ganz einfach.

Der Shaderspeicher wird als lineare Speicher ausgelegt in dem mehr als ein Programm gelagert werden kann. Jeder Pixel bekommt dann bei einspeisen in die Pipeline einen eigenen Instruction Pointer (kann man für PS 3.0 ja sowieso gebrauchen). Da an jeder beliebigen Stelle das Programm anfangen kann muss der Chip vor dem Einspeisen in die Pipe die entsprechenden Startaddresse für seinen Shader ermitteln. Sobald ein Programm bei der Endanweisung angekommen ist fliegt der Pixel aus der Pipeline und vorne kann der nächste übernommen werden. Die Zeit welche die Pixel vor der Pipeline warten müssen kann genutzt werden um bei Bedarf die benötigten Shaderprogramme zu laden. Hier könnte dann ein bischen Logik möglicherweise auch die Reihenfolge der Pixel etwas ändern um die Sache abzugleichen. Auf diese Weise kann jeder Pixel in der Pipeline ein anderes Programm ausführen oder im gleichen Programm an einer anderen Anweisung sein. Die Gefahr des Leerlaufens sollte so weitgehend eliminiert werden.
dazu müßten alle pixel asynchron zueinander abgearbeitet werden, oder? (weil sonst leerlauf vorkäme, ich meine in bezug auf die breite der gleichzeitig berechneten pixel...)

das stelle ich mir komplex vor, besonders in zusammenspiel mit AA, kann ja sein dass ein pixel einen shader mit vollem instructioncount bekommt und die anderen einen mit nur einem "mov"-befehl und schon läuft das ganze extrem auseinander.

MfG
micki

[loewe]

Original geschrieben von micki
dazu müßten alle pixel asynchron zueinander abgearbeitet werden, oder? (weil sonst leerlauf vorkäme, ich meine in bezug auf die breite der gleichzeitig berechneten pixel...)

das stelle ich mir komplex vor, besonders in zusammenspiel mit AA, kann ja sein dass ein pixel einen shader mit vollem instructioncount bekommt und die anderen einen mit nur einem "mov"-befehl und schon läuft das ganze extrem auseinander.

MfG
micki

Massiv parallel wird doch erst einmal nur in der HSR Einheit gearbeitet.
Auch wenn ich dafür keine Bestätigung habe, ich gehe dort von 64 parallel verarbeiteten Pixeln aus.
Um die Shaderwechsel so klein wie möglich zu halten wäre ein Abarbeitung im Pixelshader dreieckweise sinnvoll, also etwa folgendes:


für alle dreiecke einer Tile
für alle sichtbaren pixel des aktuellen dreiecks
führe den shader aus.


Sicher wird der Pixelshader mehrere Pixel parallel bearbeiten können, wäre in diesem Fall ja auch nicht so schlimm, da erst einmal für alle Pixel jeweils der gleiche Shader durchlaufen wird.
Für den Fall das verschiedene Shader laufen kann der Pixelshader sicher eine sinvolle Aufteilung der Kapazitäten bringen, ich erinnere in dem Zusammenhang an Metagence.

[Gast]

IMO läuft es nicht nur auseinander, sondern das Problem ist dieser Shaderspeicher an sich.

Wenn ich es richtig verstanden habe, ist der nicht im lokalen Graka-RAM, sondern als extra-speicher angedacht, oder?

Wenn nicht, dann braucht ihr nicht weitezulesen, falls aber doch, dann stelle ich mir die Frage nach der Größe eines solchen Speichers, soll er auch für den Ernstfall ausreichen.


Worst Case (den ich mir laienhaft vorstellen kann) bei einer Tile von xx Pixeln kann theoretisch für jeden Pixel ein anderer Shader vonnöten sein.
Wenn diese xx Shader allesamt maximalgröße haben (es wird ja von mehr als "nur" PS2.0 gemunkelt), dürfte der Shader-Speicher ziemlich umfangreich werden, oder?

[loewe]

Original geschrieben von Gast
Wenn nicht, dann braucht ihr nicht weitezulesen, falls aber doch, dann stelle ich mir die Frage nach der Größe eines solchen Speichers, soll er auch für den Ernstfall ausreichen.

Worst Case (den ich mir laienhaft vorstellen kann) bei einer Tile von xx Pixeln kann theoretisch für jeden Pixel ein anderer Shader vonnöten sein.
Wenn diese xx Shader allesamt maximalgröße haben (es wird ja von mehr als "nur" PS2.0 gemunkelt), dürfte der Shader-Speicher ziemlich umfangreich werden, oder?

Ich denke keine Firma baut eine Grafikkarte für ein andauerndes Worst Case Szenario. Es wird also eine größe gewählt werden, die bei typischer Polygonzahl und Pixelzahl völlig ausreichend ist.

Grundsätzlich besitzt PowerVR über das Mega-Tile Patent eine Technologie, die mit beliebigen Speichergrößen funktioniert. Ich hab den Link hier nicht, müßte aber durch Suchen zu finden sein.
Kurz funktioniert das etwa so,
sollte der Binningpeicher zu klein werden wird die Tile sofort mit den bisher vorhanden Polygonen fertig gerendert und zwischengespeichert. Jetzt kann der Binningspeicher gelehrt werden und die weiteren Polygone werden in den Binningspeicher geladen. Wenn voll, den mit den neuen Polygonen wie bei einem IMR weiter rendern, wenn Ende dann wird die Tile wie bei einem IMR fertig gerendert.
Das ist natürlich lange nicht so effektiv wie die komplette Abarbeitung im Chip, funktioniert dafür aber immer. Durch ein weiteres Patent zu Z Ranges ist das noch verbessert worden, ist hier auch irgendwo zu finden.

Beim PC Ship sollte dieser Fall aber nur sehr selten eintreten, also muß der Speicher groß genug gewählt werden.
AFAIK ist der Binningspeicher bei KYRO 6 MB, ich will jetzt nicht viel rumrechnen und rate auh einfach mal so, wenn sie jetzt 32 MB nehmen, sollten sie schon recht weit kommen.

Was ich natürlich nicht weiß, wieviele Shader eigentlich üblicher Weise je Szene vorhanden sein werden. Zu viele werden sicher auch IMRs Probleme bereiten.

[micki]

wo der ist hängt vom treiber und der hardware ab, laut demi ist der bei GFFX im vram...

und wenn du aufmerksam gelesen hättest, würde er auseinander laufen wenn man mehrere shader drinne hätte und pro pixel einen zuweisen würde, da es einen pixel geben könnte der die volle shaderlänge nutzt und somit laut dx9 bis 96Hz braucht.
bei 8 parallel arbeitenden pixelpipes, würde man also 967 simpelst-shader-pixel und 1 komplex-shader-pixel rausbekommen. für AA müßte man die doch eventuell cachen damit man danach alles verrechnen kann und .....

es wäre ziemlich asynchron denk ich mir... *AufDemisAntwortWart*


das mit dem "im tile für jedes dreieck" halte ich auch für ziemlich gut. ich würde aber eher davon ausgehen, dass sie alle pixel von einem tile nach shader sortieren (so wie sie es schon mit dem zbuffer machen für alpha) und dann in jedem pixel eines tiles steht welche position der ursprünglich hattte... das sollte ja nicht die welt sein.

VRam (oder GPU cache) wäre dann natürlich der beste ort für shader.

MfG
micki

[Demirug]

Bei einem TBDR sollte man das ganze natürlich asyncron lösen.

Die Tile müsste komplett an eine Einheit vor den Pixelshadern übergeben werden. Dann läuft jeder Pixel durch den shader und am Ende wird die Tile wieder zusammengesetzt um dann an die nächste Einheit wieder komplett weitergereicht zu werden.

Unterschiedliche Shaderlängen sollten kein Problem darstellen. Man sollte allerdings mit den Pixeln anfangen welche die meisten Anweisungen ausführen müssen.

[ow]

.

[micki]

ja kann man, weil die pixelshäder keine jumpbefehle haben zur zeit, somit wird immer der ganze abgearbeitet...

ich würde die shader zuerst laufen lassen, deren verhältnis texturereads:instructions mehr texturreads-gewichtung haben, weil dann beim flushen aus dem cache ins ram mehr bandbreite bliebe (wenn es asynchron ist, also noch pixel berechnet würden)

MfG
micki

[Demirug]

Original geschrieben von ow
Wieso das? Es müssen doch alle Pixel komplett berehcnet werden, warum spielt da die Reihenfolge eine Rolle?
Und kann man überhaupt im voraus wissen, wieviele Anweisungen welcher Pixel braucht?

Die Pipeline hat ja eine bestimmte Länge. Sagen wir mal 25 Stufen (sind wahrscheinlich zu wenig). Um sie also voll auszunutzen müssen immer 25 Pixel in Flight sein. Wenn man jetzt zuerst die kurzen Programme bearbeitet bleiben am schluss nur noch die langen übrig und wenn das weniger als 25 sind schiebt man Blassen durch die Pipeline. Fängt man jetzt mit den längsten an kann man die Blasen mit den kurzen auffüllen. Man könnte natürlich auch den Speicher vor und hinter dem PS vergrössern so das man Pixel aus mehr als einer Tile in der Pipe haben kann.

Wie micki schon sagt weiss man es bei 2.0 Shader eigentlich genau. Er könnte aufgrund eines Pixelkills höchstens kürzer werden aber auch dann weiss man wie lange er mindestens wird. Ähnlich ist es aber auch bei Shadern mit dynamischen Branches. Auch hier kann man eine mindest und maximalanzahl von Anweisungen schon im Vorfeld ermitteln.