Speku:Stromverbrauch von Nv31-Karten

[Tiamat]

Hi ,
da ich keine anderen Angaben habe beziehe ich mich auch die von Tecchannel.
Eine G4 ti4600 u. Radeon 9700 verbrauchen 24W im Desktopbetrieb.
Im 3d Modus erhöht sich der Wert auf 40W bei der Geforce 4600 und 54W bei der Radeon9700Pro.
Gibt es zufällig eine Angabe zur der G4ti4400 u. 4200 und den Radeon 9500Pro und 9700 non Pro Modellen ?
Der Nv31 wird ja bekanntlich in 0.13mikron gefertigt und Gerüchten zufolge wird es 2 Versionen geben...
Eine l-Variante mit 275/275 und eine h-Variante mit 350/350...
Kann man die Werte schon abschätzen anhand von 0.13mikron und den Coretakt und Ramantaktangabe?
Ich glaube der Schritt von 0.18 mikron auf 0.13mikron brachte eine 20%ige Stromersparnis ein wenn ich mich nicht irre.
Dann dürfte der Schritt von 0.15 auf 0.13mikron ca. 10% ausmachen woduch die L-Variante auf die 30W Grenze kommen dürfte.Die H-Variante müßte demnach auf ca. 38 W kommen ,oder?
Da für mich bis auf weiteres alle Modelle flachfallen die einen externen Stromanschluss benötigen finde ich das Thema interessant.
Was meint ihr ?
Gruß
Tiamat

[Quasar]

Falls die kleinen FXer auch im Design und nicht nur im Takt abgespeckt werden sollten, denke ich, dass die Chance auf eine Version ohne Zusatzstromversorgung recht gut ist.
Besonders für den Mobilsektor muss das ja schon eingeplant sein, gelle? ;)

edit:
Wenn man einfach mal simpel (sicher zuu simpel) den Takt runterrechnet, käme man für den nV30 bei 350MHz noch auf 52,5W (ausgehend von 75W bei 500MHz). Dazu noch etwas niedrigere vCore, die Hälfte der Pipelines und weniger/niedriger taktendes RAM, und schon ist man wieder unterhalb der magischen 40W-Grenze. Ob das jedoch umgesetzt wird, steht in den Sternen, ATi hat ihrer R9500 ja auch noch den Floppystecker gelassen, obwohl der rein von der absoluten Leistungsaufnahme nicht nötig gewesen wäre.

[Hui!]

Ein Vergleich Radeon9500 <-> NV31 ist auch reichlich unfair, da letztere ja ein Speziell auf den Low/Mid-End Bereich abgestimmter Chip ist.
Um einfach mal ins blaue zu tippen würde ich von 30W im 3D Betrieb ausgehen(TI4200 ca. 35W afaik) und von um die 10W in 2D (je nach verwendetem Takt).

[ow]

Originally posted by Hui!
Ein Vergleich Radeon9500 <-> NV31 ist auch reichlich unfair, da letztere ja ein Speziell auf den Low/Mid-End Bereich abgestimmter Chip ist.


??
Ich seh da nix unfaires dabei. Beide arbeiten mit 4 pipes und haben ein 128Bit DDR RAM-Interface.
Die inaktiven Transistoren der 9500 verbrauchen ja auch keinen Strom, beim NV31 gibt´s diese Transis erst gar nicht.

[Tiamat]

Originally posted by Hui!
Ein Vergleich Radeon9500 <-> NV31 ist auch reichlich unfair, da letztere ja ein Speziell auf den Low/Mid-End Bereich abgestimmter Chip ist.
Um einfach mal ins blaue zu tippen würde ich von 30W im 3D Betrieb ausgehen(TI4200 ca. 35W afaik) und von um die 10W in 2D (je nach verwendetem Takt).

Stimmt wenn man vom Ti4200 Takt ausgeht müßte der Stromverbrauch mit 0.13mikron unter der 30er Grenze liegen (bei der 275/275er).
Damit könnten Karten mit Passivkühlung drin sein..freu mich schon drauf...

[Hui!]

Originally posted by ow


??
Ich seh da nix unfaires dabei. Beide arbeiten mit 4 pipes und haben ein 128Bit DDR RAM-Interface.
Die inaktiven Transistoren der 9500 verbrauchen ja auch keinen Strom, beim NV31 gibt´s diese Transis erst gar nicht.
Unfair deswegen weil man ja davon ausgehen kann das erhebliche Entwicklungsarbeit in den NV31 gesteckt wurde, während es sich bei der R9500 ja eher um Verschnitt handelt.
nVidia macht sehr konsequente, effektive Low-Cost Lösungen(NV18), ich traue ihnen einen mehr als guten Wurf mit dem NV31 zu, da werden sie sich nicht lumpen lassen.
Worauf wollte ich überhaupt hinaus? Genau, ich spekuliere auf ein sehr potentes Performance/Verlustleistungsverhältnis zu Gunsten des NV31 bei dem die 0,13µ Technologie das erste Mal zeigen kann was in ihr steckt.

[askibo]

Originally posted by Hui!
Worauf wollte ich überhaupt hinaus? Genau, ich spekuliere auf ein sehr potentes Performance/Verlustleistungsverhältnis zu Gunsten des NV31 bei dem die 0,13µ Technologie das erste Mal zeigen kann was in ihr steckt.

Der NV31 tritt gegen den RV350 an. Beide in 0,13µ.
Bis der NV31 auf den Markt kommt ist die Produktion der 9500er Karten wahrscheinlich schon eingestellt da sie einfach zu teuer sind für den Budgetbereich.

[Axel]

Originally posted by Hui!

nVidia macht sehr konsequente, effektive Low-Cost Lösungen(NV18), ich traue ihnen einen mehr als guten Wurf mit dem NV31 zu, da werden sie sich nicht lumpen lassen.


Naja, die Lowcost-Karten die bislang erschienen sind waren allesamt für die Tonne. Ich meine damit die MX-Versionen. Die 4200 als erste brauchbare Grafikkarte war schon wieder teuer.
Ich hoffe, daß die neue Generation preiswert und leistungsfähig ist. Obwohl ich nach der 5800 meine Zweifel habe.

[LovesuckZ]

Originally posted by Axel
Naja, die Lowcost-Karten die bislang erschienen sind waren allesamt für die Tonne. Ich meine damit die MX-Versionen. Die 4200 als erste brauchbare Grafikkarte war schon wieder teuer.

Die MX war sehr erfolgreich, da guenstig und schnell.
Die TI200 war sehr erfolgreich, da guenstig und schnell.
Die Ti4200 war sehr erfolgreich, da guenstig und schnell.
Einzig allein die GF4MX Reihe passt nicht so richtig in die Reihe.

[Axel]

Originally posted by LovesuckZ


Die MX war sehr erfolgreich, da guenstig und schnell.
Die TI200 war sehr erfolgreich, da guenstig und schnell.
Die Ti4200 war sehr erfolgreich, da guenstig und schnell.
Einzig allein die GF4MX Reihe passt nicht so richtig in die Reihe.

Die MX hatte die mieseste Bildqualität aller modernen Grafikkarten. Die anderen zwei sind für mich persönlich bei Vorstellung der Karte schon wieder zu teuer gewesen.
Erfolgreich waren wahrscheinlich alle, brauchbar nur die TI200 und 4200, aber nicht wirklich lowcost (Ti200 vielleicht).

[AlfredENeumann]

Originally posted by Hui!

Unfair deswegen weil man ja davon ausgehen kann das erhebliche Entwicklungsarbeit in den NV31 gesteckt wurde, während es sich bei der R9500 ja eher um Verschnitt handelt.
nVidia macht sehr konsequente, effektive Low-Cost Lösungen(NV18), ich traue ihnen einen mehr als guten Wurf mit dem NV31 zu, da werden sie sich nicht lumpen lassen.
Worauf wollte ich überhaupt hinaus? Genau, ich spekuliere auf ein sehr potentes Performance/Verlustleistungsverhältnis zu Gunsten des NV31 bei dem die 0,13µ Technologie das erste Mal zeigen kann was in ihr steckt.

Ist doch eh wurscht. Der 9500non Pro war doch eh nur ein vorrübergehndes Produkt bis der RV350 fertig ist.

[LovesuckZ]

Originally posted by Axel
Erfolgreich waren wahrscheinlich alle, brauchbar nur die TI200 und 4200, aber nicht wirklich lowcost (Ti200 vielleicht).

Du willst im richtigen Low Cost Sektor Geschwindigkeit verlangen? Dann wird dich jeder Hersteller enttaeuschen.

[stromschlag]

das würd ich auch mal so sehen.und die ehemaligen highendkarten werden wohl nie als lowcostkarten zu haben sein.sie werden immer vom markt genommen bevor die preise zu stark sinken.ne gf2ti bekommt man ja meines wissens nach auch nicht mehr-ne gf 2 mx 200 dagegen schon

[Hui!]

Ich hatte mal eine Geforce2MX, gabs absolut nix dran auszusetzen, auch die Geforce4MX hab ich schon ein paar mal in Action gesehen, eigentlich beides anständige Grafikkarten, gibt halt auch Leute die nicht so viel Kohle hinlegen wollen/können nur hier anscheinend nicht...
(ich weiß, ich weiß, Technologie Bremse bla, bla, bla...)

Das er NV31 sich mit dem RV350 messen muss weiß ich auch, hab ja über den Vergleich einer R9500 mit einer fiktiven Karte mit NV31 Chip gemeckert.

[Andreas Tidl]

ATi erwähnte zudem, dass man bezüglich des 0.13 Mikron Prozesses bereits vor einiger Zeit von TSMC gewarnt wurde und sich deshalb auch entschloss, beim R300 auf den älteren, aber bewährten 0.15 Mikron Prozess zu setzen. Laut ATi würde ein in 0.13 Mikron (mit Low-K Dielektrika) gefertigter R300 nur ca. 20-25% weniger Strom benötigen. Dies erachtete man als zu wenig und setzte daher auf 0.15 Mikron.

Finde ich im Zusammenhang mit dem Stromverbrauch überaus interessant.
Vermutlich hat sich Nvidia mehr vom Die-Shrink erhofft bzw. wurden durch die gute R300 Performance gezwungen hohe Taktraten zu fahren und ignorierten die Gefahr des thermischen Kollapses.

[Ailuros]

Wenn man einfach mal simpel (sicher zuu simpel) den Takt runterrechnet, käme man für den nV30 bei 350MHz noch auf 52,5W (ausgehend von 75W bei 500MHz). Dazu noch etwas niedrigere vCore, die Hälfte der Pipelines und weniger/niedriger taktendes RAM, und schon ist man wieder unterhalb der magischen 40W-Grenze. Ob das jedoch umgesetzt wird, steht in den Sternen, ATi hat ihrer R9500 ja auch noch den Floppystecker gelassen, obwohl der rein von der absoluten Leistungsaufnahme nicht nötig gewesen wäre.

Fuer eine genaue Antwort muesste man wohl einen Inginieur fragen, aber soweit ich weiss war NV30 fuer low k di electric ausgesetzt, was auch anscheinend deren groesstes Problem war. Da die finale NV30 heute kein low k Zeug hat, kann es sein dass der extrem hohe Stromverbrauch daher kommt.

Dabei kann es sein dass eine 400MHz FX so wie Du spekulierst doch an die 40W verbraucht, was aber im Vergleich zu 15um und an die 24W bei der R300 keinen Vergleich mehr darstellt, da der Stromverbrauch ungewoehnlich hoch aussieht fuer 13um und der FX@400.

Keine Ahnung ob die Sache mit dem low k Zeug in Zwischenzeit geklappt hat. Das Raetsel wird dann wohl NV31 nach release loesen.

[Unregistered]

hier gibts einige nette infos was beim NV30 so schief gegangen ist usw. 0,13µ ,low-k

http://www.penstarsys.com/editor/Today/nvidia3/index.html

fand´s recht interessant

[Ailuros]

Josh hat in manchen Stellen danebengeschossen in dem Artikel. Z.B. bezweifle ich dass Carmack jemals mit seinen Aussagen behauptet oder angedeutet hat dass NV30 mit ARB2 um zweimal so schnell ist wie R300.

Die Frage verbleibt trotzdem wie es mit NV31 aussieht, da dieser anscheinend schon sein tapeout hinter sich hat.

[Richthofen]

nich nur das.
Er liegt schon im A1 Stepping vor.
Das A2 und wohl finale wird im Februar erwartet.
Lang wirds daher nimmer dauern.

[Crushinator]

Originally posted by Unregistered hier gibts einige nette infos was beim NV30 so schief gegangen ist usw. 0,13µ ,low-k... Ja, der Artikel ist nicht schlecht, aber über diese Aussage muß man nur lachen, weil sie einfach nicht dem entspricht, was JC geschrieben hat.

"Carmack also commented on the performance of the GeForce FX under different rendering modes with Doom III. Under NV-30 mode, the GeForce FX was roughly twice as fast in some operations as the Radeon 9700 Pro in ARB-2 (Architectural Review Board standard with complex shading lanquage)."

:bonk:

[Crazytype]

war das nicht umgekehrt?... lol

[Ailuros]

Originally posted by Crazytype
war das nicht umgekehrt?... lol

Die Aussagen von Carmack und die verschiedenen FP- Werte haben wohl genuegend zur Verwirrung beigetragen. Ich versuch's mal so einfach wie moeglich zu machen:

R300=
FP24/96bit

NV30=
FP16/64bit
FP32/128bit

NV30/FP16 > R300/FP24 (R300 bessere Qualitaet)

R300/FP24 > NV30/FP32 (NV30 bessere Qualitaet)

Wobei ich mich immer noch frage ob Qualitaets-Unterschiede zwischen FP16 und 24 ueberhaupt zu sehen sein werden in Doom3; wieviele Texturen pro pass benutzt das Spiel eigentlich maximal? Sechs, acht? Macht es in diesem Fall ueberhaupt einen Unterschied?

Ich kann mich eher an einen Kommentar erinnern von Carmack, wobei er sagt dass in manchen Faellen die eine, und die anderen Faellen die andere schneller war. Ich wuerde eher auf ungefaehr gleiche Leistung spekulieren.

Vielleicht hilft es ATI wenn die ihre dot3 Leistung ein bisschen aufpumpen...

[Unregistered]

Originally posted by Ailuros


Die Aussagen von Carmack und die verschiedenen FP- Werte haben wohl genuegend zur Verwirrung beigetragen. Ich versuch's mal so einfach wie moeglich zu machen:

R300=
FP24/96bit

NV30=
FP16/64bit
FP32/128bit

NV30/FP16 > R300/FP24 (R300 bessere Qualitaet)

R300/FP24 > NV30/FP32 (NV30 bessere Qualitaet)

Wobei ich mich immer noch frage ob Qualitaets-Unterschiede zwischen FP16 und 24 ueberhaupt zu sehen sein werden in Doom3; wieviele Texturen pro pass benutzt das Spiel eigentlich maximal? Sechs, acht? Macht es in diesem Fall ueberhaupt einen Unterschied?

Ich kann mich eher an einen Kommentar erinnern von Carmack, wobei er sagt dass in manchen Faellen die eine, und die anderen Faellen die andere schneller war. Ich wuerde eher auf ungefaehr gleiche Leistung spekulieren.

Vielleicht hilft es ATI wenn die ihre dot3 Leistung ein bisschen aufpumpen...

Wenn Du (im Gegensatz zu JC) meinst, dass man die Qualität zw. FP16 und FP24 nicht sehen kann, wie soll man dan erst den "Qualitätsvorteil" von FP32 zu FP24 wahrnehmen?!

[ShadowXX]

Hier noch mal der Text des letzten .plan-updates von JC:


Jan 29, 2003
------------
NV30 vs R300, current developments, etc

At the moment, the NV30 is slightly faster on most scenes in Doom than the
R300, but I can still find some scenes where the R300 pulls a little bit
ahead. The issue is complicated because of the different ways the cards can
choose to run the game.

The R300 can run Doom in three different modes: ARB (minimum extensions, no
specular highlights, no vertex programs), R200 (full featured, almost always
single pass interaction rendering), ARB2 (floating point fragment shaders,
minor quality improvements, always single pass).

The NV30 can run DOOM in five different modes: ARB, NV10 (full featured, five
rendering passes, no vertex programs), NV20 (full featured, two or three
rendering passes), NV30 ( full featured, single pass), and ARB2.

The R200 path has a slight speed advantage over the ARB2 path on the R300, but
only by a small margin, so it defaults to using the ARB2 path for the quality
improvements. The NV30 runs the ARB2 path MUCH slower than the NV30 path.
Half the speed at the moment. This is unfortunate, because when you do an
exact, apples-to-apples comparison using exactly the same API, the R300 looks
twice as fast, but when you use the vendor-specific paths, the NV30 wins.

The reason for this is that ATI does everything at high precision all the
time, while Nvidia internally supports three different precisions with
different performances. To make it even more complicated, the exact
precision that ATI uses is in between the floating point precisions offered by
Nvidia, so when Nvidia runs fragment programs, they are at a higher precision
than ATI's, which is some justification for the slower speed. Nvidia assures
me that there is a lot of room for improving the fragment program performance
with improved driver compiler technology.

(Quelle: http://www.shacknews.com/docs/press/012903_carmackplan.x)

JC sagt also das die fx in manchen sachen etwas schneller ist, in manchen aber auch etwas langsamer.
(Wenn man NV30-path gegen ARB2/R200-path stellt).

Im ARB2-path ist die fx nur halb so schnell wie die r300.

MfG
J.S.Shadow

[Ailuros]

Originally posted by Unregistered


Wenn Du (im Gegensatz zu JC) meinst, dass man die Qualität zw. FP16 und FP24 nicht sehen kann, wie soll man dan erst den "Qualitätsvorteil" von FP32 zu FP24 wahrnehmen?!

Oben wurde gerade der Kommentar von JC gequotet.

***edit: von JC's Aussagen schaetze ich dass FP16 genug sein koennte fuer D3, nur weil die eingesetze Anzahl von Texturen pro pass nicht allzu hoch ist sowie die Anzahl von Blending Operations. Natuerlich ist FP32 optimal, aber beide Karten (selbst wenn R300 ueber volles FP32 faehig waere) werden wohl viel zu langsam dafuer sein, wobei der Leistungseinbruch nicht in Analogie mit der Qualitaets-Verbesserung stehen koennte.

ARB (minimum extensions, no
specular highlights, no vertex programs), R200 (full featured, almost always
single pass interaction rendering), ARB2 (floating point fragment shaders,
minor quality improvements, always single pass).

....fuer R300.

The R200 path has a slight speed advantage over the ARB2 path on the R300, but
only by a small margin, so it defaults to using the ARB2 path for the quality
improvements.

Uebrigens:

NV20 (full featured, two or three
rendering passes), NV30 ( full featured, single pass), and ARB2.

NV20path= 4 textures per pass, zwei oder drei rendering passes. Dabei hat keiner wohl ne Ahnung wozu der dritte rendering pass noetig ist. Denn:

R200 (full featured, almost always
single pass interaction rendering)

R200 path= 6 Texturen pro pass. Deshalb auch meine Spekulation dass der groesste Teil bei D3 um die 6T/pass liegt, und stellenweise mehr Texturen/pass, die dann eine NV20 biz zu 3 rendering passes zwingt.

Letztenendes:

The reason for this is that ATI does everything at high precision all the
time, while Nvidia internally supports three different precisions with
different performances. To make it even more complicated, the exact
precision that ATI uses is in between the floating point precisions offered by
Nvidia, so when Nvidia runs fragment programs, they are at a higher precision
than ATI's, which is some justification for the slower speed.

Wo ist die Logik in meinem Beispiel fehlgelaufen? Schau Dir nochmal das Beispiel mit FP-Praezisionswerten an. FP24 liegt genau in der Mitte zwischen FP16 und FP32. Wobei der Unterschied zwischen FP16 und 32 gross sein koennte, aber FP16<->FP24 oder FP24<->FP32 eher klein.

[Xmas]

Originally posted by Ailuros
Uebrigens:

NV20path= 4 textures per pass, zwei oder drei rendering passes. Dabei hat keiner wohl ne Ahnung wozu der dritte rendering pass noetig ist. Denn:

R200 path= 6 Texturen pro pass. Deshalb auch meine Spekulation dass der groesste Teil bei D3 um die 6T/pass liegt, und stellenweise mehr Texturen/pass, die dann eine NV20 biz zu 3 rendering passes zwingt.
Je nach "Shader" ist es möglich, dass nur 5 Texturen verwendet werden die der R200 in einem Pass macht, der NV20 aber drei braucht. Es reicht nicht, die Anzahl der Texturen durch die Anzahl der "virtuellen" TMUs zu teilen, um die Anzahl der benötigten Passes zu erhalten.

[Ailuros]

Originally posted by Xmas

Je nach "Shader" ist es möglich, dass nur 5 Texturen verwendet werden die der R200 in einem Pass macht, der NV20 aber drei braucht. Es reicht nicht, die Anzahl der Texturen durch die Anzahl der "virtuellen" TMUs zu teilen, um die Anzahl der benötigten Passes zu erhalten.

Da stimme auch zu. Die Frage hier ist ob mit einer solchen Anzahl von Texturen in single pass oder zwei/drei multipasses, der Unterschied ueber 64bit interner Farbpraezision wirklich so wichtig ist letzenendes.

Wuerde es 16 Texturen/pass betreffen, waere es natuerlich eine ganz andere Geschichte.

[zeckensack]

John hat in einem älteren plan mal gesagt, wie das mit den Texturlayern aussieht. Das war ungefähr so:

Überwiegend 6 Texturen, aber auf eine davon (normalization cube map) wird zweimal zugegriffen.

Macht zwei dependant reads in die cube map, vielleicht ist das das Problem der Gf4Ti???

Der R200 kann zwar auch nur 6 Texturen binden, aber innerhalb seiner Möglichkeiten (Shaderlänge) beliebig viele dependant reads ausführen.

[Demirug]

Originally posted by zeckensack
John hat in einem älteren plan mal gesagt, wie das mit den Texturlayern aussieht. Das war ungefähr so:

Überwiegend 6 Texturen, aber auf eine davon (normalization cube map) wird zweimal zugegriffen.

Macht zwei dependant reads in die cube map, vielleicht ist das das Problem der Gf4Ti???

Der R200 kann zwar auch nur 6 Texturen binden, aber innerhalb seiner Möglichkeiten (Shaderlänge) beliebig viele dependant reads ausführen.

Die Cubemap zum normalisieren ist in dem FP Pfaden nicht mehr drin weil man das Normalisieren dort besser (genauer) direkt machen kann.

Bei den Cubemaps ist primär nichts mit dependant reads. Das ergebniss aus den Cubemaps wird mit DOT3 weiterverrechnet. Die einzige Stelle wo ich mir unter Umständen einen dependant read vorstellen kann wäre die Spiegelungen. Aber wenn dem so wäre dürfte der NV10 Pfad ja nicht Full Featured sein.

Warum aber nun der NV20 Pfad für machne Effekte 3 Passes braucht weis ich auch nicht. Möglicherweisse reichen da die Colorops nicht aus.

P.S: Bist du dir sicher das der R200 unlimitierte dependant reads kann. AFAIK kann er nur einmal dependant read Stufe und der R300 kann 4 Stufen.

[zeckensack]

Originally posted by Demirug


Die Cubemap zum normalisieren ist in dem FP Pfaden nicht mehr drin weil man das Normalisieren dort besser (genauer) direkt machen kann.Ja, das war auch eine alte Diskussion wo's noch um NV20 vs R200 ging. Da war ja noch nichts mit FP :)
Bei den Cubemaps ist primär nichts mit dependant reads. Das ergebniss aus den Cubemaps wird mit DOT3 weiterverrechnet. Die einzige Stelle wo ich mir unter Umständen einen dependant read vorstellen kann wäre die Spiegelungen. Aber wenn dem so wäre dürfte der NV10 Pfad ja nicht Full Featured sein.Ehm, wenn ich das richtig verstanden habe, waren das normalization cube maps. Und Vektornormalisierung über eine Cube map ist ein dependant read (Vektor ausrechnen, als Texturkoordinaten nehmen, lesen). Für NV30/R300 kann das natürlich entfallen.
Warum aber nun der NV20 Pfad für machne Effekte 3 Passes braucht weis ich auch nicht. Möglicherweisse reichen da die Colorops nicht aus.Ich weiß es auch nicht (mehr? die alten plans finde ich nicht auf die schnelle ...). Deswegen spekuliere ich hier auch in die Richtung :)

P.S: Bist du dir sicher das der R200 unlimitierte dependant reads kann. AFAIK kann er nur einmal dependant read Stufe und der R300 kann 4 Stufen. Nein, das meinte ich natürlich nicht.
Der R200 kann keine rekursiven dependant reads. Aber er kann durchaus in Phase 1 sechs Texturkoordinaten ausrechnen, und diese in Phase 2 alle zum Sampeln von Texturen benutzen. Phase 3 (das wäre dann bereits Rekursion) gibt's auf dem R200 nicht.

[Demirug]

Originally posted by zeckensack
Ehm, wenn ich das richtig verstanden habe, waren das normalization cube maps. Und Vektornormalisierung über eine Cube map ist ein dependant read (Vektor ausrechnen, als Texturkoordinaten nehmen, lesen). Für NV30/R300 kann das natürlich entfallen.

Nur zur Sicherheit das wir das gleiche meinen.

Die beiden Vectoren die über die Cubemap normalisiert werden sind L und H im Tangent-Space. L und H werden im Vertexshader berechnet in den Tangentspace Transformiert und dann interpoliert und pro Pixel über die Cubemap normalisiert.

Aus der Normalmap wird dann N (im Tangentspace) für den Pixel geholt und mit N dot H sowie N dot L werden die Faktoren für das Diffuse sowie Speculare Licht bestimmt. Das ganze dann noch mit der Diffusemap bzw. Specularmap multipliziert und beide werte addiert. Fertig ist das DOOM III Basis Lichtmodel. Die beiden Texturen die noch fehlen dürften die Lichtmaske und eine Detailtexture sein.

Ich sehe da keinen einzigen dependent read.

Nein, das meinte ich natürlich nicht.
Der R200 kann keine rekursiven dependant reads. Aber er kann durchaus in Phase 1 sechs Texturkoordinaten ausrechnen, und diese in Phase 2 alle zum Sampeln von Texturen benutzen. Phase 3 (das wäre dann bereits Rekursion) gibt's auf dem R200 nicht.

OK war dann wohl nur eine Begriffsverwirrung. Bei DX wird unter der Anzahl der "dependent reads" verstanden wie oft man das ergebniss eines Texturfechts wieder als Texturkoordinate weiterverwenden darf. Also die Anzahl der Phasen.

[zeckensack]

Originally posted by Demirug
Nur zur Sicherheit das wir das gleiche meinen.

Die beiden Vectoren die über die Cubemap normalisiert werden sind L und H im Tangent-Space. L und H werden im Vertexshader berechnet in den Tangentspace Transformiert und dann interpoliert und pro Pixel über die Cubemap normalisiert.

Aus der Normalmap wird dann N (im Tangentspace) für den Pixel geholt und mit N dot H sowie N dot L werden die Faktoren für das Diffuse sowie Speculare Licht bestimmt. Das ganze dann noch mit der Diffusemap bzw. Specularmap multipliziert und beide werte addiert. Fertig ist das DOOM III Basis Lichtmodel. Die beiden Texturen die noch fehlen dürften die Lichtmaske und eine Detailtexture sein.

Ich sehe da keinen einzigen dependent read.Tja, also dann hast du Recht :)
Dann haken wir die dependant reads ab, ich war irgendwie der Meinung, die Cubemaps zählen zu müssen, was irgendwie Quatsch ist, wenn der Vektor direkt aus dem Interpolator kommt ;)

OK war dann wohl nur eine Begriffsverwirrung. Bei DX wird unter der Anzahl der "dependent reads" verstanden wie oft man das ergebniss eines Texturfechts wieder als Texturkoordinate weiterverwenden darf. Also die Anzahl der Phasen. Du solltest dir vielleicht mal kurz PS1.4 ansehen, da gibt's auch Phasen. Die Begrifflichkeit hängt direkt mit der R200-Architektur zusammen, und gilt auch unter OGL nur für die R200-Fragment Shader ;)

Kurzform:
PS1.4
#Phase 1
##Textursampling
##Color-/Alpha-Ops in Paaren (maximal acht Paare)

#Phase 2
##Textursampling *
##Color-/Alpha-Ops in Paaren (maximal acht Paare)

Dadurch daß PS1.4 nicht zwischen Farb- und Addressregistern trennt, können Color-/Alpha-Ops auch auf Texturkoordinaten angewendet werden.
Gleichzeitig dürfen die Ops aber in jeder Phase aber erst nach dem Textursampling passieren.

Dadurch ergibt sich, daß ich frühestens zu Beginn von Phase 2 dependant reads auflösen kann. Beim Textursampling in Phase 1 gibt's nur die Koordinaten aus dem Interpolator, ohne daß Ops drübergelaufen sind.

__________________
Dabei fällt mir aber ein weiterer Satz aus dem alten plan ein:
John hatte erwähnt, daß der R200 die Cube map zweimal benutzen kann, was wohl irgendwie etwas besonderes sein muß, denn sonst hätte er's nicht erwähnt.

Kann es sein, daß es da eine Einschränkung bei der Gf3/4Ti gibt, sodaß man nur einmal sinnvoll auf die NCM zugreifen kann???

[Demirug]

Originally posted by zeckensack
Du solltest dir vielleicht mal kurz PS1.4 ansehen, da gibt's auch Phasen. Die Begrifflichkeit hängt direkt mit der R200-Architektur zusammen, und gilt auch unter OGL nur für die R200-Fragment Shader ;)

Kurzform:
PS1.4
#Phase 1
##Textursampling
##Color-/Alpha-Ops in Paaren (maximal acht Paare)

#Phase 2
##Textursampling *
##Color-/Alpha-Ops in Paaren (maximal acht Paare)

Dadurch daß PS1.4 nicht zwischen Farb- und Addressregistern trennt, können Color-/Alpha-Ops auch auf Texturkoordinaten angewendet werden.
Gleichzeitig dürfen die Ops aber in jeder Phase aber erst nach dem Textursampling passieren.

Dadurch ergibt sich, daß ich frühestens zu Beginn von Phase 2 dependant reads auflösen kann. Beim Textursampling in Phase 1 gibt's nur die Koordinaten aus dem Interpolator, ohne daß Ops drübergelaufen sind.

Ich kenne die PS 1.4. Musste mich schon genug damit herumärgern.

Das mit den phase gibt es aber nur dort. Und obwohl die PS 2.0 ja im Prinzip auch Phasen haben wird es dort im Code nicht mehr Explizit angegeben. Das Aufteilen des Shaders auf die Phasen ist jetzt wohl die Aufgabe des Treibers.

Der Rest ist schon klar. Deswegen sparch ich ja auch von nur einem Dependant read. Im Prinzip sind es bis zu 6 mal ein Dependant read beim R200.


Dabei fällt mir aber ein weiterer Satz aus dem alten plan ein:
John hatte erwähnt, daß der R200 die Cube map zweimal benutzen kann, was wohl irgendwie etwas besonderes sein muß, denn sonst hätte er's nicht erwähnt.

Kann es sein, daß es da eine Einschränkung bei der Gf3/4Ti gibt, sodaß man nur einmal sinnvoll auf die NCM zugreifen kann???

Der R200 kann ja aus jedem der 6 Sampler zwei Samples holen (Phase1 und Phase2). Man holt sich also zum Beispiel in Phase 1 den Vektor für L sowie N und die Diffusemap und rechnet den Diffuse Anteil aus. N und den Diffuseanteil übergibt man an Phase2 direkt. In Phase 2 holt man dann noch H aus der Cubemap und die Specularmap und brechnet den engültigen Farbwert. Was man sonst noch braucht verteilt man auf Phase 1 und 2.

Beim NV25 kann man von jedem Sampler nur ein Sample pro Pass holen. Braucht man zwei Samples muss man die Texture zwei Samplern zuweisen. Da der NV2x aber nur 4 Sampler hat bekommt man Probleme da man für den Diffuse und Specular Anteil jeweils 3 Samples braucht (Lichtvektor, Normal, Colormap). Die Normale ist zwar in beiden Fällen gleich aber dann sind es immer noch 5 Texturen. Also braucht man schon mal 2 Passes für den Specular und Diffuseanteil. Die Normalmap muss dabei sogar zweimal mit den gleichen Koordinaten gefetcht werden. In jedem Pass hat man dann noch einen Sampler für sonstiges zur Verfügung. Kommt man damit nicht hin werden es halt 3 Passes.

P.S.: DOOM III hat noch eine nette Beschränkung bezüglich Alpha-Blending. Es ist nur Dest + Src möglich. Mit dem Alphawert kann man aber noch ein bischen was machen. Aber eine Multiplikation von Destination Color und Source Color ist nicht drin.

[zeckensack]

Hätte ich mir denken können, daß du die PS1.4 kennst :D

Naja, macht ja nichts, dann haben wir wenigstens das Forum wieder um ein wenig Information bereichert =)

Und die Frage, warum der NV20-Pfad mehr Passes braucht als der R200-Pfad dürfte jetzt auch geklärt sein.
Thx :)

[Frank]

Wenn ich hier die ganzen Vermutungen der WattAngaben lese, frage ich mich bei aller gedanklicher Verschönerung der Werte immernoch, wie die Dinger jemals in ein Notebook wandern sollen. :|