PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Radeon X1x00 - kein FP-Filtern?


tb
2005-10-10, 00:50:15
The Radeon X1x00 family has improved floating point surface support by adding blending and multisampling, which will be discussed later; however, floating point texture filtering is not supported. (Radeon X1x00 Programming Guide)

Könnte mal bitte ein X1x00 Besitzer die letzte Version von ShaderMark v2.1 laufen lassen und von den 3 HDR Tests Bilder machen (dürfte per 'q' gehen)?

Thomas

deekey777
2005-10-10, 01:03:08
Inwieweit würde es mit bloßem Auge auffallen?

PS: Es wird noch etwas dauern, bis jemand im Forum eine X1000 hat, doch in irgendeinem Review wurde Shadermark benutzt.

http://www.hothardware.com/viewarticle.cfm?articleid=734

Weiterhelfen tut es aber nicht.

tb
2005-10-10, 01:21:30
Inwieweit würde es mit bloßem Auge auffallen?

PS: Es wird noch etwas dauern, bis jemand im Forum eine X1000 hat, doch in irgendeinem Review wurde Shadermark benutzt.

http://www.hothardware.com/viewarticle.cfm?articleid=734

Weiterhelfen tut es aber nicht.

Jap, man würde/müsste eine deutliche Blockbildung sehen. TechReport haben ShaderMark auch durchlaufen lassen, merkwürdig, denn ich bzw. ShaderMark prüfe ja zuvor ob die Karte auch FP16 Filtern kann, oder nicht.

Naja, ich hab mal ne Mail an die Jungs von HotHardware geschrieben.

Thomas

Coda
2005-10-10, 02:44:29
Kann sein, dass Shadermark dann im Shader 4 Samples nimmt und selber bilinear filtert.

tb
2005-10-10, 03:05:53
nein. es sind ja 3 hdr tests, der 1 ohne filterung, der zweite mit filterung der textureeinheit und der 3. mit pixel shader filterung. die letzten beiden liefern eine gleiche bildqualität, welche besser als die des ersten ist. meinen fehler in shadermark hab ich jetzt gefunden, auf ati karten nimmt er D3DFMT_A16B16G16R16 weil man die filtern kann, auf nvidia D3DFMT_A16B16G16R16F - shadermark läuft dann zwar, müsste aber eine meldung anzeigen, dass eventuell die qualität nicht vergleichbar ist.

Thomas

Demirug
2005-10-10, 07:11:30
Sie kann es nicht und das wird in den Caps auch so gemeldet. War eine der ersten Sachen die ich überprüft habe.

Tigerchen
2005-10-10, 07:17:50
Sie kann es nicht und das wird in den Caps auch so gemeldet. War eine der ersten Sachen die ich überprüft habe.


Was bedeutet das in der Praxis für mich? :confused:

Quasar
2005-10-10, 12:52:34
...daß die Karte vermutlich nichts für dich ist, wenn du auf dieses Feature Wert legst.

aths
2005-10-10, 13:08:16
nein. es sind ja 3 hdr tests, der 1 ohne filterung, der zweite mit filterung der textureeinheit und der 3. mit pixel shader filterung. die letzten beiden liefern eine gleiche bildqualität, welche besser als die des ersten ist. meinen fehler in shadermark hab ich jetzt gefunden, auf ati karten nimmt er D3DFMT_A16B16G16R16 weil man die filtern kann, auf nvidia D3DFMT_A16B16G16R16F - shadermark läuft dann zwar, müsste aber eine meldung anzeigen, dass eventuell die qualität nicht vergleichbar ist.

ThomasWelche anderen Karten könnten eigentlich 4-Kanal-Int16-Texturen filtern?

Crushinator
2005-10-10, 13:51:22
Was bedeutet das in der Praxis für mich? :confused:
Daß Du entweder nicht so schöne HDR-Effekte auf der Karte zu Gesicht bekommst, solange keiner sich die Mühe machen wird eine solche Filterung im Pixelshader zu realisieren, oder daß aufgrund einer nicht gerade geringen Wahrscheinlichkeit die Filterung im PS einfach grottenlahm wäre, was im Zweifelsfalle dazu führt, daß ersteres eintreten wird. :ueye:

Demirug
2005-10-10, 14:53:04
Das ist die Ausweichlösung von ATI für den Bilinearen Filter:

float2 texWidthHeight = {TEX_WIDTH, TEX_HEIGHT};
float4 texOffsets = {-0.5/TEX_WIDTH+fudge, -0.5/TEX_HEIGHT+fudge, 0.5/TEX_WIDTH-fudge, 0.5/TEX_HEIGHT-fudge};

float4 tex2D_bilerp(sampler s, float2 texCoord)
{
float4 offsetCoord = texCoord.xyxy + texOffsets;
float2 fracCoord = frac(offsetCoord.xy * texWidthHeight);

float4 s00 = tex2D(s, offsetCoord.xy);
float4 s10 = tex2D(s, offsetCoord.zy);
float4 s01 = tex2D(s, offsetCoord.xw);
float4 s11 = tex2D(s, offsetCoord.zw);

s00 = lerp(s00, s10, fracCoord.x);
s01 = lerp(s01, s11, fracCoord.x);
s00 = lerp(s00, s01, fracCoord.y);
return s00;
}

Überschlagen sind das 4 Takte in der TMU und 4/5 Takte in den ALUs.

Tigerchen
2005-10-10, 16:32:49
...daß die Karte vermutlich nichts für dich ist, wenn du auf dieses Feature Wert legst.

Was du alles weißt ohne je die praktischen Auswirkungen gesehen zu haben.
Ich warte da doch lieber auf die ersten vergleichenden Screenshots.

Crushinator
2005-10-10, 16:38:11
(...) Überschlagen sind das 4 Takte in der TMU und 4/5 Takte in den ALUs.
Wäre recht interessant zu erfahren, wie sich das in Praxis auf die Gesamtperformance auswirken würde. Taktbereinigt halb so langsam wie auf G70 - wenn ich das richtig verstanden habe - läßt einen irgendwie doch noch hoffen.

betasilie
2005-10-10, 16:40:27
Was du alles weißt ohne je die praktischen Auswirkungen gesehen zu haben.
Ich warte da doch lieber auf die ersten vergleichenden Screenshots.

Ack. Außerdem muss man erstmal abwarten wie oft FP-Filtering überhaupt in nächster Zeit eingesetzt wird. Man sicher mit den richtigen Kniffen auch ohne FP-F ordentliche ergebnisse erreichen.

Quasar
2005-10-10, 16:40:40
Was du alles weißt ohne je die praktischen Auswirkungen gesehen zu haben.
Ich warte da doch lieber auf die ersten vergleichenden Screenshots.

Ich kann dir auch erzählen, daß einige Spiele ohne Patch nicht mit HDR auf so einer Karte laufen würden - aber im Endeffekt würde das auf den Satz von oben hinauslaufen (den ich übrigens selbst gemeldet habe, da er mir im Nachhinein unangemessen erschien).
Ack. Außerdem muss man erstmal abwarten wie oft FP-Filtering überhaupt in nächster Zeit eingesetzt wird. Man sicher mit den richtigen Kniffen auch ohne FP-F ordentliche ergebnisse erreichen.
Ja, natürlich. RTHDRIBL sieht zum Beispiel sehr hübsch aus und braucht weder FP-Filtering noch FP-Blending "in Hardware".

Eigentlich bräuchten wir gar keine TMUs mehr, lieber mehr Shader-ALUs und alles wird "zu Fuß" erledigt. Nein, aber mal im Ernst: Meistens haben spezialisierte Einheiten durchaus ihre Existenzberechtigung, da sie das, was sie können, i.d.R. besser schneller können, als Allzweckeinheiten. (Beispiel: Warum gibt es Grafikkarten? Warum gab es darauf TNL-Einheiten? Warum gibt es Pixel- und Vertexshader?)

Crushinator
2005-10-10, 16:43:58
(...) Was du alles weißt ohne je die praktischen Auswirkungen gesehen zu haben. Ich warte da doch lieber auf die ersten vergleichenden Screenshots.
Ich bitte nicht weiter nachzutreten, denn a) hat er das so nicht gemeint, wie Du es scheinbar interpretiert hast und b) hat er es ausdrücklich konjunktiv formuliert. Daß er's vielleicht etwas unglücklich formuliert hat, ist ihm selbst auch bewußt. Ich sehe jetzt keinen Bedarf sich drüber aufzuregen. In diesem Sinne: Bitte Schwamm drüber! :)
Ich kann dir auch erzählen, daß einige Spiele ohne Patch nicht mit HDR auf so einer Karte laufen würden (...)
Das ist meiner Meinung nach das bedauerlichste daran. ;(

Demirug
2005-10-10, 16:46:04
Ack. Außerdem muss man erstmal abwarten wie oft FP-Filtering überhaupt in nächster Zeit eingesetzt wird. Man sicher mit den richtigen Kniffen auch ohne FP-F ordentliche ergebnisse erreichen.

Jedes HDR Spiel nutzt derzeit den FP Filter für das Downsamplen. Deswegen brauchen die jetzt auch alle einen Patch.

betasilie
2005-10-10, 16:47:42
Also wollt ihr mir sagen, dass man ohne FP-F keinen vernünftigen HDR Content zu sehen bekommt?

Crushinator
2005-10-10, 16:49:04
Also wollt ihr mir sagen, dass man ohne FP-F keinen vernünftigen HDR Content zu sehen bekommt?
Zumindest nicht so schöne wie mit. ;(

Demirug
2005-10-10, 16:51:31
Wäre recht interessant zu erfahren, wie sich das in Praxis auf die Gesamtperformance auswirken würde. Taktbereinigt halb so langsam wie auf G70 - wenn ich das richtig verstanden habe - läßt einen irgendwie doch noch hoffen.

Takt und Pixelprozessor (G70 = 6 PP ; R520 = 4 PP) bereinigt dürfte halb so schnell recht gut hinkommen. Unter Umständen hat der R520 noch ein TMU / Pixelprozessor Transfer limit. Dazu habe ich aber keine Daten zur Hand. Darum ging ich jetzt erst mal davon aus das es keines gibt.

betasilie
2005-10-10, 16:53:16
Zumindest nicht so schöne wie mit. ;(
Nun, das ist aber ne sehr realtive Aussage. Ich meine die Frage Abseits der Theorie ist halt, wie viel ein vernünftiges Studio tricksen kann und anpassen kann. Mich interessiert halt immer mher die Praxis, als die graue Theorie. NV40 zb kann zwar FP-F, aber recht langsam, daher würde ich erstmal vermuten, dass man HDR ohne FP-F realisiert und schaut, dass man durh geschicktes Design die Nachteile kaschiert.

Crushinator
2005-10-10, 17:03:26
Nun, das ist aber ne sehr realtive Aussage. Ich meine die Frage Abseits der Theorie ist halt, wie viel ein vernünftiges Studio tricksen kann und anpassen kann. Mich interessiert halt immer mher die Praxis, als die graue Theorie.
Klar, deswegen rede ich mir den Mund ja auch die ganze Zeit fuselig, daß doch noch Hoffnung besteht. =)
NV40 zb kann zwar FP-F, aber recht langsam, daher würde ich erstmal vermuten, dass man HDR ohne FP-F realisiert und schaut, dass man durh geschicktes Design die Nachteile kaschiert.
Ich fürchte, daß der einzige Weg über Filtern im PS geht, und dann ist's zumindest theoretisch in etwa halb so langsam wie auf NV-Hardware. Dafür hat man dann allerdings den Genuß von AA. Irgendeinen Tod muß man nun mal sterben. :ueye:

Demirug
2005-10-10, 17:05:48
Also wollt ihr mir sagen, dass man ohne FP-F keinen vernünftigen HDR Content zu sehen bekommt?

HDR Texturecontent der in einem Format vorliegt das nicht gefilter werden kann bekommt dann nur Point-Filterung oder muss aufwendig in den Shadern gefiltert werden. AF wird da richtig übel.

Allerdings ist HDR Texturecontent derzeit noch nicht sonderlich verbreitet. IMHO werden wir das vorallem zuerst bei den Texturen sehen welche für den Hintergrund (Himmel, weit entfernte Berge) benutzt werden.

tb
2005-10-10, 17:23:45
Nun, das ist aber ne sehr realtive Aussage. Ich meine die Frage Abseits der Theorie ist halt, wie viel ein vernünftiges Studio tricksen kann und anpassen kann. Mich interessiert halt immer mher die Praxis, als die graue Theorie. NV40 zb kann zwar FP-F, aber recht langsam, daher würde ich erstmal vermuten, dass man HDR ohne FP-F realisiert und schaut, dass man durh geschicktes Design die Nachteile kaschiert.

Die Methode ohne FP-F benötigt mehr Pixel Shader Leistung, da dort per Hand gefiltert wird und evtl. mehr Samples gelesen werden. Mittels FP-F Filterung kann man z.b. auch die Anzahl von Samples bei einem Blur Filter reduzieren, welcher bei HDR gern eingesetzt wird:

ohne FP-Filter:

half4 PS_blurX_hq( PS_INPUT IN ) : COLOR
{
float2 Origin;
float2 Offset;

Origin=IN.TexCoord0;
Offset.y=Origin.y;

float3 col=0.0;

// sample 0-24
for (int i = 0; i < 25; i++)
{
Offset.x=Origin.x+FilterTaps_and_Weights_point[i].x;
col+=tex2D(cRenderTargetQuad, Offset).rgb*FilterTaps_and_Weights_point[i].z;
}
return half4(col, 1.0);
}



mit FP-Filter:

half4 PS_blurX_fb( PS_INPUT IN ) : COLOR
{
// W - weights
// T - texture coordinate
// alpha = Wi / (Wi + Wj)
// Wij = Wi + Wj
// Tij = Ti * alpha + Tj * (1 - alpha)

float2 Origin;
float2 Offset;

Origin=IN.TexCoord0;
Offset.y=Origin.y;

float3 col=0.0;

// sample 0-8
for (int i = 0; i < 9; i++)
{
Offset.x=Origin.x+FilterTaps_and_Weights_bilinear[i].x;
col+=tex2D(cRenderTargetQuad_Linear, Offset).rgb*FilterTaps_and_Weights_bilinear[i].z;
}
return half4(col, 1.0);
}


Das Resultat ist mathematisch gesehen bei beiden Shadern gleich. Ein großer Nachteil düfte das Fehlen von FP-Filtern für die X1x00 nicht sein...

Thomas

SentinelBorg
2005-10-10, 20:43:17
Was war eigentlich nochmal der technische Grund, warum der NV40/G70 kein MSAA bei FP64 kann?

Sentinel

Gerhard
2005-10-10, 20:54:14
Nunja, das Problem sollte man aber nicht übertreiben. Immerhin kann er I16 Filtern. Texturen lassen sich recht einfach konvertieren und I16 unterstützt immerhin den 256fachen Dynamikumfang von den bisher in allen Spielen verwendeten I8 Texturen (auch in den bisherigen HDR spielen).
Dies reicht schon für recht extreme Dynamikumfänge selbst bei Lightmaps aus.

Braucht man wirklich einen höheren Dynamikumfang gibt es Workarounds, welche zwar etwas Geschwindigkeit kosten, was aber kein Problem sein dürfte da dies selbst wenn man sich extreme Beispiele vorstellt (z.B. Weltraumsimulationen - Flug in die Sonne oder ein FP16Framebuffer - Postfilter) nur bei sehr wenig Texturen notwendig ist.
Ausserdem gibt es auch bei NVidia beim FP Filtern einen ziemlichen Geschwindigkeitsverlust.

Den wirklichen Nachteil hat der Programmierer da er einfach etwas mehr Fälle berücksichtigen muss. Ist zwar auch kein grosser Aufwand, ist aber nichts desto trotz ärgerlich.

aths
2005-10-10, 21:48:36
Nunja, das Problem sollte man aber nicht übertreiben. Immerhin kann er I16 Filtern. Texturen lassen sich recht einfach konvertieren und I16 unterstützt immerhin den 256fachen Dynamikumfang von den bisher in allen Spielen verwendeten I8 Texturen (auch in den bisherigen HDR spielen).
Dies reicht schon für recht extreme Dynamikumfänge selbst bei Lightmaps aus.Das hatte ich auch erst gedacht. Aber: Das Auge bietet einen Dynamikumfang von ca 14-15 dB. Ein gutes FP16-Format hat ca. 12 db, ein einfaches FP16-Format (ohne Denoms) von 9 dB, FX16 (FX = Fixpoint) von weniger als 5 dB, FX8 von nur noch 2,4 dB.

Ich weiß nicht, ob man FP16 als schon für HDR-tauglich bezeichnen kann (zumindest wenn Denorms unterstützt werden, sage ich mal "ja") aber FX16 als "HDR" zu bezeichnen, hielte ich für übertrieben.

Ausserdem gibt es auch bei NVidia beim FP Filtern einen ziemlichen Geschwindigkeitsverlust.Bandbreiten-Problem. Mir ist nicht ganz klar, ob die TMUs nicht an sich doch FP16-Filterung in einem Takt könnten – aber auch in diesem Fall ist die Bandbreite nicht da, und es dauert die zwei Takte ehe die Daten im Cache sind. So oder so, die Methode ist mindestens doppelt so schnell im Vergleich mit der Filterung im Pixelshader.

Tigerchen
2005-10-11, 07:14:17
Ich seh schon. Das ist wieder eine Sache die irgendwann mal in 3 Jahren vielleicht von Interesse ist.

Quasar
2005-10-11, 10:55:35
Ich seh schon. Das ist wieder eine Sache die irgendwann mal in 3 Jahren vielleicht von Interesse ist.

Möglicherweise. Vielleicht aber auch schon früher, da die Next-Gen-Konsolen auch über solche Features verfügen und die Spiele dort es mit Sicherheit nutzen werden.

Daraus läßt sich auch folgern, daß, wenn die Grafikkarten auf dem PC-Markt bei Neuerscheien Featuremäßig einheitlicher wären (von mir aus auch "nur" aus Programmierersicht), wir erheblich früher mit dem Einbau solcher Features rechnen könnten, als wenn jeder Hersteller sein eigenes Süppchen kocht und versucht, dem anderen wo es nur geht, Steine in den Weg zu legen.

Crushinator
2005-10-11, 11:04:24
Ich seh schon. Das ist wieder eine Sache die irgendwann mal in 3 Jahren vielleicht von Interesse ist.
Objektiv betrachtet, darf man es aber nicht so sehen. Denn andersrum würde man sich doch freuen, wenn sowohl die Leistung als auch die Bandbreite dazu ausreichen und man somit bei wesentlich mehr Titeln in den Genuß von derzeitig machbarem HDR-Rendering kommen würde.

Gaestle
2005-10-11, 11:13:53
Ich seh schon. Das ist wieder eine Sache die irgendwann mal in 3 Jahren vielleicht von Interesse ist.


Stimmt. Aber irgendwann muss jede Sache angefangen werden. Und wenn die Sache heute nicht angefangen würde, hätten wir sie in drei Jahren nicht zur Verfügung.

Ich mag HDR schon in seiner heutigen Form. Und ich würde mir wünschen, dass die derzeit bestehenden mankos ausgebügelt werden. Und ich würde mir wünschen, dass die Studios ihr Geld lieber in die Qualität des spielerischen Contents stecken könnten, anstatt es dafür ausgeben zu müssen, die Besonderheiten (oder auch Extrawürste) einzelner Chips bei der technischen Umsetzung zu berücksichtigen.

Grüße

Mr. Lolman
2005-10-11, 11:36:01
Damals haben alle 3dfx wegen fehlendem T&L vernichtet. Und wo sind die hochgepriesenen T&L Einheiten heute?

Coda
2005-10-11, 11:37:12
Damals haben alle 3dfx wegen fehlendem T&L vernichtet. Und wo sind die hochgepriesenen T&L Einheiten heute?Vertexshader? :|

Das wäre ja wie wenn man sagt: Wo sind die hochangeprisenen DOT3-Combiner heute? X-D

Mr. Lolman
2005-10-11, 11:39:27
Vertexshader? :|

Je eben. Der Sage hätte auch Vertexshader gehabt ;)

Gaestle
2005-10-11, 11:44:52
Je eben. Der Sage hätte auch Vertexshader gehabt ;)

Konnten Sie das Potential nicht vermarkten, und hat nVidia gebremst? Kam es zu spät, zu nahe an der Pleite?
(ich weiss es wirklich nicht)

Grüße

Mr. Lolman
2005-10-11, 11:49:39
Konnten Sie das Potential nicht vermarkten, und hat nVidia gebremst? Kam es zu spät, zu nahe an der Pleite?
(ich weiss es wirklich nicht)

Grüße

Zuerst hätte noch der Rampage erscheinen müssen. Warum daraus nix geworden ist hat viele Gründe. Veraltete Designtools, Management Fehler, Stimmungmache seitens NV -> schlechte Kritiken bei GraKareviews -> fehlende Akzeptanz bei den Kunden...

Gaestle
2005-10-11, 11:54:14
Zuerst hätte noch der Rampage erscheinen müssen. Warum daraus nix geworden ist hat viele Gründe. Veraltete Designtools, Management Fehler, Stimmungmache seitens NV -> schlechte Kritiken bei GraKareviews -> fehlende Akzeptanz bei den Kunden...

Also wäre Sage der "Gegner" für GF3 geworden (auch mit VS) ?

Grüße

MeLLe
2005-10-11, 12:05:14
Also wäre Sage der "Gegner" für GF3 geworden (auch mit VS) ?

Grüße
Nicht ganz - Sage war nur der Geometrie-Kern, der Rampage beschleunigt mit Geometrie-Daten versorgen sollte.
Es hätte da wohl mehrere Fusion-Ausführungen (der NV20-Konkurrent von 3dfx) geben sollen, u.a. Rampage-only (also ohne T&L in Hardware), 1 Rampage + 1 Sage, 2 Rampage + 1 Sage, ...
Schön skalierbar eben.

Gerhard
2005-10-11, 12:21:20
Ich weiß nicht, ob man FP16 als schon für HDR-tauglich bezeichnen kann (zumindest wenn Denorms unterstützt werden, sage ich mal "ja") aber FX16 als "HDR" zu bezeichnen, hielte ich für übertrieben.

Es geht hier ja um Textureformate und nicht Framebufferformate. Selbst bei HDR Spielen dürfte I8(FX8) für die meisten Texture ausreichen da innerhalb einer Textur in der Regel nur geringe Dynamikumfänge vorhanden sind.

Coda
2005-10-11, 13:01:26
Je eben. Der Sage hätte auch Vertexshader gehabt ;)Äh und jetzt? FP-Filtering lässt sich im Gegensatz zu T&L nicht auf der CPU ausführen?

deekey777
2005-10-11, 14:16:28
Ich kann dir auch erzählen, daß einige Spiele ohne Patch nicht mit HDR auf so einer Karte laufen würden - aber im Endeffekt würde das auf den Satz von oben hinauslaufen (den ich übrigens selbst gemeldet habe, da er mir im Nachhinein unangemessen erschien).
...

In SC3 mußte die X1800 wohl auf das "SM2.0 HDR" ausweichen - warum wohl? Alle Vergleiche zur 7800er sind für den Popo.
Und Far Cry? In irgendeinem Review wurde auf die 7800er ausgewichen, damit der vermeintliche Käufer einer X1800er weiß, wie das HDRR bei ihm dann in Far Cry aussehen wird oder könnte. Man braucht definitiv Patches für die beiden, und da die beiden Spiele von ubisoft als Publisher sind...

Das einzige Licht im Tunnel ist wohl HL2. X-D

Gaestle
2005-10-11, 14:43:52
Nicht ganz - Sage war nur der Geometrie-Kern, der Rampage beschleunigt mit Geometrie-Daten versorgen sollte.
Es hätte da wohl mehrere Fusion-Ausführungen (der NV20-Konkurrent von 3dfx) geben sollen, u.a. Rampage-only (also ohne T&L in Hardware), 1 Rampage + 1 Sage, 2 Rampage + 1 Sage, ...
Schön skalierbar eben.


Dankeschön.

seahawk
2005-10-11, 14:56:51
In SC3 mußte die X1800 wohl auf das "SM2.0 HDR" ausweichen - warum wohl? Alle Vergleiche zur 7800er sind für den Popo.
Und Far Cry? In irgendeinem Review wurde auf die 7800er ausgewichen, damit der vermeintliche Käufer einer X1800er weiß, wie das HDRR bei ihm dann in Far Cry aussehen wird oder könnte. Man braucht definitiv Patches für die beiden, und da die beiden Spiele von ubisoft als Publisher sind...

Das einzige Licht im Tunnel ist wohl HL2. X-D

Ich möchte erstmal beide HDR Varianten in der Realität sehen, bevor ich urteile.
Die Frage ist nur, wie ist HDR-Litening wohl im HL2 implementiert ?

betasilie
2005-10-11, 15:10:17
Möglicherweise. Vielleicht aber auch schon früher, da die Next-Gen-Konsolen auch über solche Features verfügen und die Spiele dort es mit Sicherheit nutzen werden.
Wäre mir neu, dass die Xbox360 FP-Filtering kann.

aths
2005-10-11, 15:23:26
Es geht hier ja um Textureformate und nicht Framebufferformate. Selbst bei HDR Spielen dürfte I8(FX8) für die meisten Texture ausreichen da innerhalb einer Textur in der Regel nur geringe Dynamikumfänge vorhanden sind.Der Framebuffer, bzw. die als Rendertarget genutzt Textur sollte sich zur Bestimmung der Gesamthelligkeit mippen lassen. Bilineare Texturfilterung bietet hier die schnellste Lösung.

In Spielen die HDR-Rendering nutzen sollte für viele Diffusemaps LDR-Auflösung zwar reichen. Bei Lightmaps sieht es jedoch anders aus.

Mr. Lolman
2005-10-11, 15:57:53
Komisch, dass tb, einer derjenigen, die wohl am meisten Plan von der Materie haben, kein großes Problem im fehlenden FP-F sieht...

betasilie
2005-10-11, 16:07:25
Komisch, dass tb, einer derjenigen, die wohl am meisten Plan von der Materie haben, kein großes Problem im fehlenden FP-F sieht...
Manche verlieren halt den Blick für die Realität nicht gänzlich aus den Augen, denn dass man erst bei 128bit Dynamikumfang durch die Bank beim Film angekommen ist, ist wohl jedem klar.

Komisch aths, dass Du deine gewonne Erfahrung was geschicktes Contentdesign aus unterlegen Konsolen alles rausholen kann, nicht auf den PC übertragen kannst. Egal worum es geht, bei dir ist ein fehlendes Feature immer der Weltuntergang, egal ob die derzeitige Dev.-Praxis das bestätigt oder nicht.

Coda
2005-10-11, 16:23:08
Komisch, dass tb, einer derjenigen, die wohl am meisten Plan von der Materie haben, kein großes Problem im fehlenden FP-F sieht...Solang es nicht als Diffusetextur eingesetzt wird ist es ja in Ordnung, ansonsten gibt's halt kein tolles ATi-AF.

Quasar
2005-10-11, 16:27:14
Wäre mir neu, dass die Xbox360 FP-Filtering kann.
Richtig, somit ist es aber immerhin eine der Next-Gen-Konsolen.

betasilie
2005-10-11, 16:32:41
Richtig, somit ist es aber immerhin eine der Next-Gen-Konsolen.
Du weißt, dass man sich bei Multiplattformtiteln am kleinsten gemeinsamen Nenner orientiert?

Quasar
2005-10-11, 16:36:30
Du weißt, dass man sich bei Multiplattformtiteln am kleinsten gemeinsamen Nenner orientiert?
Ja, aber PC+PS3 > PC.

Demirug
2005-10-11, 16:49:25
Komisch, dass tb, einer derjenigen, die wohl am meisten Plan von der Materie haben, kein großes Problem im fehlenden FP-F sieht...

Du hast aber schon gesehen für was tb den Filter braucht, oder?

DanMan
2005-10-11, 16:56:38
Das hatte ich auch erst gedacht. Aber: Das Auge bietet einen Dynamikumfang von ca 14-15 dB. Ein gutes FP16-Format hat ca. 12 db, ein einfaches FP16-Format (ohne Denoms) von 9 dB, FX16 (FX = Fixpoint) von weniger als 5 dB, FX8 von nur noch 2,4 dB.
Unser Auge kann aber von dem 14dB Spektrum immer nur ca. 5dB gleichzeitig erfassen. Das darf man dabei nicht vergessen.

Sonst könnten wir ja mittags die Sterne sehen. :wink:

Demirug
2005-10-11, 17:05:01
Unser Auge kann aber von dem 14dB Spektrum immer nur ca. 5dB gleichzeitig erfassen. Das darf man dabei nicht vergessen.

Sonst könnten wir ja mittags die Sterne sehen. :wink:

Deswegen gibt es beim HDR am Ende ja ein Tonemapping.

DanMan
2005-10-11, 17:15:50
Deswegen gibt es beim HDR am Ende ja ein Tonemapping.
Dem hab' ich nicht widersprochen, oder? :)

aths
2005-10-11, 19:01:53
Dem hab' ich nicht widersprochen, oder? :)Die Szene sollte man aber in voller Dynamik berechnen. Schwache Schattierungen im Dunklen noch aufzulösen und gleichzeitig die pralle Sonne auf Schnee korrekt zu berücksichtigen – da kommst du mit 5 dB nicht weit.

DanMan
2005-10-11, 19:21:36
Die Szene sollte man aber in voller Dynamik berechnen. Schwache Schattierungen im Dunklen noch aufzulösen und gleichzeitig die pralle Sonne auf Schnee korrekt zu berücksichtigen – da kommst du mit 5 dB nicht weit.
Jo, is klar. Wollte das ja nur mal der Vollständigkeit halber erwähnt haben. Die Ausgangsdaten sollten natürlich in vollem Dynamikumfang vorliegen. Sonst könnten ja, je nach Situation, hinten raus zu wenig Bit und damit Colorbanding oder Detailmangel bei heraus kommen. Tonemapping eben. Das macht unser Auge ja von sich aus. Nur auf dem Bildschirm müssen eben zu einem Zeitpunkt nicht mehr als 5dB an Dynamikumfang zu sehen sein, weil wir die nicht wahrnehmen würden.
Ich bin mir natürlich bewusst, dass unsere aktuellen Monitore da noch weit von entfernt sind.

aths
2005-10-11, 21:38:37
Jo, is klar. Wollte das ja nur mal der Vollständigkeit halber erwähnt haben. Die Ausgangsdaten sollten natürlich in vollem Dynamikumfang vorliegen. Sonst könnten ja, je nach Situation, hinten raus zu wenig Bit und damit Colorbanding oder Detailmangel bei heraus kommen. Tonemapping eben. Das macht unser Auge ja von sich aus. Nur auf dem Bildschirm müssen eben zu einem Zeitpunkt nicht mehr als 5dB an Dynamikumfang zu sehen sein, weil wir die nicht wahrnehmen würden.
Ich bin mir natürlich bewusst, dass unsere aktuellen Monitore da noch weit von entfernt sind.Ja, TFTs können froh sein, 3 dB Dynamik anzubieten. Die Dynamik in den Berechnungen braucht man nicht nur um Colorbanding zu vermeiden, sondern auch gegen Über- oder Unterbelichtung. Da sind Fixpoint-Formate traditionell nur bedingt geeignet.

Übrigens kostet das bilineare Sample einer Textur mit 16 Bit pro Kanal natürlich auch zwei Takte auf der Radeon (sofern man eine Vierkanaltextur nutzt).

Coda
2005-10-11, 22:16:58
Die Dynamik in den Berechnungen braucht man nicht nur um Colorbanding zu vermeidenWie willst du das verhindern, wenn der RAMDAC eh nur 8-8-8-8 auslesen kann? Das einzige was da hilft ist ATis 10-10-10-2 Format.

StefanV
2005-10-11, 22:28:22
Irre ich mich oder ist die R520 der 2. Chip, nach der Parhelia, der ein 10-10-10-2 Format beherrscht? ;)

aths
2005-10-11, 22:33:49
Irre ich mich oder ist die R520 der 2. Chip, nach der Parhelia, der ein 10-10-10-2 Format beherrscht? ;)Kann schon R300, jedoch funktioniert dann kein MSAA.

aths
2005-10-11, 22:37:02
Wie willst du das verhindern, wenn der RAMDAC eh nur 8-8-8-8 auslesen kann? Das einzige was da hilft ist ATis 10-10-10-2 Format.Oder ein FP16-Format.

8 Bit heißt nicht, dass man nur 2,4 dB Dynamik haben kann, das gilt nur wenn die Zahlen linear interpretiert werden. Leider wird in der GPU gemischt gerechnet, sRGB-Texturen werden wie lineares RGB behandelt, und was im Framebuffer steht, also sRGB oder nicht, ist auch nicht so ganz klar.

Ich bin für mindestens lineare 10 Bit inkl. Option auf Dithering, und 16 Bit Gamma-Auflösung :)

Aber Colorbanding muss auch bei RGBA 8888 nicht zwangsläufig auftreten, wenn man das Pixel mit vernünftigen Methoden singlepass rendert.

Coda
2005-10-11, 22:42:32
Oder ein FP16-Format.Es gibt aber keine Grafikkarte auf der du eine FP16-Renderchain allozieren kannst. HDR nützt in dem Zusammenhang heute noch nichts, außer man macht das Tonemapping eben auf 10-10-10-2.

aths
2005-10-12, 01:47:50
Es gibt aber keine Grafikkarte auf der du eine FP16-Renderchain allozieren kannst. HDR nützt in dem Zusammenhang heute noch nichts, außer man macht das Tonemapping eben auf 10-10-10-2.Ich weiß nicht, was du die ganze Zeit mit 10-10-10-2 willst. Vernünftiges HDR-Rendering schafft Colorbanding-freie Bilder auch für einen RGBA 8888-Framebuffer. Ich möchte trotzdem die Option auf einen FP16-Framebuffer, und zwar erzwingbar für alle Anwendungen.

tb
2005-10-12, 02:13:02
Komisch, dass tb, einer derjenigen, die wohl am meisten Plan von der Materie haben, kein großes Problem im fehlenden FP-F sieht...

Solange es nur für die heutigen HDR Methoden verwendet wird, da diese nur relativ wenig(natürlich Auflösungsabhängig) pro Frame filtern. Im schlimmsten Fall läuft es eben etwas langsamer auf den X1x00. Fehlendes AA bei FP16 ist da schon wesentlich kostspieliger zu kompensieren.

Thomas

Coda
2005-10-12, 02:36:09
Ich weiß nicht, was du die ganze Zeit mit 10-10-10-2 willst. Vernünftiges HDR-Rendering schafft Colorbanding-freie Bilder auch für einen RGBA 8888-Framebuffer.Ich ging jetzt davon aus du meinst die Bandings die auch bei Singlepass entstehen.

Solange es nur für die heutigen HDR Methoden verwendet wird, da diese nur relativ wenig(natürlich Auflösungsabhängig) pro Frame filtern.Das Problem ist erst da wenn jemand anfängt für irgendwas FP16-Texturen verwenden zu wollen. Bilinear ist halt nicht wirklich befriedigend heutzutage.

seahawk
2005-10-12, 08:14:02
Ich verstehe die Diskussion nicht. ATI hat einen geringeren Dynamikumfang, der aber trotzdem über dem der meisten Monitore liegt. Dafür haben sie HDR + AA , was für die gesamte BQ wohl besser ist als FP16-HDR ohne AA.

Manchmal sollte man auch den praxisnahen Ansatz loben.

No.3
2005-10-12, 09:34:04
Manchmal sollte man auch den praxisnahen Ansatz loben.

so was wird nur selten gemacht, wenn überhaupt, siehe Bsp 3dfx ;)

Rainer

Coda
2005-10-12, 17:08:24
Ich verstehe die Diskussion nicht. ATI hat einen geringeren Dynamikumfang, der aber trotzdem über dem der meisten Monitore liegt. Dafür haben sie HDR + AA , was für die gesamte BQ wohl besser ist als FP16-HDR ohne AA. Halt mal, halt mal. Erstens hat R5xx keinen "geringeren Dynamikumfang" und zweitens wird der sehr wohl durch's Tonemapping auf den Bildschirm gebracht.

Manchmal sollte man auch den praxisnahen Ansatz loben.Es gibt da die Legende von einem Tal mit wo nur fleißige Entwicklern leben. Is klar ne...

Bin ich froh wenn mit DX10 diese sogenannten "praxisnahen Ansätze" in der Versenkung verschwinden.

Spasstiger
2005-10-12, 23:52:31
Halt mal, halt mal. Erstens hat R5xx keinen "geringeren Dynamikumfang"

Woher das Gerücht kommt, verstehe ich auch nicht. Der R520 ist ein reinrassiger fp32-Chip im Gegensatz zu den Vorgängern.

aths
2005-10-13, 00:02:24
Ich verstehe die Diskussion nicht. ATI hat einen geringeren Dynamikumfang, der aber trotzdem über dem der meisten Monitore liegt. Dafür haben sie HDR + AA , was für die gesamte BQ wohl besser ist als FP16-HDR ohne AA.

Manchmal sollte man auch den praxisnahen Ansatz loben.Die internen Berechnungen sind beim R520 genauso dynamisch wie bei der GeForce FX und GeForce 6. Doch FP32 als Datenformat und Rendertarget ist von vornherein zu bandbreitenlastig. FP16-Genauigkeit tuts vorläufig auch. Die Frage ist also:

- Kann man ein FP16-Rendertarget nutzen?

- Kann man FP16-Eingangsdaten (Texturen) nutzen?

Beides kann beim NV40+ / R520 mit "ja" beantwortet werden. Der NV40+ kann die FP16-Texturen allerdings noch filtern.

Würde der Monitorkontrastumfang als Obergrenze für den sinnvollen Dynamikumfang fungieren, bräuchte man gar kein HDR-Rendering, also auch kein HDR-Rendering mit Multisampling.

betasilie
2005-10-13, 02:04:12
Würde der Monitorkontrastumfang als Obergrenze für den sinnvollen Dynamikumfang fungieren, bräuchte man gar kein HDR-Rendering, also auch kein HDR-Rendering mit Multisampling.
Genau, und deswegen gibt es Tonemapping. :rolleyes:

Grestorn
2005-10-13, 07:08:45
Beides kann beim NV40+ / R520 mit "ja" beantwortet werden. Der NV40+ kann die FP16-Texturen allerdings noch filtern.Jetzt muss ich doch nochmal nachfragen, weil ich im anderen Thread ja eins auf die Finger bekommen habe...

Also, klar ist, dass der R520 FP32 filtern kann. Gut.

Dein Text, aths, den ich hier zitiert habe, liest sich so, als ob der R520 FP16 überhaupt nicht filtern könnte, sprich dieses Texturformat eigentlich für Diffuse-Maps unbrauchbar wäre. In anderen Threads liest sich das nur so, als ob diese Texturen nur in Vertex-Shadern nicht gefiltert werden können (wobei ich ganz klar zugeben muss, dass ich mir überhaupt nicht vorstellen kann, wozu man in einem Vertex-Shader Texturen überhaupt filtern muss, aber das kann ja an meinem unbestreitbar limitierten Wissen zum Thema GPU-Programmierung liegen...)

Also, wie ist es nun genau? Und was bedeutet das letztlich wirklich für die Entwickler?

Demirug
2005-10-13, 07:17:13
Die TMUs des R520 können Fliesskommaformate nicht filtern.

Man kann mit entsprechendem Aufwand das Filtern in den Pixelshadern nachprogrammieren. Was beim Bilinearen Filter noch relative leicht ist aber bei AF schon recht kompliziert wird.

Die Folgen für die Entwicklung sind das man auf jeden Fall zusätzlichen Shadercode schreiben muss. Will man nun die FP16 Filterung von nVidia nutzen braucht man dann entsprechend zwei Versionen von jedem Shader der eine FP16 Texture als Datenquelle verwendet und davon gefilterte Werte braucht.

Pirx
2005-10-13, 08:43:06
Und bis zu welchem Grad kann der G70 die FP-Formate maximal filtern?

ShadowXX
2005-10-13, 09:04:08
Und bis zu welchem Grad kann der G70 die FP-Formate maximal filtern?

Der nv40/G70 könne kann die FP-Formate bi, tri und anisotropisch Filtern. (Also genauso wie bei Int-Formaten.)

seahawk
2005-10-13, 09:11:36
Würde der Monitorkontrastumfang als Obergrenze für den sinnvollen Dynamikumfang fungieren, bräuchte man gar kein HDR-Rendering, also auch kein HDR-Rendering mit Multisampling.

Das sind exakt meine Bedenken gegne den HDR-R Hype.

Grestorn
2005-10-13, 09:27:47
Das sind exakt meine Bedenken gegne den HDR-R Hype.Dann gehörst Du auch zu den Menschen, die nicht verstanden haben, worum es bei HDR geht.

Es geht nicht darum, den gesamten Dynamikumfang in einem Frame darzustellen. Es ist völlig klar, dass dies nicht geht. Weder vom Monitor her, noch vom Auge (das sich ja auch an einen Dynamik-Bereich anpassen muss).

ShadowXX
2005-10-13, 10:16:40
IMHO ist HDR (zumindest das von der HW direkt unterstützte HDR) damit tot.

Bevor sich die Devs mit 2 verschiedenen Versionen rumplagen (und dann bei ATI sogar höchsten Bi-Filterring per Shader in annehmbarer Geschwindigkeit rausspringt), benutzen Sie lieber gleich "Fake"-HDR ala Valves HDR-Implemantation bei DoD:S bzw. Lost Toast.

Hat den vorteill das es auf allen Karten läuft die mindestens SM2.0 können und es funktioniert AA auf allen Karten.

Demirug
2005-10-13, 10:24:04
IMHO ist HDR (zumindest das von der HW direkt unterstützte HDR) damit tot.

Bevor sich die Devs mit 2 verschiedenen Versionen rumplagen (und dann bei ATI sogar höchsten Bi-Filterring per Shader in annehmbarer Geschwindigkeit rausspringt), benutzen Sie lieber gleich "Fake"-HDR ala Valves HDR-Implemantation bei DoD:S bzw. Lost Toast.

Hat den vorteill das es auf allen Karten läuft die mindestens SM2.0 können und es funktioniert AA auf allen Karten.

So schlimm ist es nun auch wieder nicht und Fake HDR ist in der Regel noch aufwendiger in der Entwicklung.

Zudem betrifft das Filterproblem ja nur HDR Content. Je weniger statisches Licht ein Spiel enthält desto weniger braucht man HDR Content.

Es ist mehrarbeit und als Entwickler kann man nur mal wieder fluchen das die Vereinheitlichung wieder nicht vorran gekommen ist aber man wird wie in der Vergangenheit damit leben müssen und es auch können.

ShadowXX
2005-10-13, 10:38:00
So schlimm ist es nun auch wieder nicht und Fake HDR ist in der Regel noch aufwendiger in der Entwicklung.

Zudem betrifft das Filterproblem ja nur HDR Content. Je weniger statisches Licht ein Spiel enthält desto weniger braucht man HDR Content.

Es ist mehrarbeit und als Entwickler kann man nur mal wieder fluchen das die Vereinheitlichung wieder nicht vorran gekommen ist aber man wird wie in der Vergangenheit damit leben müssen und es auch können.

Ja natürlich ist das Fake-HDR in der Entwicklung komplizierter, aber es bietet eben auch allerhand vorteile: Es läuft auf allen DX9-Karten und dazu noch auf allen mit AA.

Und Valve (ums mal als Beispiel zu nehmen) hat sich ja zum Beispiel auch gegen eine 2-Wege-Lösung (obowhl relativ ATI-Freundlich) entschieden (und da Sie insgesamt sogar 4 Versionen mal programmiert hatten, lags bestimmt nicht an fehlender Experimentierfreudigkeit) und benutzt jetzt lieber Fake-HDR.

Ich wills mal so ausdrücken: Die Entwickler werden IMHO durch die jetzige Situation eher nur sowas wie Bloom (oder andere Fullscreen-Effekte in der Richtung) einbauen und das dann HDR nennen, als sich extra den Aufwand einer 2-wege-Lösung zu geben (zumindest bei Multi-Plattform-Titeln).

Demirug
2005-10-13, 10:57:01
Ja natürlich ist das Fake-HDR in der Entwicklung komplizierter, aber es bietet eben auch allerhand vorteile: Es läuft auf allen DX9-Karten und dazu noch auf allen mit AA.

Und Valve (ums mal als Beispiel zu nehmen) hat sich ja zum Beispiel auch gegen eine 2-Wege-Lösung (obowhl relativ ATI-Freundlich) entschieden (und da Sie insgesamt sogar 4 Versionen mal programmiert hatten, lags bestimmt nicht an fehlender Experimentierfreudigkeit) und benutzt jetzt lieber Fake-HDR.

Ich wills mal so ausdrücken: Die Entwickler werden IMHO durch die jetzige Situation eher nur sowas wie Bloom (oder andere Fullscreen-Effekte in der Richtung) einbauen und das dann HDR nennen, als sich extra den Aufwand einer 2-wege-Lösung zu geben (zumindest bei Multi-Plattform-Titeln).

Bei den Effekten nimmt man nur dann Rücksicht auf technologisch nicht mehr aktuelle Hardware wenn der Effekt ein tragendes Spielelement ist oder wenn man für die Rücksichtnahme eine Vergütung erhält.

Die Unterschiede zwischen R(V)5XX und NV4X/G7X liegen solange man keinen HDR Content braucht nur in den Postfilter und dort nur beim auslesen des bereits gerenderten HDR Bildes. Der NV4X/G7X kommt dabei auch mit der R(V)5XX Lösung zurecht. Wer also nur einen Pfad schreiben will nimmt die R(V)5XX Lösung und gut ist. Wer sich etwas mehr arbeit machen will oder eine sehr gute Engine hat (die macht sowas aleine) benutzt dann noch die Filterung des NV4x/G7x zur Beschleunigung.

ShadowXX
2005-10-13, 11:25:30
Bei den Effekten nimmt man nur dann Rücksicht auf technologisch nicht mehr aktuelle Hardware wenn der Effekt ein tragendes Spielelement ist oder wenn man für die Rücksichtnahme eine Vergütung erhält.

Die Unterschiede zwischen R(V)5XX und NV4X/G7X liegen solange man keinen HDR Content braucht nur in den Postfilter und dort nur beim auslesen des bereits gerenderten HDR Bildes. Der NV4X/G7X kommt dabei auch mit der R(V)5XX Lösung zurecht. Wer also nur einen Pfad schreiben will nimmt die R(V)5XX Lösung und gut ist. Wer sich etwas mehr arbeit machen will oder eine sehr gute Engine hat (die macht sowas aleine) benutzt dann noch die Filterung des NV4x/G7x zur Beschleunigung.

Klar, aber genau das: "Wer also nur einen Pfad schreiben will nimmt die R(V)5XX Lösung und gut ist", geht mir persönlich ziemlich auf den Senkel.

Was das dann die Lösung ist, die zu 99% verwendet werden wird und die Vorteile des G70 wieder brach liegen lässt...im Gegenteil: Dadurch das der r520 auch AA bei seiner HDR-Lösung kann, liegen die Vorteile dann nur bei den ATI-Karten.

Sorry...ich hab eigentlich weder ein positive noch negative Einstellung zu irgendwelchen IHVs, aber sowas macht mir ATI nicht unbedingt sympathischer.
(Wenn ich fies wäre, würde ich mal behaupten, das das ganze kalkulierte Absicht von ATI war, die nichts mit dem Transistorbudget zu tun hatte.
nV ein reinwürgen und dabei noch als der lächelnde Sieger vom Parkett gehen.)

Pirx
2005-10-13, 11:34:43
Das macht ATi doch nicht mit Absicht, sondern es war eben technisch/zeitlich nicht möglich, es im R520 zu integrieren. Es gibt nunmal unterschiedliche Grafikchips, die unterschiedliche Beschränkungen haben, damit werden die Programmierer leben müssen und sich darüber aufregen dürfen, wie es schon immer war.

Demirug
2005-10-13, 11:40:24
Klar, aber genau das: "Wer also nur einen Pfad schreiben will nimmt die R(V)5XX Lösung und gut ist", geht mir persönlich ziemlich auf den Senkel.

Was das dann die Lösung ist, die zu 99% verwendet werden wird und die Vorteile des G70 wieder brach liegen lässt...im Gegenteil: Dadurch das der r520 auch AA bei seiner HDR-Lösung kann, liegen die Vorteile dann nur bei den ATI-Karten.

Sorry...ich hab eigentlich weder ein positive noch negative Einstellung zu irgendwelchen IHVs, aber sowas macht mir ATI nicht unbedingt sympathischer.
(Wenn ich fies wäre, würde ich mal behaupten, das das ganze kalkulierte Absicht von ATI war, die nichts mit dem Transistorbudget zu tun hatte.
nV ein reinwürgen und dabei noch als der lächelnde Sieger vom Parkett gehen.)

Wer den FP Filter bei NV nicht nutzt wird wohl auch den Aufwand scheuen das AA bei ATI zu programmieren.

Crushinator
2005-10-13, 12:08:16
(...) (Wenn ich fies wäre, würde ich mal behaupten, das das ganze kalkulierte Absicht von ATI war, die nichts mit dem Transistorbudget zu tun hatte. nV ein reinwürgen und dabei noch als der lächelnde Sieger vom Parkett gehen.)
Wenn es ein Feature wäre, das noch von niemandem benutzt würde, könnte man in der Tat sowas vermuten. Da es aber bereits Verwendung findet, kann man nicht davon sprechen, daß man als lächelnder Sieger vom Prakett ginge. Nur mal so zur Info: Die HDR-Implementierung á la ATi in einem allseits bekannten Spiel läuft im jetzigen Betastadium langsamer als auf der vergleichbaren HW der Konkurrenz, wobei auf letzterem natürlich nicht die ATi-Variante zum Einsatz kommt.

seahawk
2005-10-13, 12:22:44
BETA halt.

ShadowXX
2005-10-13, 12:26:04
Wenn es ein Feature wäre, das noch von niemandem benutzt würde, könnte man in der Tat sowas vermuten. Da es aber bereits Verwendung findet, kann man nicht davon sprechen, daß man als lächelnder Sieger vom Prakett ginge. Nur mal so zur Info: Die HDR-Implementierung á la ATi in einem allseits bekannten Spiel läuft im jetzigen Betastadium langsamer als auf der vergleichbaren HW der Konkurrenz.

Du meinst Valves Fake-HDR??

Das benutzt weder auf ATI noch auf nV native HDR-HW. (Sonst wäre auch schlecht AA bei nV möglich und es würde noch viel weniger auch auf r4x0/r300 laufen).

Das das bei nV schneller läuft (AFAIR nur beim G70) liegt wohl eher an der stärkeren ALU-Power des G70.

Verwendung findet "natives" HDR AFAIK nur bei SC3 und FarCry (vielleicht noch bei Serious Sam II, da man dort auf den r4x0 Karten das HDR scheinbar nicht aktivieren kann).

Und die oben genannten Beispiele laufen in ihrer jetzigen Inkarnation auch nicht mit HDR auf dem r520....da werden Patches benötigt.

Da aber die Devs immer den gemeinsamen kleinsten Nenner suchen werden, werden Sie anfangen bei neuen Games im höchstfall die ATI-Variante /die ja auch auf nV läuft) einzusetzen...
Das solte dann bei beiden ungefähr gleichschnell sein, mit dem Vorteil, das wohl die meisten dann auch gleich AA-Support für ATI mitanbieten werden (da es soweiso eine "ATI-Lösung" ist wird das dann wohl eher mit reinprogrammiert, als zusätzlich noch eine nV-Lösung. Ich sehe das etwas pessimistischer/pragmatischer als Demi.)

Von gekauften Games, die den einen oder anders IHV dann bervorteilen mal ganz abgesehen.

Ich kann es ATI nicht ganz abnehemen, das nicht auf noch FP-Filtersupport mit drinne gewesen wäre (wenn man sowieso schon FP-Blendingsupport mit einbaut).

Crushinator
2005-10-13, 12:30:59
Du meinst Valves Fake-HDR??
Nein. Siehe letzten Satz des editierten Beitrages.
Verwendung findet "natives" HDR AFAIK nur bei SC3 und FarCry (vielleicht noch bei Serious Sam II, da man dort auf den r4x0 Karten das HDR scheinbar nicht aktivieren kann). (...)
Korrekt.
(...) Ich kann es ATI nicht ganz abnehemen, das nicht auf noch FP-Filtersupport mit drinne gewesen wäre (wenn man sowieso schon FP-Blendingsupport mit einbaut).
Ich höre gerade eine Stimme, die mir was von relativ winkelunabhägingem AF erzählt und daß das viele Transistoren gefressen hat. Ich weiß nicht, woher sie kommt. :upara:

ShadowXX
2005-10-13, 12:56:49
Nein. Siehe letzten Satz des editierten Beitrages.


Welches Game meinst du denn, oder darfst du nix dazu sagen?

Davon abgesehen, mag das bei den Titeln, die jetzt erscheinen sogar noch zutreffen (weil die Devs scheinbar bsi vor kurzen selbst nicht wussten das ATI kein FP-Filtering bieten wird) und dadurch die ATI-Variante natürlich noch dazugroprammiert werden muss.
Der "nV-Teil" steht ja schon, da das wohl in letzter Zeit die eher benutzte Dev-HW war.

Bei neuen Games, bzw. Games bei denen die Entwicklung noch nicht so weit fortgeschritten ist, kann das ganze dann schon wieder völlig anders aussehen.

Aber egal...aufregen ist schlecht für den Blutdruck....

Ich hätte nun mal gerne beides gehabt, FP-Filtering und AA.


Ich höre gerade eine Stimme, die mir was von relativ winkelunabhägingem AF erzählt und daß das viele Transistoren gefressen hat. Ich weiß nicht, woher sie kommt. :upara:

Hat das wirklich viele Transistoren gefressen?? Das weiss keine so genau.
Prinzipiel kann keiner von uns darüber aussagen treffen, ob FP-Filtering trotz des besseren AF möglich gewesen wäre....oder ob es ingesamt gesehen überhaupt drinne gewesen wäre.

Beim r580 wird sich in dieser Hinsicht wohl leider auch nix ändern, genausowenig wie nV wohl beim G70 Nachfolger HDR-AA einbaut.

Ich finde es einfach schade, das sich die beiden großen IHVs bei einem der interessantesten Features der letzten Zeit nicht auf einen gemeinsamen Nenner einigen konnten.
Schuld will ich dabei eigentlich keinem zuweisen, da man nicht weiss zu welchen Zeitpunkt der r520 "fertig" war und ATI vielleicht nicht "wusste" das nV FP-Filtering bzw. überhaupt HDR anbieten wird.

Schade ist es trotzdem.

Crushinator
2005-10-13, 13:17:42
Welches Game meinst du denn, oder darfst du nix dazu sagen?
Sagen wir's so. Ich möchte nichts explizites sagen, weil es mir von jemandem einfach so anvertraut worden ist. Ich müßte abgesehen davon auch erzählen gegen welche Hardware der Vergleich gemeint war, und das würde zu viel Feuer ins Öl gießen.
Ich hätte nun mal gerne beides gehabt, FP-Filtering und AA.
Du glaubst gar nicht, wie gern ich das gehabt hätte. In Verbidung mit dem neuen AF sowieso. :ulove: Aber einen Tod muß man nun mal sterben. :usad:
(...) Schuld will ich dabei eigentlich keinem zuweisen, da man nicht weiss zu welchen Zeitpunkt der r520 "fertig" war und ATI vielleicht nicht "wusste" das nV FP-Filtering bzw. überhaupt HDR anbieten wird.
Doch, das wußte man. Man entschied sich aber für AA trotz HDR und Verbesserung des AF. Was insgesamt betrachtet nicht zwingend schlechter sein muß.

aths
2005-10-13, 16:21:58
Jetzt muss ich doch nochmal nachfragen, weil ich im anderen Thread ja eins auf die Finger bekommen habe...

Also, klar ist, dass der R520 FP32 filtern kann. Gut.

Dein Text, aths, den ich hier zitiert habe, liest sich so, als ob der R520 FP16 überhaupt nicht filtern könnte, sprich dieses Texturformat eigentlich für Diffuse-Maps unbrauchbar wäre. In anderen Threads liest sich das nur so, als ob diese Texturen nur in Vertex-Shadern nicht gefiltert werden können (wobei ich ganz klar zugeben muss, dass ich mir überhaupt nicht vorstellen kann, wozu man in einem Vertex-Shader Texturen überhaupt filtern muss, aber das kann ja an meinem unbestreitbar limitierten Wissen zum Thema GPU-Programmierung liegen...)

Also, wie ist es nun genau? Und was bedeutet das letztlich wirklich für die Entwickler?Die TMU des R520 kann nur FX8- und FX16-Texturen filtern. Dabei können pro Takt nur 32 Bit genutzt werden – eine Textur mit 4x FX16 braucht also zwei Takte.

FP16 und FP32 können nur mit Point Sampling gelesen, aber nicht gefiltert werden. Das 32-Bit-Limit gilt soweit ich weiß auch hier (die FP16-Textur mit 4 Kanälen kostet demnach zwei Takte, also 8 Takte um die 4 Samples zu holen, während NV40 nur 2 Takte braucht für das Bi-Sample.)

Da man die Formel fürs bilineare Filtern im Pixelshader nachstellen kann, kann man mit dem R300/R520 auch bilinear gefilterte FP16-Texturen nutzen. Nur ist das eben viel langsamer. Trilinear nachzustellen ginge auch noch, AF kannst du aber vergessen.

Im Vertexshader mehr als Point Sampling anzubieten wird schwierig, da man keine Quads hat und demzufolge schlecht das LOD bestimmen kann.

Coda
2005-10-13, 16:30:18
Im Vertexshader mehr als Point Sampling anzubieten wird schwierig, da man keine Quads hat und demzufolge schlecht das LOD bestimmen kann.
LOD wird bei einem Vertex-Texturefetch explizit angegeben. Außerdem bräuchte man für bilinear gar keinen LOD.

NV4x kann ja auch Mipmapping für Vertex-Texture-Sampling.

aths
2005-10-13, 16:37:00
LOD wird bei einem Vertex-Texturefetch explizit angegeben. Außerdem bräuchte man für bilinear gar keinen LOD.Mit MIP-Mapping schon.
NV4x kann ja auch Mipmapping für Vertex-Texture-Sampling.Eben deshalb.

Mit dem LOD alleine kann man nicht anistrop filtern. Trilinear wäre natürlich möglich. (Und für vernünftiges adaptives Displacement Mapping auch notwendig.)

aths
2005-10-13, 16:37:10
Der nv40/G70 könne kann die FP-Formate bi, tri und anisotropisch Filtern. (Also genauso wie bei Int-Formaten.)Anisotrop. Nicht -isch.

Coda
2005-10-13, 16:56:44
Mit MIP-Mapping schon.
Eben deshalb.

Mit dem LOD alleine kann man nicht anistrop filtern. Trilinear wäre natürlich möglich. (Und für vernünftiges adaptives Displacement Mapping auch notwendig.)Was ist jetzt das Problem? Du meintest, man könne schlecht mehr als Point-Sampling machen weil man kein LOD hat. Bilinear und Trilinear sind aber auf jeden Fall möglich, weil es nur texldl gibt in VS3.0 wo man das LOD angeben muss.

Beim Aniso geb ich dir recht, da bräuchte man noch dx und dy.

aths
2005-10-13, 17:44:32
Was ist jetzt das Problem? Du meintest, man könne schlecht mehr als Point-Sampling machen weil man kein LOD hat. Bilinear und Trilinear sind aber auf jeden Fall möglich, weil es nur texldl gibt in VS3.0 wo man das LOD angeben muss.

Beim Aniso geb ich dir recht, da bräuchte man noch dx und dy.Man braucht sogar noch mehr.

Man hat kein LOD was man im VS einfach berechnen kann, sondern muss es extra angeben, das meinte ich damit dass man kein LOD hätte (gemeint ist: Von alleine kein LOD.) Bei einer normalen tex-Operation im Pixelshader wird das LOD ja automatisch berechnet und das ist im VS nicht möglich, da gibts nur texldl.

Coda
2005-10-13, 17:55:47
Ja, und genau deshalb wäre es doch auch kein Problem bilinear und trilinear anzubieten :|

aths
2005-10-13, 18:52:23
Ja, und genau deshalb wäre es doch auch kein Problem bilinear und trilinear anzubieten :|Das sagst du so leicht daher.

Einerseits hat man das LOD-Problem. Man muss es selbst berechnen und übergeben. Andererseits rechne doch mal nach, wie viel Bandbreite man braucht, um FP32-Texturen frei zu filtern. Ein trilineares Sample sind dann schon mal eben 1024 Bit, die irgendwo herkommen müssen. Entweder baut man eine TMU ein, die filtern kann, oder – wie im NV40 und G70 – vier TMUs, die leider nicht filtern können. Für mehr als die vier physikalischen Vertexshader-Pointsampling-TMUs ist die Bandbreite nicht da, und so ist man flexibler als mit einer einzelnen TMU, die dafür filtern kann.

Natürlich hätte ich trotzdem gerne trilineare Filterung im Vertexshader :) Aber das würde wegen der Bandbreite trotzdem mehrere Takte brauchen, und die benötigten FP32-Einheiten zum Filtern sind leider nicht kostenlos. Da müssen wir wohl warten, bis es unified Shaderhardware gibt.

Demirug
2005-10-13, 19:30:22
Das sagst du so leicht daher.

Einerseits hat man das LOD-Problem. Man muss es selbst berechnen und übergeben. Andererseits rechne doch mal nach, wie viel Bandbreite man braucht, um FP32-Texturen frei zu filtern. Ein trilineares Sample sind dann schon mal eben 1024 Bit, die irgendwo herkommen müssen. Entweder baut man eine TMU ein, die filtern kann, oder – wie im NV40 und G70 – vier TMUs, die leider nicht filtern können. Für mehr als die vier physikalischen Vertexshader-Pointsampling-TMUs ist die Bandbreite nicht da, und so ist man flexibler als mit einer einzelnen TMU, die dafür filtern kann.

Natürlich hätte ich trotzdem gerne trilineare Filterung im Vertexshader :) Aber das würde wegen der Bandbreite trotzdem mehrere Takte brauchen, und die benötigten FP32-Einheiten zum Filtern sind leider nicht kostenlos. Da müssen wir wohl warten, bis es unified Shaderhardware gibt.

Auch mit unified Shaderhardware hast du die Bandbreite nicht. Oder möchtest du jetzt darauf hinaus das man auch andere Formate für Vertextexturen benutzen möchtest?

Coda
2005-10-13, 19:44:49
Einerseits hat man das LOD-Problem. Man muss es selbst berechnen und übergeben.Muss man doch sowieso?

aths
2005-10-13, 19:49:26
Muss man doch sowieso?Im Vertexshader, ja.

Auch mit unified Shaderhardware hast du die Bandbreite nicht. Oder möchtest du jetzt darauf hinaus das man auch andere Formate für Vertextexturen benutzen möchtest?Die Bandbreite reicht zwar nicht, aber man wird hoffentlich keine extra VS-TMUs mehr verbauen. In der TMU zu filtern dürfte trotz allem schneller sein als die Filterung im Vertexshader mathematisch nachzustellen.

Und ja, ich würde im VS auch gerne FP16-Texturen nutzen können :)

Coda
2005-10-13, 19:51:59
Im Vertexshader, ja.Reden wir grad aneinander vorbei? Ich hab die ganze Zeit die VS gemeint X-D

aths
2005-10-13, 20:31:51
Reden wir grad aneinander vorbei? Ich hab die ganze Zeit die VS gemeint X-DJa, ich auch. Aber das LOD zu selbst berechnen zu müssen stelle ich mir nicht so einfach vor.

Coda
2005-10-13, 20:36:01
Das geht eigentlich nur gut wenn man die Position der Nachbarvertices weiß, also bei nem Gitter z.B.

Aber was interessiert das den HW-Entwickler wenn er Tri-TMUs für den Vertexshader einbauen muss? Er bekommt den LOD ja serviert ;)

aths
2005-10-14, 18:01:25
Das geht eigentlich nur gut wenn man die Position der Nachbarvertices weiß, also bei nem Gitter z.B.

Aber was interessiert das den HW-Entwickler wenn er Tri-TMUs für den Vertexshader einbauen muss? Er bekommt den LOD ja serviert ;)Ihn interessiert der Transistorverbrauch. MIP-Mapping für Displacementmaps ist ohnehin problematisch und sollte nur für niederfrequenten Content genutzt werden.

Coda
2005-10-14, 18:04:33
Wer redet denn von Transistoren? Du lenkst ab...

aths
2005-10-14, 18:54:27
Wer redet denn von Transistoren? Du lenkst ab...Ich schreibe zu stark verkürzt. Und ich habe keine Idee, wie man beim Vertex-Texturing ohne allzugroße Umstände einen validen LOD für adaptives Displacement Mapping errechnen kann.

Mir ist so viel klar, dass man im Vertexshader TMUs braucht, die mindestens trilinear filtern können. Soweit ich weiß, hat der Parhelia sowas. Jetzt stellt sich aber die Frage, was für TMUs man wirklich einbaut.

So war ich erstaunt dass der NV40 mit 6 VS nur 4 VS-TMUs hat und dachte, dass man das Sampling doch verschnellern könne wenn man pro VS eine physikalische TMU hätte, und musste erst auf die Bandbreitenproblematik aufmerksam gemacht werden. Die Bandbreite reicht für bis zu 4 Point-Sampling-TMUs. Besteht man auf TMUs die filtern können, würde die Bandbreite ja nur für eine bi-TMU reichen. Aber mit 4 Pointsampling-TMUs ist man flexibler als mit einer bi-TMU. Gleich 4 bi-TMUs einzubauen hieße ein Mehr an Transistoren zu benötigen. In diesem Zusammenhang verstehe ich die Design-Entscheidung beim NV40.

Hat man dereinst unified Shader, und TMUs die FP32-Texturen filtern können, lassen sich diese TMUs auch für VS-Programme nutzen.

Benedikt
2005-11-09, 10:12:43
IMHO ist HDR (zumindest das von der HW direkt unterstützte HDR) damit tot.

Bevor sich die Devs mit 2 verschiedenen Versionen rumplagen (und dann bei ATI sogar höchsten Bi-Filterring per Shader in annehmbarer Geschwindigkeit rausspringt), benutzen Sie lieber gleich "Fake"-HDR ala Valves HDR-Implemantation bei DoD:S bzw. Lost Toast.

Hat den vorteill das es auf allen Karten läuft die mindestens SM2.0 können und es funktioniert AA auf allen Karten.
Zu der von Valve entwickelten HDR-Methode: Ist das denn nun Fake-HDR, oder eine echte HDR-Variante? Simples Blooming ist's ja wohl nicht. Wie kommt's aber, dass man eine Möglichkeit gefunden hat, AA plus HDR zu kombinieren, wo doch immer postuliert wurde, dass HDR und AA mit derzeitiger Hardware nicht gleichzeitig funktionieren können? Warum ist das vormals "Unmögliche" auf einmal doch möglich, nämlich Kantenglättung bei HDR-Content zu genießen?

Kann mir mal jemand (Gurus?) bitte erklären, welchen Dynamikumfang denn das Valve-HDR hat? Ist es mit FP16 vergleichbar, oder weniger? Ist es "echtes" HDR?

deekey777
2005-11-09, 12:49:32
Zu der von Valve entwickelten HDR-Methode: Ist das denn nun Fake-HDR, oder eine echte HDR-Variante? Simples Blooming ist's ja wohl nicht. Wie kommt's aber, dass man eine Möglichkeit gefunden hat, AA plus HDR zu kombinieren, wo doch immer postuliert wurde, dass HDR und AA mit derzeitiger Hardware nicht gleichzeitig funktionieren können? Warum ist das vormals "Unmögliche" auf einmal doch möglich, nämlich Kantenglättung bei HDR-Content zu genießen?

Kann mir mal jemand (Gurus?) bitte erklären, welchen Dynamikumfang denn das Valve-HDR hat? Ist es mit FP16 vergleichbar, oder weniger? Ist es "echtes" HDR?

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3631787&postcount=342

Aber VALVe hat noch "echtes" FP16 HDRR mit FP-BLending und FP-Filtering im Ärmel, was zB auf der E³ gezeigt wurde.

Benedikt
2005-11-09, 13:50:46
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3631787&postcount=342

Aber VALVe hat noch "echtes" FP16 HDRR mit FP-BLending und FP-Filtering im Ärmel, was zB auf der E³ gezeigt wurde.
Ja, aber wieso wurde dann immer geschrieben HDR plus AA sei nicht möglich auf derzeitiger Hardware? Bezog sich das explizit auf FP16-HDR?

ShadowXX
2005-11-09, 14:05:22
Ja, aber wieso wurde dann immer geschrieben HDR plus AA sei nicht möglich auf derzeitiger Hardware? Bezog sich das explizit auf FP16-HDR?

Es bezog sich explizit auf FP16-HDR mit einem nv40/G70. Die HW kann es einfach nicht.

DaBrain
2005-11-09, 16:19:12
HDR Texturecontent der in einem Format vorliegt das nicht gefilter werden kann [...]

Bisschen OT, aber welche Formate gibt es denn da?

Und wie genau muss man sich das vorstellen? Wird da wieder der Alpha Kanal verwendet? :confused:

Benedikt
2005-11-09, 16:45:43
Es bezog sich explizit auf FP16-HDR mit einem nv40/G70. Die HW kann es einfach nicht.
Ich möchte das jetzt bitte klären:
Und die ATI Hardware kann echtes FP16-HDR mit Antialiasing, ganz sicher? ;)

deekey777
2005-11-09, 16:52:00
Ich möchte das jetzt bitte klären:
Und die ATI Hardware kann echtes FP16-HDR mit Antialiasing, ganz sicher? ;)

ATis PR-Abteilung sagt: "Ja!"

Im Ernst: Ja.

Demirug
2005-11-09, 16:52:05
Bisschen OT, aber welche Formate gibt es denn da?

Und wie genau muss man sich das vorstellen? Wird da wieder der Alpha Kanal verwendet? :confused:

Ich verstehe die Frage nicht. Es geht hier um ganz normale Texturen die eben einfach nur eine höhere Range brauchen.

aths
2005-11-09, 17:13:14
Der R520 kann Multisampling auf vierkanalige FP16-Targets ausführen. Was er nicht kann ist, FP16-Texturen in dem TMUs zu filtern. Die Frage ist, ob man das als Voraussetzung für "echtes" FP16-HDR definiert oder nicht.

DaBrain
2005-11-09, 17:45:25
Ich verstehe die Frage nicht. Es geht hier um ganz normale Texturen die eben einfach nur eine höhere Range brauchen.


Und wie wird das erreicht?

Ich weiss nicht genau wie ich die Frage stellen soll.

Wo besteht der Unterschied zwischen einer normalen Textur und einer HDR Textur?

Wie wird bestimmt, welcher Teil der Textur bei der Iris Simulation 'leuchet' und welcher nur eine helle Farbe hat?

aths
2005-11-09, 17:51:27
Und wie wird das erreicht?

Ich weiss nicht genau wie ich die Frage stellen soll.

Wo besteht der Unterschied zwischen einer normalen Textur und einer HDR Textur?

Wie wird bestimmt, welcher Teil der Textur bei der Iris Simulation 'leuchet' und welcher nur eine helle Farbe hat?"HDR-Texturen" speichern Texturen in einer viel höheren Präzision bzw. viel höheren Range (bei mindestens gleicher Präzision.) Man kann die hohe Range auch durch das hochskalieren der Werte einer Low-Dynamic-Range-Textur erreichen, nur ist das dann fürchterlich ungenau.

Angenommen wir haben eine Lightmap. Traditionell speichern diese Verdunklungs-Informationen, die "255" steht für "genauso hell wie die Basemap", kleinere Werte für dunklere Töne, "0" für "komplett schwarz". Warum macht man es nicht anders? Weil man beim Hochskalieren grobe Stufen reinbekommt. Nachteil: Man kann mit Lightmaps die Basemap nicht zusätzlich aufhellen. Das beste wäre also, auf Skalierungen verzichten zu können, und trotzdem noch die Information "heller als die Basemap" speichern zu können. FP16-Texturen bieten das an. FP16-Texturen können sehr große (und sehr kleine) Werte mit (vereinfacht gesagt) immer der gleichen relativen Genauigkeit speichern.

Denken wir eine tradionelle 8-Bit-Textur, und ändern aus Spaß mal das letzte, also am wenigsten bedeutsame Bit. Was passiert? Bei großen Zahlen macht das praktisch nichts aus. Bei kleinen Zahlen, die ohnehin nur die hintersten Bitstellen belegen, macht das – im Verhältnis – jedoch sehr viel aus.

FP-Texturen speichern daher die Komma-Position und die Nachkomma-Stellen. Das heißt, um sehr kleine Zahlen zu speichern, muss man nicht "vorne" mit Null auffüllen, sondern kann alle Kommastellen nutzen. Um sehr große Zahlen zu speichern ist das Verfahren ebenfalls günstig: Die letzten Vorkomma-Stellen interessieren bei so großen Zahlen ohnehin nicht mehr, also werden sie nicht gespeichert. Man speichert die Kommaposition und die folgenden Stellen soweit, wie es geht (bei FP16 werden 10 binäre Kommastellen gespeichert.)

Das heißt, möchte man in Lightmaps sowohl den Lichteinfall der prallen Sonne, als auch viel kleinere Lichtstärken speichern, benötigt man ein FP-Format. Man kann Zahlen > 1 bei gleichzeitiger Präzision die mindestens dem traditionellen 8-Bit-Format entspricht, auch mit 16 Bit Integer-Texturen realisieren. Allerdings muss man dann wieder skalieren, und der mögliche Wertebereich ist dennoch viel kleiner als bei FP16-Formaten.

DaBrain
2005-11-09, 21:26:37
Danke für die gute Erklärung. Ich denke ich habe das soweit verstanden. :)

Benedikt
2005-11-10, 16:25:49
"HDR-Texturen" speichern Texturen in einer viel höheren Präzision bzw. viel höheren Range (bei mindestens gleicher Präzision.) Man kann die hohe Range auch durch das hochskalieren der Werte einer Low-Dynamic-Range-Textur erreichen, nur ist das dann fürchterlich ungenau.

Angenommen wir haben eine Lightmap. Traditionell speichern diese Verdunklungs-Informationen, die "255" steht für "genauso hell wie die Basemap", kleinere Werte für dunklere Töne, "0" für "komplett schwarz". Warum macht man es nicht anders? Weil man beim Hochskalieren grobe Stufen reinbekommt. Nachteil: Man kann mit Lightmaps die Basemap nicht zusätzlich aufhellen. Das beste wäre also, auf Skalierungen verzichten zu können, und trotzdem noch die Information "heller als die Basemap" speichern zu können. FP16-Texturen bieten das an. FP16-Texturen können sehr große (und sehr kleine) Werte mit (vereinfacht gesagt) immer der gleichen relativen Genauigkeit speichern.

Denken wir eine tradionelle 8-Bit-Textur, und ändern aus Spaß mal das letzte, also am wenigsten bedeutsame Bit. Was passiert? Bei großen Zahlen macht das praktisch nichts aus. Bei kleinen Zahlen, die ohnehin nur die hintersten Bitstellen belegen, macht das – im Verhältnis – jedoch sehr viel aus.

FP-Texturen speichern daher die Komma-Position und die Nachkomma-Stellen. Das heißt, um sehr kleine Zahlen zu speichern, muss man nicht "vorne" mit Null auffüllen, sondern kann alle Kommastellen nutzen. Um sehr große Zahlen zu speichern ist das Verfahren ebenfalls günstig: Die letzten Vorkomma-Stellen interessieren bei so großen Zahlen ohnehin nicht mehr, also werden sie nicht gespeichert. Man speichert die Kommaposition und die folgenden Stellen soweit, wie es geht (bei FP16 werden 10 binäre Kommastellen gespeichert.)

Das heißt, möchte man in Lightmaps sowohl den Lichteinfall der prallen Sonne, als auch viel kleinere Lichtstärken speichern, benötigt man ein FP-Format. Man kann Zahlen > 1 bei gleichzeitiger Präzision die mindestens dem traditionellen 8-Bit-Format entspricht, auch mit 16 Bit Integer-Texturen realisieren. Allerdings muss man dann wieder skalieren, und der mögliche Wertebereich ist dennoch viel kleiner als bei FP16-Formaten.
Aths, zuerst mal danke für diese tolle Erklärung! ;)

Noch zwei Sachen:
*) Wofür braucht man dann Tonemapping? Um diese durch FP16 bedingte höhere Präzision wieder auf "normale Präzision" zurückzuführen, weil es keine HDR-Tauglichen Ausgabegeräte gibt, ist das so richtig? Und was ist "normale Präzision" überhaupt?
*) HDR kenne ich insofern, man entschuldige bitte meine Unwissenheit, dass z. B. die Sonne oder extrem helle Lichtquellen das Bild "überstrahlen". Auch wenn man z. B. teilweise um eine Ecke einer Mauer in das Licht hinein sieht, strahlt die Lichtquelle teilweise in diese Mauer hinein, ich kann das jetzt nicht anders ausdrücken. Wie realisiert man das, dieses in den Gegenstand hinein strahlen?

Der R520 kann Multisampling auf vierkanalige FP16-Targets ausführen. Was er nicht kann ist, FP16-Texturen in dem TMUs zu filtern. Die Frage ist, ob man das als Voraussetzung für "echtes" FP16-HDR definiert oder nicht.
Hmhm, und das funktioniert mit annehmbarer Geschwindigkeit? Es hieß doch immer, derzeitiger Hardware würde es an Bandbreite (oder ähnlichem) mangeln, um Multisampling in Kombination mit FP16 darstellen zu können!? Betrifft das nur Nvidia-Hardware (NV40, G70)?

Neomi
2005-11-10, 16:48:04
*) Wofür braucht man dann Tonemapping? Um diese durch FP16 bedingte höhere Präzision wieder auf "normale Präzision" zurückzuführen, weil es keine HDR-Tauglichen Ausgabegeräte gibt, ist das so richtig? Und was ist "normale Präzision" überhaupt?

Helligkeit, Farbsättigung, und andere Dinge kann man im Rahmen von Postprocessing anpassen, das nennt man dann Tonemapping. Mit der Präzision hat das erstmal nichts direkt zu tun.

*) HDR kenne ich insofern, man entschuldige bitte meine Unwissenheit, dass z. B. die Sonne oder extrem helle Lichtquellen das Bild "überstrahlen". Auch wenn man z. B. teilweise um eine Ecke einer Mauer in das Licht hinein sieht, strahlt die Lichtquelle teilweise in diese Mauer hinein, ich kann das jetzt nicht anders ausdrücken. Wie realisiert man das, dieses in den Gegenstand hinein strahlen?

Die hellen Bildteile werden stark geblurt und nochmal über das Bild gelegt.

Hmhm, und das funktioniert mit annehmbarer Geschwindigkeit? Es hieß doch immer, derzeitiger Hardware würde es an Bandbreite (oder ähnlichem) mangeln, um Multisampling in Kombination mit FP16 darstellen zu können!? Betrifft das nur Nvidia-Hardware (NV40, G70)?

Die neuen Radeons können FP16-Multisampling, die aktuellen nVidia-Karten nicht. Die Bandbreite entscheidet nur darüber, wie schnell etwas bestimmtes machbar ist, nicht ob es machbar ist.

aths
2005-11-10, 19:52:18
Aths, zuerst mal danke für diese tolle Erklärung! ;)

Noch zwei Sachen:
*) Wofür braucht man dann Tonemapping? Um diese durch FP16 bedingte höhere Präzision wieder auf "normale Präzision" zurückzuführen, weil es keine HDR-Tauglichen Ausgabegeräte gibt, ist das so richtig? Und was ist "normale Präzision" überhaupt?Beim Tonemapping wird das HDR-Bild auf ein LDR-Target überführt. Die Präzision spielt da weniger eine Rolle, sondern der Wertebereich. Mit einem Monitor kannst du zum Beispiel nichts heller als "100%" darstellen. Da muss dann entschieden werden, wie man das HDR-Bild herunterrechnet. Angenommen, wir haben eine Lichtquelle die extrem helles gelbes Licht ausstrahlt. So hell, dass wir es als Weiß wahrnehmen. Doch nun fällt dieses Licht durch eine recht dunkle graue Scheibe und wird dort stark abgeschwächt. Dann sollte es durch die Scheibe betrachtet nicht grau, sondern gelb sein. Um zu wissen, wie weit sich die Augenpupille öffnet, muss nun die Gesamthelligkeit des Bildes bekannt sein. Das heißt, man sollte nicht nur während des Berechnungsvorganges ein HDR-Format nutzen (was bei SM2 grundsätzlich der Fall ist) sondern auch das fertige Bild sollte noch in einem HDR-Datenformat vorliegen. Die anschließende Bestimmung der Gesamthelligkeit lässt sich effektiv mit bilinearer Filterung erledigen: Man erstellt einfach fortlaufend MIP-Maps bis man bei 1x1 angekommen ist, und hat dann die durchschnittliche Helligkeit. Hier kommt das FP-Filtern ins Spiel. Kann man die TMU filtern lassen belastet das nicht den Pixelshader.

Aber auch der gegenteilige Fall – das hochrechnen – kann vorkommen, zum Beispiel wenn alles sehr dunkel ist und man die Gewöhnung des menschlichen Auges an die Dunkelkeit simulieren möchte. Dann aber reicht es nicht, nur die Helligkeiten umzurechnen. Im Dunklen erkennen wir nur noch Graustufen, das Tonemapping sollte dann entsprechend die Farbsättigung abschwächen*. Um es perfekt zu machen, sollte man außerdem das graue Bild noch nachträglich vergröbern, denn feine Umrisse sehen wir im Dunklen ja nicht. Die reinen Helligkeitssenoren im Auge sind zwar ca. 1000x lichtempfindlicher als die Farbsensoren, aber sind auf der Netzhaut auch deutlich weniger dicht zusammen – wir können im Dunklen nur "grob" sehen.

*) HDR kenne ich insofern, man entschuldige bitte meine Unwissenheit, dass z. B. die Sonne oder extrem helle Lichtquellen das Bild "überstrahlen". Auch wenn man z. B. teilweise um eine Ecke einer Mauer in das Licht hinein sieht, strahlt die Lichtquelle teilweise in diese Mauer hinein, ich kann das jetzt nicht anders ausdrücken. Wie realisiert man das, dieses in den Gegenstand hinein strahlen? Alles, was sehr hell ist, wird (stark) geblurrt, und dann mit dem normalen Bild verrechnet (im einfachsten Fall draufaddiert.) Dabei handelt es sich also um Postprocessing.

Hmhm, und das funktioniert mit annehmbarer Geschwindigkeit? Es hieß doch immer, derzeitiger Hardware würde es an Bandbreite (oder ähnlichem) mangeln, um Multisampling in Kombination mit FP16 darstellen zu können!? Betrifft das nur Nvidia-Hardware (NV40, G70)?Ich bin mir nicht sicher, ob NV40 und G70 wirklich kein FP16-MSAA können, oder ob es nur nicht aktiviert wurde. Mit jenem MSAA wäre es, wenn es die Hardware denn anbieten würde, aber recht langsam. Der R520 hat einen besseren Speichercontroller und ohnehin mehr Speicherbandbreite, da ist der Geschwindigkeitseinbruch offenbar nicht so groß.


* Wie man die Farbsättigung effizient abschwächt, weiß ich nicht. Eine prinzipielle Möglichkeit wäre, vom HDR-Target eine Graustufen-Version zu erstellen (ein MAD pro Pixel) und die Werte ggf. je nach Helligkeit mit dem noch farbigen Bild verrechnen (um abgestufte Farbsättigung zu ermöglichen.)

Neomi
2005-11-10, 21:09:56
* Wie man die Farbsättigung effizient abschwächt, weiß ich nicht. Eine prinzipielle Möglichkeit wäre, vom HDR-Target eine Graustufen-Version zu erstellen (ein MAD pro Pixel) und die Werte ggf. je nach Helligkeit mit dem noch farbigen Bild verrechnen (um abgestufte Farbsättigung zu ermöglichen.)

Welchen Teil davon weißt du nicht? Die technische Seite ist eigentlich recht einfach. Man braucht die Farbe und einen konstanten Vektor mit der Gewichtung (meist r=0.30, g=0.59, b=0.11). Ein einzelnes dp3 zwischen den beiden reicht, schon hat man den Grauwert (und schreibt ihn in alle Komponenten eines tempregisters). Jetzt noch eine Interpolation zwischen den beiden, schon ist die Farbintensität abgeschwächt.

Das geht direkt im Shader mit nur zwei Instruktionen (wenn man nicht noch den Interpolationsfaktor errechnen muß) und kommt ganz ohne Extrabuffer aus.

deekey777
2005-11-10, 21:22:32
....Ich bin mir nicht sicher, ob NV40 und G70 wirklich kein FP16-MSAA können, oder ob es nur nicht aktiviert wurde. Mit jenem MSAA wäre es, wenn es die Hardware denn anbieten würde, aber recht langsam. Der R520 hat einen besseren Speichercontroller und ohnehin mehr Speicherbandbreite, da ist der Geschwindigkeitseinbruch offenbar nicht so groß.


http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3179206&postcount=247

Wenn mich nicht alles täuscht, sprach er auch von irgendeiner grünen Technologie-Demo, wo HDRR+MSAA zu sehen ist.

PS: Hast du dir HL2: Lost Coast angeschaut?

aths
2005-11-10, 21:40:30
Welchen Teil davon weißt du nicht? Die technische Seite ist eigentlich recht einfach. Man braucht die Farbe und einen konstanten Vektor mit der Gewichtung (meist r=0.30, g=0.59, b=0.11). Ein einzelnes dp3 zwischen den beiden reicht, schon hat man den Grauwert (und schreibt ihn in alle Komponenten eines tempregisters). Jetzt noch eine Interpolation zwischen den beiden, schon ist die Farbintensität abgeschwächt.

Das geht direkt im Shader mit nur zwei Instruktionen (wenn man nicht noch den Interpolationsfaktor errechnen muß) und kommt ganz ohne Extrabuffer aus.Ja das DP ist klar. Aber man sollte nicht einfach linear interpolieren. Überhalb einer bestimmten Pupillenöffnung sollte es komplett grau sein. Der Bereich, in denen das Farbsehen noch vorhanden ist, nur abgeschwächt, ist recht dünn.

aths
2005-11-10, 21:41:32
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3179206&postcount=247

Wenn mich nicht alles täuscht, sprach er auch von irgendeiner grünen Technologie-Demo, wo HDRR+MSAA zu sehen ist.

PS: Hast du dir HL2: Lost Coast angeschaut?Ich habe glaube ich irgendwann mal ein Video dazu gesehen.

Coda
2005-11-10, 21:42:46
Ja das DP ist klar. Aber man sollte nicht einfach linear interpolieren. Überhalb einer bestimmten Pupillenöffnung sollte es komplett grau sein. Der Bereich, in denen das Farbsehen noch vorhanden ist, nur abgeschwächt, ist recht dünn.Dann wählt man halt den Interpolationsfaktor vorher irgendwie logarithmisch aus.

aths
2005-11-10, 21:45:59
Dann wählt man halt den Interpolationsfaktor vorher irgendwie logarithmisch aus.Das ist leicht gesagt.

Coda
2005-11-10, 21:47:57
Nein, auch leicht gemacht.

aths
2005-11-10, 21:49:52
Beispiel?

Coda
2005-11-10, 21:52:03
Was ist das Problem? Man hat die durchschnittliche Bildhelligkeit vorher ausgerechnet. Darauf appliziert man halt eine gut gewählte Formel (muss ja nur einmal im Shader errechnet werden) um die gewünschte Saturation zu erhalten.

Danach appliziert man das ganze auf das Bild wie es Neomi gesagt hat.

aths
2005-11-10, 22:12:55
Was ist das Problem? Man hat die durchschnittliche Bildhelligkeit vorher ausgerechnet. Darauf appliziert man halt eine gut gewählte Formel (muss ja nur einmal im Shader errechnet werden) um die gewünschte Saturation zu erhalten.

Danach appliziert man das ganze auf das Bild wie es Neomi gesagt hat.Wenn das mal alles so einfach wär' ... die Farbsättigung muss pro Pixel bestimmt werden. Gegebenfalls vorgenommene Bildvergröberung kann auch nicht pauschal aufs gesamte Bild angewendet werden. Einzelne dunkle Gebiete in einem ansonsten hellen Bild müssen einfach dunkel dargestellt werden. Einzelne helle Gebiete in einem ansonsten dunklen Bild müssen noch Farbsättigung aufweisen.

Neomi
2005-11-10, 22:24:03
Wenn das mal alles so einfach wär' ... die Farbsättigung muss pro Pixel bestimmt werden. Gegebenfalls vorgenommene Bildvergröberung kann auch nicht pauschal aufs gesamte Bild angewendet werden. Einzelne dunkle Gebiete in einem ansonsten hellen Bild müssen einfach dunkel dargestellt werden. Einzelne helle Gebiete in einem ansonsten dunklen Bild müssen noch Farbsättigung aufweisen.

Zwischen der Ermittlung des Grauwertes und der Interpolation kann man aus dem Grauwert ja noch den Interpolationsfaktor errechnen, er entspricht ja der Helligkeit. Für Variationen abhängig von der Position im Bild reicht eine recht niedrig aufgelöste Textur (dank Interpolation), die über den ganzen Bildschirm geht und in die Berechnung des Interpolationsfaktors mit einfließt.

Die Bildvergröberung kann man dann vielleicht wie Tiefenunschärfe behandeln, nur eben nicht von der Tiefe abhängig.

Demirug
2005-11-10, 22:25:18
Welchen Teil davon weißt du nicht? Die technische Seite ist eigentlich recht einfach. Man braucht die Farbe und einen konstanten Vektor mit der Gewichtung (meist r=0.30, g=0.59, b=0.11). Ein einzelnes dp3 zwischen den beiden reicht, schon hat man den Grauwert (und schreibt ihn in alle Komponenten eines tempregisters). Jetzt noch eine Interpolation zwischen den beiden, schon ist die Farbintensität abgeschwächt.

Das geht direkt im Shader mit nur zwei Instruktionen (wenn man nicht noch den Interpolationsfaktor errechnen muß) und kommt ganz ohne Extrabuffer aus.

Du willst doch nicht etwa einfach nur linear über die Luminezenz skalieren? :nono:

Ich empfehle mal folgendes als Bettlektüre: http://www.cs.utah.edu/~reinhard/cdrom/tonemap.pdf

Neomi
2005-11-10, 23:02:07
Du willst doch nicht etwa einfach nur linear über die Luminezenz skalieren? :nono:

Ich empfehle mal folgendes als Bettlektüre: http://www.cs.utah.edu/~reinhard/cdrom/tonemap.pdf

War ja auch nur ein Schnellschuß. Noch stehe ich erst am Anfang eines DX9-Renderers, zu Tonemapping und anderen Postprocessing-Effekten komme ich in nächster Zeit noch nicht. Aber das PDF habe ich mir schonmal gesichert, sieht recht interessant aus.

Demirug
2005-11-10, 23:10:49
War ja auch nur ein Schnellschuß. Noch stehe ich erst am Anfang eines DX9-Renderers, zu Tonemapping und anderen Postprocessing-Effekten komme ich in nächster Zeit noch nicht. Aber das PDF habe ich mir schonmal gesichert, sieht recht interessant aus.

Zum Tonemapping kann man bisher nur eines sicher sagen. Die perfekte Lösung ist noch nicht gefunden.

Postprocessing ist eigentlich nichts anderes wie Photoshopfilter auf der GPU laufen zu lassen.

Was den DX9 Renderer angeht so würde ich an deiner Stelle da mit der Festlegung der Schnittstellen noch etwas warten bis in kürze die DX10 API veröffentlich wird.

deekey777
2005-11-20, 21:53:43
Ich habe glaube ich irgendwann mal ein Video dazu gesehen.

Dann wirf schnell Steam an. Wenn man diesem Posting (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3697597&postcount=278) den Glauben schenken kann, dann gibt's auch die dritte Implementierung.

Doch zurück zum Thema: Auf iXBT wurde als sechster Teil ihres X1x00 Previews ein Interview mit ATIs Guennadi Riguer veröffentlicht, wo auch zum fehlenden FP-Filtern gefragt und beantwortet wurde. Hoffentlich kommt bald auch die englische Version.

Pi-Mal-Daumen: FP-Filtern braucht man nicht unbedingt. :D ;)

http://www.ixbt.com/video2/r520-part6.shtml

Demirug
2005-11-20, 22:06:21
Pi-Mal-Daumen: FP-Filtern braucht man nicht unbedingt. :D ;)

"Was ich nicht habe ist unnötig. Alles was ich kann ist unverzichtbar"
Grundbotschaft die jedes gute Marketing vermitteln muss.

Und jeder Mitarbeiter einer Firma der Interviews geben darf ist vom Marketing gebrieft worden.

deekey777
2005-11-20, 22:39:21
Er sagt, daß beim FP16 HDR das Alpha-Blending und das MSAA eine vorrangige Rolle spielen, erst dann kommt die Filterung der FP16 Texturen, die beim HDR unkritischer sei. [Sehr viel Text] Die FP16 Filterung kann im Shader simmuliert werden, doch dies sei eher die Ausnahme als der Regelfall.

Wenn ich den letzten Absatz seiner Erklärung/Antwort zur fehlenden FP16 Filterung richtig verstanden habe, dann sagt er indirekt, daß die Entwickler lieber auf Integer-Formate setzen sollen, da diese mindestens den gleichen, wenn nicht gar höheren, Dynamikumfang haben.

Neomi
2005-11-20, 22:59:17
Er sagt, daß beim FP16 HDR das Alpha-Blending und das MSAA eine vorrangige Rolle spielen, erst dann kommt die Filterung der FP16 Texturen, die beim HDR unkritischer sei. [Sehr viel Text] Die FP16 Filterung kann im Shader simmuliert werden, doch dies sei eher die Ausnahme als der Regelfall.

Alphablending kommt wirklich zuerst, da führt kein (halbwegs vernünftiger) Weg dran vorbei. Wenn man dann mal objektiv rangeht, kommt an zweiter Stelle die Texturfilterung und erst zuletzt MSAA. Der Texturfilter kann zwar im Shader nachgebildet werden, aber das kostet mächtig Geschwindigkeit und verlangt eine Anpassung der Shader.

Wenn ich den letzten Absatz seiner Erklärung/Antwort zur fehlenden FP16 Filterung richtig verstanden habe, dann sagt er indirekt, daß die Entwickler lieber auf Integer-Formate setzen sollen, da diese mindestens den gleichen, wenn nicht gar höheren, Dynamikumfang haben.

Floatformate sind den Integern in vielen Bereichen überlegen, natürlich nicht in allen. Die Aussagen, was nun zu bevorzugen sei, richten sich natürlich nach den Fähigkeiten der eigenen Hardware. Da wird nVidia also das Gegenteil behaupten.

Coda
2005-11-20, 23:03:16
Wenn ich den letzten Absatz seiner Erklärung/Antwort zur fehlenden FP16 Filterung richtig verstanden habe, dann sagt er indirekt, daß die Entwickler lieber auf Integer-Formate setzen sollen, da diese mindestens den gleichen, wenn nicht gar höheren, Dynamikumfang haben.Aber auch nur mit mehr Speicherbedarf, somit ist das wohl kaum vergleichbar. In 16bit bekommst du mit Integern niemals den Dynamikbereich eines FP16-Wertes rein.

Sonst hätte ja niemand Floating-Point erfinden müssen :rolleyes:

aths
2005-11-21, 12:34:15
Er sagt, daß beim FP16 HDR das Alpha-Blending und das MSAA eine vorrangige Rolle spielen, erst dann kommt die Filterung der FP16 Texturen, die beim HDR unkritischer sei. [Sehr viel Text] Die FP16 Filterung kann im Shader simmuliert werden, doch dies sei eher die Ausnahme als der Regelfall.Isotrope Filterung kann man im Shader nachstellen, ja – zu hohen Kosten (auf die benötigten Takte bezogen.) Für die Ermittlung der Durchschnittshelligkeit eines Frames ist native bilineare Filterung sehr nützlich.

Wenn ich den letzten Absatz seiner Erklärung/Antwort zur fehlenden FP16 Filterung richtig verstanden habe, dann sagt er indirekt, daß die Entwickler lieber auf Integer-Formate setzen sollen, da diese mindestens den gleichen, wenn nicht gar höheren, Dynamikumfang haben.Mit Integer kann man zwar bestimmte Bereiche besser auflösen, insgesamt ist das Gleitkomma-Format aber deutlich überlegen. Int16 hat eine Dynamik von 4,8 dB, FP16 ohne Denorm-Support von 9,3 dB, mit Denorm-Support von 12,3 dB. Das sind logarithmische Maßeinheiten – mit Denorm-Support ist FP16 um 3 dB besser, also um Faktor 1000.

deekey777
2005-11-21, 12:53:26
Wenn man zuerst liest, was der Gennadi zu HDR-Fähigkeiten der X1x00er Serie geschrieben hat, und dann auf eure Postings schaut, dann wieder das Interview liest, so ist zu jedem Einwand von euch eine Antwort/Erklärung zu finden. :biggrin:
Aber auch nur mit mehr Speicherbedarf, somit ist das wohl kaum vergleichbar. In 16bit bekommst du mit Integern niemals den Dynamikbereich eines FP16-Wertes rein.

Sonst hätte ja niemand Floating-Point erfinden müssen :rolleyes:

Interessanterweise schreibt er, daß der Übergang zu FP16 Texturen mit achtfachem Speicherbedarf verbunden ist (im Vergleich zu komprimierten Texturen). Er schreibt auch, daß Fälle, wo man wirklich den Dynamikumfang von FP16 braucht, sehr selten sind, und erst in diesen sehr seltenen Fällen braucht man die FP16-Filterung. ;) :D

Coda
2005-11-21, 13:23:22
Valve speichert auf nVIDIA-Karten die Texturen im FP16-Format und nur als Fallback für ATi als Integer. Muss ich jetzt wirklich weiter ausholen?

deekey777
2005-11-21, 13:31:02
Valve speichert auf nVIDIA-Karten die Texturen im FP16-Format und nur als Fallback für ATi als Integer. Muss ich jetzt wirklich weiter ausholen?

Nein, mußt du nicht. ;)
Es ist einfach interessant, wie versucht wird zu erklären, daß keine FP-Formate zumindest zu diesem Zeitpunkt benutzt werden sollen.

aths
2005-11-21, 15:27:50
Nein, mußt du nicht. ;)
Es ist einfach interessant, wie versucht wird, daß keine FP-Formate zumindest zu diesem Zeitpunkt benutzt werden.Ja, weil es die ATI-HW nicht kann, nicht, weil es nicht sinnvoll wäre.

Wenn man zuerst liest, was der Gennadi zum HDR-Fähigkeiten der X1x00er Serie geschrieben hat, und dann auf eure Postings schaut, dann wieder das Interview liest, so ist zu jedem Einwand von euch eine Antwort/Erklärung zu finden. :biggrin:Im Rausreden sind die Leute gut.

Interessanterweise schreibt er, daß der Übergang zu FP16 Texturen mit achtfachem Speicherbedarf verbunden ist (im Vergleich zu komprimierten Texturen). Er schreibt auch, daß Fälle, wo man wirklich den Dynamikumfang von FP16 braucht, sehr selten sind, und erst in diesen sehr seltenen Fällen braucht man die FP16-Filterung. ;) :DFür FP16-Formate wird es auch bald Texturkomprimierung geben (natürlich ist das in den aktuellen Chips nicht treiberseitig nachrüstbar.) Ob man den Dynamikumfang von FP16 braucht oder nicht hängt davon ab, wie ambitioniert das Projekt ist. Für ein paar scheinbar HDR-mäßige Effekte braucht man nicht mal zwingend das Integer-Format mit 16 Bit.

zeckensack
2005-11-21, 15:36:12
Valve speichert auf nVIDIA-Karten die Texturen im FP16-Format und nur als Fallback für ATi als Integer. Muss ich jetzt wirklich weiter ausholen?Können NVIDIA-Chips große Integer-Formate (16 Bit pro Kanal) filtern? :|
Können ATI-Chips FP-Texturen filtern? :|

Wie sollte man es also angehen, wenn man auf Chips beider Hersteller gefilterte Texturen mit a)mehr als 8 Bit Präzision und b)mehr als [0;1] Dynamikumfang haben will?
Genau so wie Valve es gemacht hat ...

Coda
2005-11-21, 15:42:43
Ich sage doch gar nichts dagegen. Aber Integer ist der Fallback nicht FP16. Es kann also kaum Nachteile von FP16-Texturen geben ggü. Integer-Texture-Hacks die ähnlichen dynamischen Umfang haben.

Demirug
2005-11-21, 15:52:34
Können NVIDIA-Chips große Integer-Formate (16 Bit pro Kanal) filtern? :|

Ja eigentlich schon immer. Nur gab es früher nur 2 Kanalige 16 Bit Texturen.

aths
2005-11-21, 21:24:55
Nanu, NV-karten können FX16-Texturen filtern? Das ist mir neu. Wenn NV40+ auch 4-Kanal-FX16-Texturen filtern kann, wäre immerhin ein allgemein verwendbarer MDR-Codepath möglich.

Coda
2005-11-21, 21:26:43
FP16 dürfte aber nicht langsamer als FX16 sein.

Oder meinst du das ATi das auch kann? :|

Edit: Hm ja die ATis können das auch als Textur verwenden, aber auch filtern weiß ich nicht.

Banshee18
2005-11-21, 21:38:12
Wie filtert eigentlich der nV4x/G70 fp16-Content? Hängt das davon ab, was die Anwendung anfordert, oder kann er auch z.B. nur bilinear? Was wäre vom Speed her maximal sinnvoll?

Demirug
2005-11-21, 21:39:16
Nanu, NV-karten können FX16-Texturen filtern? Das ist mir neu. Wenn NV40+ auch 4-Kanal-FX16-Texturen filtern kann, wäre immerhin ein allgemein verwendbarer MDR-Codepath möglich.

Beim NV4X ist es ganz einfach. Alles ausser FP32 kann gefiltert werden.

Mögliche wäre es schon aber FX16 Formate muss man ja leider für s MDR immer im Pixelshader skalieren was ein MUL bzw ein MAD benötigt.

Coda
2005-11-21, 21:41:55
Wie filtert eigentlich der nV4x/G70 fp16-Content?Wie Demirug schon sagte, alles außer FP32 kann bis zu 16xAF gefiltert werden :)

Banshee18
2005-11-21, 22:05:20
Wie Demirug schon sagte, alles außer FP32 kann bis zu 16xAF gefiltert werden :)
Auch ausreichend schnell? Wie groß ist der Geschwindigkeitsverlust? Oder ist es sogar "for free"?
Wie filtern aktuelle Spiele? Wenn ich mir Screenshots von Serious Sam 2 auf dem R520 anschaue, sollte bilinear eigentlich für nahezu perfekte Qualität ausreichen, oder?

Coda
2005-11-21, 22:09:17
Auch ausreichend schnell? Wie groß ist der Geschwindigkeitsverlust? Oder ist es sogar "for free"?Schneller als irgend nen Integer-Hack. Wenn HDR gebraucht wird ist FP16 für Texturen auf jedenfall die beste Wahl, solang die Karte es kann.

Wie filtern aktuelle Spiele? Wenn ich mir Screenshots von Serious Sam 2 auf dem R520 anschaue, sollte bilinear eigentlich für nahezu perfekte Qualität ausreichen, oder?Sind wir jetzt bei der Voodoo 1 stehengeblieben oder wie?
Das reicht natürlich nicht für "perfekte Qualität", wenn du es für "richtige" Texturen verwenden willst.

aths
2005-11-21, 23:17:08
FP16 dürfte aber nicht langsamer als FX16 sein.

Oder meinst du das ATi das auch kann? :|Ob ATI was kann? Bei 16 Bit pro Kanal limitiert wahrscheinlich (nur) die Bandbreite.

Edit: Hm ja die ATis können das auch als Textur verwenden, aber auch filtern weiß ich nicht.Soweit ich weiß können Radeons ab R300 auch FX16-Texturen filtern.

aths
2005-11-21, 23:18:26
Wie filtert eigentlich der nV4x/G70 fp16-Content? Hängt das davon ab, was die Anwendung anfordert, oder kann er auch z.B. nur bilinear? Was wäre vom Speed her maximal sinnvoll?NV40+ kann FP16-Texturen auch anistrop filtern. Die Filterung dauert im Vergleich zu FX8-Texturen nur doppelt so lange – was sehr günstig ist.

aths
2005-11-21, 23:18:54
Beim NV4X ist es ganz einfach. Alles ausser FP32 kann gefiltert werden.

Mögliche wäre es schon aber FX16 Formate muss man ja leider für s MDR immer im Pixelshader skalieren was ein MUL bzw ein MAD benötigt.Das ist ja nur ein Takt pro Textur. Mir macht die eingeschränkte Dynamik mehr Sorgen.

Banshee18
2005-11-21, 23:55:50
Sind wir jetzt bei der Voodoo 1 stehengeblieben oder wie?
Nein, natürlich nicht. :biggrin:
Das reicht natürlich nicht für "perfekte Qualität", wenn du es für "richtige" Texturen verwenden willst.
HDRR wird ja bisher größtenteils nur für Bloom-Effekte benutz, da müsste es doch reichen, bzw. der Unterschied sollte nur bei genauem Hinsehen negativ auffallen.
Hier gab es mal vor kurzem Screenshots von SS2 auf R520, wo die fehlende Filterung deutlich zu sehen war. Dort würde, glaube ich, bilinear reichen*. Leider kann ich sie nicht mehr finden.

Edit: * dass es nicht optimal ist, ist klar, aber eben ausreichend, wenn man nicht genau hinschaut und ein Auge zudrückt. Gutheißen will ich das Fehlen natürlich nicht.

dargo
2005-11-22, 00:01:54
Hier gab es mal vor kurzem Screenshots von SS2 auf R520, wo die fehlende Filterung deutlich zu sehen war. Dort würde, glaube ich, bilinear reichen*. Leider kann ich sie nicht mehr finden.

Meinst du meinen Thread ?
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=260665

Coda
2005-11-22, 00:03:05
Nein, natürlich nicht. :biggrin:

HDRR wird ja bisher größtenteils nur für Bloom-Effekte benutz, da müsste es doch reichen, bzw. der Unterschied sollte nur bei genauem Hinsehen negativ auffallen.
Hier gab es mal vor kurzem Screenshots von SS2 auf R520, wo die fehlende Filterung deutlich zu sehen war. Dort würde, glaube ich, bilinear reichen*. Leider kann ich sie nicht mehr finden.

Edit: * dass es nicht optimal ist, ist klar, aber eben ausreichend, wenn man nicht genau hinschaut und ein Auge zudrückt. Gutheißen will ich das Fehlen natürlich nicht.Du kannst doch dieses FP16-Overlay nicht mit einer richtigen Textur vergleichen. Valve hat extra für ATi ein Integer-Format reingehackt, weil FP16-Texturen einfach unbrauchbar waren.

Banshee18
2005-11-22, 00:24:40
Meinst du meinen Thread ?
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=260665
Genau.
Du kannst doch dieses FP16-Overlay nicht mit einer richtigen Textur vergleichen. Valve hat extra für ATi ein Integer-Format reingehackt, weil FP16-Texturen einfach unbrauchbar waren.
Nein, aber bekommt man denn irgendwo schon fp16-Texturen zu sehen?

Warum wirst du bei mir immer ausgeloggt angezeigt, obwohl man afaik sogar eine halbe Stunde nach dem Ausloggen als eigeloggt angezeigt wid?

Coda
2005-11-22, 00:30:44
Nein, aber bekommt man denn irgendwo schon fp16-Texturen zu sehen?In Lost Coast auf nVIDIA-Hardware.

Mr. Lolman
2005-11-22, 00:32:05
In Lost Coast auf nVIDIA-Hardware.

Imo nicht. Oder wieso funktioniert sonst HDR+AA?

deekey777
2005-11-22, 00:33:18
Imo nicht. Oder wieso funktioniert sonst HDR+AA?

Geht es hier nicht um FP16 Texturen? ;)

Hier die Übersicht: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3509064&postcount=308

€:
Ihr habt doch beide mindestens eine NV40. Funktioniert dies hier: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3697597&postcount=278

aths
2005-11-22, 13:02:35
Imo nicht. Oder wieso funktioniert sonst HDR+AA?FP16-Texturen zu filtern hält den Chip nicht davon ab, MSAA zu machen. Auf ein FP16-Target kann aber kein MSAA ausgeführt werden.

Neomi
2005-11-22, 13:42:19
Nein, aber bekommt man denn irgendwo schon fp16-Texturen zu sehen?

Das ist allerdings der völlig falsche Ansatz. Wenn man auf die Unterstützung von bestimmten Features verzichtet, weil sie noch kaum genutzt werden, dann sollte man bedenken, daß sie vielleicht nur deshalb kaum genutzt werden, weil sie nicht wirklich unterstützt werden. Ein Teufelskreis.

Der R580 muß schon FP-Filterung und nutzbare Texturformate für Vertextexturing bieten, um mich zu überzeugen.

Xmas
2005-11-22, 14:34:23
Ja eigentlich schon immer. Nur gab es früher nur 2 Kanalige 16 Bit Texturen.
Früher? G70 kann doch immer noch nicht mit 4-Kanal FX16-Texturen umgehen.

Demirug
2005-11-22, 14:42:50
Früher? G70 kann doch immer noch nicht mit 4-Kanal FX16-Texturen umgehen.

Aus den G70 Caps:


Texture Formats
D3DFMT_A16B16G16R16
Yes
Yes
No
No
No
No
Yes
No
No
No

Xmas
2005-11-22, 14:47:51
Hmm... welche Formate unterstützt G70 dann nicht? Ich kann mich jedenfalls erinnern dass in der letzten Texturformat-Liste von NVidia die ich gesehen habe ein paar Formate fehlten die ATI schon länger unterstützt.

Demirug
2005-11-22, 16:45:02
D3DFMT_A2B10G10R10
D3DFMT_A2R10G10B10
D3DFMT_A2W10V10U10
D3DFMT_UYVY
D3DFMT_YUY2
D3DFMT_Q16W16V16U16
D3DFMT_R16F

Wenn ich nichts übersehen habe

Coda
2005-11-22, 16:52:31
Imo nicht. Oder wieso funktioniert sonst HDR+AA?Framebuffer != Texturen.

nVIDIA-HW verwendet in Lost-Coast FP16-Texturen, da bin ich mir absolut sicher. Für ATi-HW gibt es einen Fallback auf 4.12 fixed-point (das natürlich eine viel geringere Dynamik hat, aber in diesem Fall ausreichend ist).

Vermutlich haben deshalb der NV4x/G70 auch leicht bessere Performance als gleichwertige ATi-Karten, weil Texture-Reads und Shader-Arithmetik wegfallen.

Banshee18
2005-11-22, 17:10:26
Das ist allerdings der völlig falsche Ansatz. Wenn man auf die Unterstützung von bestimmten Features verzichtet, weil sie noch kaum genutzt werden, dann sollte man bedenken, daß sie vielleicht nur deshalb kaum genutzt werden, weil sie nicht wirklich unterstützt werden. Ein Teufelskreis.

Der R580 muß schon FP-Filterung und nutzbare Texturformate für Vertextexturing bieten, um mich zu überzeugen.
Wie schon gesagt, finde ich das Fehlen der fp16-Filterung eben aus diesem Grund auch nicht gut. Da ich aber sowieso nix daran ändern kann und ich Spieler und kein Programmierer bin, sehe ich das ein wenig anders als du.

nVIDIA-HW verwendet in Lost-Coast FP16-Texturen, da bin ich mir absolut sicher. Für ATi-HW gibt es einen Fallback auf 4.12 fixed-point (das natürlich eine viel geringere Dynamik hat, aber in diesem Fall ausreichend ist).

Vermutlich haben deshalb der NV4x/G70 auch leicht bessere Performance als gleichwertige ATi-Karten, weil Texture-Reads und Shader-Arithmetik wegfallen.
Trotz der geringeren Dynamik langsamer? Könnte man das nicht auf nV-Hardware mit geringerer Dynamik und dafür schneller machen?

aths
2005-11-22, 19:42:58
Trotz der geringeren Dynamik langsamer? Könnte man das nicht auf nV-Hardware mit geringerer Dynamik und dafür schneller machen?So einfach ist das nicht. Einige Leute glaubten ja, dass die Radeon schneller sei, weil sie nur mit FP24 rechnet, und der NV30 ja mit FP32. Aber das hat damit nichts zu tun. Der NV30 rechnet mit FP16 auch nicht schneller, nur fallen andere Flaschenhalse weg wenn man dort für Rechnungen ein FP16-Format nimmt.

Zu den Texturen: 16 Bit sind 16 Bit – wenn die Bandbreite limitiert, limitiert die Bandbreite, egal wofür die 16 Bit genutzt werden.

MikBach
2005-11-22, 20:48:24
Trotz der geringeren Dynamik langsamer? Könnte man das nicht auf nV-Hardware mit geringerer Dynamik und dafür schneller machen?
Natürlich ist ATI langsamer, wenn NV dedizierte Einheiten verwendet, ATI es aber über die Pixelshader emulieren muss.
Je nachdem welche Pixelshadereinheiten ausgelastet werden, kostet das dementsprechend Leistung, da durch die Emulation jene woanders fehlt...

Zu den Texturen hat sich aths ja schon geäussert.

Coda
2005-11-22, 21:35:12
Emulation würde ja gleiche Funktionalität bedeuten. Es wird aber ein ganz anderes Format verwendet dass zusätzliche Skalierungen im Pixelshader vorraussetzt.

Die Dynamik von diesem 4.12 Format ist übrigens nur [0,16] also ziemlich wenig.

Radeonator
2005-11-22, 21:43:27
Wieso pinkeln sich die GPU Hersteler derzeit nur selber immer wieder ans Bein...glauben die, das die Reviewer alle blind und dumm sind? Ich meine, all diese focierten "Must Have" Features sind doch beiden Seiten bekannt, warum kommt nicht endlich ein stück GPU das diese auch bietet?

Naja, vielleicht im WGF Zeitalter, aber ich glaub nicht wirklich daran... :wink:

MikBach
2005-11-22, 21:44:59
Emulation würde ja gleiche Funktionalität bedeuten.
Definitionssache.
Man kann mit unterschiedlichen Shadern zum gleichen Ergebnis (BQ) kommen...

Es wird aber ein ganz anderes Format verwendet dass zusätzliche Skalierungen im Pixelshader vorraussetzt.
Steht das jetzt im Widerspruch zu meiner Aussage?

Die Dynamik von diesem 4.12 Format ist übrigens nur [0,16] also ziemlich wenig.
Hauptsache es reicht. :biggrin:

Coda
2005-11-22, 21:54:04
Steht das jetzt im Widerspruch zu meiner Aussage? Ja, weil das keine Emulation mehr ist sondern einfach eine andere Methode um in diesem Fall ein gleichwertiges Ergebniss zu erzielen.

Wikipedia über Emulation:
"Das nachbildende System erhält die gleichen Daten, führt die gleichen Programme aus und erzielt die gleichen Ergebnisse wie das originale System."

Davon ist nichtmal ein Vorraussetzung erfüllt.

Hauptsache es reicht. Richtig. In diesem Fall reicht es, allerdings unter erheblichem Aufwand, da alle Shader geändert werden mussten und der dynamische Umfang des Ausgangsmaterials künstlich begrenzt wurde.

MikBach
2005-11-22, 22:11:38
Ja, weil das keine Emulation mehr ist sondern einfach eine andere Methode um in diesem Fall ein gleichwertiges Ergebniss zu erzielen.

Wikipedia über Emulation:
"Das nachbildende System erhält die gleichen Daten, führt die gleichen Programme aus und erzielt die gleichen Ergebnisse wie das originale System."

Davon ist nichtmal ein Vorraussetzung erfüllt.
Ok, hast gewonnen.
Ich habe den Begriff Emulation ein wenig "weiter" gedeutet. :wink:

Richtig. In diesem Fall reicht es, allerdings unter erheblichem Aufwand, da alle Shader geändert werden mussten.
ALLE Shader?
Bist du dir da sicher?
Wäre natürlich schon ziemlich heftig. Kommt noch darauf an, wie aufwändig diese Änderung war.
Für die Entwickler (und indirekt für den Spieler) echt schade, dass ATI kein FP-Filtern kann.
Das verlangsamt die Enticklung besserer Effekte und macht die Programmierung ungleich umfangreicher.

jojo4u
2005-11-22, 22:49:18
Ich verfolge die Diskussion lose, so verzeiht mir wenn der Link schon bekannt ist.
Digit-Life.com haben heute (22.11) ein Interview mit Guennadi Riguer von ATI auf Englisch online gestellt. Es geht darum was die X1000 Serie unterstützt und warum.
http://www.digit-life.com/articles2/video/r520-part6.html

Coda
2005-11-22, 23:46:59
ALLE Shader?
Bist du dir da sicher?Zumindest alle die HDR-Texturen verwenden, dürften also schon einige sein. Allerdings denke ich dass Valve das automatisiert hat, die HL²-Engine generiert das Zeug eh automatisch iirc.

Für die Entwickler (und indirekt für den Spieler) echt schade, dass ATI kein FP-Filtern kann.
Das verlangsamt die Enticklung besserer Effekte und macht die Programmierung ungleich umfangreicher.Das sind ja ganz neue Töne von dir. R520 ist halt eine Notlösung, dafür ist das Featureset ganz anständig ;)

Mit DX10 werden solche Feature-Blockaden zum Glück der Vergangenheit angehören.

MikBach
2005-11-23, 15:00:11
Zumindest alle die HDR-Texturen verwenden, dürften also schon einige sein. Allerdings denke ich dass Valve das automatisiert hat, die HL²-Engine generiert das Zeug eh automatisch iirc.
Wenn es automatisiert ist, ist es halb so schlimm. Valve ist in Sache Shader imo sehr gut, was aber mit kleineren Herstellern, die nicht so fit sind?
Deswegen wäre ein vergleichbares (oder gar gleiches) Featureset sehr zu begrüssen.
Man hat eh manchmal das Gefühl, dass viele Spieleprogrammierer nicht wirklich fit sind.
Demirug hat sich ja schon oft darüber ausgelasen, selbst John Carmack blieb nicht unverschont.
Das geht ja schon bei so "Kleinigkeiten" los, wie Abfragen der Device-ID, anstatt die Caps abzufragen...

Das sind ja ganz neue Töne von dir. R520 ist halt eine Notlösung, dafür ist das Featureset ganz anständig ;)
Wie?
Der R420 war ja schon eine Notlösung. Kann doch nicht sein, dass ATI nur Notlösungen produziert.

Mit DX10 werden solche Feature-Blockaden zum Glück der Vergangenheit angehören.
Da bin ich mal gespannt...

Coda
2005-11-23, 15:19:39
Klar ist R520 eine Notlösung, normal hätten wir schon zu R400-Zeiten einen Unified-Shader sehen sollen.

Da bin ich mal gespannt...Brauchst du nicht. Was nicht alle Features unterstützt unterstützt auch kein DX10. Es gibt nur alles oder nichts.

Demirug
2005-11-23, 15:43:17
Brauchst du nicht. Was nicht alle Features unterstützt unterstützt auch kein DX10. Es gibt nur alles oder nichts.

D3D10 bitte. Von einem neuen DX spricht bei MS niemand ausser im Zusammenhang mit DXGI aber das gehört irgendwie zum Visata SDK.

MikBach
2005-11-23, 15:46:40
Klar ist R520 eine Notlösung, normal hätten wir schon zu R400-Zeiten einen Unified-Shader sehen sollen.
OK, hast es anders gemeint als ich dachte. Ich dachte du meinst im Vergleich zum Konkurrenzprodukt.

Brauchst du nicht. Was nicht alle Features unterstützt unterstützt auch kein DX10. Es gibt nur alles oder nichts.
Das ist mir schon klar.
Ich bleibe trotzdem skeptisch, dass der G80 oder R600 voll WGF2-kompatibel sein werden.

Coda
2005-11-23, 15:49:42
OK, hast es anders gemeint als ich dachte. Ich dachte du meinst im Vergleich zum Konkurrenzprodukt.Notlösung ist Notlösung, das sieht man R520 an einigen Stellen an. Man erreicht damit aber trotzdem konkurenzfähige Performance, braucht aber anscheinend jede Menge Transistoren dafür.

Ich bleibe trotzdem skeptisch, dass der G80 oder R600 voll WGF2-kompatibel sein werden.Dann wären sie eben nur DX9 kompatibel und könnten gar kein D3D10. Da gibts keine Ausnahmen.

MikBach
2005-11-23, 15:52:22
Dann wären sie eben nur DX9 kompatibel und könnten gar kein D3D10.
Ist klar, deswegen habe ich ja auch WGF2 geschrieben, D3D10 ist doch das Gleiche.

edit:

Notlösung ist Notlösung, das sieht man R520 an einigen Stellen an. Man erreicht damit aber trotzdem konkurenzfähige Performance, braucht aber anscheinend jede Menge Transistoren dafür.
Wer weiss wo die ganzen Transis geblieben sind. Das kann sicherlich niemand ausser ATI hier sagen.
Und die Performance kommt eher durch den Takt, denn bei mehr Pipes hätte man deutlich mehr Performance rausholen können.

Coda
2005-11-23, 15:54:45
ATi oder nVIDIA werden eher an der Performance sparen als an D3D10. Das wäre ja der Super-GAU des Marketing wenn der Konkurent das kann und man selber nicht.

D3D10 bringt nicht nur neue Shadermodelle sondern auch andere Änderungen in der Pipeline die sich durch DX9 gar nicht ausnützen lassen und OpenGL interessiert keinen. Also bleibt ihnen gar nichts anderes übrig als D3D10 voll zu unterstützen.

MikBach
2005-11-23, 16:01:15
ATi oder nVIDIA werden eher an der Performance sparen als an D3D10. Das wäre ja der Super-GAU des Marketing wenn der Konkurent das kann und man selber nicht.

D3D10 bringt nicht nur neue Shadermodelle sondern auch andere Änderungen in der Pipeline die sich durch DX9 gar nicht ausnützen lassen und OpenGL interessiert keinen. Also bleibt ihnen gar nichts anderes übrig als D3D10 voll zu unterstützen.
Genau das Gleiche habe ich gedacht oder besser gesagt auch gemeint. Ich habe das schon in irgendeinem Thread erwähnt, dass es sein kann, dass der R580 schneller als der R600 sein wird.
Das wäre aber auch der Super-GAU. :wink:

Coda
2005-11-23, 16:34:22
Glaube ich kaum. R520 soll vom Design ziemlich ineffizient sein, weil es im Prinzip ein aufgebohrter R420 ist, der nicht auf SM3.0 ausgelegt war. Anderst kann man sich 320 Mio. Transistoren für 4 Quads auch kaum erklären.

Banshee18
2005-11-23, 17:02:22
Sind nV40 und G70 keine Notlösungen? Was hätte nV gemacht, wenn Vista und damit WGF früher erschienen wären? Hätten die dann dumm aus der Wäsche geschaut? Oder wusste nV etwa mehr?

MikBach
2005-11-23, 17:06:36
Sind nV40 und G70 keine Notlösungen? Was hätte nV gemacht, wenn Vista und damit WGF früher erschienen wären? Hätten die dann dumm aus der Wäsche geschaut? Oder wusste nV etwa mehr?
Eine Notlösung muss nicht unbedingt schlecht sein. Hat Coda ja schon gesagt, dass der R520 konkurrenzfähig ist. In manchen Bereichen sogar überlegen.

Coda
2005-11-23, 17:07:20
Sind nV40 und G70 keine Notlösungen?G70 ist ein Lückenfüller, keine Notlösung. NV40 war völlig im Plan.

DrumDub
2005-11-23, 17:07:31
Sind nV40 und G70 keine Notlösungen? Was hätte nV gemacht, wenn Vista und damit WGF früher erschienen wären? Hätten die dann dumm aus der Wäsche geschaut? Oder wusste nV etwa mehr? nv wusste nicht mehr, sondern hatte mit dem nv3x eine vernünftige grundlage für sm 3.0.

MikBach
2005-11-23, 17:11:49
Glaube ich kaum. R520 soll vom Design ziemlich ineffizient sein, weil es im Prinzip ein aufgebohrter R420 ist,
Und der R420 ist ein aufgebohrter R300. :rolleyes:
Warum höre ich immer nur, dass bei ATI die GPUs aufgebohrt werden, bei NV aber immer neue kommen. :confused:
Der G70 ist in dem Sinne auch ein aufgebohrter NV40...

der nicht auf SM3.0 ausgelegt war. Anderst kann man sich 320 Mio. Transistoren für 4 Quads auch kaum erklären.
Wer weiss, wo die Transistoren eingesetzt wurden...? :wink:

Coda
2005-11-23, 17:14:40
Warum höre ich immer nur, dass bei ATI die GPUs aufgebohrt werden, bei NV aber immer neue kommen. NV4x hat wesentlich weniger Ähnlichkeiten mit NV3x als R4xx mit R3xx. Der Unterschied ist das nVIDIA kein Design verworfen hat, ATi aber gleich 2 (R400 und R500).

G70 ist natürlich ein aufgebohrter NV40, das ist sogar ziemlich eindeutig. 2 Quads mehr und leichte Änderungen an den PS-ALUs + Detailtuning.

Wer weiss, wo die Transistoren eingesetzt wurden...? Riesige Programmspeicher z.B. nVIDIA ließt die Shader seit jeher aus dem VRAM, ATi nicht. Bei 4096 Instructions ist das eine Menge.

DrumDub
2005-11-23, 17:18:16
Warum höre ich immer nur, dass bei ATI die GPUs aufgebohrt werden, bei NV aber immer neue kommen. :confused: das frage ich mich auch. letztlich war der große bruch bei nv der nv3x, obwohl der auch noch die regcombiner und das msaa vom nv2x geerbt hat (und noch anderes). ati hatte mit dem r400 eine innovatives design, aber eben keins, welches mit dem nv4x mithalten konnte, sodass man zumaufbohren des r300-desigsn gegriffen hat.

MikBach
2005-11-23, 17:22:42
Der Unterschied ist das nVIDIA kein Design verworfen hat, ATi aber gleich 2 (R400 und R500).
ATI war halt zu ambitioniert...
Oder hat einfach die Performance nicht in den Griff bekommen.

Riesige Programmspeicher z.B. nVIDIA ließt die Shader seit jeher aus dem VRAM, ATi nicht. Bei 4096 Instructions ist das eine Menge.
Klingt einleuchtend.

DrumDub
2005-11-23, 17:23:25
NV4x hat wesentlich weniger Ähnlichkeiten mit NV3x als R4xx mit R3xx. das stimmt allerdings. wobei man dazu sagen muss, dass nv eben auch eine durststrecke mit dem nv3x hatte, die ati jetzt hat. mit g80 und r600 werden die karten neu gemischt, wobei ich davon ausgehe, dass beide wegen der anforderungen von von wgf 2.0 gar nicht soo unterschieliche ansätze verfolgen können. letztlich ist aber die (technische) philosophie der beiden firmen schon unterschiedlich, was die sache eben auch so spannend macht.

Coda
2005-11-23, 17:24:00
R420->R520 war auf jedenfall ein deutlich größerer Schritt als R300->R420, aber trotzdem war NV30->NV40 vermutlich größer. Der Texturfilter ist ein komplett anderer, die ALUs wurden auf FP-Leistung + 3/1, 2/2 Splitting + Branching ausgelegt und noch dazu ist NV40 was die Einheitenanzahl angeht sehr flexibel, sogar die ROPs sind entkoppelt.

nVIDIA hat radikale Einschnitte gemacht (mussten sie nach NV30 auch), bei R520 sieht es imho (!) so aus ist SM3.0 an R300 angeflanscht worden.

MikBach
2005-11-23, 17:25:03
letztlich ist aber die (technische) philosophie der beiden firmen schon unterschiedlich, was die sache eben auch so spannend macht.
:confused:
Was soll daran spannend sein?
Verlangsamt nur die Entwicklung...

Coda
2005-11-23, 17:27:31
ATI war halt zu ambitioniert...
Oder hat einfach die Performance nicht in den Griff bekommen.Ja waren sie auch, aber dennoch verzeih ich ihnen das R420-Featureset nicht :D

MikBach
2005-11-23, 17:34:07
Ja waren sie auch, aber dennoch verzeih ich ihnen das R420-Featureset nicht :D
Ich schon, weil ich bei meiner 6800GT nicht wirklich viel von SM3 hatte. :D

DrumDub
2005-11-23, 17:42:13
R420->R520 war auf jedenfall ein deutlich größerer Schritt als R300->R420, aber trotzdem war NV30->NV40 vermutlich größer. ja. ich glaube aber auch, dass der schritt vom nv25 auf nv30 der größere war, als der von r200 auf r300. (zumindest was ps und vs angeht.)

Der Texturfilter ist ein komplett anderer, die ALUs wurden auf FP-Leistung + 3/1, 2/2 Splitting + Branching ausgelegt und noch dazu ist NV40 was die Einheitenanzahl angeht sehr flexibel, sogar die ROPs sind entkoppelt. jupp. deshalb ist nv auch nicht so ein mist passiert, wie ati bei der x700 aka rv410.

nVIDIA hat radikale Einschnitte gemacht (mussten sie nach NV30 auch), bei R520 sieht es imho (!) so aus ist SM3.0 an R300 angeflanscht worden. mhh... das find ich etwas pauschal gesagt, da ja doch nen paar mehr änderungen drin. recht geb ich dir da bezüglich der vs.

Coda
2005-11-23, 21:18:52
Ich schon, weil ich bei meiner 6800GT nicht wirklich viel von SM3 hatte. :DHätte ATi SM3 gehabt hättest du davon was gehabt. Deshalb nö, ich denke nicht dass ich das gut finden kann.

Demirug
2005-11-23, 23:38:58
Riesige Programmspeicher z.B. nVIDIA ließt die Shader seit jeher aus dem VRAM, ATi nicht. Bei 4096 Instructions ist das eine Menge.

Der Programmspeicher bei nVidia ist kleiner als bei ATI. IIRC hat der Programmspeicher für um die 18 Anweisungen Platz. Die 4096 sind BTW nur eine Beregzung im Treiber. Der Optimzier ist nur für diese Länge ausgelegt. Der Chip selbst kann viel mehr.

Demirug
2005-11-23, 23:41:39
das stimmt allerdings. wobei man dazu sagen muss, dass nv eben auch eine durststrecke mit dem nv3x hatte, die ati jetzt hat. mit g80 und r600 werden die karten neu gemischt, wobei ich davon ausgehe, dass beide wegen der anforderungen von von wgf 2.0 gar nicht soo unterschieliche ansätze verfolgen können. letztlich ist aber die (technische) philosophie der beiden firmen schon unterschiedlich, was die sache eben auch so spannend macht.

D3D10 lässt genügend Spielraum für Unterschiedliche konzepte was die Umsetzung der 300 Seiten angeht.

Coda
2005-11-24, 00:16:23
Der Programmspeicher bei nVidia ist kleiner als bei ATI. IIRC hat der Programmspeicher für um die 18 Anweisungen Platz. Die 4096 sind BTW nur eine Beregzung im Treiber. Der Optimzier ist nur für diese Länge ausgelegt. Der Chip selbst kann viel mehr.Was war jetzt der Widerspruch? Ich hab doch gesagt, dass ATi mehr Speicher braucht. Oder war das nur eine Ergänzung?

Kann ATi eigentlich auch Programmcode aus dem VRAM nachladen?

Demirug
2005-11-24, 06:20:56
Was war jetzt der Widerspruch? Ich hab doch gesagt, dass ATi mehr Speicher braucht. Oder war das nur eine Ergänzung?

Kann ATi eigentlich auch Programmcode aus dem VRAM nachladen?

ATI hat aber nur 512 Anweisungen im PS daswegen dachte ich du meinst nVidia. Ob ATI die PS-Programme aus dem VRAM holt weiß ich nicht. Ich galube allerdings eher nicht.

Gast
2006-01-25, 22:12:23
So, R580 ist jetzt draußen und wie zu erwarten, gibt es immer noch kein FP-Filtering von ATI.

ShadowXX
2006-01-25, 23:04:11
So, R580 ist jetzt draußen und wie zu erwarten, gibt es immer noch kein FP-Filtering von ATI.

Tröste dich damit, das nV im G71, wie beim G70 schon, wohl auch kein HDR+MSAA anbieten wird....

deekey777
2006-09-06, 08:15:52
FP16-Texturen zu filtern hält den Chip nicht davon ab, MSAA zu machen. Auf ein FP16-Target kann aber kein MSAA ausgeführt werden.
Verständnisproblem: Warum wird im Fall der HDRR-Imlementierung Nr. 4 der Source-Engine kein FP16-Buffer benutzt? So lange kein FP16-Alphablending stattfindet, können GFs auch MSAA auf FP16-RT ausführen, wenn mich nicht alles täuscht.

Xmas
2006-09-06, 11:32:18
Da täuscht dich alles.

deekey777
2006-09-06, 14:15:13
Da täuscht dich alles.
Ich habe das schon so oft gelesen, vielleicht finde ich die Quelle.
Wenn es doch möglich ist, ist meine Überlegung überhaupt haltbar oder absoluter Nonsens?

€: Jetzt richtig gelesen: "Da täuscht dich alles" - also liege mit beidem daneben.

Xmas
2006-09-07, 01:38:15
€: Jetzt richtig gelesen: "Da täuscht dich alles" - also liege mit beidem daneben.
Beides? Das war doch nur eine Aussage.