Nochmal, ALLE DircetX 9 faehigen Karten koennen HDRR "anzeigen".
Aber die Leistung ist dementsprechend schlecht. Also kann zB. eine ATI Radeon 9700 Pro HDRR bieten aber man hat dann wohl eine Diashow.

Am besten man gibt unter Google HDRR ein und sucht danach. Oder man geht auf Wikipedia und liest dort auch noch darueber. Aus den Infos kann man sich dann ein Bild zusammenschustern.
Ist jetzt die dritte Disskusion ueber HDRR innerhalb zwei Wochen. Wurde das nicht alles schon geklaert?

Und warum die nVidia das nicht koennen hat einen Grund. Lest es nach. Hat was mit der Genauigkeit zu tun bei denen nVidia vorne liegt.
ATI hat nur einen Kopromiss getroffen.

Hier ein kleines Zitat:
Da jede DirectX9-Grafikkarte im Pixelshader mindestens FP24-Genauigkeit unterstützen muss, und jede relevante DirectX9-Karte auch FP32-Texturen einlesen kann, ist dynamisches HDR-Rendering im Prinzip auf jeder DirectX9-Karte möglich. Die Frage ist nur, zu welchem Preis. Analysieren wir die Arbeitsschritte:

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.
Bei Schritt 1 ist die Frage, welche Daten in hoher Dynamik vorliegen müssen, konkret ob man auch HDR-Texturen braucht (Vertex-Daten können sowieso in hoher Dynamik angegeben werden, das gilt auch für die beleuchtete Materialfarbe). Sofern man HDR-Texturen braucht, muss man fragen, ob man diese filtern muss. Texturfilterung findet in der TMU statt. Lightmaps sollte man grundsätzlich filtern. Um die Rechenlast zu reduzieren, sollten statische Lichteinflüsse nach wie vor als Lightmap vorliegen. Damit benötigt man für HDR-Rendering also "HDR-TMUs".

Bei 2. haben wir kein Problem, da FP24-Genauigkeit eine für unsere Zwecke extrem hohe Dynamik bietet.

3. ist zunächst unproblematisch, denn ein FP16-Format als Rendertarget bieten alle wichtigen DirectX9-Karten. Wenn es zum Alphablending kommt, müssen natürlich "HDR-Alphablender" vorhanden sein.

4. Zur Mittelwertbildung könnte man die Automipmapping-Funktion der GPU nutzen, welche wiederum auf die bilineare Texturfilterung zurückgreift. Dazu brauchen wir wieder "HDR-TMUs".

5. Das Herunterrechnen von HDR auf LDR, kurz "Tonemapping", könnte mit einer dedizierten Unit gemacht werden – wenn es die denn gäbe. Mangels Tonemapper muss dies im Pixelshader erledigt werden.

NV40 und G70 bieten FP16-TMUs und FP16-Alphablender, R520 bietet nur FP16-Alphablender und die Möglichkeit, Multisampling-Antialiasing zu nutzen.

Kann man auch "HDR-TMUs" und "HDR-Alphablender" im Pixelshader emulieren? Ja. Allerdings kostet dies erheblich Performance. Texturfilterung im Pixelshader kostet mindestens viermal so viele Takte (soweit wir wissen, in der Realität sogar achtmal so viele Takte) verglichen mit "HDR-TMUs". Um Alphablending nachzustellen, sind umständliche Umkopier-Funktionen notwendig, was die Leistung ebenfalls drückt.

Uns interessiert primär, welche Karten zu HDR-Rendering in Echtzeit fähig sind. Spielt Zeit keine Rolle, könnte man schließlich auch die CPU rendern lassen. Um aus dynamischem HDR-Rendering sinnvoll Nutzen zu ziehen, lohnt es nun nicht, LDR-Spiele fix auf HDR-Rendering umzuschreiben. Denn der auf LDR-Rendering optimierte LDR-Content würde ja weiterhin genutzt. Man hätte immerhin reduziertes Colorbanding, aber viel mehr nicht. HDR-Rendering spielt daher primär bei Spielen eine Rolle, die speziell dafür entwickelt werden. Allerdings wird man bei neu entwickelten Spielen allgemein auf Grafikpracht setzen, was die GPU belastet.

Dazu noch das:
__________
NV40 und G70 bieten vom Featureset her für HDR-Rendering das meiste (der NV40 enthält zudem eine nicht richtig funktionierende, daher deaktivierte Tonemapping-Unit). Die Verwendung von vierkanaligen FP16-Texturen als Eingangsmaterial und Framebuffer-Format zieht natürlich im Vergleich zu FX8 eine verdoppelte Bandbreitenlast nach sich. Damit wird die Framerate bei Verwendung von HDR-Rendering im Vergleich zum LDR-Rendering deutlich gedrückt. Kantenglättung ist schwierig zu realisieren. Das ist inbesondere deshalb tragisch, da HDR-Rendering für bessere Kontraste sorgen sollte – Kantenglättung wäre besonders hilfreich, um den damit deutlicher hervortretenden Treppeneffekt zu vermeiden.

__________
R520 bietet keine FP16-Texturfilterung, nur FX16-Texturen können in den TMUs gefiltert werden. FX16 ist aber klar nur ein MDR-Format. HDR-Texturen müssten aufwändig im Pixelshader gefiltert werden, wobei bilineare Filterung schon sehr aufwändig, anisotrope Filterung praktisch unmöglich ist. Kantenglättung wird im Prinzip geboten, bishin zu 6x sparse Multisampling. In welcher Endgeschwindigkeit das resultiert, wissen wir noch nicht

Der R580 sollte in der Richtung keine Aussnahme machen.

Das sollte erklaeren warum ATI Kantenglaetung bei gleichzeitigem HDRR kann und nVidia nicht.
Achja, lest euch doch biiiiitte diesen Bericht durch, dann seid ihr schlauer, habt nie wieder Fragen und gut ist.
Hoffe das reicht fuers erste.....

http://www.3dcenter.org/artikel/2006/01-01_a.php