Deferred- vs Forward-Rendering

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Antworten
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Deferred- vs Forward-Rendering

Beitrag von Zudomon »

Momentan überlege ich, ob es nicht doch sinnvoller ist, das Rendering wieder auf Forward umzustellen.

Die Vorteile, die Deferred für mich hatte, waren eigentlich gar nicht mal die Nutzung von Licht, sondern eher die ganzen möglichen Post Effekte. Allerdings ist mir das nicht verwenden können von Alphablending immer noch ein Dorn im Auge, wenn auch erstmal kein großer! :D

Was mich nun zu der Überlegung bringt, wie der Forward zu gehen ist der mit der Zeit explodiert.
War es für mich damals noch AlbedoRGB | Tiefe | Normalen... später noch Specular und Reflektion... sieht das heute so aus:
Benötigt fürs PBR (ohne besondere Packoptimierungen):
AlbedoRGB | Tiefe | Normale | Metalness | Reflektion | Roughness | SSS-Wert
damit sind schon gut 3 Rendertargets zugekleistert... aber eigentlich brauch ich mehr!
Wenn man z.B. Nässe auf Pflanzen anbringt, dann braucht man die Position des Pixels vor der Bewegung. Da man hier letztlich vom Pixel aus nicht durch Tiefe allein auf die andere räumliche Position schließen kann, bräuchte man eigentlich noch Position, also 3 Werte. Hatte damals getrickst, indem ich die Nässe nochmal als Parameter in den G-Buffer gesteckt habe. Vielleicht könnte man das beim PBR auch über die Albedo + Reflektion + Roughness direkt lösen. Aber noch ein Problem, was ich habe, sind die Rückseiten von z.B. Blätter. Denn das Licht wird ja nicht nur zum Teil durchgelassen, sondern durch das innere Scattering verändert sich auch die Farbe. Also statt einein einfachen SSS-Wert wäre vielleicht eine SSS-RGB-Textur besser, die angibt, wie das Licht verfärbt wird.

Die Überlegung ist einfach, ob es nicht sinnvoller ist, statt den G-Buffer massiv voll zu hauen, einfach Forward zu rendern, da man dort ja alle Werte parat hat. Selbst Licht sollte doch gar nicht das große Problem sein, denn man rendert doch sowieso kleine einzelne Objekte, bei denen man immer direkt sagen kann, welche Lichter aktiv sind. Zur Not noch Indexed Lighting, aber ich sehe beim Licht wirklich kein Problem, zumal ich das vielleicht für Fackeln etc an den Wänden sogar statisch umsetzen möchte.
Ich würde also vielleicht das Resultat des Forward Renderings in eine Textur speichern, und die Normale und Depth, damit ich weiterhin SSDO machen kann, vielleicht sogar SSR.

Okay, was meint ihr? :D
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Krishty »

Bauen und Benchen … und wäre der Umstieg auf D3D 11 vielleicht effektiver (Alpha ohne Sortierung und so)? ;)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Schrompf »

Lichtquellen *sind* ein Problem für Forward Rendering. Ich glaube, wenn Du jetzt aus der Position gelöster Probleme auf Forward wechselst, machst Du dabei langfristig eher miese. Irgendwann wirst Du wieder Scheinwerfer aufstellen oder Feuerbälle schmeißen wollen. Und dann brauchst Du für Forward ein cleveres Beleuchtungssystem, denn simples Multipass-Rendering "für den Anfang" wird bei Deinen Polycounts tödlich.

Dein "Nass"-Problem klingt allerdings, als müsstest Du nur beim GBuffer-Pass die Nässe noch im VertexShader samplen und anhand davon dann Albedo, Roughness und Reflection abändern. Dann kann der Deferred Pass einfach beleuchten, wie er es gewohnt ist. Transparenz kriegst Du damit natürlich nicht in den Griff. Heutige Engines sind deswegen immer Mischwesen, auch wenn du mit Tiled Forward Rendering evtl. schon sehr weit kommen kannst.

Oder Du erfindest was komplett anderes. Ich render jetzt z.B. im Voxel Space. Andere Leute haben eine Volumentextur im Camera Space aufgemacht und darin dann im Volumen Raycasting betrieben, wie ich das bei Splatter in 2D gemacht habe.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Zudomon »

Das sind schon gute Denkansätze... ich hoffe aber, dass hier noch mehr einfach schreiben... ich versuche irgendwie auf neue Ideen zu kommen.

Ich hab mal so mehr oder weniger auf Forward umgebaut. Aber schneller ist es nicht unbedingt geworden, eher ein klein wenig langsamer. Aber bisher ist auch nur eine Lichtquelle im Spiel. Hatte ich schon gesagt, dass ich eventuell zum größten Teil statisches Licht verwenden möchte? Also der Lichtaspekt, um den es hauptsächlich geht, ist erstmal irrelevant... bisher ist die Lichtberechnung auch noch ziemlich Rechenlastung durch das neue Modell, da hab ich einfach erstmal reingekloppt, damit es einigermaßen richtig aussieht, aber nichts optimiert.

Im Moment Render ich also Forward schon grob von Vorn nach Hinten sortiert. Ausgegen werden zwei Float16 Texturen... einmal mit dem Bild im linear Space und einmal Entfernung + Normale, damit ich noch SSAO und Nebel machen kann. Ich möchte letztendlich alles im Single Pass belassen. Wobei ich allerdings überlege, einen Prepass für die Normalen+Depth zu machen, damit man auch schonmal beim zweiten Rendering nur die Pixel beleuchtet, die sichtbar sind. War doch richtig, dass der Pixelshader nur für die Pixel ausgeführt wird, die den Z-Test bestehen, oder? Allerdings, wie ist das, wenn da noch Alpha-Test mit ins Spiel kommt über die clip() Funktion im Pixelshader?

Naja, also wie auch immer, schreibt einfach, was euch so einfällt zu dem Thema! :D
Benutzeravatar
B.G.Michi
Establishment
Beiträge: 163
Registriert: 07.03.2006, 20:38
Alter Benutzername: B.G.Michi
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von B.G.Michi »

Solange du im Pixelshader nicht nach SV_Depth schreibst, wird die Hardware early-z-testing verwenden und somit den Pixelshader abhängig vom Ergebnis ausführen oder nicht. Verwendest du alphatesting im Pixelshader verlierst du allerdings early-z-writing. Wenn du es genauer wissen willst, lies dir das hier mal durch. Ist zwar nach DirectX 11 gefragt und ich weiß nicht was du verwendest, aber ich denke nicht, dass es in den verschiedenen APIs hier große Unterschiede gibt, schließlich versuchen die Hersteller das Maximum an FPS aus der verfügbaren Rechenleistung herauszuholen.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Zudomon »

Okay, habs mir mal durchgelesen. Also ich wusste gar nicht, dass es einen early-z-test UND early-z-write gibt.
Wichtig ist eigentlich nur, dass der Pixel das Licht nicht berechnet wenn es eh verdeckt wird. Ich habe das jetzt so verstanden, dass ich also ungehemt Alphatesting nutzen kann, dadurch wird eben nur das early-z-write verhindert, was auch immer das für einen unterschied macht.
Benutzeravatar
B.G.Michi
Establishment
Beiträge: 163
Registriert: 07.03.2006, 20:38
Alter Benutzername: B.G.Michi
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von B.G.Michi »

So hab ich das auch verstanden. Wenn du es genau wissen willst Bau doch einfach mal ein clip(1) ein (etwas umschreiben, damit es nicht wegoptimiert wird) und schau ob es einen Unterschied macht. Ich tippe mal ins Blaue auf mehr oder weniger vernachlässigbar. Außerdem: wenn du alphatesting oder alpha-to-coverage verwendet, dann ja wohl um ein bestimmtes Ergebnis auf den Bildschirm zu zaubern und das kostet dann hald mit Recht etwas an Rechenleistung.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Zudomon »

Schrompf hat geschrieben:Oder Du erfindest was komplett anderes. Ich render jetzt z.B. im Voxel Space. Andere Leute haben eine Volumentextur im Camera Space aufgemacht und darin dann im Volumen Raycasting betrieben, wie ich das bei Splatter in 2D gemacht habe.
Was meinst du eigentlich damit genau, im Voxelspace rendern? Ist Voxelspace das gleiche wie Worldspace? Und ist Raytracing auch Worldspace rendering?
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Schrompf »

Raytracing kannst Du im World Space oder im View Space oder auch im Model Space machen - die Voraussetzung ist halt ein linearer (optional orthonormierter) Raum. Es gibt online uuuunglaublich viele Papers und Präsentationen dazu. Ich erinnere mich an ein Spiel, was den View Space in Voxel unterteilt hat, aber nicht in ein orthonormiertes Raster, sondern in ein perspektivisches Raster, also orthonormiert im Projection Space. Der Doom-Renderer, von dem Du gesprochen hast, benutzt für den Tiled Forward Renderer auch solche Tiles im Projected Space.

Mein VoxelRenderer macht sich zunutze, dass ich eh nur Voxel als einfarbige Blobs rendere. Sprich: alles Shading, was passiert, passiert genau einmal pro Voxel. Ich mache mir das zu nutze, indem ich alle Voxel auf einer großen Textur verteile. So kann ich im Shader dann einen "Deferred" Renderer auf die Voxel loslassen, bei der jeder Pixel einem Voxel entspricht und alle Beleuchtung nur genau einmal pro Voxel gemacht wird. Wenn ich dann indirekte Beleuchtung und sowas machen will, muss ich die Voxel dann doch noch in ein reguläres Volumen abbilden. In dem kann ich dann wieder Raytracen.

Bevor Du jetzt irgendwelche Änderungen am Renderer ausprobierst, wäre es aber spannend zu wissen, wo bei Dir konkret der Flaschenhals ist. Nimm Dir doch mal NVidia NSight oder was Vergleichbares und analysiere ein Frame. NSight kann Dir die Lastverteilung VertexShader/FragmentShader/InputAssembler usw. darstellen, kann Dir den teuersten DrawCall des aktuellen Frames ermitteln, usw.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Zudomon »

"Experience the ease of developing code for GPUs using NVIDIA® Nsight™ Visual Studio Edition for Windows or Nsight™ Eclipse Edition for Linux and Mac OS."
Wie soll ich das denn für Turbo Delphi 2006 benutzen?
Vielleicht sollte ich meinen Frame Analyser mal auf GPU Benchmark erweitern. :D
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von dot »

Zudomon hat geschrieben:"Experience the ease of developing code for GPUs using NVIDIA® Nsight™ Visual Studio Edition for Windows or Nsight™ Eclipse Edition for Linux and Mac OS."
Wie soll ich das denn für Turbo Delphi 2006 benutzen?
Rein prinzipiell sollte es möglich sein, ein dummy Visual Studio Projekt aufzusetzen, den Debugger Launch Command auf deine .exe zu setzen und diese dann einfach in Visual Studio mit NSight zu profilen... ;)
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Schrompf »

Wollte ich auch gerade schreiben. Aber nuja, man kann's auch selbst schreiben.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Zudomon »

Schrompf hat geschrieben:Wollte ich auch gerade schreiben. Aber nuja, man kann's auch selbst schreiben.
Hast du tipps zum selbst schreiben? Macht man das über Queries am besten?
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von dot »

Zudomon hat geschrieben:
Schrompf hat geschrieben:Wollte ich auch gerade schreiben. Aber nuja, man kann's auch selbst schreiben.
Hast du tipps zum selbst schreiben? Macht man das über Queries am besten?
Ist wohl das einzige, was du machen kannst. Selbstverständlich ist davon auszugehen, dass NSight direkt mit dem Driver redet und an Infos rankommt, an die du niemals rankommen wirst... ;)
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Zudomon »

dot hat geschrieben:
Zudomon hat geschrieben:
Schrompf hat geschrieben:Wollte ich auch gerade schreiben. Aber nuja, man kann's auch selbst schreiben.
Hast du tipps zum selbst schreiben? Macht man das über Queries am besten?
Ist wohl das einzige, was du machen kannst. Selbstverständlich ist davon auszugehen, dass NSight direkt mit dem Driver redet und an Infos rankommt, an die du niemals rankommen wirst... ;)
Das habe ich leider schon befürchtet... aber die Frage ist auch, ob man es letztendlich wirklich so detailliert braucht. Vorwiegend habe ich das bisher genutzt um überhaupt sehen zu können, was im Frame gezeichnet wird.

Was ich zur Geschwindigkeit schon mal sagen kann, dass auf meinem Rechner die Mikrogeometrie viel ausmacht. Die Vertexshader sind auch dabei extrem unoptimiert, weil sich da einfach ne Menge "Mist" angesammelt hat. Hab ja damals schon immer gesagt, Geometrie macht, zumindest auf voll ausgebauten Grafikkarten eigentlich nicht viel aus, aber wenn da dann VS mit nahezu 1000 Instruktionen daher kommen, dann irgendwie doch :lol:

Auf dem Laptop auf Low, wo dann gar keine Mikrogeometrie ist, da machen die Items wie Bäume usw. ne Menge aus. Allerdings ist es da auch so, dass die Auflösungreduzierung extrem viel an der Rendergeschwindigkeit macht. Ich brauche im Pixelshader bestimmt 150 Instruktionen um den GBuffer zu füllen (Nässeberechnungen, Komprimieren der Daten). Das Deferred Shading hinterher schlägt (auf High, bei Low werden ein paar Dinge ausgelassen) mit gut 400 Instruktionen zu buche... dann das Tonemapping (wo dann auch noch TAA und solche Dinge fabriziert wird) sind dann auch nochmal rund 400 Instruktionen. Also bin ich bei gut 1000 PS Instruktionen, wenn der Pixel nur einmal angefasst wird.
Vielleicht sollte ich noch erwähnen, dass alle Shader ohne Optimierung kompiliert werden... bei vielen halbiert sich dadurch die Anzahl der Instruktionen, dauert dann aber auch mal gut 2-20 mal länger zum kompilieren. Was ich dabei komisch finde, dass weder auf meinem Rechner, noch auf dem Laptop durch "optimierte" Shader wirklich FPS dazu kommen.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Krishty »

Wie wär’s dann einfach mal mit Messen statt raten? Dass du die Anweisungszahl (D3D? IHV-spezifisch?) von unoptimierten Shadern aufzählst, wenn du von „Leistung“ sprichst, tut ja beim Lesen weh.

Entweder nimmst du jetzt ein ordentliches Analyse-Tool, das dir deutlich ausspuckt ob die Shader in den Knien sind oder ob du einfach die Wavefronts mit zu kleinen Dreiecken nicht voll kriegst, oder du lässt es eben sein.

Hier sind kompetente Leute unterwegs, die dir relativ schnell Kenngrößen für GPU-Leistung nennen können. Die sagen dir, dass du erstmal mit gängigen Tools messen sollst. Und du kommst mit „ein Pixel Shader hat 1000 Befehle, aber wenn ich die Hälfte weglasse, steigen die FPS auch nicht“. Das muss man sich mal auf der Zunge zergehen lassen!

Manchmal kannst du mich echt auf die Palme bringen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Zudomon »

Krishty hat geschrieben:... oder du lässt es eben sein.
Dann lass ich es eben sein.
Schrompf wollte gerne wissen, wo der Flaschenhals ist, bevor ich da jetzt was ändere.
Aber Tools wie NSight kann ich nicht benutzen, das PerfHUD funzt nicht mehr! Also habe ich das, was ich so grob schon über einen Frame weiß, geschrieben.
Es tut mir leid, dass mein Post nicht deinen Erwartungen entspricht, weil du akribisch Zahlen erwartest um dir dann nochmal 2 Jahre Zeit zum analysieren und auswerten nehmen, damit das ganze dann für eine spezifische GPU nochmal 0,26% mehr Leistung bringt, sofern bestimmte Kühltechniken beachtet werden.
Übrigens kann ich mich an deinen zitierten Satz gar nicht erinnern. Also erst die Worte zusammen schmeißen um sich dann über dessen Sinnhaftigkeit auszulassen, herrlich :lol:
Ja, hier sind kompetente Leute unterwegs. Aber Kompetenz bedeutet auch, dass man Annahmen anhand grober Informationen treffen kann, ohne das System aufs kleinste zu kennen. Natürlich sind es dann auch nur grobe Annahmen. Nicht dass selbst wenn man alles exakt hätte, die Annahmen "wesentlich" präziser wären, weil ja eben noch CPU und Treiber mit einfließen. Es könnte ja sogar sein, dass das System wegen Überhitzungsschutz runter tacktet. Oder ich habe irgendwo einen Sleep(2) zwecks analyse verbaut und vergessen. Würde man das wirklich alles bis aufs kleinste analysieren wollen, könnte man daraus gleich ne Lebensaufgabe machen.

Wusste übrigens gar nicht, dass dich meine Beiträge so ärgern :D aber das liegt wahrscheinlich wirklich daran, dass du alles ins kleinste analyisierst und ich eher das genaue Gegenteil bin und gerne alles nach Bauchgefühl mache. :lol:
Oft ärgert man sich über andere, weil diese nicht in das eigene Erwartungbild passen.

Die Instruktionszahl ist übrigens die, die mir der fxc-Kompiler ausspuckt, wo ich aber meine, dass in der Hilfe stand, dass die auch nur einen Anhaltspunkt bieten.
Zuletzt geändert von Zudomon am 13.12.2016, 16:03, insgesamt 1-mal geändert.
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von dot »

Zudomon hat geschrieben:Aber Tools wie NSight kann ich nicht benutzen, [...]
Wieso nicht? Alle nötigen Tools sind frei verfügbar!? Wenn mir fad wird, kann ich mit NSight hier selbst Shogun 2, Rise of the Tomb Raider oder was auch immer profilen; wieso du deine eigene Anwendung damit nicht profilen können solltest, ist mir schleierhaft.
Zudomon hat geschrieben:[...] und gerne alles nach Bauchgefühl mache. [...]
Bachgefühl ist halt leider genau das, was absolut nix bringt, wenn es um die Analyse der Performance von Code auf modernen Maschinen geht. Mit Bachgefühl schneidest du dabei vermutlich sogar statistisch signifikant schlechter ab als reine Zufallsentscheidungen... ;)
Zudomon hat geschrieben:Die Instruktionszahl ist übrigens die, die mir der fxc-Kompiler ausspuckt, wo ich aber meine, dass in der Hilfe stand, dass die auch nur einen Anhaltspunkt bieten.
fxc kompiliert Shader in eine Intermediate Representation, die erst vom Driver in den eigentlichen, hardwarespezifischen Maschinencode übersetzt wird... ;)
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Zudomon »

dot hat geschrieben:
Zudomon hat geschrieben:Aber Tools wie NSight kann ich nicht benutzen, [...]
Wieso nicht? Alle nötigen Tools sind frei verfügbar!? Wenn mir fad wird, kann ich mit NSight hier selbst Shogun 2, Rise of the Tomb Raider oder was auch immer profilen; wieso du deine eigene Anwendung damit nicht profilen können solltest, ist mir schleierhaft.
Ich dachte, man muss dazu Visual Studio haben, funktioniert das auch standalone?
http://www.nvidia.com/object/nsight.html
Hier sehe ich nur für Visual Studio und Eclipse Edition.
dot hat geschrieben:
Zudomon hat geschrieben:[...] und gerne alles nach Bauchgefühl mache. [...]
Bachgefühl ist halt leider genau das, was absolut nix bringt, wenn es um die Analyse der Performance von Code auf modernen Maschinen geht. Mit Bachgefühl schneidest du dabei vermutlich sogar statistisch signifikant schlechter ab als reine Zufallsentscheidungen... ;)
Bauchgefühl bedeutet doch, dass man auf das, was einem die innere Stimme sagt, hört. Also vor allem auch unbewusste Aspekte mit rein spielen. Das "Bauchgefühl" hängt vor allem auch stark von Erfahrungswerten ab. Wenn jemand überhaupt keine Erfahrung hat, dann entspricht dieses wohl wirklich einer Zufallsentscheidung.
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von dot »

Zudomon hat geschrieben:
dot hat geschrieben:
Zudomon hat geschrieben:Aber Tools wie NSight kann ich nicht benutzen, [...]
Wieso nicht? Alle nötigen Tools sind frei verfügbar!? Wenn mir fad wird, kann ich mit NSight hier selbst Shogun 2, Rise of the Tomb Raider oder was auch immer profilen; wieso du deine eigene Anwendung damit nicht profilen können solltest, ist mir schleierhaft.
Ich dachte, man muss dazu Visual Studio haben, funktioniert das auch standalone?
Ja, muss man. Das tolle ist: Man kann Visual Studio einfach runterladen und installieren... ;)
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Zudomon »

dot hat geschrieben:Ja, muss man. Das tolle ist: Man kann Visual Studio einfach runterladen und installieren... ;)
Das weiß ich, aber ich dachte halt, dass es als Debugging für das Projekt integriert ist. Also dass man das nicht einfach auf irgendwelche exe Dateien los lassen kann.
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von dot »

Zudomon hat geschrieben:Also dass man das nicht einfach auf irgendwelche exe Dateien los lassen kann.
Kann man, wie gesagt, aber... ;)
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Schrompf »

Zudomon hat geschrieben:Schrompf wollte gerne wissen wollte, wo der Flaschenhals ist, bevor ich da jetzt was ändere.
Stop. Nein, nicht *ich* wollte wissen, was bei Dir das langsamste ist. *Du* willst wissen, was langsam ist. Und die einzige Methode, das herauszukriegen, ist das Messen. Dein Bauchgefühl kannst Du ignorieren. Du bist ja inzwischen lang genug ein Mensch, um die üblichen Fehler des menschlichen Hirns zu kennen, und Bauchgefühl ist da ganz vorn mit dabei. Zumal Du ja schon selbst festgestellt hast, dass das Halbieren der Anzahl Instruktionen im FragmentShader nix gebracht hat, obwohl Dein Bauchgefühl vorher dachte, das würde was bringen.

Also: messen. Und versuche nicht, das selbst zu schreiben. Lade Dir VS runter, installiere NSight, lass die Profis messen. Das sind vielleicht 2h Gebastel. Zum Selber-Profilen müsstet Du deutlich mehr arbeiten und hast hinterher keine Garantie, dass Du die tatsächliche Silizium-Zeit deiner DrawCalls misst. Ganz zu schweigen davon, dass Du manche Dinge wie z.B. die Lastverteilung auf die Funktionsgruppen gar nicht messen kannst, ohne Unterstützung durch den GPU-Treiber zu bekommen.

[edit] Leider ist es nicht so einfach, wie es klingt: NSight braucht einen instrumentierten Treiber. Und als ich das letzte Mal den instrumentierten Treiber haben wollte, gab's den noch nicht für Windows10 :roll:
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Zudomon »

Schrompf hat geschrieben:Bevor Du jetzt irgendwelche Änderungen am Renderer ausprobierst, wäre es aber spannend zu wissen, wo bei Dir konkret der Flaschenhals ist.
Klingt für mich aber eher nach deiner Neugierde, statt nach meiner.

Aber mit den restlichen Aussagen hast du/ihr eventuell recht. Da bin ich dann wohl Schachmatt... grrr. ;)
"Messen" wird wohl mein Unwort für 2017! :D
Werde mal schauen, ob ich NSight ans laufen bekomme.
Schrompf hat geschrieben:[edit] Leider ist es nicht so einfach, wie es klingt: NSight braucht einen instrumentierten Treiber. Und als ich das letzte Mal den instrumentierten Treiber haben wollte, gab's den noch nicht für Windows10
Ich seh mich schon mit einem Bein wieder im Motivationsproblemethread!
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von dot »

Schrompf hat geschrieben:[edit] Leider ist es nicht so einfach, wie es klingt: NSight braucht einen instrumentierten Treiber. Und als ich das letzte Mal den instrumentierten Treiber haben wollte, gab's den noch nicht für Windows10 :roll:
Sicher dass du das nicht mit dem veralteten PerfHUD verwechselst!? NSight funktioniert bei mir mit dem stinknormalen GeForce Driver ganz ausgezeichnet...
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Zudomon »

Also bei mir scheint das NSight zu funktionieren. Hab es auch schon hinbekommen, da was zu profilen. Aber einen Frame wirklich durchgehen, also dass ich auf dem Bildschirm sehe, welche Dreiecke gezeichnet werden usw., soweit bin ich noch nicht. Muss ich mich dann mal mehr mit beschäftigen.

Aber mal noch etwas anderes, was ich nicht so ganz verstehe. Ich wollte das ja eigentlich so machen, wie Doom 4 das dann rendert:
http://www.adriancourreges.com/blog/201 ... ics-study/
Also statt großen G-Buffer einen Hybridrenderer. Bei genauerer Überlegung verstehe ich aber nicht wirklich, was da nun der Vorteil ist. Denn wenn da Depth, Velocitymap und im nächsten Pass Lightbuffer, Normalen und Materialeigenschaften gefüllt wird, dann hört sich das aber irgendwie auch nach einem G-Buffer an. Auch wenn in dem Artikel da Thin-G Buffer steht, kommt der mir genauso groß vor, wie vorher auch. Ob nun das Licht zum teil verschoben wird in einen "Forward"-Renderingteil um dann hinterher doch die Reflektionen usw. im Postprozess zu machen, scheint mir eigentlich das gleiche zu sein. Oder übersehe ich da was?
Punika
Beiträge: 29
Registriert: 25.02.2002, 15:12
Echter Name: Lutz Hören
Kontaktdaten:

Re: Deferred- vs Forward-Rendering

Beitrag von Punika »

Hi

also Thin-G Buffer weil es eben nicht soviel Speicher braucht. Aber ich denke das hast du selber gesehen. Ich würde heutzutage
auch gar nicht mehr von Forward oder Deferred Rendering sprechen. Gerade weil man heute durch Compute Shader noch mehr
Möglichkeiten hast. Und was noch wichtiger ist: Speicher in deinem Programmcode (GPU) wie du es möchtest. Was ich damit meine, ist das du halt heute ohne
weiteres aus einem Grid die Anzahl der lichter und lichter rauslesen kannst ohne Performance Probleme zu bekommen. Der Szenengraphen kommt halt in irgendeiner Form, immer mehr auf die Grafikkarte. Damit ist der Unterschied zwischen Forward/Deferred immer kleiner. Ich würde es auch so ausdrücken: Du möchtest die Rendering Equation so gut wie möglich approximieren und du hast X Anzahl an Techniken. Die einen funktionieren auf Objektebene, die anderen vielleicht Screen-Space ebene usw. und ich glaube die hohe Kunst ist es, die verschiedenen Techniken klug zu verbinden. Speicher optimiert usw.

Also nicht auf die Namensnennung viel geben. Es ist immer das gleiche Prinzip, für mich ist ein Depth Pre-Pass eine Art Deferred Rendering, da es die GPU dazu bringt, den Pixel Shader nur die sichtbaren Pixel zu rendern. Und einen Depth Pre pass gab es schon bevor deferred rendering in Mode kam. Man könnte z.B. sagen das du am Anfang gerne Pixel Shader kosten sparen willst. Deferred schreibt dabei einfach nur in einen G-Buffer und Forward Rendering nutzt halt fast immer einen Depth Pre-pass. Jetzt gibt es halt alle Variationen wieviel man am Anfang speichert. Nur Depth, oder vielleicht schon die Normalen. Mit den beiden kriegst du dann später z.B. schon mal nen SSAO screen space Effekt hin. Und das Spiel geht dann so weiter. Leider gibt es wie immer im Leben den perfekten weg nicht. Ich finde den Doom Ansatz auf jeden fall interessant weil er doch relativ wenig Speicher benutzt, das rendering von opaquen und translucenten Oberflächen besser vereinheitlicht und die Rendering Equation ganz gut ausfüllt.

Ich glaube aber das du dir auch Gedanken machen musst, welche Techniken du gerne hättest.
Antworten