HDR und FSAA irgendwie möglich?

[crayzee]

Hey!!

Habe im Moment eine Radeon Grafikkarte und wollte mir die 7900GTO zulegen.

Ich wollte vorher wissen, ob es vielleicht irgendwie möglich ist, Antialiasing UND HDR zu benutzen? Das soll ja bei den Geforce Karten nicht gehn, richtig?

Gibts da vielleicht irgendwelche Tools die das ermöglichen?

Angenommen ich spiel mit allen Details auf 1280*1024, brauch ich dann überhaupt AA und AF? Also dass es im Endeffekt gar keine Rolle spielt, ob beides geht oder nicht?

Gruß

[Gast]

es ist mit aktuellen geforce-karten nicht möglich FSAA+HDR gleichzeitig zu verwenden (mal außnahmen wie das pseudo-hdr der source-engine).

ob du beides brauchst kann dir keiner beantworten, bei aktuellen pixelgrößen am monitor wirst du auf jeden fall einen unterschied feststellen können.

[crayzee]

Was haltet ihr von der X1950Pro? Die ist auch recht gut oder? dafür kostet sie nur 170€

[TheGoD]

Macht zwar praktisch kaum einen Sinn, aber kann man kein Super Sampling in Verbindung mit HDRR nutzen?

[Rente]

Super-Sampling Anti-Aliasing funktioniert mit HDRR zusammen, kostet aber immens Leistung, erst der G80 wird mit ziemlicher Sicherheit MSAA (so das man SSAA garnicht erst einsetzen muss) und HDRR kombinieren können und dabei noch ausreichend schnell sein.

Die X1950 Pro ist zu diesem Preis durchaus attraktiv und sie kann MSAA und HDRR, was die GTO nicht kann. Sie hat allerdings den Nachteil einer niedrigeren Füllrate und "nur" 256MB VRam.

P.S.: Das HDRR der Source Engine 1/2 ist kein Pseudo-HDRR...

[Gast]

Macht zwar praktisch kaum einen Sinn, aber kann man kein Super Sampling in Verbindung mit HDRR nutzen?

prinzipiell ja, allerdings muss das die anwendung (wie eigentlich bei jeder form von HDRR+FSAA) machen. das ganze wird beispielsweise bei age of empires 3 gemacht, und macht dort auch sinn da das spiel ziemlich stark cpu-limitiert ist, so dass zumindestens den starken karten der geforce7-serie das SSAA nicht viel ausmacht.

[Gast]

"Angenommen ich spiel mit allen Details auf 1280*1024, brauch ich dann überhaupt AA und AF? Also dass es im Endeffekt gar keine Rolle spielt, ob beides geht oder nicht?"

der unterschied ist zu sehen

[(+44)]

Und wie der zu sehn ist.

Ich komm ohne FSAA und besonders AF garnichmehr klar - ich spiele grundsätzlich in 4xSSAA und 16xAF.

Selbst in 1600x1200 auf nem 17"-Monitor erkenne ich ohne FSAA deutliche Treppenbildung - in 1280x960 ist FSAA für gute BQ also ein MUSS.
Ebenso wie AF IMHO ein MUSS ist, denn sonst verschwimmt alles nach hinten in einem widerlichen Texturbrei.

[Gast]

4xSSAA geht nur bis 1024er Auflösung, denke du meinst das normale MSAA ;=)

[DrFreaK666]

prinzipiell ja, allerdings muss das die anwendung (wie eigentlich bei jeder form von HDRR+FSAA) machen. das ganze wird beispielsweise bei age of empires 3 gemacht, und macht dort auch sinn da das spiel ziemlich stark cpu-limitiert ist, so dass zumindestens den starken karten der geforce7-serie das SSAA nicht viel ausmacht.

Was heisst nicht viel??
Die Radeons sind in dieser Einstellung ein ganzes Stück schneller.
CPU-Limitierung hin oder her

4xSSAA geht nur bis 1024er Auflösung, denke du meinst das normale MSAA ;

Das stimmt nicht. 4xSSAA geht theoretisch auch bei 2048x1536.
Nur 16xSSAA (also 4x4) ist auf 1024 limitiert

[Mr. Lolman]

P.S.: Das HDRR der Source Engine 1/2 ist kein Pseudo-HDRR...

Doch. Denn der Dynamic Breich ist zu gering. Erst mit FP16 kann man von echtem HDRR sprechen und das funzt auf aktuellen NV-Karten nunmal nicht mit AA.

[crayzee]

Hallo!!

Was redet ihr eigentlich immer von FSAA, MSAA und SSAA??
Was ist da der Unterschied?!

[deekey777]

Doch. Denn der Dynamic Breich ist zu gering. Erst mit FP16 kann man von echtem HDRR sprechen und das funzt auf aktuellen NV-Karten nunmal nicht mit AA.
Der Dynamik-Bereich is zu gering? Jetzt bist du eine Erklärung schuldig.
Die HDR-Texturen liegen im FP16- bzw. INT16-Format vor. Die Pixelshader rechnen eh mit mind. FP24-bit-Genauigkeit. Was nicht verwendet wird, sind FP16-Buffer, womit der dynamische Umfang noch breiter wäre, was aber für die Source-Engine ausreicht.
Leider gibt es da einen Nachteil bei deren Methode und zwar bei den Refractions: Transparente Objekte/Texturen lassen keine HDR-Informationen durch (schaut in die Farbglasfenster (Lost Coast) in der Kirche und zerschießt diese dann).
Hallo!!

Was redet ihr eigentlich immer von FSAA, MSAA und SSAA??
Was ist da der Unterschied?!
http://www.3d-center.de/artikel/anti-aliasing/

[Mr. Lolman]

FSAA ist Full Scene Anti Aliasing, also praktisch immer SSAA weils noch keine andere Alternative gibt, das gesamte Bild zu glätten.

SSAA ist Super Sampling Anti Aliasing, bei dem das gesamte Bild in ner höheren Auflösunge gerendert wird.
Vorteil: das gesamte Bild wird geglättet
Nachteil: Sehr Leistungsfordernd (2xSSAA = 50% weniger Füllrate) und wegen supoptimaler Subpixelverteilung keine schöne Kantenglättung

z.B. hat man beim 4xSSAA um 75% weniger Füllrate, da das Bild in x und y Achse in doppleter Auflösung berechnet wird. Trotzdem hat man an den Katen nur 1 Zwischenstufe zur Glättung. (Nur 3dfx und S3 erlaub(t)en eine optimal Subpixelverteilung, wo beim 4xSSAA dann auch 3 Zwischenstufen vorhanden waren)

MSAA ist der heute am gebräuchlichste Modus. Dabei werden nur Polygonkanten geglättet
Vorteil: hohe Performance
Nachteil: Nur Polygonkanten werden geglättet. Für Texturkanten brauchts zusätzlich AAA/TSSAA, welches bei exzessiven Einsatz von Alphatests(->führt zu Texturkanten) die Performance wieder auf SSAA Niveau drücken kann.

Der Vorteil von AAA/TSSAA ggü SSAA ist die bessere Subpixelverteilung, und die Content abhängige Performance (nur dann langsam wenns wirklich viel zu glätten gibt), der Nachteil ist dass die nicht transparenten Texturen nicht mitgeglättet werden. (Für die gibts aber eh AF)

Mehr Infos: http://www.3dcenter.org/artikel/anti-aliasing/

[Mr. Lolman]

Der Dynamik-Bereich is zu gering? Jetzt bist du eine Erklärung schuldig.
Die HDR-Texturen liegen im FP16- bzw. INT16-Format vor. Die Pixelshader rechnen eh mit mind. FP24-bit-Genauigkeit. Was nicht verwendet wird, sind FP16-Buffer, womit der dynamische Umfang noch breiter wäre, was aber für die Source-Engine ausreicht.

Für echtes HDRR muss man:

HDR-Eingangsdaten lesen.
Eingangsdaten in einem HDR-tauglichen Zahlenformaten verrechnen.
Daten im HDR-Format zwischenspeichern.
Vom im Schritt 3 angelegten Zwischenspeicher Kenngrößen (z. B. den Mittelwert) feststellen.
Die im Schritt 3 angelegten Zwischendaten je nach im Schritt 4 ermittelten Parametern auf ein vom Monitor darstellbares LDR-Format umrechnen.
http://www.3dcenter.org/artikel/2006/01-01_c.php

[The_Invisible]

Was heisst nicht viel??
Die Radeons sind in dieser Einstellung ein ganzes Stück schneller.
CPU-Limitierung hin oder her

dafür rennts bei mir recht gut in 1680x1050/HDR/max/SSAA ;)

die x1800er sucken zudem recht derbe in AoE3

mfg

[cl55amg]

Euch ist natütlich klar das NV und ATI bei AOE3 unterschiedliche HDR Modi verwenden?
Bei ATI einen schlechteren, deshalb ist die Performace beser...

[Rente]

Euch ist natütlich klar das NV und ATI bei AOE3 unterschiedliche HDR Modi verwenden?
Bei ATI einen schlechteren, deshalb ist die Performace beser...
Und bei NV wird SSAA verwendet um Kanten zu glätten, wenn angewählt, bei ATi "nur" MSAA.

[deekey777]

Euch ist natütlich klar das NV und ATI bei AOE3 unterschiedliche HDR Modi verwenden?
Bei ATI einen schlechteren, deshalb ist die Performace beser...
Warum soll das in AoE3 verwendetet 1010102-Format bzw. das damit erzielte Ergebnis schlechter sein?
Für echtes HDRR muss man:

HDR-Eingangsdaten lesen.
Eingangsdaten in einem HDR-tauglichen Zahlenformaten verrechnen.
Daten im HDR-Format zwischenspeichern.
Vom im Schritt 3 angelegten Zwischenspeicher Kenngrößen (z. B. den Mittelwert) feststellen.
Die im Schritt 3 angelegten Zwischendaten je nach im Schritt 4 ermittelten Parametern auf ein vom Monitor darstellbares LDR-Format umrechnen.
http://www.3dcenter.org/artikel/2006/01-01_c.php
Zunächst: Meine Frage war, warum das HDRR nach Source kein HDRR ist, da der Umfang zu gering sei.
Weiterhin ist aths'Aufzählung nicht einschränkend oder absolute Pflicht. Bei Source'schem HDRR wird auf den FP16-Framebuffer verzichtet, weil es nicht nötig ist und für die Source-Spiele ausreichend ist.
Man könnte so frech sein und seine Liste so ergänzen, dass HDRR erst dann gegebn ist, wenn die Bildausgabe 10-bittig pro Kanal sein muss (30 bit vs. 24 bit).

[Mr. Lolman]

Weiterhin ist aths'Aufzählung nicht einschränkend oder absolute Pflicht. Bei Source'schem HDRR wird auf den FP16-Framebuffer verzichtet, weil es nicht nötig ist und für die Source-Spiele ausreichend ist.
Man könnte so frech sein und seine Liste so ergänzen, dass HDRR erst dann gegebn ist, wenn die Bildausgabe 10-bittig pro Kanal sein muss (30 bit vs. 24 bit).

AFAIK ist es erst dann HDR, wenn der Dynamikumfang ~96dB beträgt. Wenn man aber den Framebuffer als FX16 oder gar FX10 speichert, hat man im nächsten Rechenschritt nicht mehr die 96dB und demnach ists bestenfalsl nur mehr MDR.

[cl55amg]

Allerdings sind jene Modi nicht gleichwertig, da bei nVidia-Grafikkarten hochwertiges FP16-HDR zum Einsatz kommt, während die ATi-Pendants der X1000-Serie nur INT10-HDR liefern.

Entweder ATI nutzt mittlerweile auch FP16 HDR, oder man kann es schlecht vergleichen...

Und bei NV wird SSAA verwendet um Kanten zu glätten, wenn angewählt, bei ATi "nur" MSAA.

habe ich AA oder HDR Modi geschrieben?

[Gast]

Entweder ATI nutzt mittlerweile auch FP16 HDR, oder man kann es schlecht vergleichen...Auf ATI-Karten wird weiterhin der FX10-Modus verwendet.

[deekey777]

AFAIK ist es erst dann HDR, wenn der Dynamikumfang ~96dB beträgt. Wenn man aber den Framebuffer als FX16 oder gar FX10 speichert, hat man im nächsten Rechenschritt nicht mehr die 96dB und demnach ists besten Fall nur mehr MDR.

Der HDRR-Weg sieht in etwas so aus:
Die Szene wird in HDR berechnet und in den Framebuffer in einem FP-Format geschrieben, dann kommt das Post-Processing in HDR (die PP-Effekte werden mit HDR berechnet, also mit hoher Dynamik), dann kommt das Tonemapping (das Herunterrechnen von HDR auf LDR*, da es keine Ausgabegeräte für diesen sehr hohen dynamischen Umfang gibt). Erst nach dem Tonemapping liegt die Szene mit LDR vor.


€: Bei der Source-Engine gibt (gab?) es die Möglichkeit wie oben (HDR-Methode Nr. 3). Nur wurde diese durch die aktuelle ersetzt (Meth. 4). Und es reicht für Lost Coast und weitere Source-Spiele aus. Der Dynamikumfang ist geringer als bei der dritten Methode aber höher als in HL2. Wenn ich der einen aths'schen Rechnung glauben kann, ist der Dynamikumfang von INT16 höher als bei FP16 aber deutlich niedriger als bei FP16+Denorm (so etwa um das Tausendfache). Ist aber egal, da hier nur 8-bit-Buffer benutzt wird und vorher muss alles in den PS gemacht werden (bitte um Korrektur, wenn falsch).


*Bei der X1000er Serie auch auf 10 Bit möglich.

[cl55amg]

Auf ATI-Karten wird weiterhin der FX10-Modus verwendet.

Dachte ich mir auch. Damals bei erscheinen des Games (da kam auch die x1900xtx) haben das viele nicht gewusst weil sie sie sich bei CB nur die Balken angesehen haben...

Man kann festhalten das der Vergleich hier in jedem Fall nicht möglich ist.

[Gast]

Man kann festhalten das der Vergleich hier in jedem Fall nicht möglich ist.Richtig. Das war wohl auch der Grund weshalb CB AoE3 in aktuellen Reviews nicht mehr zum Benchen einsetzt.

[Gast]

Warum soll das in AoE3 verwendetet 1010102-Format bzw. das damit erzielte Ergebnis schlechter sein?



dass FX10 weniger dynamik als FP16 bietet sollte eigentlich jedem einleuchten oder?

[deekey777]

dass FX10 weniger dynamik als FP16 bietet sollte eigentlich jedem einleuchten oder?
Lies nocheinmal das, was und wie ich es geschrieben habe, insbesondere "Warum soll das in AoE3 verwendete 1010102-Format bzw. das damit erzielte Ergebnis schlechter sein?".
Zu Verdeutlichung: Warum soll in diesem Fall, also im Fall des AoE3, das visuelle Endergebnis schlechter sein als mit FP16?

[Razor]

Eigentlich ist das Thema "AoE3 und unterschiedliche Implementierungen von HDR" mit dem Kommentar von cl55amg erledigt...
...oder?

Man kann festhalten das der Vergleich hier in jedem Fall nicht möglich ist.

Razor

[deekey777]

Eigentlich ist das Thema "AoE3 und unterschiedliche Implementierungen von HDR" mit dem Kommentar von cl55amg erledigt...
...oder?



Razor
Eigentlich nicht, denn auf meine Frage hat er nicht geantwortet.

Als absoluter FanATiAMDiker würde ich noch eine Frage in die Diskussion reinwerfen, warum nVidia seit zwei Generationen (NV40/G70) dieses 10-bit-Format nicht unterstützt, wo dieses weit verbreitet ist (OpenEXR hat sich bisher nicht durchsetzen können)?
Ich will nicht bestreiten, dass das "FP16-HDR" dem 1010102 überlegen ist, aber es kommt auch auf den Einzelfall an. Wenn man es andersherum dreht, könnte man sagen, dass nVidia selbst schuld ist, dass alles mit FP16 gemacht werden muss, sollte 1010102 in AoE3 ausreichend sein.

[cl55amg]

Ich verstehe nicht genau was du meinst?
Man kann ja auch sagen das man für einen "Überblend Effekt" kein HDR braucht?

Warum also überhaupt HDR?

Euch ist natütlich klar das NV und ATI bei AOE3 unterschiedliche HDR Modi verwenden?
Bei ATI einen schlechteren, deshalb ist die Performace beser...

Ich präzesiere meine Aussage:

ATIs genauigkeit beim HDR-R in AOU3 ist "geriger" (Synonym von "schlechter").
Ob das nun subjektiv schlechter aussieht kann ich nicht beurteilen, da ich es noch nicht auf einer ATI gesehen habe.

In weit es Theoretisch schlechter oder gleich aussehen müsste hängt ja von verschieden Faktoren ab.

[Gast]

wo dieses weit verbreitet ist (OpenEXR hat sich bisher nicht durchsetzen können)?


sorry, aber OpenEXR ist wesentlich verbreiteter als dieses komische FX10-format, außer AOE3 fällt mir gerade nichts ein was dieses seltsame format verwendet.

[Gast]

Wenn ich der einen aths'schen Rechnung glauben kann, ist der Dynamikumfang von INT16 höher als bei FP16 aber deutlich niedriger als bei FP16+Denorm (so etwa um das Tausendfache).

ein FP-format gleicher größe hat immer einen höheren dynamikumfang als ein INT-format, weshalb sollte man denn sonst FP verwenden? natürlich geht das ganze auf kosten der genauigkeit.

ich kann mir auch nicht vorstellen das aths einen solchen unsinn verbreitet, im gegensatz zu dir versteht er wie ein FP-format funktioniert.

[Hvoralek]

Die HDR-Texturen liegen im FP16- bzw. INT16-Format vor.Wozu INT16, wenn man FP16 hat? Ach Moment, für die X1xxxer, weil Valve denen keine Filterung der FP- Texturen im Shader antun möchte?

Was nicht verwendet wird, sind FP16-Buffer, womit der dynamische Umfang noch breiter wäre, was aber für die Source-Engine ausreicht.Wenn FP16 in dem Fall nicht besser als FX8, warum hat Valve dann erst so spät einen FX8- Modus implementiert?

Wenn ich der einen aths'schen Rechnung glauben kann, ist der Dynamikumfang von INT16 höher als bei FP16 aber deutlich niedriger als bei FP16+Denorm (so etwa um das Tausendfache).Auf welche Rechnung von aths beziehst Du Dich? Bei FX 16 komme ich auf eine Dynamik von 2^16 - 1 = 16383. Die von FP16 ohne Denorms liegt im Mrd- Bereich.

sorry, aber OpenEXR ist wesentlich verbreiteter als dieses komische FX10-format, außer AOE3 fällt mir gerade nichts ein was dieses seltsame format verwendet.Auf der Xbox 360 dürften fast alle Spiele dieses FP10- Format nutzen, sofern sie nicht viele Transparenzabstufungen brauchen. Da gibt es aber auch kaum Alternativen, FP16 kann Xenos mW nicht und FX16 ist diesem FP10 nicht so weit überlegen, dass der Aufwand sich lohnen würde.

[deekey777]

sorry, aber OpenEXR ist wesentlich verbreiteter als dieses komische FX10-format, außer AOE3 fällt mir gerade nichts ein was dieses seltsame format verwendet.
Wenn es um Spiele geht, ja. 10-bit-Formate werden seit dreizehn Jahren in der Film- und Fotoindustrie benutzt (Cineon), das OpenEXR entstand erst Ende der 90er.

[Gast]

Wen juckts, mit der neuen Generation is FP16 angesagt für HDR ;)
Bei NV40 hat man die HDR Möglichkeiten soweit damals möglich ja eingebaut, auch wenn die Tonemapping Unit irgendwie verloren ging. G70 war ja "nur" ein zwischenschritt damit der NV50/G80 später kommen konnte, da ja Vista/DX10 sich verschoben hat.
Da hat man bei NV halt gespart, ATI hat sich dafür beim Sprung von R300 auf R420 kein Zacken aus der Krone gebrochen, das war sicher auch eine kostengünstige Erweiterung und keine Rundumerneuerung wie der R520.

[deekey777]

Wozu INT16, wenn man FP16 hat? Ach Moment, für die X1xxxer, weil Valve denen keine Filterung der FP- Texturen im Shader antun möchte?

Und wenn VALVe nur auf INT16 Texturen gesetzt hätte...
Zur Erinnerung: Die vierte Methode (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3509064&postcount=308) unterteilt sich insoweit, dass für Grafikkarten, die FP16-Filterung beherrschen, die Texturen in einem FP16-Format gespeichert sind, für andere Grafikkarten liegen diese im INT16 vor. Vorteil: MSAA, kaum langsamer als LDR. Nachteil: geringerer Dynamikumfang, Probleme mit Refraktionen.

Wenn FP16 in dem Fall nicht besser als FX8, warum hat Valve dann erst so spät einen FX8- Modus implementiert?
Was hat das mit meinem Satz zu tun, den du zitiert hast? Und wo steht, dass FP16-HDR nicht besser sei? Mein Gott, selbst VALVe sagt, dass FP16-HDR die Zukunft ist.
Aber die Erklärung ist ganz einfach: Diese Methode funktioniert auf allen DX9-Grafikkarten, die diese Bezeichnung tragen dürfen. Und MSAA hat man auch noch. Warum sie so spät kam, obwohl die dritte Methode lange fertig war? Hm, weil diese Methode entweder länger zu entwickeln war oder viel später damit begonnen wurde (wohl nach der E³ 2005).

Auf welche Rechnung von aths beziehst Du Dich? Bei FX 16 komme ich auf eine Dynamik von 2^16 - 1 = 16383. Die von FP16 ohne Denorms liegt im Mrd- Bereich.
Fehler meinerseits. :redface:

Auf der Xbox 360 dürften fast alle Spiele dieses FP10- Format nutzen, sofern sie nicht viele Transparenzabstufungen brauchen. Da gibt es aber auch kaum Alternativen, FP16 kann Xenos mW nicht und FX16 ist diesem FP10 nicht so weit überlegen, dass der Aufwand sich lohnen würde.
FP16 kann der Xenos schon, er rechnet gar mit FP32. Was er nicht kann, ist FP16-Alphablending in HW, was im Pixelshader simuliert werden muss, was keiner macht.

Lesenswert: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=253113

[Hvoralek]

Was hat das mit meinem Satz zu tun, den du zitiert hast? Und wo steht, dass FP16-HDR nicht besser sei? Mein Gott, selbst VALVe sagt, dass FP16-HDR die Zukunft ist.Du meintest, dass ein FX8- Framebuffer für Source "ausreichen" würde. Ich verstehe dass so, dass es keinen wahrnehmbaren Unterschied zwischen den beiden Modi gibt. Wenn ein FP16- Puffer aber keine Vorteile bringt, warum hat Valve dann schon so frühzeitig daran gearbeitet und erst später mit einer FX8- Version begonnen? Deren Vorteile sind klar (das kann alles ab R300, keine Probleme mit MSAA auf NV4x, geringere Leistungseinbußen). Aber gerade da stellt sich doch die Frage: Wenn diese schnellere und bessere kompatible Variante wirklich genau so gut wäre wie FP16, warum dann nicht gleich so, sondern erst im vierten Anlauf?

FP16 kann der Xenos schon, er rechnet gar mit FP32. Was er nicht kann, ist FP16-Alphablending in HW, was im Pixelshader simuliert werden muss, was keiner macht.Auch die R3xx/R4xxer "können" FP16 (und sogar FP24), wenn man per Shader blendet. Das kann man in der Praxis aber als "nicht können" ansehen; ich wüsste nicht einmal von Techdemos, in denen das tatsächlich gemacht worden wäre.

[Gast]

FP16 kann der Xenos schon, er rechnet gar mit FP32. Was er nicht kann, ist FP16-Alphablending in HW, was im Pixelshader simuliert werden muss, was keiner macht.



was auch in anbetracht des eDRAM extrem dämlich wäre, die bandbreite zum hauptspeicher ist ja nicht wirklich hoch.