CodingCat hat geschrieben:Die Listen sollten eine ziemlich gute lokale Cache-Kohärenz aufweisen, die Schleifenrümpfe haben offensichtlich eine gute lokale Ausführungskohärenz. Auf moderner Hardware könnte das durchaus akzeptable Performance liefern?
Dass das effizient wird, hatte ich mir schon gedacht. Mir ging es eigentlich eher um die einfache Formel „Tile-based-Deferred-Renderer minus G-Buffers = Tile-based-Forward-Renderer“. Die Effizient kommt eher aus dem „tile-based“ und nicht aus dem forward oder deferred Renderer. So wie es sich für mich darstellt, sind das einfach orthogonale Komponenten, die man im beliebigen Kreuzprodukt (tile-based, normal) × (forward Renderer, deferred Renderer) kombinieren kann.
(Es gab ja schon deferred Renderer vor tile-based Verfahren, daher ist es durchaus plausibel, dass ein deferred Renderer nun einmal im Vergleich zu einem forward Renderer etwas bringt.) Ich mache hier sozusagen gerade eine Komplexitätsreduktion meiner Argumentation. ;)
Die Entscheidung tile-based forward Renderer vs. tile-based deferred Renderer ist also die gleiche, wie die Entscheidung, ob man einen forward oder deferred Renderer nehmen soll. Die Diskussion darüber wird seit über fünf Jahren geführt und ist ausgelutscht. (Effiziente Verdeckungsrechnung und komplexes AA und OIT vs. nicht ganz so effiziente Verdeckungsrechnung und straight-forward AA und Transparenz.) Auch das Argument mit den beliebig komplexen Materialien ist ausgelutscht, da muss man sich einfach nur genug fette G-Buffer nehmen, was ich in Zeiten von Graphikkarten mit bald 4 GiB VRAM nicht mehr so kritisch wie früher sehe.
Man muss halt nur das „wir stopfen alle Parameter in eine Textur/Buffer“ und das „wir frickeln uns alle Parameter wieder aus der Textur/Buffer zurück“ automatisieren und mit einer Material-ID verknüpfen, und fertig isses.
