NV40 & HDR: 2*2 > 4

[Demirug]

Nein, keine Angst der NV40 rechnet auch beim Einsatz von HDR immer noch richtig.

Hier geht es um ein Verfahren mit dem man auf dem NV40 das HDR rendering um bis zu 40% beschleunigen kann. Üblicherweise nimmt man bei HDR Rendering einen FP16 Buffer mit 4 Kanälen für Rot, Grün, Blau und Alpha. Bekanntermassen wird ein NV40 bei diesen 64Bit Transfers ja etwas langsamer. Verteilt man diese 64 Bit nun auf 2 32 Bit Speicher wird der Chip tatsächlich um bis zu 40% schneller. Ergo speichert man Rot und Grün in einem 2 Kanal FP16 Buffer und Blau und Alpha in einem zweiten. Mit Multirender Targets kann man dann in beide Buffer gleichzeitig rendern. Der gleiche Trick bringt dann auch bei FP16 Texturen mehr Leistung.

Das ganze kommt übrigens direkt von nVidia.

Es scheint so das der Leistungseinbruch beim HDR rendering eher aufgrund eines internen Bandbreitenproblems (64 Bit Daten auf 32 Bit Bussen) entsteht als einer externen Limitierung.

[q@h]

:up:
Dann besteht also durchaus Hoffnung auf wesentlich verbesserte HDR-Performance bei den next-gen Produkten auch ohne "900MHz"-GDDR3?

[q@h]

Wann gibt's das "Force 2*32"-Plugin für den DX-Tweaker?

[TheCounter]

Das hört sich ja gut an. Hab zwar keinen NV4x aber kann ja noch werden (Falls der R520 nix wird ;)).. :D

Entwickler können das ganze ja dann schon von vornherein so programmieren oder? Denn wenn das direkt von NVIDIA kommt helfen die Leute von NV doch sicherlich den Dev's.

[mapel110]

Hm, aber ich denke nicht, dass Crytek noch einen Patch bastelt. :(

Und für Splinter Cell kommt die Erkenntnis auch zu spät, oder?

Und ists möglich, mit dem DX-Tweaker noch was zu machen in beiden Fällen?

[Demirug]

TheCounter, es gibt von nVidia ein Techpaper und ein Beispiel dazu. Ist noch nicht öffentlich aber die Entwickler welche sich gerade mit HDR beschäftigen dürften es alle haben. Das ganze ist sogar gleich so beschrieben wie man beide Modies (4*FP16 und 2*2*FP16) einbauen und dann wählen kann. Die notwendigen Änderungen halten sich im Rahmen allerdings muss man leider jeden Shader nochmal anfassen.

mappel, das es da noch einen Patch gibt bezweifle ich.

Drehen könnte man wohl sowohl bei SC3 wie auch bei Farcry etwas. Wobei es bei Farcry aufgrund der "interesanten" HDR implementierung wohl nicht generisch geht. SC3 scheint mir da empfänglicher.

Quasar, ich denke darüber nach.

[Kladderadatsch]

warum kommt die erkenntnis erst so spät?:|

[mapel110]

warum kommt die erkenntnis erst so spät?:|
Könnte mir gut vorstellen, dass es zum einen andere Prioritäten gab und zum anderen lernt man ein neues Produkt erst mit der Zeit richtig kennen. Afaik arbeiten ja recht viele Leute an solch einem Chip und da hat wohl kaum einer einen kompletten Überblick, auch nicht über die (kleinsten) technischen Limitierungen.

[Xmas]

Ähm, wo genau ist da jetzt eigentlich der Unterschied der es verbietet dass NVidia das selbst im Treiber hinbiegt?

[dgsd]

rendert farcry eigentlich in 2*2 FP16-texturen, imo hast du das sogar mal kritisiert?

[Demirug]

Ähm, wo genau ist da jetzt eigentlich der Unterschied der es verbietet dass NVidia das selbst im Treiber hinbiegt?

Wenn sie es im Treiber hinbiegen müssen sie Shader dynamisch anpassen. Das macht die Drawcalls teurer. Also ist es besser die entwickler zu überzeugen es gleich so zu machen wie sie es gerne hätten.

[Demirug]

rendert farcry eigentlich in 2*2 FP16-texturen, imo hast du das sogar mal kritisiert?

Farcry rendert in alles mögliche. Primär aber in einen 4*FP16 Buffer. Beim Downsampling wird dann auch mal in 2*FP16 Buffer gesampelt.

Was ich kritisiert habe war das sie ständig von 4 Kanal auf 2 Kanal und wieder zurück gewechselt haben. Wobei die Filterstufen dabei ja sowieso zuviel unnötige Dinge gerechnet haben.

[dgd]

verwendet SC3 in der demo eigentlich schon 2 2-kanalige FP16-buffer oder nur einen 4-kanaligen? zumindest gegenüber farcry ist der einbruch beim hdr schon sehr gering (was wohl kein kunststück sein dürfte ;) )

[Demirug]

verwendet SC3 in der demo eigentlich schon 2 2-kanalige FP16-buffer oder nur einen 4-kanaligen? zumindest gegenüber farcry ist der einbruch beim hdr schon sehr gering (was wohl kein kunststück sein dürfte ;) )

Ist ein vierkanaliger Speicher.

Das der Einbruch geringer ist dürfte vorallem daran liegen das am Ende nicht unnötig viel postfilter Passes durchgeführt werden.

[sdfg]

also ist damit zu rechnen dass HDR im finalen game noch weniger einbrüche verursacht? dann würde hdr ja kaum noch mehr als das parallax-mapping kosten.

[Demirug]

also ist damit zu rechnen dass HDR im finalen game noch weniger einbrüche verursacht? dann würde hdr ja kaum noch mehr als das parallax-mapping kosten.

Aufgrund des Erscheinungstermins rechne ich nicht mehr damit das sich an den Renderverfahren noch etwas ändert.

[sdaf]

schade, sind die änderungen wirklich so kompliziert?

[MadManniMan]

Würde die Bandbreitenersparniß die heftigen Drawcalls aufwiegen, wenn man 2*2*FP16 erzwänge?

[Demirug]

schade, sind die änderungen wirklich so kompliziert?

Es müsste jeder Shader angefasst werden. Sind so etwa 30 Stück. Dazu dann noch ein paar Änderungen am Code.

[Demirug]

Würde die Bandbreitenersparniß die heftigen Drawcalls aufwiegen, wenn man 2*2*FP16 erzwänge?

Die Drawcalls ändern sich nicht. Man rendert in beide Buffer gleichzeitig. Das ist ja das interesante daran.

[Coda]

Und wie bekommt man das danach wieder in einen Framebuffer den der RAMDAC lesen kann? Pixelshader?

[MadManniMan]

Die Drawcalls ändern sich nicht. Man rendert in beide Buffer gleichzeitig. Das ist ja das interesante daran.

Ich meinte, wenn man dies nur per Treiber erzwänge und die Shader nicht per Hand darauf vorbereiten würde.

[Xmas]

Wenn sie es im Treiber hinbiegen müssen sie Shader dynamisch anpassen. Das macht die Drawcalls teurer. Also ist es besser die entwickler zu überzeugen es gleich so zu machen wie sie es gerne hätten.
Ich sehe da jetzt nicht wirklich das Problem, aus einem MOV zwei zu machen, wenn ein FP16-RT aktiv ist. Oder meinst du jetzt für den Fall, wenn die Anwendung selbst gleichzeitig auch noch MRT nutzen könnte? Nun ja, Application Detection...

[Demirug]

Ich sehe da jetzt nicht wirklich das Problem, aus einem MOV zwei zu machen, wenn ein FP16-RT aktiv ist. Oder meinst du jetzt für den Fall, wenn die Anwendung selbst gleichzeitig auch noch MRT nutzen könnte? Nun ja, Application Detection...

Es muss ja nicht nur das Rausschreiben erkannt werden sondern wenn man die Texture wieder einliesst muss das auch wieder angepasst werden.

Application Detection ist natürlich immer eine Lösung aber wenn man es vermeiden kann wird man das auch tun.

[Demirug]

Ich meinte, wenn man dies nur per Treiber erzwänge und die Shader nicht per Hand darauf vorbereiten würde.

Das eine schlägt auf die CPU das andere auf die GPU. Wenn man also noch CPU zeit übrig hat spielt der Overhead letzten Endes keine Rolle.

[aths]

Nein, keine Angst der NV40 rechnet auch beim Einsatz von HDR immer noch richtig.

Hier geht es um ein Verfahren mit dem man auf dem NV40 das HDR rendering um bis zu 40% beschleunigen kann. Üblicherweise nimmt man bei HDR Rendering einen FP16 Buffer mit 4 Kanälen für Rot, Grün, Blau und Alpha. Bekanntermassen wird ein NV40 bei diesen 64Bit Transfers ja etwas langsamer. Verteilt man diese 64 Bit nun auf 2 32 Bit Speicher wird der Chip tatsächlich um bis zu 40% schneller. Ergo speichert man Rot und Grün in einem 2 Kanal FP16 Buffer und Blau und Alpha in einem zweiten. Mit Multirender Targets kann man dann in beide Buffer gleichzeitig rendern. Der gleiche Trick bringt dann auch bei FP16 Texturen mehr Leistung.

Das ganze kommt übrigens direkt von nVidia.

Es scheint so das der Leistungseinbruch beim HDR rendering eher aufgrund eines internen Bandbreitenproblems (64 Bit Daten auf 32 Bit Bussen) entsteht als einer externen Limitierung.Sehr interessant.

Warum rückt NV erst jetzt damit raus?

[Chris Lux]

TheCounter, es gibt von nVidia ein Techpaper und ein Beispiel dazu. Ist noch nicht öffentlich aber die Entwickler welche sich gerade mit HDR beschäftigen dürften es alle haben.
wenn du die im nvsdk9.0 enthaltene demo meinst, die ist seit letzter woche öffentlich auf developer.nvidia.com unter tools zur bekommen.

[Chris Lux]

Und wie bekommt man das danach wieder in einen Framebuffer den der RAMDAC lesen kann? Pixelshader?
korrekt.

[Demirug]

wenn du die im nvsdk9.0 enthaltene demo meinst, die ist seit letzter woche öffentlich auf developer.nvidia.com unter tools zur bekommen.

Richtig öffentlich ist das 9er SDK noch nicht. Die offizielle Version ist immer noch 8.5.

[ShadowXX]

Richtig öffentlich ist das 9er SDK noch nicht. Die offizielle Version ist immer noch 8.5.

Hmmm...woran erkennt man die "Versionsnummer"?

Weil auf den DVDs der MSDN steht DX9SDK drauf....und auch nach der Installation steht da DX9SDK.

[Demirug]

Hmmm...woran erkennt man die "Versionsnummer"?

Weil auf den DVDs der MSDN steht DX9SDK drauf....und auch nach der Installation steht da DX9SDK.

Nicht das DirectX SDK. Es gibt auch noch ein SDK von nVidia.

[Chris Lux]

Richtig öffentlich ist das 9er SDK noch nicht. Die offizielle Version ist immer noch 8.5.
IMO doch, siehe hier http://developer.nvidia.com/object/sdk_home.html , es ist halt nur noch nicht auf der hauptseite verlinkt.

edit: es war nur recht kurz auf der regdev seite und da auch nicht als beta o.ä. markiert.

[Demirug]

IMO doch, siehe hier http://developer.nvidia.com/object/sdk_home.html , es ist halt nur noch nicht auf der hauptseite verlinkt.

edit: es war nur recht kurz auf der regdev seite und da auch nicht als beta o.ä. markiert.

Du hast recht. Ich habe es übersehen weil nVidia wohl den direkten Link verändert hat. Früher war es immer "nvsdk_home".

[ShadowXX]

Nicht das DirectX SDK. Es gibt auch noch ein SDK von nVidia.

Uppss....sorry, hatte mich beim Überfliegen verlesen.