Archiv verlassen und diese Seite im Standarddesign anzeigen : Deferred Rendering in Killzone 2
http://www.develop-conference.com/developconference/downloads/vwsection/Deferred%20Rendering%20in%20Killzone.pdf
8,3 MB PDF
deekey777
2007-08-11, 12:52:09
http://www.develop-conference.com/developconference/downloads/vwsection/Deferred%20Rendering%20in%20Killzone.pdf
8,3 MB PDF
Der passende und sehr informative Thread bei B3D: http://forum.beyond3d.com/showthread.php?t=41998 (wobei einige - eigentliche sehr viele - Poster vergessen haben, dass sie sich im Technologiebereich befinden).
Bitte keine Konsolen-Diskussion.
Der passende und sehr informative Thread bei B3D: http://forum.beyond3d.com/showthread.php?t=41998
Interessant, dort gibts das PDF auch als Video:
http://www.n4g.com/ps3/News-58483.aspx
deekey777
2009-01-21, 14:15:11
http://www.gamekings.tv/index/videos/minidocu-the-company-behind-killzone-2-full-version-subbed/
Das Video gewährt einen tiefen Einblick in die Grafik-Engine von KillZone 2. Interessant sind die SPU-Nutzung, die "Zusammensetzung" der einzelnen Abschnitte zur kompletten Szene und vieles mehr. Natürlich gibt es dort sehr viel Blah-Blah (Bloom als Next-Gen-Effekt (was soll das überhaupt heißen?), echtes Motion Blur, acht Lichter als Augen bei den Robots, wo andere Spiele acht Lichter pro Level haben...).
Man kann durch das "Outsourcing" auf die SPUs die Grafikkarte um 20-40% entlasten. Die SPUs übernehmen ua die Partikelsimulation.
Was mich eher stört, ist der Eindruck, dass die Einschusslöcher auf einer Oberfläche gleich aussehen (siehe Vergleich Metall <-> Wand).
Man kann durch das "Outsourcing" auf die SPUs die Grafikkarte um 20-40% entlasten. Die SPUs übernehmen ua die Partikelsimulation.
viel interresanter ist dass sie meist nur zwei SPUs nutzen und das sie die Partikel nicht nur darauf simulieren, sondern auch rendern, was vermutlich super geht, waehrend die RSX gerade die beleuchtung berechnet.
Wo genau liest du das da raus? Das halte ich nämlich für eher unwahrscheinlich, weil gerade dafür ein schneller Zugriff auf den Z-Buffer notwendig und der Shader relativ einfach ist. Das kann die GPU weitaus schneller.
Per-vertex lighting version for particles
Liest sich auch sehr nach GPU für's letztendliche Rendering.
Die SPU wird wohl für's Setup der Geometrie und Culling von zu kleinen Partikeln verwendet.
Abraxus
2009-01-22, 23:38:12
Wo genau liest du das da raus? Das halte ich nämlich für eher unwahrscheinlich, weil gerade dafür ein schneller Zugriff auf den Z-Buffer notwendig und der Shader relativ einfach ist. Das kann die GPU weitaus schneller.
RSX ist schwer Bandbreitenbeschränkt, deswegen macht man ja z.B auch das Postprocessing auf Cell. Dafür hat man ja den G-Buffer zur Hand, welcher auch den Z-Buffer beinhaltet. RSX ist halt keine normale GPU, an der ganzen PS3 ist niks "normales".
RSX ist ein stinknormales Derivat einer GeForce 7. Bandbreite hat sie natürlich wenig das stimmt.
Ich glaube trotzdem nicht daran. Schau mal in das "SPU Architecture" Schaubild. Da ist bei "Prepare Draw" nichts mehr bei den SPUs zu finden.
Um wirklich Performance rauszuholen müsste man ja auch SPU und GPU parallel arbeiten lassen, d.h. man müsste danach auch nochmal die beiden gerenderten Ergebnisse anhand der Z-Werte entsprechend kombinieren.
Aber ich lasse es mal so im Raum stehen. Wenn jemand ne bessere Aussage dazu findet immer her damit.
Abraxus
2009-01-23, 00:06:58
RSX ist ein stinknormales Derivat einer GeForce 7. Bandbreite hat sie natürlich wenig das stimmt.
Ich glaube trotzdem nicht daran. Schau mal in das "SPU Architecture" Schaubild. Da ist bei "Prepare Draw" nichts mehr bei den SPUs zu finden.
Um wirklich Performance rauszuholen müsste man ja auch SPU und GPU parallel arbeiten lassen, d.h. man müsste danach auch nochmal die beiden gerenderten Ergebnisse anhand der Z-Werte entsprechend kombinieren.
Aber ich lasse es mal so im Raum stehen. Wenn jemand ne bessere Aussage dazu findet immer her damit.
RSX hat noch einen Rückkanal zum Cell, der was von "Turbocache" aus der GF7 Serie geerbt hat. Man rendert den kompletten G-buffer direkt in den Speicher von Cell. Ich musste auch selber nochmal din das Paper schauen, aber man sieht gut das die IBL noch vor den Partikeln machen. In das fertige Bild die Partikel reinzuzeichnen sollte nicht das Problem sein, wenn man den G-Buffer noch nicht weggeschmissen hat. Ob man das dann extra nochmal durch RSX nudeln sollte ist fragwürdig, es sind doch nur Partikel.
Okay. Sie machen ja auch den Shading-Pass vom Deferred Rendering auf den SPUs, nicht? Oder hab ich das jetzt schon wieder falsch im Kopf.
deekey777
2009-01-23, 00:31:05
Hier sind die Thread bei B3D:
http://forum.beyond3d.com/showthread.php?t=51783
http://forum.beyond3d.com/showthread.php?p=1245921#post1245921
In dem ersten Thread trieb ein Troll sein Unwesen, so dass einige sehr interessante Postings gelöscht wurden.
Aber auch wenn ich das richtige Posting nicht finde, so gab es eine Aussage, dass der CELL nichts rendert (aber er tut andere coole Sachen).
Hier noch die Stats:
http://forum.beyond3d.com/showpost.php?p=1259455&postcount=77
Kann es sein, dass ihr davon ausgeht, dass das Tech-Doc über G-Buffer-Creation auf dem CELL auch für KZ2 gilt? :|
Abraxus
2009-01-23, 00:31:41
Okay. Sie machen ja auch den Shading-Pass vom Deferred Rendering auf den SPUs, nicht? Oder hab ich das jetzt schon wieder falsch im Kopf.
Die ganze Beleuchtung wird auf Cell gerechnet. Ich denke mal besondere Spezialeffekte (wenn überhaupt eingesetzt) auch. Mit Partikeln und Licht kommt man ja schon ziehmlich weit.
Ich hab mich übrigens oben verschrieben, ich wollte sagen, das der G-Buffer in den Speicher von Cell gerendert wird. Sicherlich wird man dabei interne Caches des RSX und den Speicher von RSX zu Hilfe nehmen. (ähnlich wie bei dem eDRAM von Xenos mittel Kachelung oder weiß der Geier)
Kachelung ist beim erzeugen des G-Buffer schwer machbar bei einem Forward-Rendering-Chip. Wird wohl darauf hinauslaufen, dass sie die Texturen in den VRAM stecken und dann in den XDR vom Cell rendern.
Caches braucht man dafür nicht, man muss nur groß genuge FIFOs haben irgendwo um die Latenz zu verstecken.
Abraxus
2009-01-23, 03:46:49
Kachelung ist beim erzeugen des G-Buffer schwer machbar bei einem Forward-Rendering-Chip. Wird wohl darauf hinauslaufen, dass sie die Texturen in den VRAM stecken und dann in den XDR vom Cell rendern. Wo sollte da das Problem liegen? Bei der X360 macht mand as AFAIK nicht, weil diese durch den eDRAM ein sehr starker Forward-Renderer ist. Duch Hierarchial-Z und den F-Buffer macht es da nicht viel Sinn einen DFR aufzusetzen, aber machbar sollte es sein. Zumal man ja auch das AA des eDRAM verlieren würde.
Caches braucht man dafür nicht, man muss nur groß genuge FIFOs haben irgendwo um die Latenz zu verstecken.Das ist ein besseres Wort für das was ich sagen wollte, ist damit gleich viel verständlicher.
Wo sollte da das Problem liegen?
Glaubst du wirklich sie sortieren die Geometrie nach Kacheln ala Larrabee? Kann ich mir nicht vorstellen.
Wo genau liest du das da raus?
bei 18:33
http://www.play.com/Search.aspx?searchtype=allproducts&searchstring=keyboard&page=search&pa=search&go.x=0&go.y=0
es ist nicht 100% eindeutig, aber es klingt recht wahrscheinlich, da er explizit vom postprocess der particle spricht. (also nicht nur transform&lighting)
Das halte ich nämlich für eher unwahrscheinlich, weil gerade dafür ein schneller Zugriff auf den Z-Buffer notwendig und der Shader relativ einfach ist. Das kann die GPU weitaus schneller.
das ist aber zu kurz gedacht.
1. es bringt dir nichts etwas schnell auf der gpu machen zu koennen waehrend die SPUs nichts tun. er sagt explizit dass 20% bis 40% der arbeit durch die SPUs abgenommen werden, das ist das grosse ziel. ich bezweifle nicht dass die GPU schneller ist, aber ich denke dass sie das bottleneck ist.
2. die shader sind nicht so einfach, frueher vielleicht, heutzutage spart man sich massiven overdraw indem man inteligentere particleshader hat, so kann man mit softparticles mit 1/16 vom overdraw trotzdem noch viel bessere effekte erziellen. dafuer brauchst du als pixelshader-input schon eine tiefentextur. zufaellig haben sie diese auch, den GBuffer.
3. particle zeichnen ist im vergleich zu richtiger geometrie vermutlich sehr effizient auf SPU, du hast normalerweise eh einen buffer aus dem du dann einen vertexbuffer generien musst, damit die interne darstellung (die vielleicht nur mit einem punkt pro particle auskommt) dann auf die 4-vertex darstellung mappt. natuerlich kann das eine SPU machen, aber die koennte auch einfach die particle zeichnen, der localstore der spu ist sehr schnell und befreit den buss fuer aufwendiges deffered shading, wenn man das ganze in tiles zeichnet.
man kann natuerlich darueber streiten, das ist nur meine sichtweise ;)
Um wirklich Performance rauszuholen müsste man ja auch SPU und GPU parallel arbeiten lassen, d.h. man müsste danach auch nochmal die beiden gerenderten Ergebnisse anhand der Z-Werte entsprechend kombinieren.
nein, nicht nur das man das nicht muss, man darf das sogar nicht. schon beim zeichnen der particle musst du die occlusion einrechnen, ansonsten hast du am ende 10 schichten von particle fuer einen pixel, und wie willst du dann das mit dem zbuffer herausfinden welchen farbwert du nehmen musst?
die particle koennen am ende einfach drueber geblendet werden (anhand des alphachannels vom particle-frambuffer).
natuerlich nur _falls_ sie particle wirklich mit gpu rendern.
Glaubst du wirklich sie sortieren die Geometrie nach Kacheln ala Larrabee? Kann ich mir nicht vorstellen.
ich glaube er meint die kachelung die jede GPU macht um ein freundlichereres speicherlayout fuers rasterizing zu haben.
Okay. Sie machen ja auch den Shading-Pass vom Deferred Rendering auf den SPUs, nicht? Oder hab ich das jetzt schon wieder falsch im Kopf.nein, das ganz sicher nicht (ansonsten nehm ich dir gerne den besen ab den du wegen dem larrabe-softwarerasterizer auf der speisekarte hast ;) ), denn ein grund dass deferred lighting so schnell laufen kann sind die occlusion culling techniken der GPUs. das ist aenlich dem shadowvolume rendering/lighting von doom3.
Abraxus
2009-01-23, 11:13:10
Glaubst du wirklich sie sortieren die Geometrie nach Kacheln ala Larrabee? Kann ich mir nicht vorstellen.
Ich dachte eher an was gröberes, damit man weniger VRAM verbraucht, wenn man mit Turbocache in den XDR rendert. Sozusagen den VRAM als schnellen zwischenspeicher nutzen und dabei auch den Speicherverbrauch niedrig. Ist auch nur eine Vermutung, hängt davon ab ob man bei der PS3 sich das mehrfache Setup spaaren kann, indem man intelligent Fragmente rescheduled. Obwohl, es sind letztenendes nur ca. 40MB das kann man sich noch ohne Tiling leisten.
nein, nicht nur das man das nicht muss, man darf das sogar nicht. schon beim zeichnen der particle musst du die occlusion einrechnen, ansonsten hast du am ende 10 schichten von particle fuer einen pixel, und wie willst du dann das mit dem zbuffer herausfinden welchen farbwert du nehmen musst?
die particle koennen am ende einfach drueber geblendet werden (anhand des alphachannels vom particle-frambuffer).
natuerlich nur _falls_ sie particle wirklich mit gpu rendern.
Die Partikel musst du doch eh vorsortieren da bringt dir Occlusion Culling nichts. Den Zbuffer braucht man damit man schöne Kanten der Partikel mit der Umwelt hat, sonst sieht das echt hässlich aus.
nein, das ganz sicher nicht (ansonsten nehm ich dir gerne den besen ab den du wegen dem larrabe-softwarerasterizer auf der speisekarte hast ;) ), denn ein grund dass deferred lighting so schnell laufen kann sind die occlusion culling techniken der GPUs. das ist aenlich dem shadowvolume rendering/lighting von doom3.
Ein DFR braucht kein OcclusionCulling im Shading Pass, da er eh nur ein Fullscene Quad zeichnet. Das hat nichts mit lay Z first zu tun.
Die Partikel musst du doch eh vorsortieren da bringt dir Occlusion Culling nichts. Den Zbuffer braucht man damit man schöne Kanten der Partikel mit der Umwelt hat, sonst sieht das echt hässlich aus.nein, die sortierung der particle hat nichts mit dem zbuffer zu tun, das ist absolut unabhaengig von spu/gpu gebrauch.
kanten sind nicht schoen! deswegen gibt es ja soft-particles, diese versuchen kanten zu vermeiden indem sie blenden. deswegen brauchst du einen 'depth' buffer, wenn dieser konservativ runterskaliert ist, ist die sache nicht nur schneller, sondern liefert nochmals weichere uebergaenge zwischen particle und umgebung. genau das moechte man.
harte kanten hatte man frueher immer, das ist unschoen.
Ein DFR braucht kein OcclusionCulling im Shading Pass, da er eh nur ein Fullscene Quad zeichnet. Das hat nichts mit lay Z first zu tun.fullscreenquad ist wie man es den leuten erzaehlt, damit sie verstehen wie die sache an sich geht.
in wirklichkeit braucht es sehr sehr viele optimierungen. du kannst keine 200fullscreenpases zeichnen. wenn du 200 lichtquellen hast, und 100 davon werden von geometry verdeckt, kann die hardware den pixelshader dafuer ueberspringen -> halb soviel zeitaufwand, oder anders, du kannst statt 100 nun 200 lichtquellen nutzen, weil sie von der hardware verworfen werden wenn man sie nicht sieht.
mit ein paar tricks kann man nicht nur hinter geometrie liegende lichtquellen von der hardware rejecten lassen, auch die lichtquellen die so davor liegen, dass sie keine geometry beleuchten.
in einer simplen scene mit 20lichtquellen hab ich so 6mal schnellereres shading erhalten.
ich meine natuerlich keine kompletten lichtquellen als logisches objekt, sondern die fragmentprogramms die abgearbeitet werden muessen um deren beleuchtung auf die scene einzufuegen.
die nvidia hardware hat viele optimierungen die darauf abzielen arbeit zu sparen, deferred shading ist nur deswegen moeglich.
dildo4u
2009-02-04, 20:22:49
Gehört zwar nicht direkt zu KZ2 aber hier ein sher interresantes pdf zur Nutzung der SPUs.Vieles davon kommt whol auch bei KZ2 zum Einsatz.
Ab Seite 25.
http://s08.idav.ucdavis.edu/olick-current-and-next-generation-parallelism-in-games.pdf
deekey777
2009-04-01, 22:24:57
http://cmpmedia.vo.llnwd.net/o1/vault/gdc09/slides/GDC2009-vdLeeuw-KZ2SPUsCaseStudy.pdf
Wenn es Probleme mit dem Download gibt, mehrmals versuchen. Ist die Präsentation von der GDC 09.
dildo4u
2009-08-01, 17:54:44
Bezieht sich nicht direkt auf KZ2 aber u.A auf Deferred Rendering und SPU Nutzung auf der PS3.Sher interresante Präsentation was man noch alles auf die SPUs auslagern kann.
PhyreEngine Präsentaion
http://www.technology.scee.net/files/presentations/gdc2009/DeferredLightingandPostProcessingonPS3.ppt
deekey777
2009-08-02, 15:06:46
Die eigentliche Frage ist, ob klassisches Deferred Rendering nicht eine Sackgasse auf Konsolen ist.
deekey777
2010-08-27, 23:26:07
Wie kommst du darauf?
Ich frage mich gerade, warum GG sich gerade für volles DR entschieden hat und nicht wie Naughty Dog oder Crytek für LIDR oder so was in der Art.
So ein fetter G-Buffer verbraucht nicht nur viel V-RAM, er kostet auch reichlich Füllrate.
Im Gegentum. Auf aktuellen "Next-Gen"-Konsolen musst du die GPU schonen wo du kannst. Zusätzlich hast du ein 30-Fps-Ziel. DR hat zwar hohe Einstiegskosten (die du für den Weg in die Sackgasse hältst), sind diese aber einmal einkalkuliert, kosten zusätzliche Effekte, Lichtquellen, Geometrie und sogar Aliasing-Bekämpfung (ich schreibe bewusst nicht "Anti-Aliasing") vergleichsweise wenig.
Sprich, für optisch opulente Titel dürfte gerade DR das Mittel der Wahl sein, während ein Q3-Klon mit 500 Fps damit kaum zu erreichen sein sollte (wg. der Einstiegskosten, auf dem PC sieht das anders aus).
Aber das weisst du sicher alles auch.
-carsten
deekey777
2010-08-28, 10:21:27
Auf den Konsolen gibt es zwei Titel, die volles Deferred Rendering nutzen, wenn ich mich nicht irre. Einmal ist es KZ2 und dann Trials HD, die anderen wie Uncharted 1&2, Crysis 2 nutzen abgespeckte Variationen (abgespeckt in dem Sinn, dass im G-Buffer deutlich weniger Information gespeichert wird) und sind trotzdem gut dabei.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.