Archiv verlassen und diese Seite im Standarddesign anzeigen : NV3X: FX12 anstatt FP16/32 Cheat oder gültige Optimierung?
Demirug
2003-10-09, 21:51:23
Sobald man unter DirectX Pixelshader der Version 2.0 oder höher benutzt ist Fliesspunkt (FP16/FP32) Pflicht. Nun ist es ja keine Neuigkeit das die NV3X Chips nicht gerade vor Fliesspunktleistung strotzen. Integerleistung (FX12) scheint dagegen wesentlich mehr verfügbar zu sein. Das nVidia im Prinzip kein Problem damit haben die Rechengenauigkeit abzusenken haben sie ja schon unter Beweiss gestellt. Nun bleibt natürlich die Frage in wie weit ein solches absenken erlaubt oder zumindestens tolerierbar ist.
3D Grafik ist ja nach wie vor sehr texturlastig. Daher ist das Verrechnen von Texturwerten auch nach wie vor ein typische Einsatzgebiet für den Pixelshader. Texturen liegen nun nach wie vor üblicherweise als 32Bit RGBA vor. Der Framebuffer liegt nun ebenfalls als 32Bit RGBA vor. Welche Konsequenz ergibt sich nun wenn man für das Verrechnen von Texturewerten anstatt mit FP32/FP16 nur mit FX12 arbeitet.
Hört man hier schon jemanden laut Cheat rufen?
Für alle die sich schon diebisch freuen kommt jetzt eine bittere Pille. Es muss kein Cheat sein. Es lässt sich mathematisch wie auch praktisch beweisen das für das verechnen von 2 32Bit RGBA Werten eine FX12 Einheit vollkommen ausreicht wenn das Ergebniss direkt danach in den Framebuffer geschrieben wird.
2 Werte und eine Rechenoperation sind aber nun keine grosses Möglichkeit zum Einsparen von Fliesspunktleistung. Lassen sich nun auch mehr Operationen durch die FX12 Einheiten übernehmen ohne zu Cheaten? Um die Anwort gleich vorweg zu nehmen. Es hängt unter bestimmten Umständen von der Toleranz einer möglichen Cheaterkennung ab. Sobald mehr als 2 Operationen zum Einsatz kommen lässt sich nicht mehr völlig ausschliessen das sich im Ausgabewert ein Fehler von 1/256 pro Farbkanal einschleicht. Für das menschliche Auge ist ein solcher Fehler normalerweise nicht zu sehen. Wird die Rechenkette lang genug kann der mögliche Fehler natürlich auch grösser werden. Vereinfacht gesagt kostet jeder Rechenschritt welcher auf ein FX12 Zwischenergebnissen aufbaut ein Bit an Genauigkeit (Ausnahmen bestätigen die Regel). Bei FX12 kann man den Verlust von 2 Bits verschmerzen was dazu führt das man 3 Ebenen zur Verfügung hat. Damit lassen sich bei einer baumartigen Anordnung bis zu 7 Operationen ausführen und dabei 8 Texturwerte verrechnen.
Das Absenken von FP32 auf FP16 hat übrigens sehr ähnliche Folgen. Allerdings tritt dort der 1/256 Fehler etwas seltener auf.
Zum Abschluss noch ein paar praktische Ergebnisse aus einer Testreihe welche 3 Texturwerte miteinader multipliziert. Als das Mass aller Dinge gilt hierbei die Berechnug mit FP32. Die Betrachtung wurde für einen Farbkanal durchgeführt kann aber auf die anderen 1 zu 1 übertragen werden. In Summe wurden jeweils 16777216 Tests mit jeder Rechengenauigkeit durchgeführt. Bei der Verwendung von FP16 konnte bei 2,42% eine Abweichung festgestellt werden. Kommt FX12 zum Einsatz sind 94,45% identisch. Ein Test mit FP16 als Referenz ergab dann bei 3,13% der Testfälle eine Abweichung im Endergebniss. In allen Fällen betrug die Abweichung 1/256. Zwischen FP32 und FP24 konnte bei diesem Shaderbeispiel keine Abweichungen festgestellt werden.
Die ursprüngliche Frage konnte nicht abschliessen beantwortet werden da hierzu eine Aussage von den zuständigen Organisationen bezüglich der erlaubten Toleranz fehlt. Für sich selbst muss wohl jeder selbst entscheiden ob ein Geschwindigkeitsgewinn die Abweichung von 1/256 rechtfertig.
AA
BB
CC
Hi, Demi!
Ui ui ui, wenn das hier mal friedlich abgeht... ;)
Normalerweise würde ich sagen NEIN, das wäre ein "Cheat".
Aber vermutlich wird NV es so oder so machen, und womöglich ist das auch ganz gut so. Wenn NV es nur so schafft, endlich mal eine halbwegs vernünftige PS-Leistung herauszubekommen ("Wunder-Deto" hin oder her), dann sollten sie das wohl besser auch so machen. Ein bisschen Qualitätsverlust lässt sich dem User sich leichter unterschieben als generell miese PS-Performance.
Zwar würde ich mir gerne mal dazu einige Screenshots ansehen, aber generell dürfte das sicher für viele NV-User eine willkommene Optimierung sein, ich kann's ja verstehen.
Mein Fazit: Ja, FX12 statt FP16/32 ist Cheat, aber wohl unumgänglich und dürfte für die meisten User besser sein.
PS: Hab mich ohnehin schon seit langem gefragt, wenn schon auf FP16 zurückgreifen, warum dann nicht gleich auch auf FX12? :D
(Wieviel schneller könnte FX12 denn theoretisch gegenüber FP16 sein?)
BTW: Ist es überhaupt sicher, dass NV das noch nicht praktiziert?
Demirug
2003-10-09, 22:55:02
Original geschrieben von Keel
Hi, Demi!
Ui ui ui, wenn das hier mal friedlich abgeht... ;)
Deswegen Technologie.
Normalerweise würde ich sagen NEIN, das wäre ein "Cheat".
Aber vermutlich wird NV es so oder so machen, und womöglich ist das auch ganz gut so. Wenn NV es nur so schafft, endlich mal eine halbwegs vernünftige PS-Leistung herauszubekommen ("Wunder-Deto" hin oder her), dann sollten sie das wohl besser auch so machen. Ein bisschen Qualitätsverlust lässt sich dem User sich leichter unterschieben als generell miese PS-Performance.
Zwar würde ich mir gerne mal dazu einige Screenshots ansehen, aber generell dürfte das sicher für viele NV-User eine willkommene Optimierung sein, ich kann's ja verstehen.
Du siehst das ABC oben? Zwischen zwei gleichen Buchstaben hat die Farbe 1/256 Unterschied.
Mein Fazit: Ja, FX12 statt FP16/32 ist Cheat, aber wohl unumgänglich und dürfte für die meisten User besser sein.
PS: Hab mich ohnehin schon seit langem gefragt, wenn schon auf FP16 zurückgreifen, warum dann nicht gleich auch auf FX12? :D
(Wieviel schneller könnte FX12 denn theoretisch gegenüber FP16 sein?)
Doppelt oder mehr. Hängt aber stark von den genauen umständen ab. Und wenn etwas anderes bremst bringt es überhaupt nichts.
BTW: Ist es überhaupt sicher, dass NV das noch nicht praktiziert?
Bei den im Treiber hinterlegten gehe ich davon aus und ich weiss auch das der Treiber unter umständen auch bei nicht bekannten Shadern auf FX12 herunter geht. Allerdings nur unter bestimmten Umständen die ich nicht abschliessend Herausfinden konnte.
Original geschrieben von Demirug
Du siehst das ABC oben? Zwischen zwei gleichen Buchstaben hat die Farbe 1/256 Unterschied.
Ich denke eigentlich, dass ich das verstanden habe. Jedoch wird mir der Zusammenhang zwischen deinem Post und dem von mir zitierten Abschnitt nicht klar (vielleicht bin ich auch zu müde...)
Der Unterschied ist gering, ja - trotzdem würde ich das gerne mal in der Praxis sehen.
Original geschrieben von Demirug
Doppelt oder mehr. Hängt aber stark von den genauen umständen ab.
Und wenn etwas anderes bremst bringt es überhaupt nichts.
lol :D
LovesuckZ
2003-10-09, 23:20:09
Nachdem MS nun das WHQL Testprogramm verschaerft hat, wie sollte solch eine "Optimierung" dann noch vorgenommen werden?
Original geschrieben von Keel
Wenn NV es nur so schafft, endlich mal eine halbwegs vernünftige PS-Leistung herauszubekommen ("Wunder-Deto" hin oder her), dann sollten sie das wohl besser auch so machen.
Siehe Halo und 52.13. So schlecht ist der PS2.0 Speed nicht mehr.
Quasar
2003-10-09, 23:25:00
Original geschrieben von Demirug
AA
BB
CC
:lol: :rofl:
Wieeee GEILeinseins111!!!!
(/me hat's natürlich beim runterscrollen sofort gesehn)
Demirug
2003-10-09, 23:26:19
Original geschrieben von LovesuckZ
Nachdem MS nun das WHQL Testprogramm verschaerft hat, wie sollte solch eine "Optimierung" dann noch vorgenommen werden?
Das ist ja die Frage wie viel Toleranz ist erlaubt. Bei den meisten WHQL-Tests die bisher gemacht wurden waren immer leichte Abweichungen gegenüber dem Refrast erlaubt. Und 1/256 ist nicht viel. Besteht MS auf exakte Genauigekeit müsste sie den Refrast ja sowieso erst mal ändern das man die Genauigkeit der Chips einstellen kann. Denn solange der Refrast immer mit FP32 rechnet bekommt auch ATI Probleme.
Siehe Halo und 52.13. So schlecht ist der PS2.0 Speed nicht mehr.
Und wer sagt uns das 52.13 nicht schon fleisig solchen Trick benutzt?
Exxtreme
2003-10-10, 11:35:59
Für mich ist das ganz klar ein Cheat.
Erstens wird auf jeden Fall die Bildqualität beeinträchtigt (und darüber entscheidet der IHV was "gut genug" ist) und zweitens ist das nicht mehr API-konform da man laut DX9-Norm auf jeden Fall mit 16/32-Bit FP rechnen muss.
Quasar
2003-10-10, 11:50:41
Original geschrieben von Exxtreme
Für mich ist das ganz klar ein Cheat.
Q.e.e.
Original geschrieben von Exxtreme
Erstens wird auf jeden Fall die Bildqualität beeinträchtigt
:lol: Sischer, sischer....
Tip: Schau dir mal Demis AA BB CC an...
Original geschrieben von Exxtreme
(und darüber entscheidet Nvidia was "gut genug" ist)
Das finde ich auch zum :kotz:
Original geschrieben von Exxtreme
und zweitens ist das nicht mehr API-konform da man laut DX9-Norm auf jeden Fall mit 16/32-Bit FP rechnen muss.
Echt? ATi kann also nicht nach DX9-Norm rechnen? Oder wie meintest du das? ;) ;D
Für Shader 1.1-1.4 sollte auf jeden Fall auch ein INT-Format reichen, das konnten die "alten" Chips ja auch nur.
Problematisch ist's nur, wenn, wie Demirug eingangs sagte, das Endergebnis nicht nur optisch, sondern sogar mathematisch gleich ist.
Ist es dann Wortklauberei, INT12 als Cheat zu bezeichnen? Würde das auch getan, wenn das nicht nV sondern andere IHVs täten?
Demirug
2003-10-10, 11:59:14
Original geschrieben von Exxtreme
Für mich ist das ganz klar ein Cheat.
Erstens wird auf jeden Fall die Bildqualität beeinträchtigt (und darüber entscheidet der IHV was "gut genug" ist) und zweitens ist das nicht mehr API-konform da man laut DX9-Norm auf jeden Fall mit 16/32-Bit FP rechnen muss.
Nicht in jedem Fall. Zwei Texture (32Bit RGBA) multipliziern oder addieren und dann in einen 32Bit Framebuffer schreiben gibt egal ob nun FX12, FP16, FP24 oder FP32 immer genau das gleiche Ergebniss.
In komplexeren Fällen besteht die Gefahr von 0,39% Fehler bei wenigen Pixel. Ob das in Ordnung geht sollen ja nicht die IHVs sondern MS festlegen.
PS: DX9 fordert FP16 bzw FP24. Wenn es FP32 wäre würde ATI alt aussehen. ;)
micki
2003-10-10, 12:01:53
es ist ein cheat, denn es wird mittels eines tricks ein vorteil gezogen. ein cheat muss nicht heißen, dass etwas falsch ist/wird.
z.B. optimieren compiler oft eine division durch 2 mit einem shift 1 rechts. auch ein cheat, wobei sich nichts am ergebnis ändert, jedoch hat der programmierer das nicht angeordnet, was er explizit machen könnte. es kann ja sein, dass er den performanceunterschied testen möchte und zwei varianten hat, eine mit shift und eine mit div...
(ps. man kann für codestücke angeben ob sie optimiert oder ausgeschlossen werden sollen, aber von sich aus wird das wegoptimiert)
dx9 verlang FP, sind es keine FP ist es ein cheat, wobei ich den nicht als schlimm empfinde. schliesslich wird überall genauso gecheatet, z.b. die antialiasing modes, das ding von matrox/playstation hat kaum was mit FSAA zu tun, trotzdem ist es AA,dxt gepackte texturen sind auch nur ein cheat, täuschen bei gleichem speicherverbrauch durch höchere auslösung qualität vor, aber haben weit aus weniger (was wir "blinden" nicht erkennen sofern die textur nicht animiert ist), dabei sind die meißten texturen in dxt1/3/5 heutzutage, haben also nur 16bit/pixel als auflösung, was bei einem fehler von 1/256 egal ist da es überhaupt nur 5bit mit daten im oberen teil der bytes gibt.
und eine bumpmap ist auch nur ein cheat :)
in sofern ist so ein wenig ungenauigkeit im austausch für performance egal.
MfG
micki
Exxtreme
2003-10-10, 12:04:38
Original geschrieben von Demirug
Nicht in jedem Fall. Zwei Texture (32Bit RGBA) multipliziern oder addieren und dann in einen 32Bit Framebuffer schreiben gibt egal ob nun FX12, FP16, FP24 oder FP32 immer genau das gleiche Ergebniss.
In komplexeren Fällen besteht die Gefahr von 0,39% Fehler bei wenigen Pixel. Ob das in Ordnung geht sollen ja nicht die IHVs sondern MS festlegen.
Mir geht es auch nicht darum ob das menschliche Auge das sieht oder nicht. :)
Hier wird trotzdem die BQ gesenkt auch wenn es die HW anders könnte.
Und der zweite Punkt ist, daß hier ganz klar gegen die Vorgaben des API verstossen wird, was ich noch schlimmer finde als Punkt 1. :)
Original geschrieben von Demirug
PS: DX9 fordert FP16 bzw FP24. Wenn es FP32 wäre würde ATI alt aussehen. ;)
Ich weiss.
Quasar
2003-10-10, 12:11:55
Original geschrieben von micki
es ist ein cheat, denn es wird mittels eines tricks ein vorteil gezogen. ein cheat muss nicht heißen, dass etwas falsch ist/wird.
z.B. optimieren compiler oft eine division durch 2 mit einem shift 1 rechts. auch ein cheat, wobei sich nichts am ergebnis ändert, jedoch hat der programmierer das nicht angeordnet, was er explizit machen könnte. es kann ja sein, dass er den performanceunterschied testen möchte und zwei varianten hat, eine mit shift und eine mit div...
(ps. man kann für codestücke angeben ob sie optimiert oder ausgeschlossen werden sollen, aber von sich aus wird das wegoptimiert)
In diesem Fall muss man IMHO unterscheiden, ob es ein Benchmark ist, der für alle dieselbe Arbeit erzeugen soll, oder ein Spiel, bei dem Programmierer einen bestimmten Output erreichen will.
Im ersten Fall ist ganz klar der Workload das Hauptanliegen und die treiberseitige Heruntersetzung auf ein INT-Format klar ein Cheat. Insbesondere, wenn die Shader auch noch per ASM gecodet werden.
Im zweiten Fall jedoch ist es IMO legitim (solange das Ergebnis auch WIRKLICH dasselbe bleibt!!), da 'der typische Gamedesigner' ja eh eine HLSL benutzt, sprich, er will einen bestimmten Effekt mit einer bestimmten Optik, das 'wie' ist ihm dabei egal (sonst würde er keinen Compiler nehmen).
Quasar
2003-10-10, 12:13:21
Original geschrieben von Exxtreme
Mir geht es auch nicht darum ob das menschliche Auge das sieht oder nicht. :)
Hier wird trotzdem die BQ gesenkt auch wenn es die HW anders könnte.
Was ist ein Bild ohne das Auge des Betrachters?
Und was ist 1 + 1 = 2 im FP512-Format?
Richthofen
2003-10-10, 12:20:25
also mal ehrlich, wenn das ein recht simpler Shadereffekt ist und ich am Ende keinen grob auffallenden Qualitätsunterschied sehe - und damit meine ich nicht, dass ich einen Screenshot mache und den x-fach zoome - dann ist es mir doch völlig egal, ob das nun FX12, FP16, FP24 oder FP32 ist. Da sind mir auch die DX9 Specs egal.
Es ist nicht einzusehen, wieso jeder noch so simple Shader plötzlich unter die DX9 Spec zwanghaft fallen muss. Das ist Ressourcenverschwendung und wenn ich das selbe Ergebnis (wie gesagt hängt vom Aufwand des Effektes ab) mit weniger Genauigkeit auch erreichen kann, dann soll mir das recht sein.
Insofern, wenn die Programmierer zu faul sind und sich nach der ATI Maßgabe richten und jeden Scheiss unbedingt DX9 konform machen wollen obwohl es unnötig ist, dann soll Nvidia das im Treiber analysieren und ersetzen und der Reviewer soll es spielen und schauen ob er während des Spiels einen Unterschied sieht.
Wenn ja dann muss Nvidia an der speziellen Stelle eben nachsitzen und nochmal korrigieren und wenn nein, dann passts.
micki
2003-10-10, 12:34:06
Original geschrieben von Quasar
In diesem Fall muss man IMHO unterscheiden, ob es ein Benchmark ist, der für alle dieselbe Arbeit erzeugen soll, oder ein Spiel, bei dem Programmierer einen bestimmten Output erreichen will.
Im ersten Fall ist ganz klar der Workload das Hauptanliegen und die treiberseitige Heruntersetzung auf ein INT-Format klar ein Cheat. Insbesondere, wenn die Shader auch noch per ASM gecodet werden.
Im zweiten Fall jedoch ist es IMO legitim (solange das Ergebnis auch WIRKLICH dasselbe bleibt!!), da 'der typische Gamedesigner' ja eh eine HLSL benutzt, sprich, er will einen bestimmten Effekt mit einer bestimmten Optik, das 'wie' ist ihm dabei egal (sonst würde er keinen Compiler nehmen).
Man muss bei der Sache das Ziel sehen.
wenn Grafikkarten wirklich dafür gebaut werden würden, dass sie die selbe Arbeit machen (so wie zur VGA zeiten), dann hättest du nicht die Not einen treiber zu haben um die Anweisungen für die Hardware zu übersetzen.
Sie werden aber dafür gebaut, dass du am eingang Input anlegst und einen Output bekommst, der dem entspricht, den du mit dem standartisiertem weg (in diesem Fall dem RefRas) auch erhalten würdest, wenn du mit deinem dafür vorgesehenem Messgerät (Auge, ist ja ne Spielekarte) auch verifizieren könntest.
wenn NVidia anstatt FP32 lieber 128FIXP gehabt hätte, wäre die qualität in den meißten fällen wohl noch um einiges höcher, obwohl man den standartweg nicht befolgt hätte, wenn sie nachteile dadurch hätten, wäre es nichtmal ein cheat... trotzdem ist das alles legitim, weil das ziel wofür die graka gebaut wurde erreicht ist.
wir können eh nicht einsehen ob die nicht ein paar logicschaltkreise haben die prüfen ob z.b. mit 0.5 multipliziert werden soll und als optimierung dann ein paar Shift ausgeführt werden. aber was juckt es uns wenn am ende (ziemlich) das gleich rauskommt?
der kleine qualitätsunterschied, der bei dem filtering mit FIX12 rauskommt ist doch garnichts verglichen mit den ganzen AA AF cheats. keine graka filtert nach den vorgaben, sonst könnte man erzwingen dass eine ganze level durchgehend bis in die weitesten polys und kleinsten mipmap stufen noch AF hat für alle 16 texturreads.
und wir sorgen uns um 0.39% farbverlust.
cheat: ja
OK: ja
MfG
micki
Exxtreme
2003-10-10, 12:34:08
Original geschrieben von Quasar
Was ist ein Bild ohne das Auge des Betrachters?
Und was ist 1 + 1 = 2 im FP512-Format?
Spielt IMHO keine Rolle.
Wenn ein Programmierer FP16/24/32 benutzt dann hat er seine Gründe das zu tun. Wenn er nämlich der Meinung wäre, daß FX12 ausreicht, dann hätte er das benutzt um mehr Leistung zu bekommen.
Und hier hat der Treiber nichts, aber auch gar nichts selbst rumzupfuschen. :)
Demirug
2003-10-10, 12:36:20
Original geschrieben von Exxtreme
Mir geht es auch nicht darum ob das menschliche Auge das sieht oder nicht. :)
Mir auch. Bei dem Beispiel mit den 2 Texturwerten ist der Inhalt des Framebuffers bis aufs Bit identisch.
Hier wird trotzdem die BQ gesenkt auch wenn es die HW anders könnte.
Korrekt. Allerdings verursachen unterschiede beim Mipmap LOD, AF-Verfahren, AA-Verfahren weit grössere Unterschiede als besagtes 1/256. Sobald man also in der echte Praxsis geht kann man gar nicht mehr sagen woher die Abweichung nun kommt.
Und der zweite Punkt ist, daß hier ganz klar gegen die Vorgaben des API verstossen wird, was ich noch schlimmer finde als Punkt 1. :)
Die API definiert FP16 bzw FP24 Formate AFAIK gibt es aber keine exakte Festlegung der Rechenregeln dafür. nV und ATI haben ja schon verlauten lassen das aus Einsparungsgründen der IEEE standard für Fliesspunktzahlen nicht komplett implemnetiert wurde. So können also kleine Unterschiede durchaus zu abweichungen von einem Mantissenbit führen. Problematisch ist ja auch das wenn man zum Beispiel mit mehr Bits rechnet als gefordert werden. Auch in diesem Fall kann das letzte Bit aufgrund von Rundungsunterschieden nicht identisch sein.
Richthofen
2003-10-10, 12:37:36
Original geschrieben von Exxtreme
Spielt IMHO keine Rolle.
Wenn ein Programmierer FP16/24/32 benutzt dann hat er seine Gründe das zu tun. Wenn er nämlich der Meinung wäre, daß FX12 ausreicht, dann hätte er das benutzt um mehr Leistung zu bekommen.
Und hier hat der Treiber nichts, aber auch gar nichts selbst rumzupfuschen. :)
Das glaubst ja wohl selber nicht. Die Programmierer machen auch nur so viel aufwand wie unbedingt nötig. Zeit ist Geld und die ATI developer Präsentation kennst ja auch.
Ich finde schon das der Treiber da rumzufuschen hat.
Wenn ich den Unterschied nicht sehe, dann kann NV von mir aus alles ersetzen was sie wollen, wenn es Performance bringt.
Exxtreme
2003-10-10, 12:39:21
Original geschrieben von Richthofen
also mal ehrlich, wenn das ein recht simpler Shadereffekt ist und ich am Ende keinen grob auffallenden Qualitätsunterschied sehe - und damit meine ich nicht, dass ich einen Screenshot mache und den x-fach zoome - dann ist es mir doch völlig egal, ob das nun FX12, FP16, FP24 oder FP32 ist. Da sind mir auch die DX9 Specs egal.
Ja genau.
Wegen der "Die-Specs-sind-mir-egal"-Einstellung haben wir z.B. Spiele, die unter WinDOS9x laufen, unter Win2k/WinXP aber nicht... etc.
Original geschrieben von Richthofen
Es ist nicht einzusehen, wieso jeder noch so simple Shader plötzlich unter die DX9 Spec zwanghaft fallen muss. Das ist Ressourcenverschwendung und wenn ich das selbe Ergebnis (wie gesagt hängt vom Aufwand des Effektes ab) mit weniger Genauigkeit auch erreichen kann, dann soll mir das recht sein.
Es muss nicht jeder simple Shader zwanghaft mit FPxx gerechnet werden. Es muss aber jeder DX9-Shader damit gerechnet werden. Wenn man diese Genauigkeit nicht braucht dann schreibt man einen DX8-Shader und gut ist's.
Original geschrieben von Richthofen
Insofern, wenn die Programmierer zu faul sind und sich nach der ATI Maßgabe richten und jeden Scheiss unbedingt DX9 konform machen wollen obwohl es unnötig ist, dann soll Nvidia das im Treiber analysieren und ersetzen und der Reviewer soll es spielen und schauen ob er während des Spiels einen Unterschied sieht.
Wenn ja dann muss Nvidia an der speziellen Stelle eben nachsitzen und nochmal korrigieren und wenn nein, dann passts.
Das sollte immer noch der Entwickler entscheiden ob man diese Genauigkeit braucht oder nicht.
Demirug
2003-10-10, 12:39:58
Original geschrieben von Exxtreme
Spielt IMHO keine Rolle.
Wenn ein Programmierer FP16/24/32 benutzt dann hat er seine Gründe das zu tun. Wenn er nämlich der Meinung wäre, daß FX12 ausreicht, dann hätte er das benutzt um mehr Leistung zu bekommen.
Und hier hat der Treiber nichts, aber auch gar nichts selbst rumzupfuschen. :)
Ich darf aber bei einem PS 2.0 kein FX12 auswählen :heul: Und einen Shader in Multipass zu zerlegen ist Gift für die Performance.
Exxtreme
2003-10-10, 12:42:53
Original geschrieben von Richthofen
Das glaubst ja wohl selber nicht. Die Programmierer machen auch nur so viel aufwand wie unbedingt nötig. Zeit ist Geld und die ATI developer Präsentation kennst ja auch.
Ich finde schon das der Treiber da rumzufuschen hat.
Wenn ich den Unterschied nicht sehe, dann kann NV von mir aus alles ersetzen was sie wollen, wenn es Performance bringt.
Das Problem ist, daß wenn ein Treiber anfängt rumzupfuschen, die Programmierer sich NIEMALS mehr sicher sein können, was am Ende rauskommt. Es wird ein Try&Error-Spielchen werden. Ein Treiber soll exakt das liefern, was der Programmierer erwartet. Alles andere ist Pfusch und gehört in die Tonne!
Exxtreme
2003-10-10, 12:44:09
Original geschrieben von Demirug
Ich darf aber bei einem PS 2.0 kein FX12 auswählen :heul:
Dann beschwere dich bei Microsoft. ;)
Zecki hat schon mal gesagt, daß die es nicht schaffen ein vernünftiges API auf die Beine zu stellen.
Ansonsten nimmste halt einen DX8-Shader. :)
Quasar
2003-10-10, 12:44:35
Original geschrieben von Exxtreme
Spielt IMHO keine Rolle.
Wenn ein Programmierer FP16/24/32 benutzt dann hat er seine Gründe das zu tun. Wenn er nämlich der Meinung wäre, daß FX12 ausreicht, dann hätte er das benutzt um mehr Leistung zu bekommen.
Und hier hat der Treiber nichts, aber auch gar nichts selbst rumzupfuschen. :)
Wenn dem so wäre, daß die meisten Devs das auch wirklich täten (und nicht der ATi-Doktrin "Use PS2.0 whenever possible, else 1.4" zum Opfer fielen), würde ich dir ja recht geben.
Aber leider ist es in der Realität nicht so und da wird für simple Grundrechenarten ohne Nachkommastellen die FP-Keule rausgeholt.
Quasar
2003-10-10, 12:46:24
Original geschrieben von Exxtreme
Ansonsten nimmste halt einen DX8-Shader. :)
ATi ist da anderer Meinung...
Exxtreme
2003-10-10, 12:49:54
Original geschrieben von Quasar
ATi ist da anderer Meinung...
Egal. :)
ATi gibt die Specs nicht vor. Sie geben nur Empfehlungen. An die kann man sich halten oder auch nicht.
Quasar
2003-10-10, 12:53:08
Ooohhhh... du weißt doch genau, wie stark in letzter Zeit auf die Entwickler eingehämmert wird, Dinge so oder so zu machen.
Schau mal auf Seite 14 (http://www.ati.com/developer/Dark_Secrets_of_shader_Dev-Mojo.pdf)...
"most Hardware doesn't"
'Well, that is a lie', um's mal mit Grimas Worten zu sagen.
Exxtreme
2003-10-10, 12:59:07
Original geschrieben von Quasar
Ooohhhh... du weißt doch genau, wie stark in letzter Zeit auf die Entwickler eingehämmert wird, Dinge so oder so zu machen.
Schau mal auf Seite 14 (http://www.ati.com/developer/Dark_Secrets_of_shader_Dev-Mojo.pdf)...
"most Hardware doesn't"
'Well, that is a lie', um's mal mit Grimas Worten zu sagen.
Wie schon gesagt, man kann sich daran halten oder auch nicht. Deswegen sollte man sich Informationen aus mehreren Quellen holen.
Quasar
2003-10-10, 13:01:27
Wie schon gesagt, wenn man maßgebliche Inputmöglichkeiten zur Spec-Gestaltung hatte, ist es hinterher natürlich einfach zu sagen, man gebe nur Empfehlungen, aber an die Spec müssen sich alle halten...
Exxtreme
2003-10-10, 13:02:31
Original geschrieben von Quasar
Wie schon gesagt, wenn man maßgebliche Inputmöglichkeiten zur Spec-Gestaltung hatte, ist es hinterher natürlich einfach zu sagen, man gebe nur Empfehlungen, aber an die Spec müssen sich alle halten...
Diese Inputmöglichkeiten haben alle Hersteller.
Ist aber jetzt ziemlich OT.
Quasar
2003-10-10, 13:12:48
_Maßgebliche_ Möglichkeiten haben eben nicht alle Hersteller. Und besonders in diesem Falle schien das etwas 'anders' als sonst gelaufen zu sein.
Und wenn man dann noch den Umstand bedenkt, daß gerade die DX9-Architekturen höchst sensibel auf Optimierungen zugunsten/zulasten des einen oder des anderen reagieren, erübrigt sich eigentlich jede weitere Haarspalterei....
BTW, wie willst du nachweisen, daß eine 2 per INT oder FP errechnet wurde? Kennst du den Maschinencode der Grafikchips? :D
StefanV
2003-10-10, 13:32:23
Original geschrieben von Quasar
ATi ist da anderer Meinung...
nV ist auch nur anderer Meinung, weil die einen anderen Weg als ATI gegangen sind.
ATI hat exakt eine Einheit, die nur ein Format verarbeiten...
Wenns umgekehrt wäre, dann würd nV das sagen...
reunion
2003-10-10, 14:25:37
Ist meinermeinug nach klar ein Cheat!
DX9 schreibt nunmal FP16/24 vor, und daran hat sich auch NV zu halten.
edit:
Außerdem haben die Spielprogrammierer zu entscheiden welche genauigkeit man nimmt und nicht die Treiberprogrammierer von NV.
Und zu guter letzt wird dabei auch noch die Bildqualität gesenkt. Ob man das jetzt wahrnimmt oder nicht ist zweitrangig.
Allerdings wird man vermutlich sowieso nichts dagegen unternehmen können, da NV vermutlich einfach überall wo man zu langsam ist die Qualität senkt(siehe Det 50).
mfg
reu
micki
2003-10-10, 14:40:52
Original geschrieben von reunion
Ist meinermeinug nach klar ein Cheat!
DX9 schreibt nunmal FP16/24 vor, und daran hat sich auch NV zu halten.
klar ist das ein cheat, aber solange es niemandem schadet ist es ok...
außerdem schreib dx9 vor das man min FP24 unterstützen muss, ich glaube es wird nirgens vorgeschrieben, dass man sich an die angaben in den shadern halten _muss_, weil ansonsten atikarten, die weder FP16 noch FP32 können, pure-cheater wären die nie die geforderte qualität liefern...
MfG
micki
Quasar
2003-10-10, 14:42:25
Original geschrieben von reunion
Und zu guter letzt wird dabei auch noch die Bildqualität gesenkt. Ob man das jetzt wahrnimmt oder nicht ist zweitrangig.
siehe dazu:
Original geschrieben von Demirug
Nicht in jedem Fall. Zwei Texture (32Bit RGBA) multipliziern oder addieren und dann in einen 32Bit Framebuffer schreiben gibt egal ob nun FX12, FP16, FP24 oder FP32 immer genau das gleiche Ergebniss.
Du siehst, es geht auch über die Wahrnehmungsgrenze hinaus...
AA
BB
CC
Exxtreme
2003-10-10, 14:54:32
Original geschrieben von micki
außerdem schreib dx9 vor das man min FP24 unterstützen muss, ich glaube es wird nirgens vorgeschrieben, dass man sich an die angaben in den shadern halten _muss_, weil ansonsten atikarten, die weder FP16 noch FP32 können, pure-cheater wären die nie die geforderte qualität liefern...
MfG
micki
Doch, man muss sich daran halten. Die Ausnahme ist Partial Precision. Das ist nur ein Vorschlag an den Treiber, der hier FP16 benutzen darf.
Ich weiss nicht ob man FP32 explizit fordern kann.
Schreibt DX vor, dass mit FP24 gerechnet werden muss, oder schreibt DX vor, dass die Genauigkeit minstesten so sein muss, als hätte man mit FP24 gerechnet?
Original geschrieben von ow
(und btw muesste man ebenso dann als Cheat betrachten, dass ATi alles mit FP24 berechnet, selbst wenn nut INT12 oder FP16 gefordert ist)
..hmm lol. ..aber ok, damit kann ich leben. *g* ;)
cu
BUG
micki
2003-10-10, 15:17:04
Original geschrieben von aths
Schreibt DX vor, dass mit FP24 gerechnet werden muss, oder schreibt DX vor, dass die Genauigkeit minstesten so sein muss, als hätte man mit FP24 gerechnet?
"
Internal Precision
- All hardware that support PS2.0 needs to set
D3DPTEXTURECAPS_TEXREPEATNOTSCALEDBYSIZE.
- MaxTextureRepeat is required to be at least (-128, +128).
- Implementations vary precision automatically based on precision of
inputs to a given op for optimal performance.
- For ps_2_0 compliance, the minimum level of internal precision for
temporary registers (r#) is s16e7
- The minimum internal precision level for constants (c#) is s10e5.
- The minimum internal precision level for input texture coordinates (t#) is s16e7.
- Diffuse and specular (v#) are only required to support [0-1] range, and high-precision is not required.
"
Source: http://www.digit-life.com/articles2/ps-precision/
eigentlich kann dx9 nicht vorschreiben wie gerechnet wird, weil es sicherlich viele wege gibt um ein ziel zu erreichen, AMD cpus rechnen auch decent anders als INTEL cpus trotz gleicher datentypen.
was wichtig ist, ist die darstellung der datentypen in den registern und davon unabhängig ist wohl die art der berechnungen.
und wenn NV ein ausreichend genaues ergebnis liefert, ist der rechenweg/rechenart anscheinend egal....
gruesse
micki
Demirug
2003-10-10, 15:19:08
DX schreibt lediglich mindest Genauigkeiten vor. Aber genau daraus ergibt sich nun ein Problem wenn es darum geht ein Referenzbild zu erzeugen.
Der gleicher Shader mit _pp Hints einmal auf NV30, einmal mit R300 und einmal mit Refrast gerendert. Welches Ergebniss ist das richtige um einen IQ Check durchzuführen?
DrumDub
2003-10-10, 15:21:16
welchen sinn hatte es dann fp16 als mindestanforderung für 2.0er shader zu fordern, wenn fx12in manchen fällen reicht?
ot: was ich net raff, wieso der wert bei
<font color="0x000000">A</font><font color="0x000001">A</font>
in html 1/256 ist, aber als rgb siehts so aus
A 1=R:0 B:0 G:0
A 2=R:0 B:16G:0
bei bb und cc ist es auch im rgb-schema jeweils ein 1/256 unterschied.
btw. den unterschied zwischen 16bit/32bit sieht man auch nur in besonderen fällen (nebel etc.).
Quasar
2003-10-10, 15:30:20
Original geschrieben von micki
- Implementations vary precision automatically based on precision of inputs to a given op for optimal performance.
Sorry, micki [edit: sorry!], daß ich dein Zitat so verstümmelt habe, aber der Satz scheint mir wichtig.
- vary precision (also != FP24)
- automatically (also auch ohne pp_hint)
- based on precision of inputs (1+1=2 <-> sincos1.003422E6)
- to a given op (also je nach Operation)
Oder hab' ich hier was mißverstanden?
micki
2003-10-10, 15:48:49
Original geschrieben von Quasar
Sorry, micky, daß ich dein Zitat so verstümmelt habe, aber der Satz scheint mir wichtig.
- vary precision (also >= FP24)
- automatically (also auch ohne pp_hint)
- based on precision of inputs (1+1=2 <-> sincos1.003422E6)
- to a given op (also je nach Operation)
Oder hab' ich hier was mißverstanden?
zitat modifieziert != = >=, kann man nicht FETT darstellen
ich interpretiere das so, dass sie sagen, dass das was rauskommt nicht genau die mindestsanforderung treffen muss (also >=FP24) weil eine operation auf verschiedene weisen implementiert werden kann.
das heißt aber auch, dass wenn ATI's FP24 einheit nicht 100% richtig rechnet (sonder so wie die meißten fpus leichte ungenauigkeiten hat), ATIs ops unter die mindestgenauigkeit von FP24 fallen können. (was aber nicht schlimm ist, solange sie die register als FP24 haben)
würde ich jedenfalls so interpretieren.
der pp_hint muss stehen um anzuzeigen dass man die mindestgeforderte dx9 genauigkeit von FP24 für ein register nicht fordert... anscheinend könnte man also auch mit FIX9 rechnen solange man das im FP24 register speichert..
gruesse
micki ... seh ich aus wie ne maus? :D
Quasar
2003-10-10, 15:56:42
Ok, soweit erstmal.
Aber wie passt die variable Genaugkeit dann mit dem 'for optimal performance' zusammen?
Zumindest schwammig ist diese Richtlinie.
DrumDub
2003-10-10, 16:32:10
Original geschrieben von ow
Gar keinen, ausser NV eins reinzuwuergen, denn die wollten ja INT12 Berechneungen fuer PS2.x in der Spec drin haben, weil sie eben fuer viele Berechnungen ausreichen und man da nicht mit der FP-Keule kommen muss.
beweise musste dafür aber schon bringen... nicht das ich das m$ nicht zutraue, aber ich behaupte einfach, dass nv sich einfach zu sicher war, dass sich ihr konzept durchsetzen würde.
Razor
2003-10-10, 16:58:21
Original geschrieben von DrumDub
beweise musste dafür aber schon bringen... nicht das ich das m$ nicht zutraue, aber ich behaupte einfach, dass nv sich einfach zu sicher war, dass sich ihr konzept durchsetzen würde.
Dann mal eine Frage: Was für einen Sinn macht es, dieses Datenformat auszuschließen ?
:???:
Razor
Original geschrieben von ow
Gar keinen, ausser NV eins reinzuwuergen, denn die wollten ja INT12 Berechneungen fuer PS2.x in der Spec drin haben, weil sie eben fuer viele Berechnungen ausreichen und man da nicht mit der FP-Keule kommen muss. Andererseits die Frage, wieso überhaupt noch an Int festhalten? Man braucht FP-Logik in jedem Fall. Der Support von Int kostet zusätzliche Transistoren. Ok, Int-Rechnungen sind dann auch schneller, aber ATIs Hardware, die ohne Int-Unterstützung auskommt und alles mit "langsamen" FP-Einheiten rechnet, ist bei "full precision" trotzdem schneller als NV bei "mixed precision". Taktbereinigt würde die Schere noch größer...
Razor
2003-10-10, 17:14:16
Du weißt aber schon, dass 'mixed precision' aus fp16 UND fp32 besteht, während ATI's 'full precision' lediglich fp24 ist... auch hat beispielsweise die FX5900 keine INT-Einheit mehr und kann trotzdem noch bei 'alten' Anwendungen punkten.
Ist alles eine Frage der Architektur, oder ?
;-)
Razor
Original geschrieben von DrumDub
beweise musste dafür aber schon bringen... nicht das ich das m$ nicht zutraue, aber ich behaupte einfach, dass nv sich einfach zu sicher war, dass sich ihr konzept durchsetzen würde.
Dann erklär mir doch, warum sich NVs Konzept nicht durchgesetzt hat. Hat ATi da vielleicht interveniert?
Aquaschaf
2003-10-10, 17:33:56
Original geschrieben von ow
Oder warum alles mit FP machen, wenn INT doch ausreicht?
Weil es Transistoren spart die INT Einheiten wegzulassen und ebenso schnell auf FP wie auf INT laufen kann?
Original geschrieben von LovesuckZ
Siehe Halo und 52.13. So schlecht ist der PS2.0 Speed nicht mehr.
Von der PS-Performance der NV-Karten bin ich aber noch nicht überzeugt, schon gar nicht bei Halo.
1. Wir wissen nicht, ob nicht schon FX12 benutzt wird.
2. Die PS2.0 Shader bei Halo sind von der Anzahl her afaik doch sehr gering und dürften daher das Ergebnis eigentlich nicht so stark beeinflussen.
3. Wer sagt uns, dass NV die paar PS2.0 Shader nicht einfach per Hand optimiert hat? (Das würde ich ja nichtmal als schlimm ansehen, kann den User doch freuen, wenn's so viel besser läuft - nur lässt sich so kaum eine Aussage über die PS-Performance allgemein machen)
(4. Wer sagt uns, dass NV - oder meinetwegen auch ATI - nicht schon speziell auf diesen Bench optimiert hat/haben? -> daher custom timedemos)
Meine Meinung zu FX12 steht ja schon da.
Razor
2003-10-10, 17:50:24
Original geschrieben von Keel
Von der PS-Performance der NV-Karten bin ich aber noch nicht überzeugt, schon gar nicht bei Halo.
1. Wir wissen nicht, ob nicht schon FX12 benutzt wird.
2. Die PS2.0 Shader bei Halo sind von der Anzahl her afaik doch sehr gering und dürften daher das Ergebnis eigentlich nicht so stark beeinflussen.
3. Wer sagt uns, dass NV die paar PS2.0 Shader nicht einfach per Hand optimiert hat? (Das würde ich ja nichtmal als schlimm ansehen, kann den User doch freuen, wenn's so viel besser läuft - nur lässt sich so kaum eine Aussage über die PS-Performance allgemein machen)
(4. Wer sagt uns, dass NV - oder meinetwegen auch ATI - nicht schon speziell auf diesen Bench optimiert hat/haben? -> daher custom timedemos)
Meine Meinung zu FX12 steht ja schon da.
Ad1:
na und ?
Ist die BQ schlechter, als die bei ATI ?
:???:
Ad2: (mit 'ner Anwendung ausgezählt ;-)
PS_1_1 = 372
PS_1_4 = 264
PS_2_0 = 278
VS_1_1 = 128
Ad3:
Und wieder... na und ?
Auch glaube ich kaum, dass nVidia 'mal eben' 542 Shader 'per Hand' optimiert hat...
Ad4:
ATI ja wohl nicht, oder warum sind sie jetzt langsamer ?
:D
Razor
Razor
2003-10-10, 17:52:42
Original geschrieben von ow
Doch die FX5900 wird die INT Einheiten auch noch haben, denke ich.
Gibt's dazu irgendwelche Hinweise oder zumindest Annahmen ?
Würde mich wirklich interessieren...
Razor
DrumDub
2003-10-10, 17:57:08
Original geschrieben von ow
Dann erklär mir doch, warum sich NVs Konzept nicht durchgesetzt hat. Hat ATi da vielleicht interveniert?
weiß ich nicht. da musste m$ fragen.
möglich wäre aber auch ein kompletter verzicht auf int, da man damit einen schlussstrich ziehen wollte, um das in zukunft nicht mehr am bein zu haben, da int in zukunft eh nicht ausreicht.
btw. dave baumann ist der ansicht, dass der nv35 keine int alu mehr hat: http://www.beyond3d.com/forum/viewtopic.php?t=8005
del_4901
2003-10-10, 18:08:45
Original geschrieben von micki
es ist ein cheat, denn es wird mittels eines tricks ein vorteil gezogen. ein cheat muss nicht heißen, dass etwas falsch ist/wird.
z.B. optimieren compiler oft eine division durch 2 mit einem shift 1 rechts. auch ein cheat, wobei sich nichts am ergebnis ändert, jedoch hat der programmierer das nicht angeordnet, was er explizit machen könnte. es kann ja sein, dass er den performanceunterschied testen möchte und zwei varianten hat, eine mit shift und eine mit div...
(ps. man kann für codestücke angeben ob sie optimiert oder ausgeschlossen werden sollen, aber von sich aus wird das wegoptimiert)
Wo ist das bitteschön cheat, da wir uns im Rechner im Körper Z2 befinden, ist ein Bitshift Äquivalent zu div(2) mul(2).
Das nennt man Optimieren und hat mit Cheaten niks zu tun.
del_4901
2003-10-10, 18:23:28
Ich hab die Sache mit den Fehlstellen und Rundungsfehlern grad in Numerischer Mathe. Also Solange der Algorithmus stabil und gut konditioniert bleibt, hab ich nichts dagegen FX12 zu benutzen. Man muss den Algortihmus halt so anlegen, das der Ausgangsfehler im Berreich der Eingangsfehler liegen, ergo die Verstärkungsfaktoren möglichst klein bleiben. Solange das der Fall ist Fällt das keinem von uns auf. Der ganze Spass lässt sich mathematisch bestimmen, wenn der Algorithmus entsprechend "umgebaut" wird sollte das ok sein.
Original geschrieben von micki
es ist ein cheat, denn es wird mittels eines tricks ein vorteil gezogen. ein cheat muss nicht heißen, dass etwas falsch ist/wird.
z.B. optimieren compiler oft eine division durch 2 mit einem shift 1 rechts. auch ein cheat, wobei sich nichts am ergebnis ändert, jedoch hat der programmierer das nicht angeordnet, was er explizit machen könnte. es kann ja sein, dass er den performanceunterschied testen möchte und zwei varianten hat, eine mit shift und eine mit div...
Dies ist kein Cheat, weil der Programmierer eine Division durch zwei vorsieht und genau das auch bekommt. SHR x, 1 ist nicht "ein billiges Replacement für eine Division durch 2", sondern ist eine Division durch 2. Statt SHR könnte der mnemonische Befehl ja auch IDPT (Integer Division by Power of Two) heißen. Arithmetische Operationen definieren sich nun mal nur durch den Transfer.
Mathematisch gesagt:
Df = Dg, f(x) = g(x) | x € Dg => f = g
del_4901
2003-10-10, 18:34:22
Original geschrieben von Xmas
Dies ist kein Cheat, weil der Programmierer eine Division durch zwei vorsieht und genau das auch bekommt. SHR x, 1 ist nicht "ein billiges Replacement für eine Division durch 2", sondern ist eine Division durch 2. Statt SHR könnte der mnemonische Befehl ja auch IDPT (Integer Division by Power of Two) heißen. Arithmetische Operationen definieren sich nun mal nur durch den Transfer.
Mathematisch gesagt:
Df = Dg, f(x) = g(x) | x € Dg => f = g
jo, siehe auch: "b-adische Brüche zur Basis b=2"
+/-Sum(i=-unendl. -> n; mi*b^i; n € N, mi € {0,1})
Original geschrieben von ow
Wieso haben CPUs noch INT Einheiten?
Oder warum alles mit FP machen, wenn INT doch ausreicht?CPU != GPU. Für Zähler etc. braucht man Int. Für die generelle Verarbeitung von Daten und Code braucht man Int. (Pointer etc.)
Original geschrieben von ow
NV hat die FP Einheiten eben nur zu den Zwecken vorgesehen, in denen INT nicht ausreicht. Eine durchaus nachvollziehbare Entscheidung. Böse gesagt, weil sie offenbar nicht in der Lage waren, einen Chip zu designen, der alles gleich mit FP rendern kann und dabei noch schnell ist. Weniger böse gesagt, hat NVs Idee des Übergangs ja auch was für sich. Allerdings bedeutet das auch mehr Arbeit für den Programmierer. Der müsste, ginge es nach NV, ständig zwischen FX12, FP16 und FP32 entscheiden. Bei ATI geht alles mit FP24, wie gesagt bei vorbildlicher Performance. Dass FP24 keinen Bestand hat, und früher oder später FP32 weichen muss, und NV insofern fortschrittlicher ist, spielt angesichts der Real-World-Performance eine ungeordnete Rolle, (diesmal höflich gesagt.)
Original geschrieben von ow
Dass sie damit bei MS keinen Anklang fanden war wohl Pech. Immerhin hat MS das "Zugeständnis" an NV gemacht, dass FP16 erlaubt sein kann, und es somit gültige 2.0-er PS geben kann, die durchweg in FP16 rechnen. (Wobei Texture Ops besser genauer sein sollten.)
DrumDub
2003-10-10, 19:50:16
hab den link zwar schon geliefert, aber hier noch mal der quote:
OK, in another thread I described R300's pipeline as "shallow and wide" and NV30/35's as "Narrow and deep". However Eric Demers (sireric) did a presentation at shader day that surprised me because he imparted a little more detail on R300's Shader pipeline that appears to make that statement a little erroneous. Unbeknown to many before there is not two ALU's (1 Vec3 + 1 scalar) per R300/R350 pipeline, but 4 - Full Vec3/Scalar ALU's and "mini" Vec3/Scalar ALU's (capable of some basic math functions.
When we compare R300/R350 to NV30 and NV35 this appear to be what we have (as far as I can discern so far):
NV30 (x4) NV35 (x4) R300/R350 (x8)
---------------- --------------- ---------------
| | | | | |
| Tex addr | | Tex addr | |Tex addr proc|
| proc / | | proc / | | |
| Full FP32 | | Full FP32 | ---------------
| ALU | | ALU | |
---------------- --------------- -------------
| | | |
---------------- --------------- ------------ -----------
| | | Mini | | Full Vec | | Full |
| FX12 ALU | | FP32 | | FP24 ALU | | Scalar |
| | | ALU | | | | FP24 ALU|
---------------- --------------- ------------ -----------
| | | |
---------------- --------------- ------------ -----------
| | | Mini | | Mini Vec | | Mini |
| FX12 ALU | | FP32 | | FP24 ALU | | Scalar |
| | | ALU | | | | FP24ALU |
---------------- --------------- ------------ -----------
| | | |
| | --------------
| | |
Apart from the very basic Math ops Eric wasn't keen to give away any more details on what instructions the Mini ALU's support. So far we know that the 'Mini' FP32 ALU's in NV35 support ADD, SUB, MUL, DP3, DP4 (off the top of my head).
Update: A little more detail on the known functionality / limitations of the mini ALU's...
R300/R350 - ADD, SUB, MUL
NV35 - Both can do ADD, SUB, MUL, DP3, DP4. Both combined can do an FP32 MAD, or each can do an FP15 MAD. PS1.4 range still [-2,2]. Each of NV30' FX12 units could do 2 MUL per cycle - the new FP units can't so some PS1.1-1.4 shaders will be slower here.
http://www.beyond3d.com/forum/viewtopic.php?t=8005
int hat sich damit wohl eh ab dem nv35 erledigt, wenn die infos stimmen.
nggalai
2003-10-10, 20:37:36
Original geschrieben von Keel
2. Die PS2.0 Shader bei Halo sind von der Anzahl her afaik doch sehr gering und dürften daher das Ergebnis eigentlich nicht so stark beeinflussen.
Die Anzahl separate PS2-Shader ist relativ schnurz. Viel interessanter ist, wieviele Pixel denn damit gerendert werden, und wie die Shader gebaut (resp. "optimiert") werden.
93,
-Sascha.rb
Quasar
2003-10-10, 20:43:00
Original geschrieben von DrumDub
hab den link zwar schon geliefert, aber hier noch mal der quote:
http://www.beyond3d.com/forum/viewtopic.php?t=8005
int hat sich damit wohl eh ab dem nv35 erledigt, wenn die infos stimmen.
Nein, das denke ich nicht. Denn die FX12-Einheiten sind nicht durch volle FP32-ALUs ersetzt worden, sondern "nur" durch solche mit reduziertem Funktionsumfang: INT12 wird weiterhin deutlich schneller bleiben, IMO.
Original geschrieben von Quasar
Nein, das denke ich nicht. Denn die FX12-Einheiten sind nicht durch volle FP32-ALUs ersetzt worden, sondern "nur" durch solche mit reduziertem Funktionsumfang: INT12 wird weiterhin deutlich schneller bleiben, IMO. Kein Wunder, da nach wie vor (in der Regel) pro Pipe 2 Int12-Anweisungen ausgeführt werden können. Solange keine Textur-Ops gerechnet werden, kann NV35 aber auch 2 arithmetische FP-Rechnungen machen, wenn mich nicht alles täuscht.
Nachdem ich mir den Thread so durchgeschaut habe, muss ich schon sagen, das ich das erste Posting von Demirug schon etwas seltsam finde. ( Die Postings der Nvidia-Anhänger sind dagegen einfach nur lustig ).
Ein Entwickler muss sich darauf verlassen können, das der Treiber sein Programm zuverlässig in Pixelshader-Code, entsprechend der Vorgaben der API (DX9) umsetzt.
Wieso ist Demirug dann so erpicht daruaf, das Nvidia seinen DX9-code zerstückelt und ein Resultat ausgibt, das nichts mehr mit der Spec zu tun hat?
Wenn du nur wenige Befehle mit geringer Genauigkeit brauchst, wie in deinen Beispielen, dann benutze doch DX8.1 (PS1.1-1.4); und wenn du umbedingt FX12 für PS2.0-ähnliche Effekte benutzen willst, dann benutze OpenGL. In DX9 ist FX12 einfach nicht vorgesehen/erlaubt.Punkt.
Microsoft hat die Schranken für DX9/PS2.0 festgelegt ( >=FP24; bzw. FP16 für Nvidia ). Alles andere verletzt die Specs und ist damit unzulässig.
Das ganze rumgejammere ändert nichts an der Tatsache das FX12 nicht den DX9-Specs entspricht und damit unzulässig ist.
Demirug
2003-10-10, 21:00:16
IMHO lässt das Shaderverhalten eines NV35 darauf schliessen das im Combinerteil eine FP32 Einheit (MUL/ADD) und 2 INT12 Einheiten ihere Diente leisten . Weiterhin halte ich es für sehr wahrscheinlich das diese 3 Einheiten physikalisch sich viele Transitoren teilen und daher entweder 2 Int12 Ops oder eine FP32 Op ausgeführt werden kann.
DrumDub
2003-10-10, 21:06:08
Original geschrieben von Demirug
IMHO lässt das Shaderverhalten eines NV35 darauf schliessen das im Combinerteil eine FP32 Einheit (MUL/ADD) und 2 INT12 Einheiten ihere Diente leisten . Weiterhin halte ich es für sehr wahrscheinlich das diese 3 Einheiten physikalisch sich viele Transitoren teilen und daher entweder 2 Int12 Ops oder eine FP32 Op ausgeführt werden kann.
aha, das erklärt einiges.
Quasar
2003-10-10, 21:11:59
Original geschrieben von Gast
Wenn du nur wenige Befehle mit geringer Genauigkeit brauchst, wie in deinen Beispielen, dann benutze doch DX8.1 (PS1.1-1.4); und wenn du umbedingt FX12 für PS2.0-ähnliche Effekte benutzen willst, dann benutze OpenGL. In DX9 ist FX12 einfach nicht vorgesehen/erlaubt.Punkt.
Das ist doch genau das Problem. Viele Devs (Valve?) folg(t)en blind den Optimierungsregeln im SDK (die auf ATI-Hardware basierten).
Dabei übersah man (vielleicht auch, weil die Situation vorher nie so diversifiziert war), daß diese Optimierungen eben nur für ATi-Hardware gut sind (was mit S3 und XGI ist, wird man noch sehen, aber die haben mit ihrem Design wohl erst begonnen, als FP24 feststand).
Was die ATi-User freut, ist für Devs wie Valve eine Katastrophe (wenn man sich nicht grade im Vorfeld mit zig Millionen Dollar die Entwicklungskosten wieder reingeholt hat) und nun muss man sehen, wie man Schadensbegrenzung betreibt.
Wer auch immer diese Situation (absichtlich?) herbeigeführt hat, eines ist damit erstmal erreicht: nVidia dominiert den Grafikmarkt bis zum 3.0-Shader auf jeden Fall nicht mehr nach Belieben.
(Und mir fällt nur einer ein, der Motiv und Mittel hatte, das so "einzufädeln")
Demirug
2003-10-10, 21:17:34
Original geschrieben von Gast
Nachdem ich mir den Thread so durchgeschaut habe, muss ich schon sagen, das ich das erste Posting von Demirug schon etwas seltsam finde. ( Die Postings der Nvidia-Anhänger sind dagegen einfach nur lustig ).
Ein Entwickler muss sich darauf verlassen können, das der Treiber sein Programm zuverlässig in Pixelshader-Code, entsprechend der Vorgaben der API (DX9) umsetzt.
Wieso ist Demirug dann so erpicht daruaf, das Nvidia seinen DX9-code zerstückelt und ein Resultat ausgibt, das nichts mehr mit der Spec zu tun hat?
Genau hier ist doch das Problem. Die Spec ist nicht genau genug um 100% reproduzierbare Ergebnisse zu fordern. Die besagte Abweichung um 1/256 kann ich auch unter reiner Benutzung von FP Formaten zwischen NV3X und R(V)3XX bekommen. Die gleiche Abweichungen gibt es auch zwischen NV2X und R(V)2XX Chips.
Wenn du nur wenige Befehle mit geringer Genauigkeit brauchst, wie in deinen Beispielen, dann benutze doch DX8.1 (PS1.1-1.4); und wenn du umbedingt FX12 für PS2.0-ähnliche Effekte benutzen willst, dann benutze OpenGL. In DX9 ist FX12 einfach nicht vorgesehen/erlaubt.Punkt.
OpenGL kann ich nicht nehmen.
Die 1.X Shader haben manchmal nicht genügend Slots und mache Berechnungen innerhalb eines Pixels hätte ich schon gerne mit hoher Genauigkeit.
Microsoft hat die Schranken für DX9/PS2.0 festgelegt ( >=FP24; bzw. FP16 für Nvidia ). Alles andere verletzt die Specs und ist damit unzulässig.
Das ganze rumgejammere ändert nichts an der Tatsache das FX12 nicht den DX9-Specs entspricht und damit unzulässig ist.
Genau das ist ja die Frage. Verletzt eine Berechnung welche ein Ergebniss innerhalb einer durch die Spec erlaubten Toleranz liefert diese wirklich?
Die mögliche Abweichung von 1/256 ist ja nicht vermeidbar solange man nicht genau ein bestimmtes Format vorschreibt. Ein Rundungsfehler eben.
Original geschrieben von Demirug
Die mögliche Abweichung von 1/256 ist ja nicht vermeidbar solange man nicht genau ein bestimmtes Format vorschreibt. Ein Rundungsfehler eben. BTW ziemlich schlau von dir, im Blau-Kanal das Bit zu ändern. Da, wo der Mensch am unempfindlichsten ist. Grün ist da sicher kritischer. Behauptung: Spätestens 2 Bit Unterschied bei Grün kann man bei den "richtigen" (in diesem Sinne also "falschen") Texturen schnell sehen.
Demirug
2003-10-10, 22:31:05
Bitte:
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
Mit Rücksicht auf die Modembenutzer und die Bandbreite die Farbauswahl etwas reduziert
nggalai
2003-10-10, 23:35:26
Original geschrieben von Demirug
Mit Rücksicht auf die Modembenutzer und die Bandbreite die Farbauswahl etwas reduziert Der war schon fast gemein. :D Aber point taken.
Zum Topic: Wenn in der Spec nach genau einer Genauigkeit wie z.B. s10e5 verlangt wird, dann ist's ein Verstoss gegen die Spezifikationen. Andererseits--so what? Specs wurden schon immer von den Entwicklern "gedehnt". Solange das Endergebnis zu einem akzeptablen Teil mit dem vom Entwickler Geforderten übereinstimmt, geht das für mich rein moralisch gesehen in Ordnung.
93,
-Sascha.rb
reunion
2003-10-11, 14:54:07
Original geschrieben von Quasar
siehe dazu:
Du siehst, es geht auch über die Wahrnehmungsgrenze hinaus...
AA
BB
CC
Und??
Kann schon sein das es manchmal über die wahrnehmungsgrenze hinausgeht. Trozdem verschafft man sich einen Vorteil indem man die Bildqualität senkt. Und dabei auch noch gegen die vorgaben verstößt.
reunion
2003-10-11, 14:55:33
Original geschrieben von ow
Ich tippe mal auf letzteres. Alles andere wuerde imo keinen Sinn ergeben.
(und btw muesste man ebenso dann als Cheat betrachten, dass ATi alles mit FP24 berechnet, selbst wenn nut INT12 oder FP16 gefordert ist)
Mega :lol:. Du willst doch ATI nicht allenernstes vorwerfen das sie zu genau rechnen :naughty:
Demirug
2003-10-11, 16:03:50
Wie reden hier ständig vom senken der Bildqualität ohne diesen heiligen Kral des Renderns überhaupt schon gefunden zu haben. Könnten wir also bitte mal definieren was die korrekte Bildqualität ist von der man nicht abweichen darf?
Solange keine Referenz festgelegt ist kann man nicht beurteilen ob eine Aktion jetzt die Bildqualität senkt oder nicht.
del_4901
2003-10-11, 16:43:48
Original geschrieben von Demirug
Wie reden hier ständig vom senken der Bildqualität ohne diesen heiligen Kral des Renderns überhaupt schon gefunden zu haben. Könnten wir also bitte mal definieren was die korrekte Bildqualität ist von der man nicht abweichen darf?
Solange keine Referenz festgelegt ist kann man nicht beurteilen ob eine Aktion jetzt die Bildqualität senkt oder nicht.
Na wenn du schon so fragst ... da fällt mir nur eins ein: Mental-Ray ;)
del_4901
2003-10-11, 16:53:02
Original geschrieben von reunion
Und??
Kann schon sein das es manchmal über die wahrnehmungsgrenze hinausgeht. Trozdem verschafft man sich einen Vorteil indem man die Bildqualität senkt. Und dabei auch noch gegen die vorgaben verstößt.
Es kann bei instabilen, schlecht konditonierten algorithmischen Problemen durchaus vorkommen, das die "Quallität" mit FP32 schlechter ist als mit FX12. Es kommt immer darauf an, was man damit macht, und vorallen, wie man es dann algorithmisch löst.
Auch wenn die hohe Präzision nicht benötigt wird ist nichts dagegen einzuwenden FX12 als Optimierungsmaßnahme zu benutzen. Es ist doch OK, das maximal Mögliche aus dem Chip rauszuholen, und ihn nicht mit überflüssigen Berrechnungen zu belasten.
Demirug
2003-10-11, 18:19:23
Original geschrieben von AlphaTier
Na wenn du schon so fragst ... da fällt mir nur eins ein: Mental-Ray ;)
Dürfte etwas kompliziert werden Mental-Ray als Refrast für DX einzusetzten. ;)
reunion
2003-10-11, 19:40:04
Original geschrieben von AlphaTier
Es kann bei instabilen, schlecht konditonierten algorithmischen Problemen durchaus vorkommen, das die "Quallität" mit FP32 schlechter ist als mit FX12. Es kommt immer darauf an, was man damit macht, und vorallen, wie man es dann algorithmisch löst.
Auch wenn die hohe Präzision nicht benötigt wird ist nichts dagegen einzuwenden FX12 als Optimierungsmaßnahme zu benutzen. Es ist doch OK, das maximal Mögliche aus dem Chip rauszuholen, und ihn nicht mit überflüssigen Berrechnungen zu belasten.
Nein eben nicht !!!!
DX9 schreibt FP16/24 nunmal vor und daran hat sich gefälligst auch NV zu halten!!!!
Man kann sich nicht einfach über einen Standart hinwegsetzten nur weil die eigene Hardware zu langsam ist.
del_4901
2003-10-11, 19:55:03
Original geschrieben von reunion
Nein eben nicht !!!!
DX9 schreibt FP16/24 nunmal vor und daran hat sich gefälligst auch NV zu halten!!!!
Man kann sich nicht einfach über einen Standart hinwegsetzten nur weil die eigene Hardware zu langsam ist.
Wer hat gesagt, das die Karte für DX9 entwickelt wurde? ;) Nvidia wollte mit der FX den OpenGL Markt, (respektive CAD Markt) aufmischen, und 3dLabs ans Bein pissen. Denn da sind sie unangefochtener Spitzenreiter mit der QuadroFX, in dem Segment hat Ati nichts zu melden.
Ok, das Prestigeobj. (die schnellste Spielekarte) ham se nun an Ati verloren, aber damit wird eh keine Kohle gemacht. Der fette Schmott wird mit den Quadros, oder Grakas ala FX5200 gemacht. Und wer hat behauptet das sich Nvidia über DX9 Spezifikationen hinwegsetzt? Das war ne reine Hypothese von Demi. Im OGL-Segment macht NV eh das was sie für richtig halten. Mit DX9 hamse halt den Zonk gezogen, aber das ist so Wurst egal, denn im Unterschied zu Ati macht NV Gewinn. (nicht zu verwechseln mit dem Umsatz).
zeckensack
2003-10-11, 19:55:57
Original geschrieben von AlphaTier
Es kann bei instabilen, schlecht konditonierten algorithmischen Problemen durchaus vorkommen, das die "Quallität" mit FP32 schlechter ist als mit FX12.Nein. Das ist nicht möglich.
FP16 vs FX12 ist ein Grenzfall, FP24 oder gar FP32 ist aber immer genauer als FX12.
del_4901
2003-10-11, 20:14:32
Original geschrieben von zeckensack
Nein. Das ist nicht möglich.
FP16 vs FX12 ist ein Grenzfall, FP24 oder gar FP32 ist aber immer genauer als FX12.
Ok bei FP32 muss man sich schon ziehmlich dumm anstellen damit der Fall eintritt. Mit FP16 als Grenzfall will ich dir auch nicht wiedersprechen. Man kann aber Algrorithmen bauen, wo bei floats sehr sehr große Verstärkungsfaktoren durch Rundung auftreten. Bei int ist das natürlich auch möglich, aber da muss man von Fall zu Fall differenzieren, und sich wie gesagt ziehmlich dumm anstellen.
micki
2003-10-11, 20:23:15
Original geschrieben von Xmas
Dies ist kein Cheat, weil der Programmierer eine Division durch zwei vorsieht und genau das auch bekommt. SHR x, 1 ist nicht "ein billiges Replacement für eine Division durch 2", sondern ist eine Division durch 2. Statt SHR könnte der mnemonische Befehl ja auch IDPT (Integer Division by Power of Two) heißen. Arithmetische Operationen definieren sich nun mal nur durch den Transfer.
Mathematisch gesagt:
Df = Dg, f(x) = g(x) | x € Dg => f = g
es ist ein cheat, weil nicht die divisionseinheit der cpu benutzt wird, dabei wird ja auch der rest in EDX gleich mit berechnet.
eigentlich hast du ja recht, es ist eine division durch 2 mathematisch gesehen, aber technisch ist es keine und nur darum geht es hier. manchen passt es nicht, dass FIX12 anstatt FP32 genutzt wird, selbst wenn der fehler so minimal ist, dass er auch durch leicht unterschiedliche implementationen der ops auftauchen könnten.
fp24 hat sicherlich auch ungenauigkeiten verglichen zu fp32 und fix12 dann auch ein wenig... aber wichtig sind diese nicht, schliesslich spielt man damit und zielt nicht auf atombemombenberechnungen.
MfG
micki
zeckensack
2003-10-11, 20:34:03
Original geschrieben von AlphaTier
Ok bei FP32 muss man sich schon ziehmlich dumm anstellen damit der Fall eintritt. Mit FP16 als Grenzfall will ich dir auch nicht wiedersprechen. Man kann aber Algrorithmen bauen, wo bei floats sehr sehr große Verstärkungsfaktoren durch Rundung auftreten. Bei int ist das natürlich auch möglich, aber da muss man von Fall zu Fall differenzieren, und sich wie gesagt ziehmlich dumm anstellen. :???:
Nochmal, es gibt keine FX12-Zahl, die man nicht präzise und verlustfrei als FP24 darstellen kann. Es gibt keine Operation auf FX12, die man nicht mit mathematisch präziserem Ergebnis auf FP24 ausführen kann.
Das einzige was FX12 an sich hat, sind stärkere Rundungsfehler (1/2:=0). Wenn man Rundungsfehler haben will, dann ist FX12 womöglich besser geeignet, aber warum sollte man das wollen?
Und um den ganzen die Krone aufzusetzen: Integer-artige (ie absolute) Rundungsfehler lassen sich unter Einsatz von zusätzlichen Instruktionen auch mit Fließkommaformaten 'nachbilden', falls gewünscht (floor/frac).
reunion
2003-10-11, 20:41:50
Original geschrieben von AlphaTier
Wer hat gesagt, das die Karte für DX9 entwickelt wurde? ;)
Nvidia ;)
Nvidia wollte mit der FX den OpenGL Markt, (respektive CAD Markt) aufmischen, und 3dLabs ans Bein pissen. Denn da sind sie unangefochtener Spitzenreiter mit der QuadroFX, in dem Segment hat Ati nichts zu melden.
Und??
Etwas OT...
Ok, das Prestigeobj. (die schnellste Spielekarte) ham se nun an Ati verloren, aber damit wird eh keine Kohle gemacht. Der fette Schmott wird mit den Quadros, oder Grakas ala FX5200 gemacht.
Sehe ich nicht so, wer die schnellst Karte baut bekommt auch eine menge gratiswerbung, wodurch sich auch die billigeren Karte besser verkaufen lassen. (So nach dem Motto: "Was ist zurzeit schneller, Geforce oder Radeon??? Radeon. OK. dann kauf ich mir ne Radeon ;))
Und wer hat behauptet das sich Nvidia über DX9 Spezifikationen hinwegsetzt?
Wie erklärst du dir denn sonst die Performancegewinne mit dem 5x.xx Treibern ??? Da würde sicherlich fleisig "optimiert" (z.B.: in Aquanox 2) ;)
Das war ne reine Hypothese von Demi. Im OGL-Segment macht NV eh das was sie für richtig halten. Mit DX9 hamse halt den Zonk gezogen, aber das ist so Wurst egal, denn im Unterschied zu Ati macht NV Gewinn. (nicht zu verwechseln mit dem Umsatz).
Ahhm ...
ATI macht auch Gewinn... (22,xx Mio $ im gerade abgelaufenen Quartal. Bin gespannt wieviel Gewinn NV da gemacht hat ;))
del_4901
2003-10-11, 21:00:44
Original geschrieben von reunion
Nvidia ;)
Und??
Etwas OT...
So OT is das gar nicht, auch da werden Shader zum HW-rendern eingesetzt
Original geschrieben von reunion
Sehe ich nicht so, wer die schnellst Karte baut bekommt auch eine menge gratiswerbung, wodurch sich auch die billigeren Karte besser verkaufen lassen. (So nach dem Motto: "Was ist zurzeit schneller, Geforce oder Radeon??? Radeon. OK. dann kauf ich mir ne Radeon ;))
Wer kauft sich denn schon ne Graka? Das sind wenige, die meißten Leute haben keinen Plan von ihrem rechner, und die bauen da auch nicht rum. Die kaufen sich lieber nen Komplettrechner, und da kaufen die OEMs die Graka, und da interessiert nicht wie schnell die is, sondern wie billig.
Original geschrieben von reunion
Wie erklärst du dir denn sonst die Performancegewinne mit dem 5x.xx Treibern ??? Da würde sicherlich fleisig "optimiert" (z.B.: in Aquanox 2) ;)
Sicherlich tun die Hersteller in letzter Zeit Misst baun, mit ihren Optimierungen, Ati ist da aber auch nicht besser. Da aber die neuen 5x.xx Treiber auch im Shadermark zugelegt ham denke ich schon, das NV die shader umbaut um sie für ihrer Architektur "erträglicher" zu machen. ich will hierbei nochmal betonen, das beim Umbauen vom Shadern es zu keinen Quallitätiven Unterschieden kommt. Die Sache mit AF das is ne Andere Story, und soll hier nicht mit reingehören.
Original geschrieben von reunion
Ahhm ...
ATI macht auch Gewinn... (22,xx Mio $ im gerade abgelaufenen Quartal. Bin gespannt wieviel Gewinn NV da gemacht hat ;))
Na toll, das letzte Quartal sah ganz gut aus für Ati, aber die davor warn scheisse. Nvidia hat schon lange keine Verluste mehr eingesteckt, und im mom. müssten sie bei irgendwas von $30Mio Gewinn sein. Auf's Jahr gerechnet sieht es sogar ganz übel für ATI aus.
edit: http://www.nasdaq.com/asp/extendfund.asp?symbol=ATYT&selected=ATYT&page=full
http://www.nasdaq.com/asp/extendfund.asp?symbol=NVDA&selected=NVDA&page=full
Original geschrieben von micki
es ist ein cheat, weil nicht die divisionseinheit der cpu benutzt wird, dabei wird ja auch der rest in EDX gleich mit berechnet.
eigentlich hast du ja recht, es ist eine division durch 2 mathematisch gesehen, aber technisch ist es keine und nur darum geht es hier.
Doch, es ist auch technisch eine Division durch 2. Der Rest ist in diesem Fall (sowie in fast allen anderen Fällen, in denen in einer High-Level-Sprache eine Division durchgeführt wird) völlig irrelevant. Es gibt keinen "einzig richtigen" Divisionsalgorithmus, jeder Algorithmus der in allen Fällen das erwartete Ergebnis bringt ist richtig.
In PS2.0 gibt es beispielsweise kein DIV, ein "a / b" in HLSL wird durch eine RCP-MUL-Folge ersetzt. Trotzdem ist dies eine völlig korrekte Division.
Original geschrieben von micki
es ist ein cheat, weil nicht die divisionseinheit der cpu benutzt wird, dabei wird ja auch der rest in EDX gleich mit berechnet.Auf den Rest kann aber beim schreiben von
int a=49;
a/=2;
nicht zugegriffen werden, so dass eine Ersetzung mit 'shr 1' (wie schreibt man das nochmal in c?) sicherlich zulässig ist. Inline-ASM wird vom Compiler afaik nicht optimiert.
Crushinator
2003-10-12, 01:20:34
Original geschrieben von aths
(...shr) wie schreibt man das nochmal in c? (...) Mit "<<" nach links und ">>" nach rechts. =)
micki
2003-10-12, 22:55:30
Original geschrieben von Xmas
Doch, es ist auch technisch eine Division durch 2. Der Rest ist in diesem Fall (sowie in fast allen anderen Fällen, in denen in einer High-Level-Sprache eine Division durchgeführt wird) völlig irrelevant. Es gibt keinen "einzig richtigen" Divisionsalgorithmus, jeder Algorithmus der in allen Fällen das erwartete Ergebnis bringt ist richtig.
mathematisch ist es das selbe, technisch nicht, du kannst ja nicht ausschliessen dass eine division grundsätzlich mit der reciproxen multiplikation abgearbeitet wird oder welchen algo die da sonst nutzen. und dass der compiler das wegoptimiert kann auch ein grosser fehler sein, denn es gibt manche leute die einen selbst modifizierenden code schreiben und dine div 2 in div 320 oder änliches ändern.
somit ist shr kein 100%ig richtiger ersatz für div, auch wenn es in vielen fällen ok ist.
Original geschrieben von Xmas
In PS2.0 gibt es beispielsweise kein DIV, ein "a / b" in HLSL wird durch eine RCP-MUL-Folge ersetzt. Trotzdem ist dies eine völlig korrekte Division.
naja, sind zwei befehle, rcp und mul, genau das was ne cpu intern machen könnte oder macht. es ist nicht unbedingt ein shr der da ausgeführt wird.
somit ist das nicht in jedem fall technisch das gleich, nur eben mathematisch...
oder ist für dich rcp-mul das gleiche wie shr?
MfG
micki
Original geschrieben von micki
mathematisch ist es das selbe, technisch nicht, du kannst ja nicht ausschliessen dass eine division grundsätzlich mit der reciproxen multiplikation abgearbeitet wird oder welchen algo die da sonst nutzen. und dass der compiler das wegoptimiert kann auch ein grosser fehler sein, denn es gibt manche leute die einen selbst modifizierenden code schreiben und dine div 2 in div 320 oder änliches ändern.
Sorry, aber in dem Fall liegt der Fehler im Programm, ganz sicher nicht beim Compiler. Keine High-Level-Sprache gibt irgendeine Garantie, dass ein bestimmter Ausdruck in eine bestimmte Folge von Instruktionen gewandelt wird, das würde auch völlig ihrem Zweck widersprechen.
somit ist shr kein 100%ig richtiger ersatz für div, auch wenn es in vielen fällen ok ist.
SHR ist ein 100%ig richtiges Pendant für (int(x) / 2). Deine Annahme dass / in High-Level-Code automatisch DIV bedeutet ist dagegen falsch.
naja, sind zwei befehle, rcp und mul, genau das was ne cpu intern machen könnte oder macht. es ist nicht unbedingt ein shr der da ausgeführt wird.
somit ist das nicht in jedem fall technisch das gleich, nur eben mathematisch...
oder ist für dich rcp-mul das gleiche wie shr?
Nein, das gleiche wie DIV. Das gleiche wie SHR nur im Falle einer Division durch eine Zweierpotenz.
Daran wollte ich nur zeigen dass es völlig abwegig ist bei einem Ausdruck in High-Level-Code davon auszugehen dass er in bestimmte Maschinensprachebefehle übersetzt wird.
Demi, ich hab noch mal nachgedacht und meine jetzt, 1 Bit Abweichung zu tolerieren ist zuviel.
Angenommen, wir haben 128,2. Wenn ich dich richtig verstanden habe, wärst du mit 127 und 129 auch noch glücklich. Damit gibt es bereits eine Spanne von 2 Bit, das ist bald 1%. (Es sollte nicht verwundern, dass ich endlich den 10-10-10-2-er Framebuffer fordere. Am besten noch mit nichtlinearer Werteskalierung. Kann ja via Gamma-LUT zurück gebogen werden.)
Imo wäre ledliglich +-0,5 Bit ok. Aus 128,2 dürfte entweder 128 oder 129 werden.
Der Reference-Rasterizer müsste entweder mit der vorgegebenen Genauigkeit rendern (FP24, FP16) oder, um das "wahre" Bild (möglichst gut angenähert) zu bekommen, gleich mit FP64.
Demirug
2003-10-13, 09:22:32
Original geschrieben von aths
Demi, ich hab noch mal nachgedacht und meine jetzt, 1 Bit Abweichung zu tolerieren ist zuviel.
Angenommen, wir haben 128,2. Wenn ich dich richtig verstanden habe, wärst du mit 127 und 129 auch noch glücklich. Damit gibt es bereits eine Spanne von 2 Bit, das ist bald 1%.
Imo wäre ledliglich +-0,5 Bit ok. Aus 128,2 dürfte entweder 128 oder 129 werden.
Da hast du mich falsch verstanden. Ich sprach von einer maximalen Abweichung von einem Bit (= 1/256 bei 32Bit-RGBA) inkl Rundungsfehler. Um dein Beispiel zu nehmen. 127 für 128,2 wäre mehr als das eine Bit. Vor dem Runden sind das dann deine besagten 0,5 Bit.
Der Reference-Rasterizer müsste entweder mit der vorgegebenen Genauigkeit rendern (FP24, FP16) oder, um das "wahre" Bild (möglichst gut angenähert) zu bekommen, gleich mit FP64.
Ich würde für die Mindestgenauigkeit plädieren.
Jeder Chip darf dann um die oben angesprochenen Toleranz abweichen?
Hauwech
2003-10-13, 09:26:21
Solange die BQ nicht wahrnehmbar beeinflusst und es dadurch schneller wird, ist es mir ziemlich wurscht, ob es ein Cheat oder ein 'Feature' ist.
Original geschrieben von Demirug
Vor dem Runden sind das dann deine besagten 0,5 Bit.Japp, dann sind wir uns in diesem Punkte ja doch einig :)
Original geschrieben von Demirug
Ich würde für die Mindestgenauigkeit plädieren.
Jeder Chip darf dann um die oben angesprochenen Toleranz abweichen? Wenn der Refrast mit 24 Bit FP arbeitet, und der Shader mindestens 24 Bit FP verlangt, wäre es natürlich toll, wenn es keine Abweichungen gäbe. Ausnahme: Durch 24 Bit FP kommt es ggü. 32 Bit FP zu Rundungsfehlern. Wenn die Abweichung aus höherer Genauigkeit resultiert, ist das ok. Das wäre die Hardcore-Linie, die ich eigentlich vertrete. Praktisch wird man wohl mit 1/2 Bit Unsicherheit in der Endgenauigkeit leben müssen, zumal das ja schon durch minimal abweichende Filter-Algorithmen bzw. leicht unterschiedliche Samplepositionen auftreten kann.
micki
2003-10-13, 09:39:17
Original geschrieben von Xmas
Sorry, aber in dem Fall liegt der Fehler im Programm, ganz sicher nicht beim Compiler. Keine High-Level-Sprache gibt irgendeine Garantie, dass ein bestimmter Ausdruck in eine bestimmte Folge von Instruktionen gewandelt wird, das würde auch völlig ihrem Zweck widersprechen.
somit ist es ganz rechtens dass texturen mit fix12 anstatt fp32 berechnet werden, da eine gewisse abweichung sowieso bedacht wird und der compiler im treiber fix12 nutzen kann... juhu, das wäre der beweis, falls du für deine aussage jetzt nicht ein "aber" findest.
gruesse
micki
Original geschrieben von micki
somit ist es ganz rechtens dass texturen mit fix12 anstatt fp32 berechnet werden, da eine gewisse abweichung sowieso bedacht wird und der compiler im treiber fix12 nutzen kann... juhu, das wäre der beweis, falls du für deine aussage jetzt nicht ein "aber" findest.
gruesse
micki
Ich verstehe nicht ganz worauf du hinauswillst. Ich dachte meine Aussage, dass sich eine Operation nur über den Transfer definiert, wäre klar. Mit anderen Worten, wenn das Rechnen mit FX12 identische Ergebnisse zu jenen bringt, die man von FP24+ erwarten kann (oder FP16+ bei _pp), so ist es IMO vollkommen akzeptabel, FX12 zu verwenden.
Etwas anderes liegt vor, wenn die Ergebnisse leicht abweichen, denn in einigen Fällen könnte man einen "Ripple-Effekt" bekommen, wenn die Abweichung systematisch ist. Also beispielsweise ein Farbverlauf mit Banding, obwohl die Abweichung zu FP24 nie größer als 1/256 ist.
zeckensack
2003-10-13, 15:13:12
micki,
float in C ist immer eine Fließkommazahl, und nie ein Integer. Datentypen werden eben doch garantiert.
Das wäre ein schönes "aber", hmm? ;)
Aquaschaf
2003-10-13, 20:08:39
Kommt wirklich ein identisches Resultat heraus, kann es einem eigentlich wirklich egal sein. Aber da mit FX12 nun einmal kein identisches Resultat herauskommt wäre es mir sympathischer wenn derjenige der die Shader schreibt darüber entscheiden kann ob die Ungenauigkeit toleriert werden kann.
Der eigentliche Schuldige ist wohl MS, wäre FX12 als Option in Verbindung mit PS2 erlaubt, bestünde kein Problem und erst recht keine Legitimation seitens NV die Genauigkeit "hinter dem Rücken" der Entwickler zu verändern.
Original geschrieben von Aquaschaf
Kommt wirklich ein identisches Resultat heraus, kann es einem eigentlich wirklich egal sein. Aber da mit FX12 nun einmal kein identisches Resultat herauskommt wäre es mir sympathischer wenn derjenige der die Shader schreibt darüber entscheiden kann ob die Ungenauigkeit toleriert werden kann.
Wie Demirug schon im ersten Posting darlegte ist es in bestimmten Fällen durchaus möglich dass das Resultat vollkommen identisch ist. Eben z.B. beim Multiplizieren oder Addieren von zwei Textursamples (8 Bit pro Kanal vorausgesetzt).
Etwas genauer: Die Addition von zwei Textursamples gibt auch in den Registern dasselbe Ergebnis, die Multiplikation nur wenn das Ergebnis dann in den Framebuffer geschrieben wird.
Aquaschaf
2003-10-13, 20:18:46
Original geschrieben von Xmas
Wie Demirug schon im ersten Posting darlegte ist es in bestimmten Fällen durchaus möglich dass das Resultat vollkommen identisch ist. Eben z.B. beim Multiplizieren oder Addieren von zwei Textursamples (8 Bit pro Kanal vorausgesetzt).
Aber eben nur dann, egal wäre es wenn das Ergebnis immer identisch ist.
Original geschrieben von Aquaschaf
Aber eben nur dann, egal wäre es wenn das Ergebnis immer identisch ist.
Der Treiber kann doch von Fall zu Fall entscheiden, wo ist das Problem?
DrumDub
2003-10-13, 20:32:21
Original geschrieben von Xmas
Der Treiber kann doch von Fall zu Fall entscheiden, wo ist das Problem?
das sollte dann aber ein compiler leisten. sonst ist es für den entwickler wirklich umständlich.
Aquaschaf
2003-10-13, 20:47:20
Original geschrieben von Xmas
Der Treiber kann doch von Fall zu Fall entscheiden, wo ist das Problem?
Ob der Treiber unbedingt im Sinne des Entwicklers entscheidet ist dann vielleicht eine andere Sache.
Original geschrieben von Aquaschaf
Ob der Treiber unbedingt im Sinne des Entwicklers entscheidet ist dann vielleicht eine andere Sache.
Ja, das ist wirklich eine andere Sache.
Habe gerade diese Diskussion gesehen.
Nach meiner Meinung definieren die Spiele-Entwickler die Maßstäbe der Qualität in ihrem eigenen Spiel. Wenn sie Optimierungen machen wollen, warum nicht? Aber DIE sollten es entscheiden und nicht NVidia. Da werden doch auch PS1.1/1.4 und PS2.0 usw. bei einigen aktuellen Spielen angepasst gemischt.
Wenn NVidia nach belieben dies macht oder machen soll und wenns daneben geht, dann noch unverschämt dies als "Bug" bezeichnet, dann wars das für NVidia.
Die ganze Sache mit NVidia, ob sie FX12, FX16 oder FX32 nutzen sollen, erinnert mich an die Zeit von 3DFX. Obwohl die Voodoos nur 16bit (auch hier kaum Qualitätseinbußen feststellbar) nutzten, wurde es von NVidia PR-mäßig ausgenutzt, obwohl deren 32bit nur ein Aushängeschild war.
Deswegen meine Meinung: Es geht hier ums Prinzip! Entweder die nutzen mind. FX16 oder die sollten die FX-Serie nicht mehr als DX9 bewerben. Ich warte nur noch, bis ein Ami ne Klage macht.
Also NVidia: damals hast DU auf 3DFX herumgeritten und nun ist es nix böses, wenn DU ähnliches machst?
Da werden wir User wieder mal an der Nase herumgeführt.
Entschuldigung, aber musste nach den Vorfällen in letzter Zeit raus.
Razor
2003-10-23, 10:29:50
Du hast diese Diskussion offenbar 'gesehen', aber nicht gelesen, oder ?
Oder was hast Du an den Posts der letzten 2 Seiten nicht verstanden ?
:???:
Razor
P.S.: Und es geht hier nicht ums Prinzip, sondern um Performance und trotz 'Eingreifen' des Treibers um gleichbleibende Qualität.
Original geschrieben von Razor
Du hast diese Diskussion offenbar 'gesehen', aber nicht gelesen, oder ?
Oder was hast Du an den Posts der letzten 2 Seiten nicht verstanden ?
:???:
Razor
P.S.: Und es geht hier nicht ums Prinzip, sondern um Performance und trotz 'Eingreifen' des Treibers um gleichbleibende Qualität.
Ich habe es auch gelesen. :)
Wie weit ist gleichbleibende Qualität? Solange man mit dem Auge nicht nicht mehr unterscheiden kann? Ein weit gedehnter Begriff.
Außerdem geht es auch ums Prinzip. Damals hatte NVidia 3DFXs 16bit niedergemacht, obwohl es auch eine gleichbleibende Qualität hatte.
Ich bin für Optimierungen, aber das sollten die Spieleentwickler entscheiden. Dann endet es mit einigen "Bugs" des Treibers. Sonst sollte man es so machen, dass man dann als User selbst per Treiber entscheidet, in wie weit es gehen darf.
Original geschrieben von ow
Mathematisch identisches Ergebnis = gleichbleibende Qualität. Da ist nichts dehnbar.
Scheinst wohl doch nicht alles gelesen zu haben. :)
Ich meine nicht nur im mathematischen Sinne. Den PR-Leuten von den beiden Firmen interessieren doch mathematische Algorithmen, Beweise usw. überhaupt nichts. Den geht es eher nur um Zahlen (Frames). Wie die zustande kommen, ist doch denen im Grunde egal.
Razor
2003-10-25, 23:12:01
Original geschrieben von KM
Ich meine nicht nur im mathematischen Sinne. Den PR-Leuten von den beiden Firmen interessieren doch mathematische Algorithmen, Beweise usw. überhaupt nichts. Den geht es eher nur um Zahlen (Frames). Wie die zustande kommen, ist doch denen im Grunde egal. Weswegen die PR-Leutz ja auch keinen Einfluß auf die Entwicklung haben...
:D
Also noch einmal:
Gleichbleibende Qualität = gleiches Ergebnis
Aber eben mit einem (eigenen, bzw. unterschiedlichen) Weg, der nicht die vorgeschriebene Präzision benutzt, sondern mit einer geringeren (statt fp32 also fp16 oder gar int12) das gleiche Ergebnis erzielt.
Wozu eine Präzision von fp32, wenn man 1+1 rechnet ?
Auch bei int12 belibt das Egebnis 2...
DARUM geht es hier !
Und nicht um das, was irgendwelche PR-Fuzzis von sich geben...
Razor
nggalai
2003-10-25, 23:57:42
Original geschrieben von Razor
Weswegen die PR-Leutz ja auch keinen Einfluß auf die Entwicklung haben...
:D*hust*
http://www.marketingblubber.ch/articles/20030306.htm
*hust*
;)
Aber prinzipiell hast Du schon recht--PR-Leute haben wenig Einfluss auf den Verlauf der Entwicklung. Da ist das Marketing schon eine ganz andere Sache.
93,
-Sascha.rb
Razor
2003-10-26, 00:24:42
Hi nggalai,
Original geschrieben von nggalai
*hust*
http://www.marketingblubber.ch/articles/20030306.htm
*hust*
;)Kenn ich...
;D
Original geschrieben von nggalai
Aber prinzipiell hast Du schon recht--PR-Leute haben wenig Einfluss auf den Verlauf der Entwicklung. Da ist das Marketing schon eine ganz andere Sache.Jo.
Je nachdem welche Befugnisse das Marketing im Unternehmen hat, kann es ganze Produktlinien, -philosophien und -entwicklungen bestimmen. Kommt natürlich dann auch immer auf lokal-Kompetenz an, die bei einer entsprechend befugten Abteilung aber vorhanden sein sollte (sonst ist Fa. schnell pleite ;-).
Razor
Original geschrieben von nggalai
*hust*
http://www.marketingblubber.ch/articles/20030306.htm
*hust*
;)
Danke für den Link. Habe mich köstlich amüsiert. :)
War das dein Artikel? :D :up:
Original geschrieben von Razor
Weswegen die PR-Leutz ja auch keinen Einfluß auf die Entwicklung haben...
:D
Also noch einmal:
Gleichbleibende Qualität = gleiches Ergebnis
Aber eben mit einem (eigenen, bzw. unterschiedlichen) Weg, der nicht die vorgeschriebene Präzision benutzt, sondern mit einer geringeren (statt fp32 also fp16 oder gar int12) das gleiche Ergebnis erzielt.
Wozu eine Präzision von fp32, wenn man 1+1 rechnet ?
Auch bei int12 belibt das Egebnis 2...
DARUM geht es hier !
Und nicht um das, was irgendwelche PR-Fuzzis von sich geben...
Dagegen habe ich ja nichts einzuwenden. Es ist ja auch nichts dagegen einzuwenden, dass man DX7/8-Elemente unter DX9 verwenden darf.
Razor
2003-10-26, 10:41:37
Original geschrieben von KM
Dagegen habe ich ja nichts einzuwenden.
OK, hier verstehen wir uns also...
Original geschrieben von KM
Es ist ja auch nichts dagegen einzuwenden, dass man DX7/8-Elemente unter DX9 verwenden darf.
Natürlich nicht !
Schließlich stellt ein DX-Level ja nur die Obergrenze dar...
Wär' ja schlimm, wenn alle alten Proggi's mit 'ner neuen DX-Version nicht mehr funzen, oder im umgekehrten Fall ein neues Proggi (insbesondere Games) nicht mehr auf alten Karten laufen würde.
DX ist nur ein Techlevel und ich kann nun fröhlich alles von DX1-9 mixen (was in der Praxis wohl auf DX6-9 hinaus läuft ;-).
Also, wogegen gibt es denn jetzt etwas einzuwenden ?
:???:
Razor
Original geschrieben von Razor
OK, hier verstehen wir uns also...
Natürlich nicht !
Schließlich stellt ein DX-Level ja nur die Obergrenze dar...
Wär' ja schlimm, wenn alle alten Proggi's mit 'ner neuen DX-Version nicht mehr funzen, oder im umgekehrten Fall ein neues Proggi (insbesondere Games) nicht mehr auf alten Karten laufen würde.
DX ist nur ein Techlevel und ich kann nun fröhlich alles von DX1-9 mixen (was in der Praxis wohl auf DX6-9 hinaus läuft ;-).
Also, wogegen gibt es denn jetzt etwas einzuwenden ?
:???:
Razor
Mir persönlich ist es egal, ob man int, fp12, fp16, fp24 oder fp32 einsetzt, solange die Qualität nicht sichtbar einbricht.
Bei MS ist unter DX 9 fp16,fp24 und fp32 definiert, unter DX9 darf man auch kleinere DX Versionen benutzen, real bleiben 6-9, in letzter Zeit bei den neuen Spielen eher 7-9.
ATI und NVidia haben sich längst damit abgefunden während wir uns hier die Köpfe einschlagen. :D
Schaut euch folgende Präsentation, die von ATI UND NVidia gemeinsam gemacht worden war:
http://mirror.ati.com/developer/gdc/D3DTutorial1_Shaders.pdf
Das gleiche Dokument auf NVidia:
http://developer.nvidia.com/docs/IO/8230/D3DTutorial1_Shaders.pdf
Lest euch mal die Seiten 70-72 durch!
Die Hersteller haben den Kuchen längst unter sich aufgeteilt.
Razor
2003-10-26, 13:52:31
Original geschrieben von KM
Mir persönlich ist es egal, ob man int, fp12, fp16, fp24 oder fp32 einsetzt, solange die Qualität nicht sichtbar einbricht.
Dann ist ja gut, denn darum geht es in diesem Thread...
Original geschrieben von KM
Bei MS ist unter DX 9 fp16,fp24 und fp32 definiert, unter DX9 darf man auch kleinere DX Versionen benutzen, real bleiben 6-9, in letzter Zeit bei den neuen Spielen eher 7-9.
Jo, ist es...
Und nun zum initialen Post von Demirug.
Wenn nVidia nun eine Berechnung mit undefinierter Präzision durchführen soll, diese dann aber dahingehend optimiert, dass nicht das Minimum fp24 (also fp32 im Falle von nVidia) sondern fp16 oder gar int12 benutzt wird, dabei das Ergebnis aber NICHT verändert...
...ist das nun eine gültige Optimierung, oder nicht ?
DARUM geht es hier, um nichts anderes...
Razor
Original geschrieben von Razor
Dann ist ja gut, denn darum geht es in diesem Thread...
Jo, ist es...
Und nun zum initialen Post von Demirug.
Wenn nVidia nun eine Berechnung mit undefinierter Präzision durchführen soll, diese dann aber dahingehend optimiert, dass nicht das Minimum fp24 (also fp32 im Falle von nVidia) sondern fp16 oder gar int12 benutzt wird, dabei das Ergebnis aber NICHT verändert...
...ist das nun eine gültige Optimierung, oder nicht ?
DARUM geht es hier, um nichts anderes...
Razor
:D
Du kennst schon meine Meinung. Solange das Ergebnis nicht (sichtbar) verfälscht wird, warum nicht?
Ne Frage: Warum machen wir keine Umfrage? Dann würden sich deutlich mehr Personen dazu äußern.
Original geschrieben von ow
Nein, es müssen IMO schon 7-9 sein.
DX6 Funktionen dürften von DX9 nicht mehr unterstützt werden. Hierfür müsste man schon das ganze als DX8 Applikation programmieren.
Da hast du schon recht. DX6/DX7 wird seit längerem nicht mehr als DX6/7 unterstützt. DX8 bzw. DX8.1 ist seit langem Pflicht.
Original geschrieben von ow
Ich bin mir nicht sicher, ob wir dasselbe meinen.
Bei den Grafiktreibern sieht das so aus:
Ein Treiber, der für DX5 geschrieben wurde, wird nur bis einschlieslich DX7 überhaupt als HW-Device erkannt.
Ein DX6 Treiber funzt bis zur DX8 runtime, und um unter DX9 noch als HW-Device erkannt zu werden, muss der Treiber min. nach DX7 programmiert sein.
Im Umkehrschluss folgere ich daraus, dass man, wenn man das DX9 SDK zur Entwicklung nutzt, dabei keine DX6 Funktionen mehr nutzen kann sondern auf min. DX7-Funktionen angewiesen ist.
Aus dieser Sicht habe ich es nicht betrachtet, aber ich stimme schon zu.
Genau genommen gilt: Wer D3D9-Funktionen nutzen will, darf nur D3D9-Funktionen verwenden. Natürlich hat D3D9 eine ganze Menge Funktionalität von D3D8 geerbt, aber das ist keine Garantie, dass man alle Möglichkeiten von D3D8/7/6/... mit D3D9 nutzen kann, oder dass die Implementierung identisch ist. Ein paar Features von D3D7/8 sind in D3D9 nicht mehr zugänglich.
Welche sind das z.B.? Afaik flog mit DX8 Chroma Keying raus. Was haben sie jetzt bei DX9 schon wieder wegrationalisiert?
reunion
2003-10-31, 15:51:03
Original geschrieben von Razor
Dann ist ja gut, denn darum geht es in diesem Thread...
Jo, ist es...
Und nun zum initialen Post von Demirug.
Wenn nVidia nun eine Berechnung mit undefinierter Präzision durchführen soll, diese dann aber dahingehend optimiert, dass nicht das Minimum fp24 (also fp32 im Falle von nVidia) sondern fp16 oder gar int12 benutzt wird, dabei das Ergebnis aber NICHT verändert...
...ist das nun eine gültige Optimierung, oder nicht ?
DARUM geht es hier, um nichts anderes...
Razor
Und genau das ist eindeutig ein CHEAT!
M$ hat eindeutig definiert das bei nicht extra optimierten Shadern MINDESTENS(!) FP24 eingesetzt werden MUSS!
UND DARAN HAT SICH AUCH NV ZU HALTEN!
INT12 hat bei PS2.0 Shadern schon überhaupt nichts verloren und FP16 darf auch nur eingesetzt werden wenn der Spieleprogrammiere(!) und nicht die NV Treiberprogrammierer die Qualität herabsetzten!
Und außerdem wer garantiert dir das man den unterschied nicht sieht??? NV wird einfach überall wo man gegen ATI nichts ausrichten kann, die genauigkeit senken egal ob mit oder ohne Bildqualitätsverlust(oder tut es schon längst?)
Und ja, es geht ums Prinzip, die Definitionen sind da, um eingehalten zu werden! Ist im grunde genau wie bei NVs Filteroptimierung, kann schon sein das man den Unterschied meistens kaum wahrnimmt, ABER DIE BILDQUALITÄT WIRD TROZDEM GESENKT!
Und beides ist klar ein CHEAT!
mfg
reu
Original geschrieben von reunion
Und genau das ist eindeutig ein CHEAT!
M$ hat eindeutig definiert das bei nicht extra optimierten Shadern MINDESTENS(!) FP24 eingesetzt werden MUSS!
UND DARAN HAT SICH AUCH NV ZU HALTEN!Wenn das Ergebnis am Ende so genau ist, als hätte man mit FP24 gerechnet, ist alles in Ordnung. Die Addition von zwei Texturen wird mit FP24 nunmal nicht genauer, als mit FX12.
Das Problem liegt darin, dass NV hier und da anklingen lässt, dass sie durchaus leichte BQ-Einbußen für akzeptabel halten. Man kann leichte BQ-Einbußen nur schwer nachweisen. Wogegen sollte man testen? Gegen den REF, der mit FP32 rendert? Gegen R300, der beim LOD "nur" 5 Nachkomma-Bits berücksichtigt? (Reicht für die Praxis aus, das Differenzbild würde trotzdem Unterschiede zeigen.)
Shader-Replacement für Benchmarks halte ich btw. für Cheating, völlig egal ob das Endergebnis gleich ist oder nicht. Nicht für Cheating halte ich eine generelle Optimierung des Shaders durch den Treiber, wenn diese Optimierung wie gesagt allgemeingültig und nicht benchmarkspezifisch ist, und das korrekte Ergebnis liefert.
Doch sehen wir der Wahrheit ins Auge: Nvidia hat schon immer gecheatet, cheatet, und wird weiter cheaten. Ebenso hat ATI schon immer gecheatet, cheatet, und wird weiter cheaten. Praktisch jede Verschnellerung eines bestimmten Benchmarks / Spieles ist auf anwendungsspezifische "Optimierung" zurückzuführen. Von generellen Treiber-Optimierungen würden beinahe alle Spiele profitieren, was jedoch äußerst selten ist. Ohne Beweise dafür zu haben behaupte ich, dass ATI z.B. den 3DMark erkennt, und spezielle Treibereinstellungen setzt. Würde ich an ATIs Stelle auch machen. Das muss gar nicht mal zwangsläufig die BQ senken, nur wird hier über einen Benchmark eine Leistungssteigerung vorgegaukelt, die praktisch nicht vorhanden ist. Zumindest moralisch ein Cheat.
Deshalb btw ein Hoch auf Leo, der nicht mit "Benchmarks" testet, sondern Spiele bencht, und zwar nicht nur Quake3 und UT. Innerhalb einer Hardware-Linie gehören die 3DCenter-Benches imo zu den wertvollsten, die man im Web finden kann, auch deshalb, weil Leo mit Argusaugen die Bildqualität kontrolliert.
Demirug
2003-10-31, 16:44:22
Original geschrieben von aths
Das Problem liegt darin, dass NV hier und da anklingen lässt, dass sie durchaus leichte BQ-Einbußen für akzeptabel halten.
Ja, vorallem da sie leicht nicht näher definiert haben.
reunion
2003-10-31, 16:57:58
Original geschrieben von aths
Wenn das Ergebnis am Ende so genau ist, als hätte man mit FP24 gerechnet, ist alles in Ordnung. Die Addition von zwei Texturen wird mit FP24 nunmal nicht genauer, als mit FX12.
Und genau da bin ich anderer meinung!
M$ verlangt FP24 bei nicht extra optimierten Shadern und da NV die FX Karten als DX9 Karten bewirbt, haben sie sich daran auch IMMER(!) zu halten. Denn für was mach ich denn Definitionen die dann eh nicht eingehalten werden???
Und auch FP16 darf nur von Spielprogrammiere verwendet werden!
Fazit: Bewußtes herabsetzten der Genauigkeit und damit verstoß gegen die DX9 Specs um mehr leistung herauszuschinden und zusätzlich auch noch teilweise herabsetzten der Bildqualität --> CHEAT!
Original geschrieben von reunion
Und genau da bin ich anderer meinung!
M$ verlangt FP24 bei nicht extra optimierten Shadern und da NV die FX Karten als DX9 Karten bewirbt, haben sie sich daran auch IMMER(!) zu halten. Denn für was mach ich denn Definitionen die dann eh nicht eingehalten werden???
Und auch FP16 darf nur von Spielprogrammiere verwendet werden!
Fazit: Bewußtes herabsetzten der Genauigkeit und damit verstoß gegen die DX9 Specs um mehr leistung herauszuschinden und zusätzlich auch noch teilweise herabsetzten der Bildqualität --> CHEAT! Herabsetzen der Bildqualität ist ein Cheat, da gehe ich mit. Bleibt Verringerung der Rechen-Genauigkeit, wenn das Ergebnis um weniger als +- 1/2 Bit vom "echten" Ergebnis abweicht.
Am Ende wird die Farbe ohnehin auf 8:8:8 (RGB) gerundet. Ob man nun z.B. für Rot "127,4" oder "127,2" ausrechnet, ist Jacke wie Hose, in den Framebuffer wird "127" geschrieben. Wenn nun durch Verringerung der Genauigkeit "127,8" ausgerechnet wird, und in den Framebuffer "128" geschrieben wird, liegt das praktisch innerhalb eines Bitrauschens, welches vernachlässigbar ist. +- 1/2 Bit Ungenauigkeit (und mehr) kann sowieso auftreten. Beispiel: ATI rechnet mit FP24 bei Texturkoordinaten. NVidia kann mit 32 Bit rechnen, und demzufolgen genauer samplen. Auch dadurch können leichte Unterschiede entstehen. +- 0,5 Bit "Rauschen" im Ergebnis als zulässig zu definieren, da kommt man praktisch gar nicht drum herum. Zumal beim Runden vor dem Framebuffer-Schreibzugriff die Farbe ohnehin um bis zu 0,5 Bit "verfälscht" werden muss. Das sind 0,2% auf die Gesamtgenauigkeit. Durch ATIs LOD mit "nur" 5 Nachkommabits können Abweichungen von der "echten" Farbe in ungünstigen Fällen größer werden als 0,2%.
Wenn man jetzt zwei Texturen addiert und das in den Framebuffer schreibt, ist das mit FX12 (also Integer) bereits völlig genau. Es macht hier keinen Sinn, FP16 oder FP32 zu nehmen, wenn das länger dauert, das Ergebnis aber nicht genauer wird.
Angenommen durch das Verwenden von FP16 statt FP32 (weil FP24 gefordert wird) ist das Ergebnis um +- 0,5 Bit ungenau. Warum sollte man diese Genauigkeit beim Shader fordern, wenn bereits beim Sampling bzw. beim Framebuffer-Schreibzugriff solche Ungenauigkeiten auftreten können, dass diese Shader-Ungenauigkeit in diesem "Fehler-Rauschen" praktisch untergeht?
reunion
2003-10-31, 17:13:07
Original geschrieben von aths
Herabsetzen der Bildqualität ist ein Cheat, soweit gehe ich mit. Bleibt Verringerung der Rechen-Genauigkeit, wenn das Ergebnis um weniger als +- 1/2 Bit vom "echten" Ergebnis abweicht.
Am Ende wird die Farbe ohnehin auf 8:8:8 (RGB) gerundet. Ob man nun z.B. für Rot "127,4" oder "127,2" ausrechnet, ist Jacke wie Hose, in den Framebuffer wird "127" geschrieben. Wenn nun durch Verringerung der Genauigkeit "127,8" ausgerechnet wird, und in den Framebuffer "128" geschrieben wird, liegt das praktisch innerhalb eines Bitrauschens, welches vernachlässigbar ist. +- 1/2 Bit Genauigkeit kann sowieso auftreten. Beispiel: ATI rechnet mit FP24 bei Texturkoordinaten. NVidia kann mit 32 Bit rechnen, und demzufolgen genauer samplen. Auch dadurch können leichte Unterschiede entstehen. +- 0,5 Bit "Rauschen" im Ergebnis als zulässig zu definieren, da kommt man praktisch gar nicht drum herum. Zumal beim Runden vor dem Framebuffer-Schreibzugriff die Farbe ohnehin um bis zu 0,5 Bit "verfälscht" werden muss.
Wenn man jetzt zwei Texturen addiert und das in den Framebuffer schreibt, ist das mit FX12 (also Integer) am genauesten. Es macht hier keinen Sinn, FP16 oder FP32 zu nehmen, wenn das länger dauert, das Ergebnis aber nicht genauer wird.
Das ist mir durchaus bewusst, doch:
1.)Weißt du nicht ob NV nicht auch bei Shadern wo man sehrwohl einen Unterschied sieht die Genauigkeit senkt.
2.)Verstöß NV damit gegen die DX9 Spezifikationen.
3.)Geht es hier ums Prinzip, es ist einfach nicht erlaubt!
Original geschrieben von reunion
Das ist mir durchaus bewusst, doch:
1.)Weißt du nicht ob NV nicht auch bei Shadern wo man sehrwohl einen Unterschied sieht die Genauigkeit senkt.
2.)Verstöß NV damit gegen die DX9 Spezifikationen.
3.)Geht es hier ums Prinzip, es ist einfach nicht erlaubt! Ein mal noch :) Danach hilft ein reines Wiederholen der Argumente kaum weiter, wir müssten uns langsam einigen, welche Argumente durch andere "überboten" werden.
Original geschrieben von reunion
1.)Weißt du nicht ob NV nicht auch bei Shadern wo man sehrwohl einen Unterschied sieht die Genauigkeit senkt.Dann handelt es sich um Cheating, das ist klar.
Original geschrieben von reunion
2.)Verstöß NV damit gegen die DX9 Spezifikationen.MS' Forderung nach 24 Bit FP ist das eine Forderung an die Genauigkeit. Wenn NV die mit FP16 oder FX12 auch bringen kann, ist alles in Butter. Es gibt bestimmte Fälle, wo das möglich ist. Warum sollte Nvidia dann rendundante Rechenschritte vornehmen, wenn das Ergebnis doch nicht besser wird?
Original geschrieben von reunion
3.)Geht es hier ums Prinzip, es ist einfach nicht erlaubt!Warum sollte eine allgemeingültige Optimierung nicht erlaubt sein, wenn sich am Ergebnis nichts ändert?
Ein analoges Beispiel: Angenommen, du sollst Geldbeträge addieren und am Ende auf einen glatten Euro runden. Wenn du nun siehst, dass einige Beträge bereits runde Euro-Summen sind, ohne Cent-Anteile, und du addierst hier nur die Euros anstatt im Nachkomma-Anteil noch 0+0 zu rechnen, ist das Cheating?
Diese Frage stünde auch noch offen:
Original geschrieben von aths
Warum sollte man diese Genauigkeit beim Shader fordern, wenn bereits beim Sampling bzw. beim Framebuffer-Schreibzugriff solche Ungenauigkeiten auftreten können, dass diese Shader-Ungenauigkeit in diesem "Fehler-Rauschen" praktisch untergeht?
Original geschrieben von reunion
Und genau das ist eindeutig ein CHEAT!
M$ hat eindeutig definiert das bei nicht extra optimierten Shadern MINDESTENS(!) FP24 eingesetzt werden MUSS!
UND DARAN HAT SICH AUCH NV ZU HALTEN!
INT12 hat bei PS2.0 Shadern schon überhaupt nichts verloren und FP16 darf auch nur eingesetzt werden wenn der Spieleprogrammiere(!) und nicht die NV Treiberprogrammierer die Qualität herabsetzten!
Du sagst es indirekt selber. Wenn man PS/VS 2.0 benutzt, sollte man sich an Spezifikationen halten. Aber es spricht nichts dagegen unter DX9 PS/VS <2.0 zu benutzen.
Außerdem wird nichts anderes mit Compilern gemacht. Jede Version wird an die entsprechende Hardware optimiert, um bei gleichbleibendem Ergebnis schneller zu werden.
Und außerdem wer garantiert dir das man den unterschied nicht sieht??? NV wird einfach überall wo man gegen ATI nichts ausrichten kann, die genauigkeit senken egal ob mit oder ohne Bildqualitätsverlust(oder tut es schon längst?)
Da macht NVidia selber einen Fehler. Man sollte dies dem User entscheiden lassen, ob er Qualität oder Quantität haben möchte. Im Moment ist NVidia aus meiner Sicht mit deren Arroganz auf dem Holzweg.
Und ja, es geht ums Prinzip, die Definitionen sind da, um eingehalten zu werden! Ist im grunde genau wie bei NVs Filteroptimierung, kann schon sein das man den Unterschied meistens kaum wahrnimmt, ABER DIE BILDQUALITÄT WIRD TROZDEM GESENKT!
Und beides ist klar ein CHEAT!
Aus meiner Sicht geht es darin deswegen Prinzip, weil NVidia damals nur mit PR-Argumenten 3DFX fertig gemacht hatte. Genauso könnte man die damaligen PR-Argumente leicht abgewandelt heute gegen NVidia selbst anwenden.
Ein einfaches Beispiel (symbolisch!):
i:integer;
for i=1 to 10000 step 1;
j:fp16; (oder fp32)
for j=1 to 10000 step 1;
Die 1. Schleife läuft bedeutend schneller als die 2. und dennoch erfüllen die den gleichen Zweck.
Original geschrieben von Demirug
Ja, vorallem da sie leicht nicht näher definiert haben.
Das gleiche ist ähnlich mit verlustbehafteten Algorithmen. Da werden eine Menge Neu-Algorithmen hochgelobt mit starker Kompression bei kaum Unterschieden, aber in der Praxis sind die meist :down:
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.