BEARBEITEN: Ich bin immer noch auf der Suche nach Hilfe bei der Verwendung von OpenCL- oder Compute-Shadern. Ich würde es vorziehen, OGL 3.3 weiter zu verwenden und mich nicht mit der schlechten Treiberunterstützung für OGL 4.3 und OpenCL 1.2 zu befassen, aber ich kann mir sowieso nicht vorstellen, diese Art der Schattierung ohne einen der beiden zu machen (um Lichter und Fliesen). Ist es möglich, kachelbasiertes Culling ohne GPGPU zu implementieren?
Ich habe einen verzögerten Render in OpenGL 3.3 geschrieben. Im Moment mache ich keinen Culling für den Lichtdurchgang (ich mache nur einen Vollbildschirm-Quad für jedes Licht). Dies hat (offensichtlich) eine Menge Overdraw. (Manchmal ist es ~ 100%). Aus diesem Grund habe ich nach Möglichkeiten gesucht, die Leistung während des Lichtdurchgangs zu verbessern. Es scheint, als wäre der beste Weg (fast) jedermanns Meinung, die Szene mit Hilfe von Kacheln auf dem Bildschirm auszusortieren. Dies war die Methode, die in Frostbite 2 verwendet wurde. Ich habe die Präsentation von Andrew Lauritzen während der SIGGRAPH 2010 gelesen ( Ссылка ), und ich bin mir nicht sicher, ob ich das Konzept vollständig verstehe. (Und warum ist es besser als alles andere, und wenn es für mich besser ist)
In der Präsentation geht Laurtizen über die verzögerte Schattierung mit Lichtvolumen, Quads und Kacheln hinaus, um die Szene zu cullen. Nach seinen Angaben war der Kachel-basierte Deferred Renderer der schnellste (bei weitem). Ich verstehe nicht, warum es so ist. Ich nehme an, es hat etwas damit zu tun, dass für jedes Plättchen alle Lichter zusammengefügt werden. In der Präsentation heißt es, den G-Buffer einmal zu lesen und dann die Beleuchtung zu berechnen, aber das ergibt für mich keinen Sinn. In meinen Gedanken würde ich das folgendermaßen umsetzen:
%Vor%Dies würde immer noch beinhalten, den G-Buffer viel zu probieren. Ich würde denken, dass dies die gleiche (wenn nicht sogar schlechtere) Leistung hätte, als wenn man für jedes Licht einen Bildschirm mit ausgerichteter Quadrate rendert. Wie es aber aussieht, scheint es so zu sein:
%Vor%Aber ich sehe nicht, wie man das machen würde, ohne das Befehlslimit für den Fragment-Shader auf einigen GPUs zu überschreiten. Kann mir jemand dabei helfen? Es scheint auch so, als ob fast jeder Kachel-basierte Deferred-Renderer Compute-Shader oder OpenCL verwendet (um die Lichter zu chargen), warum ist das so, und wenn ich diese nicht verwenden würde, was würde passieren?
Aber ich sehe nicht, wie man das machen würde, ohne das Befehlslimit für den Fragment-Shader auf einigen GPUs zu überschreiten.
Es hängt eher davon ab, wie viele Lichter Sie haben. Die "Anweisungsgrenzen" sind ziemlich hoch; Es ist im Allgemeinen nicht etwas, um das Sie sich außerhalb von degenerierten Fällen kümmern müssen. Selbst wenn mehr als 100 Lichter eine Kachel beeinflussen, sind die Chancen ziemlich gut, dass Ihre Lichtberechnungen die Anweisungsgrenzen nicht überschreiten werden.
Moderne GL 3.3-Hardware kann mindestens 65536 dynamische Anweisungen in einem Fragment-Shader ausführen und wahrscheinlich mehr. Für 100 Lichter sind das noch 655 Anweisungen pro Licht . Selbst wenn Sie 2000 Anweisungen zur Berechnung der Kameraposition verwenden, bleiben 635 Anweisungen pro Licht. Selbst wenn du Cook-Torrance direkt in der GPU machst, ist das wahrscheinlich immer noch ausreichend.
Tags und Links opengl lighting culling deferred-rendering deferred-shading