HDR und Alphablending

[Demirug]

Die Fähigkeit eine neue Pixelfarbe mit der an der gleichen Stellen bereits im Buffer vorhandenen zu verrechnen nennt man Alphablending. Benötigt wird diese Fähigkeit immer dann wenn ein Objekt mit einer Multipass Technik gerendert wird, wenn Transparenz Effekte zum Einsatz kommen oder wenn man die harten Kanten des Alphatests vermeiden möchte. In vielen Fällen ist es dabei nun schwer und bisweilen sogar unmöglich ohne Alphablending den gewünschten Effekt zu erreichen. Eigentlich gehörte das Alphablending zu den Themen über die man sich keine Sorgen macht weil sowieso jede halbwegs aktuelle Hardware dies unterstützt. Mit der DX9 Generation von Grafikhardware wurden diese aber um die Fähigkeit erweitert auch Buffer mit Fliesspunkt Formaten zu beschreiben. Dies macht eine neue Gruppe von HDR Effekten möglich. Leider ist die Unterstützung dieser Formate bei den meisten GPUs unvollständig. Es fehlt die Möglichkeit weiterhin Alphablending zu benutzen. Damit wird es nun doch plötzlich wieder zu einem wichtigen Thema.

Verfügt die Hardware über eine Alphablending Einheit für das benötigte Format ist alles in Butter. Der Pixelshader bestimmt die neuen Farbwert und die Alphablending Einheit verrechnet diesen so wie es die Konfiguration vorschreibt mit dem alten Wert. Häufig werden dabei einfach beide Werte addiert.

Hat man nun aber keine Alphablendig Einheit und braucht trotzdem aus oben genannten Gründen Alphablending muss man diese Funktion emulieren. Dies ist etwas umständlich und der Performance auch nicht sonderlich zuträglich. Zuerst braucht man neben dem eigentlichen Buffer zum rendern einen zweiten mit gleicher Größe und Format. Bei 1280*1024 mit FP16 verliert man dadurch schon mal 10 MB Texturespeicher. Das lässt sich aber in der Regel noch gut verschmerzen. Problematischer wird es dann beim Rendern. Ohne Alphablending kann nur der Wert welcher von den Pixelshadern berechnet wird direkt ohne Änderung in den Buffer geschrieben werden. Das Alphablending muss also im Pixelshader durchgeführt werden. Aber auch an diesen zusätzlichen Shaderanweisungen (häufig nur eine) stirbt man eigentlich noch nicht. Das Problem besteht nun darin die aktuelle Farbe des Pixels im Buffer in den Pixelshader zu bekommen. Um auf Werte aus dem Grafikspeicher zugreifen zu können müsse diese in einer Textur liegen. Soweit kein Problem mag man denken den man rendert ja auch in eine Textur. Leider ist es aber verboten die gleiche Texture gleichzeitig als Ziel und Quelle in einem Pass zu benutzen. Es ist daher erforderlich vor jedem Pass welcher Alphablending braucht den Inhalt des eigentlich Zielbuffers in den vorher angelegten Ersatzbuffer zu kopieren damit dieser dann als Quelle benutzt werden kann. Wenn man den Bildbereich in den das neue Objekt gerendert werden soll eingrenzen kann muss man nicht den gesamten Buffer kopieren. Auf jeden Fall muss aber jeder Pixel welcher durch das neue Objekt verändert wird kopiert werden. Daraus ergibt sich dann im besten fall durch das Fehlen einer Alphablending Einheit folgenden Belastung pro Pixel.

- Auslesen des primären Buffers (1* Texelfillrate + Bandbreite)
- Schreiben in den Ersatzbuffer (1* Pixelfillrate + Bandbreite)
- Auslesen des Ersatzbuffers (1* Texelfillrate + Bandbreite)
- Alphablendig im Shader (FPU Leistung)
- Schreiben in den primären Buffer (1* Pixelfillrate + Bandbreite)

Kann man den Objektbereich nicht pixelgenau eingrenzen müssen die ersten beiden Schritte entsprechend für alle Pixel die im angenommen Bereich liegen ebenfalls durchgeführt werden. Im schlimmsten fall für alle Pixel des Buffers.

Mit einer Alphablending Einheit sieht die Bilanz wie folgt aus:

- Auslesen des primären Buffers (Bandbreite; keine Texelfillrate weil die Alphablend Einheit das übernimmt)
- Alphablendig in der entsprechenden Einheit (kein zusätzlicher FPU Aufwand)
- Schreiben in den primären Buffer (1* Pixelfillrate + Bandbreite)

Eine Alphablend Einheit spart hier also Bandbreite und Fillrate. Hinzu kommt noch das bei Emulationsverfahren ständig der Zielbuffer gewechselt werden muss. Dabei besteht immer die Gefahr das der Chip zuerst die Pipeline weitgehend bis vollständig leer laufen lassen muss. Dabei verliert man dann viele Takte in denen der Chip eigentlich gar nicht tut.

Eine dedizierte Alphablend Einheit ist also durchaus sehr sinnvoll. Zumindestens solange wie man in den Pixelshadern selbst keinen direkten Zugriff auf den Inhalt des aktuellen Zielbuffers hat.

[IVN]

Die Fähigkeit eine neue Pixelfarbe mit der an der gleichen Stellen bereits im Buffer vorhandenen zu verrechnen nennt man Alphablending. Benötigt wird diese Fähigkeit immer dann wenn ein Objekt mit einer Multipass Technik gerendert wird, wenn Transparenz Effekte zum Einsatz kommen oder wenn man die harten Kanten des Alphatests vermeiden möchte. In vielen Fällen ist es dabei nun schwer und bisweilen sogar unmöglich ohne Alphablending den gewünschten Effekt zu erreichen. Eigentlich gehörte das Alphablending zu den Themen über die man sich keine Sorgen macht weil sowieso jede halbwegs aktuelle Hardware dies unterstützt. Mit der DX9 Generation von Grafikhardware wurden diese aber um die Fähigkeit erweitert auch Buffer mit Fliesspunkt Formaten zu beschreiben. Dies macht eine neue Gruppe von HDR Effekten möglich. Leider ist die Unterstützung dieser Formate bei den meisten GPUs unvollständig. Es fehlt die Möglichkeit weiterhin Alphablending zu benutzen. Damit wird es nun doch plötzlich wieder zu einem wichtigen Thema.

Verfügt die Hardware über eine Alphablending Einheit für das benötigte Format ist alles in Butter. Der Pixelshader bestimmt die neuen Farbwert und die Alphablending Einheit verrechnet diesen so wie es die Konfiguration vorschreibt mit dem alten Wert. Häufig werden dabei einfach beide Werte addiert.

Hat man nun aber keine Alphablendig Einheit und braucht trotzdem aus oben genannten Gründen Alphablending muss man diese Funktion emulieren. Dies ist etwas umständlich und der Performance auch nicht sonderlich zuträglich. Zuerst braucht man neben dem eigentlichen Buffer zum rendern einen zweiten mit gleicher Größe und Format. Bei 1280*1024 mit FP16 verliert man dadurch schon mal 10 MB Texturespeicher. Das lässt sich aber in der Regel noch gut verschmerzen. Problematischer wird es dann beim Rendern. Ohne Alphablending kann nur der Wert welcher von den Pixelshadern berechnet wird direkt ohne Änderung in den Buffer geschrieben werden. Das Alphablending muss also im Pixelshader durchgeführt werden. Aber auch an diesen zusätzlichen Shaderanweisungen (häufig nur eine) stirbt man eigentlich noch nicht. Das Problem besteht nun darin die aktuelle Farbe des Pixels im Buffer in den Pixelshader zu bekommen. Um auf Werte aus dem Grafikspeicher zugreifen zu können müsse diese in einer Textur liegen. Soweit kein Problem mag man denken den man rendert ja auch in eine Textur. Leider ist es aber verboten die gleiche Texture gleichzeitig als Ziel und Quelle in einem Pass zu benutzen. Es ist daher erforderlich vor jedem Pass welcher Alphablending braucht den Inhalt des eigentlich Zielbuffers in den vorher angelegten Ersatzbuffer zu kopieren damit dieser dann als Quelle benutzt werden kann. Wenn man den Bildbereich in den das neue Objekt gerendert werden soll eingrenzen kann muss man nicht den gesamten Buffer kopieren. Auf jeden Fall muss aber jeder Pixel welcher durch das neue Objekt verändert wird kopiert werden. Daraus ergibt sich dann im besten fall durch das Fehlen einer Alphablending Einheit folgenden Belastung pro Pixel.

- Auslesen des primären Buffers (1* Texelfillrate + Bandbreite)
- Schreiben in den Ersatzbuffer (1* Pixelfillrate + Bandbreite)
- Auslesen des Ersatzbuffers (1* Texelfillrate + Bandbreite)
- Alphablendig im Shader (FPU Leistung)
- Schreiben in den primären Buffer (1* Pixelfillrate + Bandbreite)

Kann man den Objektbereich nicht pixelgenau eingrenzen müssen die ersten beiden Schritte entsprechend für alle Pixel die im angenommen Bereich liegen ebenfalls durchgeführt werden. Im schlimmsten fall für alle Pixel des Buffers.

Mit einer Alphablending Einheit sieht die Bilanz wie folgt aus:

- Auslesen des primären Buffers (Bandbreite; keine Texelfillrate weil die Alphablend Einheit das übernimmt)
- Alphablendig in der entsprechenden Einheit (kein zusätzlicher FPU Aufwand)
- Schreiben in den primären Buffer (1* Pixelfillrate + Bandbreite)

Eine Alphablend Einheit spart hier also Bandbreite und Fillrate. Hinzu kommt noch das bei Emulationsverfahren ständig der Zielbuffer gewechselt werden muss. Dabei besteht immer die Gefahr das der Chip zuerst die Pipeline weitgehend bis vollständig leer laufen lassen muss. Dabei verliert man dann viele Takte in denen der Chip eigentlich gar nicht tut.

Eine dedizierte Alphablend Einheit ist also durchaus sehr sinnvoll. Zumindestens solange wie man in den Pixelshadern selbst keinen direkten Zugriff auf den Inhalt des aktuellen Zielbuffers hat.

So,this is good to know.R420 isn't really capable of rendering FarCry + HDR in real time?

[Mr. Lolman]

Angenommen man extrahiert den Paradise Rendermode Shader und ändert die Glow und Bloom Effekte, dass sie noch intensiver sind (ca. so halt wie die HDR Effekte). (Das unterscheidet ja im Grunde den "Paradise" Rendermode vom "Verbessert" Rendermode)

Wodurch würde sich das echte NV40 HDR vom "Pseudo HDR" unterscheiden?
Denn Kontraständerungen gibts ja auch schon bei den Rendermodi. (z.B. wenn man auf einen sehr hell beleuchteten Strabdabschnitt direkt drauf blickt, beginnen sich langsam Strukturen abzuzeichnen)

[betasilie]

Wodurch würde sich das echte NV40 HDR vom "Pseudo HDR" unterscheiden?
Denn Kontraständerungen gibts ja auch schon bei den Rendermodi. (z.B. wenn man auf einen sehr hell beleuchteten Strabdabschnitt direkt drauf blickt, beginnen sich langsam Strukturen abzuzeichnen)
HDR kann ja nicht nur FS-Kontraständerungen, sondern auch partielle, oder irre ich?

[Demirug]

So,this is good to know.R420 isn't really capable of rendering FarCry + HDR in real time?

IMHO benutzt Farcry dermassen viel Alphablending das man es nicht mehr in Echtzeit realisieren kann. Wenn ich mal wieder langeweile habe probiere ich es vielleicht mal aus.

[Demirug]

Angenommen man extrahiert den Paradise Rendermode Shader und ändert die Glow und Bloom Effekte, dass sie noch intensiver sind (ca. so halt wie die HDR Effekte). (Das unterscheidet ja im Grunde den "Paradise" Rendermode vom "Verbessert" Rendermode)

Wodurch würde sich das echte NV40 HDR vom "Pseudo HDR" unterscheiden?
Denn Kontraständerungen gibts ja auch schon bei den Rendermodi. (z.B. wenn man auf einen sehr hell beleuchteten Strabdabschnitt direkt drauf blickt, beginnen sich langsam Strukturen abzuzeichnen)

Ich habe den Effekt noch nicht komplett analysiert (da sind sehr viele Passes beteiligt). Aber auf jeden Fall geht am Ende die durchschnittliche Lichtstärke des gesamten Frames in die Berechnung ein. Hierbei wirken sich dann natürlich die überhellen (>1) Stellen aus. Aus dem Grund braucht man auch einen FP Buffer weil ein normaler Buffer diese Stellen ja nicht speichern könnte sondern einfach bei 1 stehen bleibt.

[IVN]

IMHO benutzt Farcry dermassen viel Alphablending das man es nicht mehr in Echtzeit realisieren kann. Wenn ich mal wieder langeweile habe probiere ich es vielleicht mal aus.

Hmm,that would be very nice from you.Could you also test your 6800u against x800pe,just to see how fast(slow) this really is.Only if you have time,i'm not forcing you.

[betasilie]

Nutzt Painkiller2 HDR?

[IVN]

Nutzt Painkiller2 HDR?

I didn't see any contrast adaptability,so the answer is no.

[betasilie]

I didn't see any contrast adaptability,so the answer is no.
Ich würde da auch so sehen und lediglich Glow- und Bloomeffekte sehen. Aber bei Painkiller2 war im Vorfeld immer von HDR die Rede. :ratlos:

[Demirug]

Ich würde da auch so sehen und lediglich Glow- und Bloomeffekte sehen. Aber bei Painkiller2 war im Vorfeld immer von HDR die Rede. :ratlos:

Glow wird aus Marketinggründen auch mal gerne als HDR Effekt verkauft.

[betasilie]

Glow wird aus Marketinggründen auch mal gerne als HDR Effekt verkauft.
Mhhh. Sowas ist natürlich unverschämt. :(

[IVN]

Mhhh. Sowas ist natürlich unverschämt. :(

No,that's normal.Some people also said that CS source has HDR :hammer: .
Exm. on the Dust map when you come into this dark room.
But that's not HDR for sure.Ati cards from r3xx to r420 aren't capable of real HDR.Maybe you can make a similar effect,and later call it HDR,but that's not right.

[marco42]

Demirug, weisst du eigentlich, ob programmierbare alpha blending hardware geplannt ist. so das man varyings zum alpha blenden benuzten kann. da die alpha blending hardware ganz hinten sitzt in der pipeline koennte man das doch ganz gut fuer convolution filter benutzen. solange es keine probleme bei der parallelen verarbeitung gibt. damit koennte man sich dann sparen in eine texture zu rendern.

[Demirug]

Demirug, weisst du eigentlich, ob programmierbare alpha blending hardware geplannt ist. so das man varyings zum alpha blenden benuzten kann. da die alpha blending hardware ganz hinten sitzt in der pipeline koennte man das doch ganz gut fuer convolution filter benutzen. solange es keine probleme bei der parallelen verarbeitung gibt. damit koennte man sich dann sparen in eine texture zu rendern.

Bei 3dlabs soll die entsprechenden Einheit angeblich programmierbar sein. Allerdings gibt es keine Extension dafür.

Für WGF war auch mal im Gespräch das man die (Pixel)shader auf den aktuellen Zielbuffer zugreifen lassen möchte. Allerdings ist es im Bezug auf diesen Punkt eher ruhig geworden.

[dildo4u]

Ich finds auch schade vor allem da jetzt vieleicht wegen dem R420 kein HDR in HL2 gibt.

Geplant wars ja wie man bei dem video sieht.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2405771&postcount=23

[DrumDub]

Ich finds auch schade vor allem da jetzt vieleicht wegen dem R420 kein HDR in HL2 gibt.

Geplant wars ja wie man bei dem video sieht.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2405771&postcount=23

das ist kein hdr oder mdr, was du das siehst.

[dildo4u]

das ist kein hdr oder mdr, was du das siehst.
sondern? auf jedenfall ist es im Finalen HL2 nich mher dabei warum?

[IVN]

sondern? auf jedenfall ist es im Finalen HL2 nich mher dabei warum?

Well,if HL2 doesn't has HDR, maybe the Source engine has it?
It's almost always the case that engines have more capabilities than the games that are based on them.

[DrumDub]

sondern? auf jedenfall ist es im Finalen HL2 nich mher dabei warum?

doch es ist dabei. es ist aber nur kein hdr/mdr, sondern eben nur ein glow/bloom-effekt. dieser effekt wirkt sich nicht auf die umgebung aus, wie das mdr in far cry. (siehste gut am boden.)

wie oben schon gesagt, werden marketingstechnisch dinge als hdr verkauft, die es nicht sind.

[Tigerchen]

doch es ist dabei. es ist aber nur kein hdr/mdr, sondern eben nur ein glow/bloom-effekt. dieser effekt wirkt sich nicht auf die umgebung aus, wie das mdr in far cry. (siehste gut am boden.)

wie oben schon gesagt, werden marketingstechnisch dinge als hdr verkauft, die es nicht sind.

Aber ist es nicht viel sinnvoller auf "echtes" HDR zu verzichten solange es noch so viel Performance frißt und AA verhindert?

[Mr. Lolman]

No,that's normal.Some people also said that CS source has HDR :hammer: .
Exm. on the Dust map when you come into this dark room.
But that's not HDR for sure.Ati cards from r3xx to r420 aren't capable of real HDR.Maybe you can make a similar effect,and later call it HDR,but that's not right.

ist rthdribl kein echtes HDR?

[Coda]

Aber ist es nicht viel sinnvoller auf "echtes" HDR zu verzichten solange es noch so viel Performance frißt und AA verhindert?
Es ist vor allem nicht sinnvoll gegen alles zu wettern was ATi nicht hat :rolleyes:

[Xmas]

ist rthdribl kein echtes HDR?
Doch, aber nur eine relativ limitierte Demo ohne Alpha-Blending und wenigen Objekten. Auch die Glas- oder Edelsteinshader nutzen lediglich die Cubemap und blenden nicht.
Zudem ist es recht ineffizient.

btw, Demirug, es gab mal Gerüchte, rthdribl würde beim FP-Texturzugriff den Filtermodus nicht auf Point Sampling stellen. Könntest du das mal nachprüfen?

[IVN]

ist rthdribl kein echtes HDR?

I don't know.Does it use fp16 frame bufer and fp alpha blending,and does it have contrast adaptability?Otherwise it's not HDR.Just a similar looking effect.

[Tigerchen]

Es ist vor allem nicht sinnvoll gegen alles zu wettern was ATi nicht hat :rolleyes:

Hast du auch was zum Thema beizutragen?

[DrumDub]

Aber ist es nicht viel sinnvoller auf "echtes" HDR zu verzichten solange es noch so viel Performance frißt und AA verhindert?


zwingt einen ja keiner dazu hdr in far cry anzuschalten. ;)

mich hat das hdr (bzw. lt. aths mdr) in far cry auch nicht beonders beeindruckt. (zumindest die videos, die ich davon gesehen habe.) aber auf jeden fall ist es eine möglichkeit, um eine realitischere umwelt in spielen zu schaffen. das ist auf jeden fall positiv. die momentanen kompromisse (speed und kein msaa), die ich damit eingehen müsste, um es in far cry mit einem nv40 zu nutzen, sprechen aber für mich dagegen.

[Coda]

Hast du auch was zum Thema beizutragen?
Weich nicht aus.

Du hast auch nichts bezutragen, deine Argumentation bezieht sich auf "zu langsam" -> brauch ich nicht.

Aber FarCry ist mit Sicherheit nicht die einzige Anwendungsmöglichkeit des Features und wie Demirug bereits mehrmals gesagt hat ist FC nicht gerade ein Optimierungswunder.

[Mr. Lolman]

I don't know.Does it use fp16 frame bufer and fp alpha blending,and does it have contrast adaptability?Otherwise it's not HDR.Just a similar looking effect.

Ja, die Demo hat auf jeden Fall einen adaptiven Kontrast. Das Frambuffer Format ist AFAIK eins was NV nicht beherrscht, und ob Alphablending genutzt wird weiss ich nicht. Blending gibts auf jeden Fall genug.

[Coda]

Das Frambuffer Format ist AFAIK eins was NV nicht beherrscht, und ob Alphablending genutzt wird weiss ich nicht. Blending gibts auf jeden Fall genug.
NV30 konnte keine FP Rendertargets, bei NV40 sieht das ganz anders aus.

Und es geht auch um's Blending und das kann ATi garantiert nicht. Wahrscheinlich berechnet das Program tatsächlich das Blending im Pixelshader, das würde auch die recht schlechte Performance erklären.

[Mr. Lolman]

Die Performance selbst ist nicht schlecht, wenn man Multisampling und Depth of Field deaktiviert ist sie sogar ziemlich gut:

http://img26.exs.cx/img26/7456/Untitled-271.th.jpg (http://img26.exs.cx/my.php?loc=img26&image=Untitled-271.jpg)

[IVN]

Die Performance selbst ist nicht schlecht, wenn man Multisampling und Depth of Field deaktiviert ist sie sogar ziemlich gut:

http://img26.exs.cx/img26/7456/Untitled-271.th.jpg (http://img26.exs.cx/my.php?loc=img26&image=Untitled-271.jpg)

79 fps only for 6 balls in the room.That's not good.Can you imagine how slow would x800 be in FC HDR with that method.(if that is posible) :|

[Tigerchen]

Weich nicht aus.

Du hast auch nichts bezutragen, deine Argumentation bezieht sich auf "zu langsam" -> brauch ich nicht.

Aber FarCry ist mit Sicherheit nicht die einzige Anwendungsmöglichkeit des Features und wie Demirug bereits mehrmals gesagt hat ist FC nicht gerade ein Optimierungswunder.

Brauch ich nicht hab ich nirgends geschrieben.
Find ich sogar gut. Aber ist es denn nicht wirklich sinnvoller, auch für nV-User, ein Verfahren zu wählen welches schnell(er) ist und AA erlaubt?

Gut wenn du jetzt sagst dieses Hardware HDR ist so viel besser als ein emuliertes Verfahren und die Nachteile nehme ich dann gerne in Kauf ist daß okay.

[Xmas]

Ja, die Demo hat auf jeden Fall einen adaptiven Kontrast. Das Frambuffer Format ist AFAIK eins was NV nicht beherrscht, und ob Alphablending genutzt wird weiss ich nicht. Blending gibts auf jeden Fall genug.
rthdribl nutzt ein FP16-Format, das von NV3x nicht unterstützt wird. Alpha Blending wird lediglich für das Rendern der Schrift in den finalen 32bit-Framebuffer gebraucht. Welches Blending meinst du?
Was Demirug hier beschreibt, kommt bei dieser Demo nicht zum Tragen. Es gibt keine echt transparenten Objekte, durch die man durchschauen könnte, noch wird ein Partikelsystem eingesetzt.

[Mr. Lolman]

Immerhin werden auf meiner Karte je nach Setting fast 8Mio. Polys/sec. gerendert. Sollte imho auch für Farcry reichen.

http://img113.exs.cx/img113/168/Untitled-61.jpg

[Quasar]

Die Performance selbst ist nicht schlecht, wenn man Multisampling und Depth of Field deaktiviert ist sie sogar ziemlich gut:

Wieviel magst' noch deaktivieren, bis die Demo in deine Argumentation passt? ;)
Glare Type: disabled bringt auch direkt nochmal 50% fps mehr. Und als model die Teekanne auch nochmal 10%....
edit:
Material auf "air?" bringt auch nochmal mehr FPS...

edit:
"HDR".... :|
http://img32.exs.cx/img32/8382/Bonk.jpg

[Mr. Lolman]

rthdribl nutzt ein FP16-Format, das von NV3x nicht unterstützt wird. Alpha Blending wird lediglich für das Rendern der Schrift in den finalen 32bit-Framebuffer gebraucht. Welches Blending meinst du?
Was Demirug hier beschreibt, kommt bei dieser Demo nicht zum Tragen. Es gibt keine echt transparenten Objekte, durch die man durchschauen könnte, noch wird ein Partikelsystem eingesetzt.

Ok da muss ich dir Recht geben. Also ists unmöglich mit dieser Methode Alphablending zu realisieren. Denn die Performance müsste reichen. (mit der Komplexität der Objekte steigt auch der Polygondurchsatz. 20Mio/Polys sollten genug sein. Gibts also nur mehr das Transparenz Problem...

[Xmas]

Brauch ich nicht hab ich nirgends geschrieben.
Find ich sogar gut. Aber ist es denn nicht wirklich sinnvoller, auch für nV-User, ein Verfahren zu wählen welches schnell(er) ist und AA erlaubt?
Natürlich ist es sinnvoller, ein schnelleres Verfahren zu wählen - wenn es denn eins gibt, und wenn die Qualität gleichwertig ist. Um FP-Rendertargets kommt man aber kaum herum.

Was man auch nicht vergessen sollte ist dass Far Cry verschiedene Stufen für HDR kennt. Empfohlen für beste Qualität (und AFAIK auch gebencht) wird 7, aber auch 2 bringt schon sichtbare Verbesserungen (auf Kosten von AA, das ist der Tradeoff).

[Mr. Lolman]

Wieviel magst' noch deaktivieren, bis die Demo in deine Argumentation passt? ;)

Kann man bei FC1.3 Multisampling beim HDR aktivieren? Gibts da Depth of Field?

Aber egal mit allen Features aktiviert, hab ich in der Totenkopfszene immernoch 15Mio Polys/sec.

[Xmas]

Immerhin werden auf meiner Karte je nach Setting fast 8Mio. Polys/sec. gerendert. Sollte imho auch für Farcry reichen.
Aber schau auch mal, welche Fläche von Objekten belegt wird, und welche lediglich die Hintergrund-Cubemap zeigt. Auch wenn es viele Polygone sind, die Füllratenanforderungen sind moderat und die Tiefenkomplexität viel zu gering, um mit einem Spiel verglichen zu werden.

[Quasar]

Mir fällt da gerade was auf - meine "normale" Performance liegt, wie für GeForces üblich, auf nicht sehr hohem Niveau. (default um 60fps wenn ich die Demo einfach nur so starte)

Nun sehe ich Lolmans Skull-Szene und stelle erstaunt fest, daß da nur 37fps angezeigt werden.
Ich habe hier (mit lt. Screenshot ähnlichen Einstellungen) knapp das dreifache...

Kann es sein, daß die Anzahl der Objekte bei nV-Karten den Ausschlag gibt? Bsw. wird ja das FP16-Format vom nV30 nicht unterstützt. Möglicherweise wird die Szene anders gerendert - bsw. für ATi alle Objekte gemeinsam in die verschiedenen MRT - für den nV30 ging das nicht - eventuell musste man hier jedes Objekt separat rendern und durch eine spassige ID-Erkennung ist nun auch der nV40 betroffen??


Bitte um Aufklärung (auch an Lolman bezgl. des Bildes vom Schädel - welche Settings?).

edit:
Bitte ignorieren - hatte das 4xMS übersehen!

[Mr. Lolman]

Aber schau auch mal, welche Fläche von Objekten belegt wird, und welche lediglich die Hintergrund-Cubemap zeigt. Auch wenn es viele Polygone sind, die Füllratenanforderungen sind moderat und die Tiefenkomplexität viel zu gering, um mit einem Spiel verglichen zu werden.

Ok da wirst du wohl recht haben, aber selbst wenn ich das FOV maximiere, und dann von unten durch den Totenschädel durchschau, so dass die ganze Bildfläche vom Schädel verdeckt wird hab ich noch 10Mio Polys/sec.

Aber das ist ohnehin alles hypothetisch, denn ohne Alphablending kommt man nicht allzu weit. Andererseits wundere ich mich immernoch warum der HDR ähnliche Effekt des Paradise Rendermode nicht weiterentwickelt wurde. Denn der bringt deutlich bessere Performance, auch einen adaptiven Kontrast und AA ist auch noch möglich.

Ausserdem frag ich mich, warum der Farcry Typ im SM3.0 Präsentationsvideo betont hat dass die Effekte mit SM2.0 auch möglich sind, als der NV Fuzzi mit den HDR Effekten bei Farcry geprahlt hat.

[Mr. Lolman]

edit:
Bitte ignorieren - hatte das 4xMS übersehen!

Ok. Ich hab ausserdem nicht auf max mögliche Performance geachtet. (PC war untertaktet, und 100000 Programme offen)

[Quasar]

Ok. Ich hab ausserdem nicht auf max mögliche Performance geachtet. (PC war untertaktet, und 100000 Programme offen)
Dito - trotzdem kommt's mir komisch vor (auch wenn es nicht die dreifache Performance ist), daß 'wir' bei der Planet-Szene quasi gleichauf liegen und mit dem Schädel in ähnlicher Position sich das Verhältnis doch etwas ändert.

Könnte man ja mal versuchsweise eruieren...

[Mr. Lolman]

Szene sofort gestoppt, auf Totenkopf gewechselt und die Kamera aufs Gesicht gerichtet, sonst nix geändert:

[Quasar]

Welche Taktraten / Treiber?
edit:
Bitte mit 3DA - die Stats schauen seeehr interessant aus...

[Demirug]

So ich habe mir mal angeschaut wie der HDR Filter bei FC im Detail arbeitet.

Das sieht aus wie mit dem R3XX/NV3X angefangen, dann aufgegeben und als man einen NV40 hatte einfach noch ein bischen hingefummelt. Da wird Leistung verschwendet das ist schon nicht mehr schön.

[Mr. Lolman]

400/350, Catalyst 4.11b:

http://img19.exs.cx/img19/6374/Untitled-319.jpg

[Mr. Lolman]

So ich habe mir mal angeschaut wie der HDR Filter bei FC im Detail arbeitet.

Das sieht aus wie mit dem R3XX angefangen, dann aufgegeben und als man einen NV40 hatte einfach noch ein bischen hingefummelt. Da wird Leistung verschwendet das ist schon nicht mehr schön.


So ähnlich dacht ich mir das nämlich. Also wärs theoretisch möglich auch mit R3x0 Karte in FC HDR zu haben!?

BTW: Kannst du dir auch den "verbessert" und den "Paradise" rendermode mal genauer ansehen? Ich bin mir ziemlich sicher, dass man mit einem leicht abgeänderten Paradise Rendermode das "bessere" HDR realisieren könnte...

[Gast]

So ähnlich dacht ich mir das nämlich. Also wärs theoretisch möglich auch mit R3x0 Karte in FC HDR zu haben!?


Wenn die spf als Geschwindigkeitsmaß genügen, ja.

[Demirug]

So ähnlich dacht ich mir das nämlich. Also wärs theoretisch möglich auch mit R3x0 Karte in FC HDR zu haben!?

Ja und Nein. Die Filterendstufe könnte man leicht für einen R3XX/R4XX modifizieren. Das Alphablending Problem bleibt aber. Das müsste man mit dem oben beschriebene Verfahren emulieren. Das würde sich schlecht auf die Performances auswirken.

Das schlecht optimiert bezog sich auf die Endstuffe. Von den 46 Shaderpasses könnte man wohl 16 einsparen (beim NV40). Und von den verbleibenden noch ein paar beschleunigen weil dort "falsche" Shader benutzt werden.

BTW: Kannst du dir auch den "verbessert" und den "Paradise" rendermode mal genauer ansehen? Ich bin mir ziemlich sicher, dass man mit einem leicht abgeänderten Paradise Rendermode das "bessere" HDR realisieren könnte...

Da habe ich gerade kein aufgezeichnetes Archiv zur Hand. Die sind leider immer so gross das man davon nicht viele gleichzeitig auf der Platte haben kann.

[Quasar]

400/350, Catalyst 4.11b:

http://img19.exs.cx/img19/6374/Untitled-319.jpg

http://img117.exs.cx/img117/3302/Bonk3.jpg
Nicht 100% getroffen, aber scheint halbwegs zu passen, von der Poli/Bild-Anzahl ausgehend.

Meine 6800 habe ich entsprechend auf 200/350 getaktet, Treiber war der 66.93 @ HQ.
Preisfrage:
Wo liegen die SIGNIFIKANTEN Unterschiede? ;)

edit:
Aus der FAQ von 3DA:

counters -> zeigt 6 Zähler:
Frames pro Sekunde
Polygone pro Bild
Polygone pro Sekunde
VRAM Auslastung (nur bei DirectX)
Overdraw nach Z-Test (nur bei DirectX 9.0)
Gezeichnete Pixel pro Bild nach Z-Test (nur bei DirectX 9.0)

edit2:
Nein, es ist nicht die Tatsache, daß ich im Fenstermodus war - Fullscreen ist es sogar noch deutlicher - und ich habe 1fps mehr...

[Mr. Lolman]

Ja und Nein. Die Filterendstufe könnte man leicht für einen R3XX/R4XX modifizieren. Das Alphablending Problem bleibt aber. Das müsste man mit dem oben beschriebene Verfahren emulieren. Das würde sich schlecht auf die Performances auswirken.


Wieviel Shaderpasses bäuchte man demnach ca. wenn man das Alphablending mit den Pixelshadern emuliert und sonst optimalen Code vorliegen hat?


Wo liegen die SIGNIFIKANTEN Unterschiede? ;)


Dein Bild ist weicher/unschärfer/verwaschener. Weniger fps und mehr Overdraw. Kannst du auch mit original Takt benchen, und/oder die Karte soweit hochtakten, das die fps gleich sind?

[Demirug]

Wieviel Shaderpasses bäuchte man demnach ca. wenn man das Alphablending mit den Pixelshadern emuliert und sonst optimalen Code vorliegen hat?

Das hängt davon ab wie viele Objektepasses jeweils mit Alphablendig gerendert werden müssen. Für jedes dieser Passes muss ein zusätzlicher eingefügt werden. Gerade in den Aussenlevels sind das recht viele.

[Quasar]

Kannst du auch mit original Takt benchen, und/oder die Karte soweit hochtakten, das die fps gleich sind?
Das habe ich aus Versehen beim ersten Versuch gemacht - irgendwie hatte ich mit zwölf Pipes gerechnet und kam dabei natürlich auf 266MHz - damit (aber eben auch mit 16Pipes) hatte ich dann fast exakt deine FPS.

[betasilie]

Wieviel Shaderpasses bäuchte man demnach ca. wenn man das Alphablending mit den Pixelshadern emuliert und sonst optimalen Code vorliegen hat?
Würde mich auch interessieren. Besonders da es ja Videos auf Giga von FarCry gab, afair, einige Zeit vor dem Release und eine ganze Zeit bevor es den den NV40 gab. Lief das Spiel da mit einem R300? Wenn ja, kann er ja nicht so schlecht performen mit HDR. :confused:

[marco42]

Bei 3dlabs soll die entsprechenden Einheit angeblich programmierbar sein. Allerdings gibt es keine Extension dafür.


3dlabs besitzt ja geruechteweise auch hardware noise einheiten. das fehlt mir beim nv40 wirklich. mag ja fuer spieler noch nicht so interessant sein, aberich vermisse es sehr.


Für WGF war auch mal im Gespräch das man die (Pixel)shader auf den aktuellen Zielbuffer zugreifen lassen möchte. Allerdings ist es im Bezug auf diesen Punkt eher ruhig geworden.

naja, das killt halt die performance einer langen pipeline. ich bin mir aber nicht so sicher ob eine kurze pipeline besser ist. deswegen bin ich sehr skeptisch bei der allseits propagierten generalisierung. die GPU's ziehen ihre geschwindigkeit doch gerade aus ihrer einfachheit. mal schauen wie sich das entwickelt. mal sehen ob es einen erweiteren VS gibt odere mehrere Topologieshader, oder so. ich faende ja einen VS, wo punkte generiert oder verworfen werden koennten besser, als da mehrere spezialisierte einheiten hintereinander zu stellen.

[Demirug]

Würde mich auch interessieren. Besonders da es ja Videos auf Giga von FarCry gab, afair, einige Zeit vor dem Release und eine ganze Zeit bevor es den den NV40 gab. Lief das Spiel da mit einem R300? Wenn ja, kann er ja nicht so schlecht performen mit HDR. :confused:

Wenn ich den Sourcecode hätte würde ich es ja mal schnell einbauen. Ohne diesen ist es aber problematisch weil man dann zusätzlich noch ein paar andere NV40 Features (SM3, DST) emulieren müsste.

[Quasar]

Dein Bild ist weicher/unschärfer/verwaschener. Weniger fps und mehr Overdraw. Kannst du auch mit original Takt benchen, und/oder die Karte soweit hochtakten, das die fps gleich sind?
Hm..... auch auf 375MHz bekomme ich grad mal 38fps - 50% des Mehrtaktes im Vergleich zu 200MHz-GPU verpuffen anscheinend irgendwo (in der Bandbreite?).

So langsam werd' ich das Gefühl nicht mehr los, das RTHDRIBL auf nV und ATi auf unterschiedlichen Wegen zum Ziel kommt.

[aths]

So ich habe mir mal angeschaut wie der HDR Filter bei FC im Detail arbeitet.

Das sieht aus wie mit dem R3XX/NV3X angefangen, dann aufgegeben und als man einen NV40 hatte einfach noch ein bischen hingefummelt. Da wird Leistung verschwendet das ist schon nicht mehr schön.Das hatte ich befürchtet.

[Demirug]

BTW: Möchte jemand die Effektcascade (also wie die Daten für den FS Effekt verarbeitet werden) für den Farcry HDR Effekt haben?

[RLZ]

BTW: Möchte jemand die Effektcascade (also wie die Daten für den FS Effekt verarbeitet werden) für den Farcry HDR Effekt haben?
Jup
Ich bitte darum :)

[IVN]

BTW: Möchte jemand die Effektcascade (also wie die Daten für den FS Effekt verarbeitet werden) für den Farcry HDR Effekt haben?

Me to. =)

[Quasar]

JA, auch wenn ich vermutlich nicht viel damit anfangen kann...

[mapel110]

*anschliess*

[Mr. Lolman]

Leider ist es aber verboten die gleiche Texture gleichzeitig als Ziel und Quelle in einem Pass zu benutzen

Angenommen, man setzt sich über das Verbot hinweg. Was hat man zu befürchten? :D

[Xmas]

Angenommen, man setzt sich über das Verbot hinweg. Was hat man zu befürchten? :D
Dass auf dem Bildschirm nichts erscheint oder das Programm mit einer Fehlermeldung abbricht. Direct3D lässt dies nicht zu, aus gutem Grund. Denn aufgrund der Pipeline-Struktur kann man nicht garantieren, dass der Framebuffer-Inhalt den "korrekten" Stand wiedergibt.

[Demirug]

Für alle die es haben wollten. http://www.forum-3dcenter.org/vbulletin/showthread.php?t=183257

[Coda]

Angenommen, man setzt sich über das Verbot hinweg. Was hat man zu befürchten?
Es ist ganz einfach, warum das keinen Sinn macht. Du kannst in DX9 Pixelshadern von beliebigen Positionen in Texturen samplen. D.h. wenn Input=Output könntest du von Positionen samplen, die schon vom neuen Wert beschrieben wurden, was sicher nicht gewünscht ist.
Und in welcher Reihenfolge die Pixel geschrieben werden ist ja auch nirgends definiert, z.B. rendert die neue Generation von ATi und nVidia mit Quads, aber ob XGI, S3 und PowerVR das auch so machen ist nicht gesagt. Aber auch die Reihenfolge der Quads oder Pixel kann von links nach rechts oder rechts nach links laufen, das ist völlig egal.