FP24 doch zuwenig?

[Demirug]

Das FP24 Format hat ja bekanntermassen als s16e7 aufgebaut. Es stehen also 16 Bit zum adressieren von Texturen zur Verfügung. Die R300 Chips können maximal 2K texturen nutzen. Zum pixelgenauen addressieren sind dafür 11 Bits notwendig. Bleiben also noch 5 Bit für das lineare Texturfiltern. Das entspricht 32 Zwischenstufen. Nicht perfekt aber eigentlich genug für unsere Augen. Soweit so gut.

Setzt man nun Dependent Textur Reads ein werden die Texturkoordinaten ja vor dem auslesen in der Regel noch verrechnet. Eine beliebte Sache dabei ist das Berechnen einer Umgebungsreflektion. Dazu muss ein Augenvektor normalisiert werden und dann an der Normalen des Pixels reflektiert werden. Die Normale kann entweder ebenfalls interpoliert und normalisiert werden oder aus einer Bumpmap stammen. Das ist hier aber nebensächlich.

Beim Rechnen entstehen ja zwangsläufig Rechenfehler. Eine der Theorien dazu sagt aus das sich bei jedem Rechenschritt sich der Fehler um bis zu einem halbes Bit der Mantisse erhöhen kann. Für das Normalisieren sind 5 Schritte notwendig. Die Reflektion besteht ebenfalls aus 5 Schritten. Das sind 10 Schritte oder 5 Bits. Dazu kommt noch ein halbes Bit das man von Anfang an bei Fliesspunktzahlen sowieso immer hat.

Von den 16 Bit blieben also noch der Berechung nur noch 10,5 übrig. Das reicht gerade noch so um annähernd genau ein Pixel in einer 2K textur zu treffen. Für Zwischenstufen beim Filtern ist dann nichts mehr übrig. Da aber denoch die zusätzlichen Bits im Speicherformat vorhanden sind, wird eben irgendwas gefiltert. Resultat: Leichtes Pixelflimmern wenn sich ein Objekt langsam über das Bild bewegt und eine grosse Cubemap als Refelektionsquelle benutzt.

[Coda]

Hm hab ich was falsch verstanden? Was hat denn das Filtering mit dem Registerinhalt zu tun...
Dann würde ein Integer Lookup ja generell graußam aussehen ?!?

Außerdem ist das mit den Berechnungen etwas arg über einen Kamm geschert

[Demirug]

Original geschrieben von Coda
Hm hab ich was falsch verstanden? Was hat denn das Filtering mit dem Registerinhalt zu tun...
Dann würde ein Integer Lookup ja generell graußam aussehen ?!?

Als Ergebniss von den Berechungen ergibt sich die Texturkoordinate für den Lookup. Sind dort zu viele Bits in der Mantisse aufgrund von Rundungs-/ Rechenfehler verloren gegangen kann das Filtern nicht mehr genau durchgeführt werden. Auf einem Standbild merkt man das allerdings nicht wirklich es macht sich durch ein mehr oder weniger starkes Flimmern bei Bewegungen bemerkbar.

Wenn du mir jetzt noch sagst was du mit einem Integer Lookup meinst?

Außerdem ist das mit den Berechnungen etwas arg über einen Kamm geschert

Es ist ein übliches Theorem Rundungsfehler bei Kettenrechungen aufzusummieren. Bei CPUs hat man damit allerdings weit weniger Probleme weil diese Intern ja um ein vielfaches genauer Rechnen als das Ergebniss am Ende gespeichert wird. Eine GPU speichert aber nach jedem Schrit den Wert zurück in ein Register was erneut Rundungsfehler verursacht.

[Coda]

Wenn du mir jetzt noch sagst was du mit einem Integer Lookup meinst?
Gab es in DX8 noch keine dependent texture reads?

Eigentlich dürfte das doch relativ einfach nachzuprüfen sein... Muss ich mal ausprobieren

[Demirug]

Original geschrieben von Coda
Gab es in DX8 noch keine dependent texture reads?

Eigentlich dürfte das doch relativ einfach nachzuprüfen sein... Muss ich mal ausprobieren

Ja, bei den 1.X Shader gibt es auch schon Dependet Reads. Allerdings rechnet nVidia die Texturkoordinaten dafür auch schon mit FP32.

ATI benutzt ein 16 Bit Format (anders als FP16) für alles. Gerade bei der Reflektionsberechung mit R2XX Chips kommt es da immer mal wieder zu leichten Artefakten. Da man diese aber meist in Verbindung mit einer kleinen Cubemap sowie einer Bumpmap zur Streung einsetzt fällt es nicht so sehr auf.

[micki]

es gibt zwar leichte artefackte, aber ob es zuwenig ist muss dann jeder selbst entscheiden, wenn ich einen cone (vom spotlight mit scharfen kanten) berechne, schaut es auch leicht zackig aus auf fp24, auf fp16 der 5600 ist es schon leicht grausam und auf fp32 der 5900 ist es wiederum sehr sauber.

ich weiß auch nicht ob man es so gelten lassen kann, dass es bei den operationen immer nen halben bit fehler gibt. bei int ist das eindeutig, aber bei float kann man das nicht genau sagen. das kommt doch sicherlich auf den exponenten der zu verrechneten zahlen an.

1e+30 + 1e-30, da wäre der fehler die vollen fp24 würde ich sagen.
oder wie genau meinst du das mit dem bitfehler bei float?

MfG
micki

[Haarmann]

Demirug

Saudumme Frage dazu - wieviele Spiele setzen denn 2k Texturen ein? Oder anders gefragt - gibts sowas schon? Ist das überhaupt nötig oder sollte man so grosse Texturen nicht eh klugerweise "schneiden"?

[Coda]

schneiden geht bei cubemaps nicht, außer du verwendest dynamische branches und die hat die R3xx nicht ;)

Naja ich hoffe mal ATi bringt mit dem R420 auch FP32 auf den Markt. Für den Zeitpunkt der R3xx war FP24 sicherlich ausreichend.

[Demirug]

Original geschrieben von Haarmann
Demirug

Saudumme Frage dazu - wieviele Spiele setzen denn 2k Texturen ein? Oder anders gefragt - gibts sowas schon? Ist das überhaupt nötig oder sollte man so grosse Texturen nicht eh klugerweise "schneiden"?

Texturen schneiden ist immer eine schlechte Idee weil es egal wie man es macht zusätzlich Leistungs kostet. Wenn es überhaupt geht.

[aths]

Original geschrieben von Coda
Naja ich hoffe mal ATi bringt mit dem R420 auch FP32 auf den Markt. Für den Zeitpunkt der R3xx war FP24 sicherlich ausreichend. Afaik reicht FP24 noch für PS_3_0, woraus ich mal messerscharf schließe, dass es ATI bei der R4xx-Generation bei FP24 belässt.

[Demirug]

Original geschrieben von Coda
Naja ich hoffe mal ATi bringt mit dem R420 auch FP32 auf den Markt. Für den Zeitpunkt der R3xx war FP24 sicherlich ausreichend.

Hoffen wir das nicht alle?

Für normale Anwendungsfälle reicht es wohl noch aus. Bringt man die Chips aber an ihr limit wird es doch sehr Grenzwertig.

[mapel110]

Original geschrieben von aths
Afaik reicht FP24 noch für PS_3_0, woraus ich mal messerscharf schließe, dass es ATI bei der R4xx-Generation bei FP24 belässt.

sollte man dann nicht eher sagen, dass fp24 noch solange ausreicht, wie 2048er texturen keine verbreitung finden?

[aths]

Original geschrieben von mapel110
sollte man dann nicht eher sagen, dass fp24 noch solange ausreicht, wie 2048er texturen keine verbreitung finden? 2048-er Texturen sind generell grenzwertig, wenn man FP24-Genauigkeit hat. Kommen vorher noch solche Rechnungen à la Demirugs Posting dazu, gelangen die Ungenauigkeits-Artefakte offenbar in den sichtbaren Bereich. Kleinere Texturen zu nehmen, kann erst mal helfen. Nun sind ATIs Texturfilter ja auch nicht so das wahre... da es imo wenig Sinn macht, hier die Genauigkeit zu erhöhen, sie da aber zu belassen, müsste ATI imo entweder einen "pixel perfect" :kicher: Chip entwickelt haben, oder weiterhin auf FP24 setzen. Betrachtet man nun, dass FP32 immerhin eine 23-Bit-Mantisse hat, ist das grob über den Daumen gepeilt 50% mehr als FP24 mit der 16-Bit-Mantisse. Imo könnte man in erster Näherung ansetzen, dass FP32-Einheiten fast 50% komplexer (größer) sind, als FP24-Einheiten.

[bendel]

Tja, so kann man Leute verunsichern. Demirugs Fehlerrechnung ist aber fehlerhaft. 10 Mal ein halbes Bit Fehler sind nunmal nicht 5 Bit Fehler sondern 3 und ein bischen (10*0,5 = 5 und das in der Binärdarstellung 101). Man sollte ja die Summe der prozentualen Fehler zusammen rechnen (je nach verwendeter Operation kann das natürlich auch mal anders sein, wenn man es genau nimmt). Nach der hier vorgestellten Methode könnte man auch mit doubles keine Rechnungen mit mehr als 100 Schritten machen, da der Fehler immer zu groß wäre.

[Exxtreme]

Original geschrieben von Haarmann
Demirug

Saudumme Frage dazu - wieviele Spiele setzen denn 2k Texturen ein? Oder anders gefragt - gibts sowas schon? Ist das überhaupt nötig oder sollte man so grosse Texturen nicht eh klugerweise "schneiden"?
Eine andere Einschränkung ist, daß kaum einer die 2048'er Auflösung fährt. :) Somit kriegen die wenigsten Leute eine 2048'er Textur überhaupt zu Gesicht. Das wird nämlich durch das LOD-Bias-System verhindert.

[micki]

Original geschrieben von Exxtreme
Eine andere Einschränkung ist, daß kaum einer die 2048'er Auflösung fährt. :) Somit kriegen die wenigsten Leute eine 2048'er Textur überhaupt zu Gesicht. Das wird nämlich durch das LOD-Bias-System verhindert.

es gibt einige spiele(engines) die mehrere texturen in eine texturpage stecken, dort hast du dann vielleicht 16 512*512 texturen in einer 2048*2048 und siehst sehr wohl die höchstauflösende stufe.
für objectspace bumpmapping sind hochauflösende texturen ebenfalls nötig, weil es da 1. viel verschnitt gibt und 2.bei groberer auflösung etwas sehr verpixelt aussehen kann (erkennt man stärker als auf normalen texturen, weil die bumpmap nur die luminanz beeinflusst und das auge das am meißten regestriert.)

ein problem was noch auftauchen kann, ist bei textur wrapping denk ich mir, wenn man ein paar mal durch ist, dann schaut es aus wie mit POINTFILTER (GL_NEAREST). wrapping kann man gut für eine detailmap auf einem terrain verwenden... hab ich aber noch nicht getestet.

MfG
micki

[R300]

UT 2003 verwendert doch einige 2K Texturen.
z.B. der riesige Mond bei DM-Plunge ist eine 2K Textur.

Original geschrieben von Exxtreme
Eine andere Einschränkung ist, daß kaum einer die 2048'er Auflösung fährt. :) Somit kriegen die wenigsten Leute eine 2048'er Textur überhaupt zu Gesicht. Das wird nämlich durch das LOD-Bias-System verhindert.

Wenn man ganz nah an die Textur rankommt, sieht man auch bei der 1024er Auflösing ein starken Unterschied zwischen 1K und 2K Texturen.
Die Texturen im Spiel sind ja nicht immer nur maximal so groß wie der Bilschirm. ;)

[Mr. Lolman]

Original geschrieben von R300
UT 2003 verwendert doch einige 2K Texturen.
z.B. der riesige Mond bei DM-Plunge ist eine 2K Textur.



Wenn man ganz nah an die Textur rankommt, sieht man auch bei der 1024er Auflösing ein starken Unterschied zwischen 1K und 2K Texturen.
Die Texturen im Spiel sind ja nicht immer nur maximal so groß wie der Bilschirm. ;)

Demi meinte aber, in seiner (falschen?) Rechnung, dass bei 2048² Cubemaps, die Genauigkeit nicht mehr auseichen könnte, und nicht dass die ATi generell bei 2048² Texturen ein Problem hat.

Nur sollte man bedenken, dass bei UT2003 die meisten Cubemaps in einer Auflösung von 128² vorhanden sind. Ein paar 256er und eine 512er Cubemap gibts auch.

Die 512er Cubemap wirkt allerdings wieder ziemlich unscharf, genauso wie der tolle 2048er Mond, wo ein ungezoomter(!!!) Ausschnitt eines relativ scharfen Bereichs der Textur (der Crap wird zum Rand hin immer unschärfer ?-)) so aussieht:

http://www.ystart.net/upload/20040113/1074020229.jpg


Muss man sich jetzt wirklich Gedanken über FP24 machen, oder eher über die Fähigkeiten mancher Gamedesigner :???:

[aths]

Original geschrieben von Mr. Lolman
Muss man sich jetzt wirklich Gedanken über FP24 machen, oder eher über die Fähigkeiten mancher Gamedesigner :???: Das ist eng verknüpft. Nimmt man Rücksicht auf FP24, kann man wohl die meisten Klippen erfolgreich umschiffen. FP32 hat "40% mehr Genauigkeit", die Werte können ggü. FP24 128 immerhin mal feiner abgestuft werden, ehe es da du Artefakten kommt...

[Haarmann]

Wird hier eigentlich nur addiert oder hats auch Multiplikationen dabei Demirug? Jede Multiplikation schmeisst Deine Rechnung nämlich wieder übern Hauffen...

[Demirug]

Original geschrieben von Haarmann
Wird hier eigentlich nur addiert oder hats auch Multiplikationen dabei Demirug? Jede Multiplikation schmeisst Deine Rechnung nämlich wieder übern Hauffen...

Natürlich wird da auch Multipliziert. Die Multiplikation mit 2 habe ich aber gar nicht mitgezählt weil 2 ja zu den zahlen gehört die man exakt darstellen kann und daher keinen zusätzlichen Fehler.

Ansonsten pflanzt sich der Worst-Case Fehler bei einer Multiplikation genauso fort.

Ich habe das ganze auch mal simuliert indem ich alle Zwischenergebnisse bei der Berechung immer wieder auf FP24 begrenzt habe. Bei 32 Bit gab es eine schöne lineare Kurve als Ergebniss. Bei FP24 gab es leichte Sprünge im Bereich von etwa einem halben Pixel. Man muss dafür natürlich auf den Randbereich (Texturkoordinate nahe der 1)der 2K Textur zielen. Ich werden mit den Messreihen (FP16, FP24, FP32) mal eine Grafik machen und posten.

PS: Übrigens gibt nVidia die Reflektionsberechung auch mit einem Worst-Case Verlust von 5 Bit an. Deswegen soll man dafür auch kein FP16 benutzten.

[Haarmann]

Demirug

16 Bit Mantisse mal 16 Bit Mantisse z.B. ergeben ne 31er oder 32er Mantisse, die dann wieder auf 16 Bit reduziert wird. Das heisst die Fehlerbit schiebst gleich hinten mit raus. Es bleibt also maximal der Fehler, den de eh schon hattest. Ich denke das leuchtet ein...

Ansonsten gilt auch, dass beim Additiven Worstcase immer auf oder abgerundet werden musste, was auch nur ne Chance von 1 zu 1024 hat in Deinem Fall. Damit kann man sehr gut leben.

[Xmas]

Original geschrieben von Haarmann
16 Bit Mantisse mal 16 Bit Mantisse z.B. ergeben ne 31er oder 32er Mantisse, die dann wieder auf 16 Bit reduziert wird. Das heisst die Fehlerbit schiebst gleich hinten mit raus. Es bleibt also maximal der Fehler, den de eh schon hattest. Ich denke das leuchtet ein...
Aber nur wenn du mit einer Konstante multiplizierst, die Vielfaches von 2 ist. Ist sie nicht Vielfaches von 2, wird die Darstellung ungenau. Und wenn es keine Konstante sondern ein anderes Rechenergebnis ist:
Stell dir mal vor du willst eigentlich 1 * 1 rechnen, aber wegen dem vorherigen Fehler rechnest du 1,01 * 1,01.

[Haarmann]

Xmas

Bei nem Vielfachen von 2 ändert sich auch nur der Exponent... Das is mir also auch klar.

Sagen wir mal Du willst 1 * 1 rechnen und rechnest 1.01 mal 1.01 = 1.0201. Nun schneide ich das Ganze wieder auf 1.02, damit ich die gleiche Genauigkeit hab. Die Fehlerzunahme hat also abgenommen. Der neue Fehler ist also kleiner, denn die Summe der Fehler vorher war.

[Xmas]

Das musst du mir mal erklären, inwiefern 0.02 kleiner als 2* 0.01 ist...

[Haarmann]

1 Zu 1.01 sind nicht 1.01 zu 1.02 -> rel. Fehler nimmt ab.

[Demirug]

Original geschrieben von Haarmann
1 Zu 1.01 sind nicht 1.01 zu 1.02 -> rel. Fehler nimmt ab.

So darfst du hier aber nicht rechnen. Die Mantisse wird ja binär gespeichert. Also muss man den rel. Fehler auch in der binären Mantisse untersuchen.

Machen wir mal ein böses Beispiel. Nehmen wir mal eine 2 Bit Mantisse damit die Zahlen nicht so unhandlich werden.

Aufgabe: 1,875^2 und 1,875^3 berechnen.

1,875 ist ein Wert der sich mit einer 3 Bit Mantisse korrekt darstellen lässt (1+0,5+0,25+0,125). Für 1,875^2 braucht man also 6 Bit und für 1,875^3 9 Bit. Das kann die FPU in unserer CPU also Fehlerfrei.

Ergebniss (Mantisse immer auf den Bereich von 1 bis 2 normalisiert)

1,875*2^0 * 1,875*2^0 = 1,7578125*2^1
(1,875*2^0 * 1,875*2^0) * 1,875*2^0 = 1,7578125*2^1 * 1,875*2^0 = 1,64794921875*2^2

Mit einer 2 Bit Mantisse haben wir jetzt ein ernsthaftes Problem. 1,875 ist nicht korrekt darstellbar. Also müssen wir auf 1,750 (1+0,5+0,25) gehen.

Daraus ergibt sich (Mantisse auf den mit 2 Bit darstellbaren Zahlenraum normalisiert)

1,750*2^0 * 1,750*2^0 = 1,500 *2^1
1,750*2^0 * 1,750*2^0 * 1,750*2^0 = 1,500 * 2^1 * 1,750*2^0 1,25*2^2

Berechnen wir jetzt den relativen Fehler der Mantisse ergibt sich:

(1,875 - 1,750) / 1,750 = 7,1%
(1,7578125 - 1,5) / 1,5 = 17,2%
(1,64794921875 - 1,25) / 1,25 = 31,8%

Der relative Fehler steigt also. OK, ich weiss das es fiess ist mit dem maximalen relativen Fehler den es bei einer 2 Bit Mantisse gibt anzufangen. Das ist aber der Worst Case Fall.

Rechen wir das noch auf Bits um ergibt sich:

Ausgangsfehler 1/2 Bit
Erste Multiplikation ca 1 Bit
Zweite Multiplikation ca 1,5 Bit

[Xmas]

Original geschrieben von Haarmann
1 Zu 1.01 sind nicht 1.01 zu 1.02 -> rel. Fehler nimmt ab.
Wieso denn 1.01 zu 1.02?
Der Fehler ist immer im Vergleich zum erwarteten Ergebnis zu sehen. Ich schrieb, man will 1 * 1 rechnen. Wenn dann 1.02 herauskommt ist der relative Fehler 2%. Bei den vorherigen Rechnungen war dann der Fehler jeweils 1%, weil 1.01 statt 1 herauskam.

[Haarmann]

Demirug

Ich darf hoffentlich hier auch mal mitrechnen in Deinem BSP. 1.875 auf 1.75 zu runden halte ich bescheiden gesagt für ziemlichen Schwachfug und runde frech wie ich bin auf 2, wie mans in der Schule gelernt hat. 0.5 wird aufgerundet und nicht abgerundet *hust*.

Nun werde ich also mal ne Reihe entwickeln mit 9 Multiplikationen.

Dann habe ich also

2 4 8 16 32 64 128 256 512 1024

statt

1.875 ... 537.05

Wo sind nur meine angeblichen 5 Bit Fehler geblieben? Irgendwie, ich weiss nicht wieso, kann ich diese drum gerade nicht finden in meiner Rechnung. Da habe ich wohl glatt was falsch gemacht... oder liegt der Fehler etwa woanders, weswegen ich diese 5 Bit nicht bekomme?

Xmas

Man sollte von einfachen Sachen nie auf komplizierte Sachen schliessen.

[Gast]

Haarmann

AFAIK musst du den Fehler nach jedem einzelnen Rechenschritt betrachten und mit dem fehlerbehafteten Ergebniss.

Das was du hier vorrechnest (die 2. Reihe) kann doch keine HW so rechnen.

[Gast]

.... mit dem fehlerbehafteten Ergebniss weiterrechnen sollte es heissen.

[Xmas]

Original geschrieben von Haarmann
Demirug

Ich darf hoffentlich hier auch mal mitrechnen in Deinem BSP. 1.875 auf 1.75 zu runden halte ich bescheiden gesagt für ziemlichen Schwachfug und runde frech wie ich bin auf 2, wie mans in der Schule gelernt hat. 0.5 wird aufgerundet und nicht abgerundet *hust*.

Nun werde ich also mal ne Reihe entwickeln mit 9 Multiplikationen.

Dann habe ich also

2 4 8 16 32 64 128 256 512 1024

statt

1.875 ... 537.05

Wo sind nur meine angeblichen 5 Bit Fehler geblieben? Irgendwie, ich weiss nicht wieso, kann ich diese drum gerade nicht finden in meiner Rechnung. Da habe ich wohl glatt was falsch gemacht... oder liegt der Fehler etwa woanders, weswegen ich diese 5 Bit nicht bekomme?

IEEE Float-Rundung hält sich nicht an das was du in der Schule gelernt hast.

Mehr als alle Bits falsch kannst du nicht bekommen. Und das hast du doch bei 1024 gegenüber 537,05.
Außerdem geht es um den möglichen Fehler, nicht um den konkret vorhandenen Fehler bei einem Zahlenbeispiel.


Xmas

Man sollte von einfachen Sachen nie auf komplizierte Sachen schliessen.
Ich habe keine Ahnung was du mit diesem Spruch jetzt ausdrücken willst.
Ich habe gar nicht von komplizierten Sachen gesprochen. Oder ist eine Multiplikation bzw. das Feststellen des prozentualen Fehlers jetzt schon kompliziert?

[Demirug]

Original geschrieben von Haarmann
Demirug

Ich darf hoffentlich hier auch mal mitrechnen in Deinem BSP. 1.875 auf 1.75 zu runden halte ich bescheiden gesagt für ziemlichen Schwachfug und runde frech wie ich bin auf 2, wie mans in der Schule gelernt hat. 0.5 wird aufgerundet und nicht abgerundet *hust*.

Nun werde ich also mal ne Reihe entwickeln mit 9 Multiplikationen.

Dann habe ich also

2 4 8 16 32 64 128 256 512 1024

statt

1.875 ... 537.05

Wo sind nur meine angeblichen 5 Bit Fehler geblieben? Irgendwie, ich weiss nicht wieso, kann ich diese drum gerade nicht finden in meiner Rechnung. Da habe ich wohl glatt was falsch gemacht... oder liegt der Fehler etwa woanders, weswegen ich diese 5 Bit nicht bekomme?

Xmas

Man sollte von einfachen Sachen nie auf komplizierte Sachen schliessen.

Bei nur 2 Bit Mantisse kann es sowieso keine 5 Bit Fehler geben.

2.0 ist ja auch wieder so ein Spezialfall. ;)

Wenn man hier aufrundet ist der Fehler wirklich kleiner. Aber wir können ja auch mit 1,874 rechnen dann muss man abrunden und der relative Fehler steigt wieder schneller.

Es ging mir ja eingentlich nur darum zu zeigen das auch bei Multiplikationen der Fehler pro Multiplikation um ein halbes Bit steigen kann. Bei "günstigen" Zahlen steigt er natürlich nicht so schnell.

[aths]

Original geschrieben von Haarmann
Demirug

16 Bit Mantisse mal 16 Bit Mantisse z.B. ergeben ne 31er oder 32er Mantisse, die dann wieder auf 16 Bit reduziert wird. Das heisst die Fehlerbit schiebst gleich hinten mit raus. Es bleibt also maximal der Fehler, den de eh schon hattest. Ich denke das leuchtet ein...Jo. Am besten, man schneidet alle Bits weg, dann hat man garantiert auch keinen Fehler mehr... Wenn die Mantisse neu auf 16 Bit Breite gerundet werden muss, kannst du Rundungsfehler von bis zu 0,5 Bit bekommen. Dieser Fehler kommt hinzu, man rechnet damit weiter — beim nächsten mal kann es wieder einen Rundungsfehler von bis zu 0,5 Bit geben...

[Gast]

Also sind die 0.5 bits worst-case?

[aths]

Original geschrieben von Gast
Also sind die 0.5 bits worst-case? Das hängt davon ab, wie man es sehen will. Bei der Addition von einer sehr großen und sehr kleinen Zahl kann es sein, dass sich die kleine Zahl gar nicht auswirkt. Bei Multiplikationen kann man in der Regel (Ausnahme Sonderfall bei denormalisierter Mantisse) bis zu 0,5 Bit Ungenauigkeit ansetzen.

[Haarmann]

Gast

Also ich denke fast, dass ein Binäres Rechenwerk diese wahnsinnigen Operationen durchaus hinkriegt. Korrektes Runden ist zudem auch nicht schwer implementierbar.

Xmas

Weisste wie sehr mich interessiert, wie die IEE Rundungsregeln gehen, wenn diese schlicht blödsinnig sind?
Ziel eines ATI Chips isses wohl möglichst exakt zu rechnen und keine Pixelfehler zu produzieren. Falls man hierbei die IEE Rundungsregeln verletzten muss - dann halt.

Demirug

Also ich lernte das mal anders. Durchaus kann man auch die 0er Bits vorne und hinten, die ja angenommen werden, mitzählen. Mindestens ich kann das sehr gut sogar ;). Ist eben alles nur ne Frage, wie man etwas auslegen will und ich legte es schlicht anders aus. Natürlich folgt sozusagen aus A B, falls die Umgebung so ist, wie Du sie hinstellst. Wenn ich aber die Umgebung auf mein Ziel hin optimiere, dann kann ich ein besseres Ergebnis erreichen.

[del_4901]

wer es genauer wissen will:
http://www.math.tu-cottbus.de/~schenk/lehre/numerik03/lecture/numerik.pdf
(Kapitel 1)

[zeckensack]

Original geschrieben von Haarmann
Wird hier eigentlich nur addiert oder hats auch Multiplikationen dabei Demirug? Jede Multiplikation schmeisst Deine Rechnung nämlich wieder übern Hauffen... Betragsmässige Addition ist relativ stabil. Addition im Allgemeinen kann aber auch betragsmässige Subtraktion sein (wenn einer der Operanden negativ ist), und diese ist das grösste aller Probleme für FP.

Beispiel:
1.65+(-1.6)=0.05

Mit 4 Bit Mantisse:
1.625+(-1.625)=0
Operanden: Absoluter Fehler 0.025 | Relativer Fehler <1.6%
Ergebnis: Absoluter Fehler 0.05 | Relativer Fehler unendlich

Mit 5 Bit Mantisse:
1.65625+(-1.59375)=0.0625
Operanden: Absoluter Fehler 0.00625 | Relativer Fehler <0.4%
Ergebnis: | Absoluter Fehler: 0.0125 | Relativer Fehler 25%

Das Problem dabei ist, dass betragsmässige Subtraktion den Exponenten des Ergebnisses beliebig weit verschieben, und damit alle signifikanten Bits fressen kann.
5 Bit Mantisse
1.10101 e+0
-1.10011 e+0
________
0.00010 e+0
<<<< Renormalisierung
=1.00000 e-4
In dem Fall sind die vier zusätzlich eingeschobenen Bits alle potentiell falsch.

PS: Unis verbreiten zum Thema FP gerne den Lehrsatz "Subtraktion ist wie Addition, nur mit umgekehrten Vorzeichen". Unsinn.

[Demirug]

Ja, und bei FP Zahlen gilt auch nicht mehr zwangsläufig das

a+b+c = c+b+a

ist.

[aths]

Original geschrieben von Haarmann
Weisste wie sehr mich interessiert, wie die IEE Rundungsregeln gehen, wenn diese schlicht blödsinnig sind? Die IEEE-Rundungsregeln sind sinnig. Man sollte sie nur erst mal kennen gelernt (und verstanden ;)) haben.

[Haarmann]

Demirug

Es gilt sogar ausdrücklich nimmer ;)

aths

Regeln sind selten sinnig. Sie sind nur dann sinnig, wenn man ne bestimmte Anwendung im Sinn hat.

[aths]

Die Anwendung ist, möglichst genau zu rechnen. IEEE-Rundungsregeln lassen sich konfigurieren, es gibt derer 4 zur Auswahl. Standard ist ein Verfahren, das für fast alle Fälle am besten ist. Ich halte es für ein wenig arrogant, groß über den Unsinn von Regeln zu reden, wenn man in der Materie weniger tief drin steckt, als es gut tun würde. Oder anders gesagt, wenn man zeckensack oder Demirug widerspricht, sollte man imo gute Argumente haben :kicher:

[Haarmann]

aths

Ich denke das Zerlegen von Demirugs Rechenexempel ist mir durchaus gelungen. Natürlich kann man sowas als Glück hinstellen, aber wer seine Umgebung geschickt wählt, de kann wirklich viel profitieren.

Setzen wir mal den seltsamen Fall, dass man auf 2 Kommastellen rundet. Ich definiere nun, das x.99 = x+1 ist. Diese Regel hat nur dann Sinn, wenn ab und an ne x+1 als x.99 vorkommt, aber ne "echte" x.99 selten ist. Das FP Format hat eine Tendenz dazu mit ganzen Zahlen seine Mühen zu haben. Dementsprechend ist so eine Vorgabe vielfach sinnvoll, aber nicht immer.

Dementsprechend ist es bei 3d Chips nicht so wichtig genau zu rechnen, sondern eben ein genaues Endergebnis zu haben. Solange man die Anwendungen von 3D Chips auch bei der Darstellung belässt.

[Gast]

Original geschrieben von Haarmann


Dementsprechend ist es bei 3d Chips nicht so wichtig genau zu rechnen, sondern eben ein genaues Endergebnis zu haben. Solange man die Anwendungen von 3D Chips auch bei der Darstellung belässt.

Du willst nicht genau rechnen, aber ein genaues Ergebnis haben? Wie denn das?

[Haarmann]

Gast

"Verrundest" Du Dich 2 mal gegen unten, so ist das gut, wenn de Subtraktion machst oder ne Division, aber "Gift" für Addition oder Multiplikation. Da bei diesen FP Operationen zudem nicht gilt, dass A+(B+C)=(A+B)+C lässt sich blendend mit sowas arbeiten.

[aths]

Original geschrieben von Haarmann
Das FP Format hat eine Tendenz dazu mit ganzen Zahlen seine Mühen zu haben.Ist mir noch nicht aufgefallen.
Original geschrieben von Haarmann
Dementsprechend ist es bei 3d Chips nicht so wichtig genau zu rechnen, sondern eben ein genaues Endergebnis zu haben. Solange man die Anwendungen von 3D Chips auch bei der Darstellung belässt. Ein genaues Endergebnis wird man wohl nur bekommen, wenn genau gerechnet wird.

Original geschrieben von Haarmann
"Verrundest" Du Dich 2 mal gegen unten, so ist das gut, wenn de Subtraktion machst oder ne Division, aber "Gift" für Addition oder Multiplikation. Da bei diesen FP Operationen zudem nicht gilt, dass A+(B+C)=(A+B)+C lässt sich blendend mit sowas arbeiten. Bitte vorrechnen. 1. Definition der Haarmannschen Rundungs-Regeln für FP. 2. Beweis, dass diese geeigneter sind, als IEEE-konforme Regeln.

[Frank]

Original geschrieben von aths
Ein genaues Endergebnis wird man wohl nur bekommen, wenn genau gerechnet wird.... und das will (und kann) schliesslich niemand. :D

Original geschrieben von Haarmann
Regeln sind selten sinnig. Sie sind nur dann sinnig, wenn man ne bestimmte Anwendung im Sinn hat. Solche Regeln werden gerade dafür gemacht, um sinnig zu sein. 0^0 ist ja auch nicht ganz umsonst 1 (geworden!).

[Haarmann]

aths

"Ist mir noch nicht aufgefallen."

Dir schon nicht, Du hast ja auch nie ne 32 Bit Int in 32 Bit FP gewandelt... oder doch? Führt das bei Dir nicht unter Umständen zu "Verlusten"?

"Ein genaues Endergebnis wird man wohl nur bekommen, wenn genau gerechnet wird."

Natürlich ist dies im allgemeinen Fall so. Aber wir sind ja hier beim FP24 Format einer Grafikkarte und da sind die Anwendungen "etwas" beschränkter. Ziel einer 3d Grafikkarte ist bekanntlich imho, dass ein möglichst genaues Bild entsteht. Wie man zu diesem Ziel kommt, ist dabei wohl nicht relevant.

"Bitte vorrechnen. 1. Definition der Haarmannschen Rundungs-Regeln für FP. 2. Beweis, dass diese geeigneter sind, als IEEE-konforme Regeln."

Ich hab nie behauptet, dass meine Regeln grundlegend geeigneter sind. Ich sagte nur, dass sie im Bezug auf diese Anwendung (3D Ahoi) geeigneter sind. Sowas geht bei mir unter anwendungsorientierter Ansatz bis ergebnisorientiertes Arbeiten. Offensichtlich beides Fremdwörter für Dich. Sonst wüssteste, dass man sich dabei oft die Regeln soweit verbiegt, bis das Ergebnis optimal ist.

Kleines Exempel am Rande. Man nehme 2 Zahlen und addiere sie. Bei FP Zahlen addieren sich die Fehler nur, wenn man den gleichen Exponenten hat. Weiss ich daher im Voraus, dass meine beiden Exponenten eh unterschiedlich sind, so kann ich die Fehlerrechnung anpassen und muss nur den einen Fehler berücksichtigen.
Ums in Demirugs Exempel zu Anfang zu integrieren. Das FP24 Format reicht nur nicht bei Pixeln, die eine Koordinate grösser denn 1024 nutzen sollten. Ich muss also nur die 1024+ Fälle mir ansehen.

Frank

Wozu dient denn 0^0=1?

Demirug

Meinem Kumpel und mir ist ein Texturflimmern aufgefallen, welches bei Rise of Nations auftritt bei NV Karten jeglicher Art und diversen Treibern. ATI sind offenbar verschont davon. Eingesetzte Karten sind ne GF4 Ti, GF3 Ti, ne UMA GF4 MX auf nem NF2 und auf Seiten ATIs ne 9700, ne 9100, ne 9000, ne 9600 und ne 9500. Gibts da ne Idee?

[aths]

Original geschrieben von Haarmann
aths

"Ist mir noch nicht aufgefallen."

Dir schon nicht, Du hast ja auch nie ne 32 Bit Int in 32 Bit FP gewandelt... oder doch? Führt das bei Dir nicht unter Umständen zu "Verlusten"?Komische Frage. Gegenfrage: Hat FP32 dafür nicht Vorteile, die Int32 nicht hat? Soll sich FP32 Dinge aus den Rippen schneiden, ohne zusätzliche Bits zu bekommen? Mit FP32 kann man bis zu Int24 verlustfrei darstellen. "The right tool for the right job".
Original geschrieben von Haarmann
Natürlich ist dies im allgemeinen Fall so. Aber wir sind ja hier beim FP24 Format einer Grafikkarte und da sind die Anwendungen "etwas" beschränkter. Ziel einer 3d Grafikkarte ist bekanntlich imho, dass ein möglichst genaues Bild entsteht. Wie man zu diesem Ziel kommt, ist dabei wohl nicht relevant.Ungenaues Runden ist dafür sicher kein guter Weg.

Original geschrieben von Haarmann
Ich sagte nur, dass sie im Bezug auf diese Anwendung (3D Ahoi) geeigneter sind. Sowas geht bei mir unter anwendungsorientierter Ansatz bis ergebnisorientiertes Arbeiten. Offensichtlich beides Fremdwörter für Dich. Sonst wüssteste, dass man sich dabei oft die Regeln soweit verbiegt, bis das Ergebnis optimal ist.Bevor man sich zum großen Regelverbieger aufschwingt, sollte man die existenten Regeln erst mal verstanden haben. Das traue ich den ATI- und Nvidia-Ingenieuren eher zu, als dir, wenn ich ehrlich bin. Das du rumfrickeln 'bis es passt' bevorzugst, nunja.
Original geschrieben von Haarmann
Kleines Exempel am Rande. Man nehme 2 Zahlen und addiere sie. Bei FP Zahlen addieren sich die Fehler nur, wenn man den gleichen Exponenten hat. Weiss ich daher im Voraus, dass meine beiden Exponenten eh unterschiedlich sind, so kann ich die Fehlerrechnung anpassen und muss nur den einen Fehler berücksichtigen. Ich will keine Beispiele sehen. Bevor man "anwenderorientiert" handelt, also irgendwo rumbiegt, sollte das Problem als solches geistig durchdrungen werden, da habe ich in diesem Fall jetzt Zweifel. (Du formulierst "deine" Rundungs-Regeln nicht klar, und kannst nicht allgemein gültig den angeblichen Vorteil darlegen. Dass es in bestimmten Fällen besser wäre, auch mal anders zu runden, ist hingegen jawohl keine großartige Erwähnung wert.) Bei Shadern weiß man meist im Voraus nicht, wie was kommt. IEEE-Logik muss verschiedene Rundungsregeln unterstützen, GPU-Logik kann das afaik nicht. Offenbar, weil das nicht notwendig ist, nach Haarmannschen Regeln zu runden.
Original geschrieben von Haarmann
Ums in Demirugs Exempel zu Anfang zu integrieren. Das FP24 Format reicht nur nicht bei Pixeln, die eine Koordinate grösser denn 1024 nutzen sollten. Ich muss also nur die 1024+ Fälle mir ansehen.FP24 wäre texelgenau bis mindestens 65536 (eigentlich bis 131072, aber wahrscheinlich ist die Umrechenlogik vereinfacht worden.) Was Demirugs Fehler-Rechnung angeht, müsste erst geklärt werden, wieviele Stufen man im Texel haben will, damit es "reicht".

[Haarmann]

aths

"The right tool for the right job"

Das ist schon mal ein Anfang zum Verstehen meines Ansatzes.

"Ungenaues Runden ist dafür sicher kein guter Weg."

Das ist eben die Ansicht eines Menschen, der sich nie mit sowas beschäftigt hat. Weil meine Variante schlicht nicht ungenauer war, sondern einfach aufrundete, statt abrundete. Würde man z.B. Butterflyrunden (also einmal auf und einmal ab) würde bei der gestellten Situation mit den Multiplikationen und der 1.875 ein sehr genaues Resultat erziehlen bei der 2er Mantisse (). Das liegt an der schlichten Tatsache, dass Multiplikationen weniger Fehler ergeben, wenn man alternierend rundet. Schau Dir mal an, welche Operationen bei Shadern vorkommen und welche eigentlich nicht resp weniger. Anhand davon liesse sich leicht ermitteln, welche Arten von Rundungs- und Rechenregeln sich eigenen um Fehler zu minimieren.

"Bevor man sich zum großen Regelverbieger aufschwingt, sollte man die existenten Regeln erst mal verstanden haben. Das traue ich den ATI- und Nvidia-Ingenieuren eher zu, als dir, wenn ich ehrlich bin. Das du rumfrickeln 'bis es passt' bevorzugst, nunja."

Wären diese Ings wohl so gut, würdens fast sicher nicht mehr dort arbeiten, sondern eigenen Projekten auf eigene Kasse nachgehen. Tun doch auch Viele.

Oder ev hatte man schlicht auch gar nicht daran gedacht, dass Demirugs Problem je zum tragen kommt... ATI scheint ja mit so manchen Problemen nicht gerechnet zu haben oder hat sie stillschweigend in Kauf genommen. Geht man von Ersterem aus, so ists klar, wieso man sich jeglichen Aufwand geschenkt hat.

Lies doch einfach Demirugs Posting am Anfang durch und Dir ist klar, wo er das Problem sieht ;).

[Coda]

Wären diese Ings wohl so gut, würdens fast sicher nicht mehr dort arbeiten, sondern eigenen Projekten auf eigene Kasse nachgehen. Tun doch auch Viele.
Ach ja? Welche denn O_o
Sorry aber das Statement ist einfach nur lächerlich

[Haarmann]

Coda

Wie oft liest Du eigentlich news von Firmenneugründungen? Offensichtlich eher selten. Bei NV und ATI isses natürlich nicht so offensichtlich, weil man dort nicht alle Hinterleute kennt im Allgemeinen. Die an der Front sind ja keine Ings wie bei 3dfx. Dementsprechend fällt Dir sowas gar nicht auf, aber kannst drauf wetten, dass hier viel Fluktuation herrscht in der Richtung. Schau Dir als Exempel für sowas nur mal Intel an oder Via - vor allem die Gründungsgeschichte und die deren Mitglieder. Fast alle dieser neueren Firmen wurden von Leuten aus älteren Firmen gegründet.

[Xmas]

Nur sind die meisten Ingenieure (gilt auch für fast alle anderen Berufsgruppen) ganz glücklich damit, einfach nur angestellt zu sein. Und das hat kaum etwas damit zu tun, wie gut sie in ihrem Feld sind.

[nggalai]

Original geschrieben von Xmas
Nur sind die meisten Ingenieure (gilt auch für fast alle anderen Berufsgruppen) ganz glücklich damit, einfach nur angestellt zu sein. Und das hat kaum etwas damit zu tun, wie gut sie in ihrem Feld sind. Jo. Schönes Beispiel: Richard Huddy. Erst als Entwickler bei NVIDIA, hat er mit ein paar Kollegen zusammen eine eigene Firma gegründet, und ist jetzt wieder angestellt--PR-Chef bei ATI. Und das wurde Don Ricardo sicher ned, weil er ein schlechter Entwickler war. ;) Dito Kevin, der jetzt den Entwickler-Support bei ATI macht. Alles schlechte Leute? Wohl kaum.

93,
-Sascha.rb

[MadManniMan]

Meiner Einer fragt sich ebenso nach der Sinnhaftigkeit hinter 0^0.

Klär0r mich wer auf! :wink:

[Kant]

Original geschrieben von MadManniMan
Meiner Einer fragt sich ebenso nach der Sinnhaftigkeit hinter 0^0.

Klär0r mich wer auf! :wink:

Ist in der Mathematik so definiert. Ein Grund wird vielleicht hierbei klar :

(2^3) / 2=(2^2)
(2^2) / 2=(2^1)
(2^1) / 2=(2^0)

Also hat man x^0=1 definiert, bzw für alle x<>0 bewiesen, und für x=0 definiert.

Edit : http://mathforum.org/dr.math/faq/faq.0.to.0.power.html

begründet es auch für die 0

[MadManniMan]

Oh, danke :) Das erklärt zumindest mal die ursprüngliche Intention!