Bandbreiten Verhältniss Polygone zu PS Operationen

[egdusp]

Wenn ich mich an einen alten Thread richtig erinnere, hat Demirug ja angeführt, dass bei Deffered Renderern unter DX>9 der Bandbreitenbedarf für die Polygonlist stärker ansteigt, als der Bandbreitenbedarf für die PS (allgemein Pixelrezeugung).

Bei DX9 Spielen wird aber durch die Fließkommafarbformate und durch die Pixelshaderoperationen jedes unnötig gezeichnete Pixel immer teurer, sowohl bei Bandbreite wie auch bei Rechenpower. Die Polygonanzahl dürfte hingegen eher stagnieren, da dadurch kaum noch optische Fortschritte zu erzielen sind IMHO. Bzw. die Polygone werden dynamisch für die jeweilige Szene von den VS berrechnet und fallen deswegen insgesamt weniger ins Gewicht, als wenn sie statisch vorgegeben wären (aus Sicht des Bandbreitenbedarfs bei DR).

mfg
egdusp

P.s.: Ich hoffe er logt mich jetzt ein.

[Demirug]

Ich liebe es aus dem Kontext zititert zu werden ;)

Der Vergleich den ich damals angestellt habe ging von einem Beispiel mit Z-Buffer First renderen aus. In diesem Fall kann ein DR gegenüber einem IMR kein Byte Texturebandbreite gut machen. Alles was man nun noch vergleichen kann ist folgendes.

IMR: Die Bandbreite für das Lesen und schreiben des Z-Buffers wärend des Z-Pass. Die Bandbreite für das Lesen des Z-Buffers bei den restlichen Passes. Geschrieben werden muss ja dann nicht mehr.

DR: Die Bandbreite für das Speichern der Displayliste und dann nocheinmal die Bandbreite um das ganze wieder einzuladen.

Von was hängen diese Bandbreiten nun ab.

IMR: Eine wesentliche Kenngrösse ist hier die Auflösung und das benutzte AA. Je grösser die Auflösung (und/oder ein mehr an AA-Sample)desto mehr Z-Werte müssen geladen und gespeichert werden. Die Polygonen Anzahl ist dabei in erster Näherung erst einmal egal da bei einem mehr an Dreiecken diese ja in der Regel kleiner werden. An mehr an Dreiecken geht aber auch nicht ganz Spurloss an einem IMR vorbei. Da ja heute auf Z-Kompression zur reduktion der Bandbreite gesetzt wird muss man hier auch sagen das sich ein mehr an Polys negativ auf die Komprimierbarkeit auswirken kann. Ein guter Chip kann sich beim Z-Pass noch eines zusätzlichen Tricks zum einsparen von Bandbreite bediehnen. Da man wärend des Z-Pass ja keine Texturen braucht kann man den Speicher den man normalerweise als Texturecache benutzt vollständing als Z-Buffer Cache benutzten. Bei 64K gehen da unkomprimiert 128*128 AA-Sampels rein. komprimiert noch mehr. Damit sind auch noch ein paar gute Bytes gut zu machen.

DR: Wie gesagt verbracht man hier Bandbreite für die Displayliste. Diese besteht zum grössten Teil aus den Vertexdaten für die Polygone. Allerdings nicht mehr zwangsläufig in der Form von diskreten Verticen. Je mehr Details man nun benutzt desto länger wird die Displayliste. Zudem machen nicht nur mehr Polys die Liste länger sondern auch komplexere Polys. Für aufwendige Pixelshader werden auch durchaus mehr Daten pro Vertex berechnet und in die Pixelshader übergeben. Diese Daten gehen bei einem DR ja auch den Umweg über den Speicher und müssen deshalb erst einmal gespeichert werden.

Was lernen wir nun daraus? Der Bandbreitenbedarf bei einem IMR und einem DR in verbindung mit einem Z-Pass First renderer ensteht aus unterschiedlichen Gründen. Beim IMR ist es die Auflösung die Schmerzhaft ist beim DR ist es die Anzahl der Polys die weh tut. Die Auflösung hat aber dann aber beim PS in etwa die gleiche Auswirkung. Ergo wenn die Bandbreite eng wird Auflösung runter und bei einem DR kann auch die Reduktion der Details noch etwas bringen beim IMR dagegen kaum.

[egdusp]

Original geschrieben von Demirug
Ich liebe es aus dem Kontext zititert zu werden ;)


Sorry, man wird alt und das Gedächtnis löchrig :)

Original geschrieben von Demirug
Was lernen wir nun daraus? Der Bandbreitenbedarf bei einem IMR und einem DR in verbindung mit einem Z-Pass First renderer ensteht aus unterschiedlichen Gründen. Beim IMR ist es die Auflösung die Schmerzhaft ist beim DR ist es die Anzahl der Polys die weh tut. Die Auflösung hat aber dann aber beim PS in etwa die gleiche Auswirkung. Ergo wenn die Bandbreite eng wird Auflösung runter und bei einem DR kann auch die Reduktion der Details noch etwas bringen beim IMR dagegen kaum.

Ich versuche mal deinen Text in für mich relevante Aussagen zu interpretieren (mit sehr vielen Mutmaßungen meinerseits).
1. Ein Z-First-Pass Renderer ist unter zukünftigen realistischen Bedingungen (overdraw >1, hohe Farbtiefen, viel PS) auf jeden Fall besser als ein herkömmlicher IMR.
2. Ein Z-First-Pass Renderer ist sowhl rein softwaremäßig (Doom3) als auch Hardware/Treibermäßig zu realisieren (angeblich S3 Deltachrome)
3. Die Umstellung auf einen Z-First-Pass Renderer von einem IMR ist relativ einfach.
4. Muss bei einem Z-First-Pass Renderer die gesamte Geometrie doppelt berechnet werden? Einmal für den Z-Pass und dann für die Pixel.
5. Gibt es solch eine Technik schon in Hardware? (Slistream?)
6. Wäre eine solche Technik mit einem sehr felxiblen Design (PS3.0, P10) treibermäßig in Hardware möglich, ohne das der Geschwindigkeitsvorteil verloren geht.

mfg
egdusp

[Demirug]

Original geschrieben von egdusp
Sorry, man wird alt und das Gedächtnis löchrig :)

Macht ja nicht wirklich was aus.



Ich versuche mal deinen Text in für mich relevante Aussagen zu interpretieren (mit sehr vielen Mutmaßungen meinerseits).
1. Ein Z-First-Pass Renderer ist unter zukünftigen realistischen Bedingungen (overdraw >1, hohe Farbtiefen, viel PS) auf jeden Fall besser als ein herkömmlicher IMR.

Ja je teuer das erzeugen eines Pixels wird und je mehr Pixel unnötig erzeugt werden desto effektiver wird ein Z-First Pass Renderer.

2. Ein Z-First-Pass Renderer ist sowhl rein softwaremäßig (Doom3) als auch Hardware/Treibermäßig zu realisieren (angeblich S3 Deltachrome)

Ja wobei das Softwareverfahren natürlich mit jedem Chip funktioniert.

3. Die Umstellung auf einen Z-First-Pass Renderer von einem IMR ist relativ einfach.

Ja weil im Zweifelsfall rein Softwaremässig lössbar.

4. Muss bei einem Z-First-Pass Renderer die gesamte Geometrie doppelt berechnet werden? Einmal für den Z-Pass und dann für die Pixel.

Im Prinzip ja. Wobei die Geometrieberechnung für den Z-Pass sich ja auf die reine Positionsbestimmung begrenzt. Alles was mit dem Shading zu tun hat muss nur beim 2 Pass gerendert werden. Es gibt dabei noch eine machbare Erweiterung des Z-Pass Verfahren welche wärend des Z-Pass informationen gewinnt welche dann dazu benutzt werden können im zweiten Pass komplette Objekte oder auch Teile davon nicht nochmal zu rendern. Dafür ist aber Hardwareunterstüzung notwendig. Eine andere mögliche Erweiterung würde darin bestehen die einmal berechneten Korrdinaten für den zweiten Pass zwiwschen zu speichern. Aber auch hier gilt das dafür Hardwaresupport nötig ist.

5. Gibt es solch eine Technik schon in Hardware? (Slistream?)

Ich bin mir nicht sicher was Slipstream wirklich tut aber ein reines Z-Pass First Verfahren scheint das nicht zu sein.

6. Wäre eine solche Technik mit einem sehr felxiblen Design (PS3.0, P10) treibermäßig in Hardware möglich, ohne das der Geschwindigkeitsvorteil verloren geht.

mfg
egdusp

Das Verfahren betrifft ja den ganzen Chip und beim Z-Pass werden die Pixelshader ja überhaupt nicht gebraucht da letzten Endes ja nur der Z-Buffer verändert wird.

[Haarmann]

Demirug

Wenn man erst alles nach Z aussortiert, wo ist dann der IMR geblieben?

[Demirug]

Man sortiert beim Z-Pass Verfahren ja nicht wirklich nach Z. Man rendert dabei ja zuerst einmal nur den Z-Buffer und benutzt diesen dann für die weiteren Passes zum Gegentesten. Jeder Pixel der dabei den Z-test nicht übersteht muss nicht in den Pixelshader. Dass ganze läuft primär immer noch nach dem IMR Verfahren ab. Sobald man aber änfängt das ganze über den Treiber/Hardware direkt zu realisieren kommt man schon in den Bereich DR. Die Grenze ist da aber durchaus fliesend.

[Haarmann]

Demirug

Das wollte ich damit eigentlich ausdrücken. Offenbar hab ichs ned ideal ausgedrückt.
Siehst Du dafür ne Zukunft oder ist es die Zukunft?

[Demirug]

Original geschrieben von Haarmann
Demirug

Das wollte ich damit eigentlich ausdrücken. Offenbar hab ichs ned ideal ausgedrückt.
Siehst Du dafür ne Zukunft oder ist es die Zukunft?

Das First-Z Pass Verfahren (in Software) wird ja schon länger von nVidia und auch von ATI gepredigt. Die Entwicklung wird also dahin gehen das man die IMRs so erweitert das sie von diesem Verfahren mehr nutzen ziehen können. Die Ansätze dazu sind ja schon erkennbar. Early-Z, Hir-Z, Die zusätzlichen Z-Only Pixel Technik bei nV, ...

Reine Hardware/Treiber implementierungen sind sicherlich möglich aber da besteht dann einfach die Gefahr das zuviel unnötig gemacht wird. Eine Engine kann das alles viel besser steuern da sie ja den grösseren Überblick hat.

[egdusp]

Original geschrieben von Demirug
Reine Hardware/Treiber implementierungen sind sicherlich möglich aber da besteht dann einfach die Gefahr das zuviel unnötig gemacht wird. Eine Engine kann das alles viel besser steuern da sie ja den grösseren Überblick hat.

Hat nicht John Carmack das Verfahren erfunden?
Ist es sehr kompliziert ein solches Verfahren einzubauen? Bzw. bringt es den Spieleentwicklern genug Mehrnutzen, wenn ihre Spiele nicht durch die Fillrate limitiert sind. Es gibt im Moment ja einige CPU limitierte Spiele. Ich kann mir durchaus vorstellen, dass solche Entwickler keine Notwendigkeit für so etwas sehen.
Ebenfalls vorstellbar wäre, dass alte Karten < GF nicht mit der Technik zurechtkommen, aber noch unterstützt werden müssen (Publisherdruck). Man könnte dann zwar auch eine Z-First Option einbauen, aber wenn ein Spiel auf ner TNT2 laufen muss, dann wird es sicher nicht so aufwändige Effekte haben, dass es eine aktuelle Karte nicht im Raw Modus locker bewältigen können wird.

mfg
egdusp

[Demirug]

Original geschrieben von egdusp
Hat nicht John Carmack das Verfahren erfunden?

Nicht wirklich. Das Verfahren ist schon sehr alt es wurde sogar schon bei Software renderen eingesetzt.

Ist es sehr kompliziert ein solches Verfahren einzubauen? Bzw. bringt es den Spieleentwicklern genug Mehrnutzen, wenn ihre Spiele nicht durch die Fillrate limitiert sind. Es gibt im Moment ja einige CPU limitierte Spiele. Ich kann mir durchaus vorstellen, dass solche Entwickler keine Notwendigkeit für so etwas sehen.

Eigentlich ist es ganz einfach einzubauen.

Wenn man CPU-limitiert ist sollte man das auch besser bleiben lassen weil es die Sache eher noch schlimmer macht. Z-Pass ist dann das richtige Verfahren wenn man einem die Pixelshaderpower ausgeht bzw die Texelfillrate am ende ist. Deswegen sagte ich ja auch das ich es bevorzugen würde wenn die Engines entscheiden ob sie es benutzen wollen oder nicht aber falls sie es benutzen sollten sie dabei von der Hardware unterstützt werden.

Ebenfalls vorstellbar wäre, dass alte Karten < GF nicht mit der Technik zurechtkommen, aber noch unterstützt werden müssen (Publisherdruck). Man könnte dann zwar auch eine Z-First Option einbauen, aber wenn ein Spiel auf ner TNT2 laufen muss, dann wird es sicher nicht so aufwändige Effekte haben, dass es eine aktuelle Karte nicht im Raw Modus locker bewältigen können wird.

mfg
egdusp

Kompatibilitätsprobleme gibt es da keine. Da aber die alten Karten ja nicht unbedingt die Helden was Early-Z angeht sind bringt es dort nur sehr wenig. In diesem Fall kann man aber in der Regel dann auch den Early-Z Pass einfach abschalten und bei den folgenden Passes den Z-Write wieder anschalten. Ausnahme: Man braucht den Z-Pass wie zum Beispiel DOOM III für Schatten oder ähnliches.