DGL https://delphigl.com/forum/ |
|
Rechnenaufwand für Per-Pixel-Beleuchtung https://delphigl.com/forum/viewtopic.php?f=20&t=9448 |
Seite 1 von 1 |
Autor: | simon1988 [ Di Sep 07, 2010 12:16 ] |
Betreff des Beitrags: | Rechnenaufwand für Per-Pixel-Beleuchtung |
Ich habe mich etwas mit Shader beschäftigt und muss sagen, dass sie mir besser gefallen, als die normale Renderpipline. Endlich versteht man den Ablauf. Eine kleine Frage hätte ich allerdings noch, um den genauen Ablauf zu verstehen. Wo genau setzt der Fragmentshader ein? Mir gehts darum, den Rechenaufwand besser abschätzen zu können. Angenommen wir haben eine Per-Pixel-Beleuchtung mit einer bestimmten Anzahl n von Lichtern. Wie hoch ist nun der Rechnenaufwand. Wird die Berechnung zur Beleuchtung nur auf die "zu sehenenden" 1280x800 Pixel (das ist halt meine Auslösung ![]() Wenn es denn so wäre, hätte ich groß einen Rechenaufwand von 1280x800xn. Ich hoffe diese Anfängerfrage ist nicht all zu dämlich ![]() |
Autor: | Coolcat [ Di Sep 07, 2010 12:29 ] |
Betreff des Beitrags: | Re: Rechnenaufwand für Per-Pixel-Beleuchtung |
Die Frage ist gar nicht dämlich. Bei älteren Grafikkarten wird der Fragmentshader immer ausgeführt. Bei neueren Karten hat man "Early-Z" eingeführt, d.h. den Z-Test vor den Fragmentshader geschoben. Das funktioniert aber z.B. nicht wenn man schreibend auf gl_FragDepth zugreift, also der Shader die Tiefe nicht verändert. Hier sind auch noch diverse andere Gründe aufgelistet die Early-Z verhindern: http://www.gpgpu.org/w/index.php/Code_Examples#Early-z Der Stencil-Test scheint dagegen immer noch nach dem Fragmentshader in der Pipeline zu liegen. Hier die Shader-Pipeline aus dem Wiki: ![]() |
Autor: | simon1988 [ Di Sep 07, 2010 13:06 ] |
Betreff des Beitrags: | Re: Rechnenaufwand für Per-Pixel-Beleuchtung |
Zitat: Das funktioniert aber z.B. nicht wenn man schreibend auf gl_FragDepth zugreift, also der Shader die Tiefe nicht verändert. Das verstehe ich nicht so ganz genau. Logisch für mich wäre, wenn ich auf gl_FragDepth zugreife, also im (Fragment)Shader den Tiefenbuffer veränder, setze ich den Ealy-Z außer Kraft?! Muss ich irgendwas beachten, also den Early-Z extra einschalten? |
Autor: | Coolcat [ Di Sep 07, 2010 13:23 ] |
Betreff des Beitrags: | Re: Rechnenaufwand für Per-Pixel-Beleuchtung |
Ich schreib den Satz nochmal neu: "Early-Z funktioniert unter anderem nicht wenn man schreibend auf gl_FragDepth zugreift." Zitat: Logisch für mich wäre, ... Genauso ist es ja auch ![]() Zitat: Muss ich irgendwas beachten, also den Early-Z extra einschalten? Nein, das macht die Grafikkarte selbst. Es gibt auch keine sinnvolle Möglichkeit festzustellen ob die Karte Early-Z unterstützt. Bei neuen Karten kannst du aber davon ausgehen. |
Autor: | simon1988 [ Di Sep 07, 2010 13:34 ] |
Betreff des Beitrags: | Re: Rechnenaufwand für Per-Pixel-Beleuchtung |
Ich hab ne Geforce 7600 Go. Müsste es hoffentlich untersützen. Der GeoShader ist leider nicht dabei ![]() Fazit: Meine Lichtberechnung wird tatsächlich (solange der Early-Z aktiv ist) "nur" auf meine 1280x800 Pixel angewendet. So müsste es dann stimmen? Eine Frage noch: Ich werde mich demnächst mit einem Schattenshader (Shadowmapping) beschäftigen. Hab bisher nur über die grobe Funktionsweise geschaut. Gibt es dort iwelche Operationen, die den Early-Z auschalten? Das alleinige Auslesen der Tiefe sollte dies nicht tun, oder ? |
Autor: | mrtrain [ Di Sep 07, 2010 13:49 ] |
Betreff des Beitrags: | Re: Rechnenaufwand für Per-Pixel-Beleuchtung |
simon1988 hat geschrieben: Meine Lichtberechnung wird tatsächlich (solange der Early-Z aktiv ist) "nur" auf meine 1280x800 Pixel angewendet. Wobei sie immer noch für jeden Pixel auf deinem Bildschirm mehrfach aufgerufen werden kann. Nämlich dann, wenn du zwei Objekte zeichnest, die übereinander liegen und das, was weiter hinten ist, zuerst gezeichnet wird. Deshalb kann es sinnvoll sein, die Objekte vor dem Rendern grob nach Entfernung zu sortieren oder einen extra Z-Prepass zu machen.simon1988 hat geschrieben: Gibt es dort iwelche Operationen, die den Early-Z auschalten? Das alleinige Auslesen der Tiefe sollte dies nicht tun, oder ? Es gibt eigentlich keinen Grund, warum der Treiber Early-Z beim Auslesen verhindern sollte.
|
Autor: | sharkman [ Di Sep 07, 2010 14:57 ] |
Betreff des Beitrags: | Re: Rechnenaufwand für Per-Pixel-Beleuchtung |
Zitat: oder einen extra Z-Prepass zu machen. Ist es dann nicht schon eher sinnvoll, gleich deferred shading zu benutzen? Getestet hab ichs zwar nicht, aber ich könnt mir vorstellen, dass das dann wieder schneller ist, weil man da kleinere Lichter nicht über den ganzen Bildschirm ziehen muss. Außerdem, zumindest ich konnte bezüglich Geschwindigkeit keinen Unterschied zwischen Per Vertex und per Pixel Beleuchtung bemerken. Und das obwohl sich meine Szenen im allgemeinen auf ne große DisplayList beschränken, also eher nicht bandbreitenlimitiert sind (und auch deutlich weniger Vertices als Pixeln haben). |
Autor: | Coolcat [ Di Sep 07, 2010 15:38 ] |
Betreff des Beitrags: | Re: Rechnenaufwand für Per-Pixel-Beleuchtung |
Zitat: Und das obwohl sich meine Szenen im allgemeinen auf ne große DisplayList beschränken, also eher nicht bandbreitenlimitiert sind (und auch deutlich weniger Vertices als Pixeln haben). Ich vermute du spielst hier auf die Bandbreite zwischen Hauptspeicher und Grafikspeicher an. Wahrscheinlich liegt bei dir aber wohl eine Bandbreitenlimitierung vor: Innerhalb der Grafikkarte! Insbesondere Texturen aber auch Vertexdaten liegen im Speicher der Grafikkarte und müssen Stückenweise in den Cache der GPU geladen werden. Da hilft auch die Displayliste nicht. In jedem Fall ist die (lokale) Lichtberechnung heute so schnell, dass du das quasi nicht bemerken wirst. Die anderen Faktoren (eben die Daten überhaupt erstmal in die GPU zubekommen) sind da weitaus ausschlaggebender. Einen Unterschied wirst du wohl erst bei richtig vielen Lichtquellen (100+) bemerken, wo dann auch Deferred Shading oder Inferred Lighting zu empfehlen sind. |
Seite 1 von 1 | Alle Zeiten sind UTC + 1 Stunde |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |