Archiv verlassen und diese Seite im Standarddesign anzeigen : FP Genauigkeit aktueller Grafikkarten
Hallo,
ich wüßte gerne wie es mit der FP Genauigkeit (also das was man effektiv im Pixelshader nutzen kann) der aktuellen Grafikkarten (so ab R3xx/NV3x) aussieht. Gibt es vielleicht irgendwo eine Tabelle wo man sieht wer was unterstützt? Habe bisher nur recht spärliche Infos gefunden.
Die Geforce (ab 5xxx AFAIK) können 32 bit, soviel weiß ich. Wie siehts mit ATI aus? Was schreiben eigentlich die DX-Specs vor?
Hallo,
ich wüßte gerne wie es mit der FP Genauigkeit (also das was man effektiv im Pixelshader nutzen kann) der aktuellen Grafikkarten (so ab R3xx/NV3x) aussieht. Gibt es vielleicht irgendwo eine Tabelle wo man sieht wer was unterstützt? Habe bisher nur recht spärliche Infos gefunden.
Die Geforce (ab 5xxx AFAIK) können 32 bit, soviel weiß ich. Wie siehts mit ATI aus? Was schreiben eigentlich die DX-Specs vor?
Normalerweise wird mit einfacher Genauigkeit gerechnet.
Demirug
2007-05-14, 22:25:51
Shader Model 2: mindestens 24 Bit
Shader Model 3: mindestens 32 Bit
Shader Model 4: mindestens 32 Bit + fast vollständige IEEE Konformität.
Wie ist "fast vollständig IEEE konform" eigentlich genau definiert?
micki
2007-05-14, 22:37:00
Wie ist "fast vollständig IEEE konform" eigentlich genau definiert?
ich glaube eigentlich sind sie konform, jedoch aufgrund von zusammenlegung von befehlen dann zu ungenau bzw falsch (z.b. ist mad ungenauer als mul+add und dot4 wird oft akkumuliert als (x+y)+(z+w) was falsch ist und ((x+y)+z)+w sein muss.)
Shader Model 2: mindestens 24 Bit
Shader Model 3: mindestens 32 Bit
Shader Model 4: mindestens 32 Bit + fast vollständige IEEE Konformität.
Danke, das hilft mir schonmal.
Fein wäre noch eine Aufstellung was die unterschiedlichen Generationen wirklich bieten, z.B. konnte ja die Geforce FX ("PS 2.0+") durchaus auch FP32, wenn ich recht informiert bin.
Stone2001
2007-05-15, 15:14:19
Wie ist "fast vollständig IEEE konform" eigentlich genau definiert?
Ich könnte schwören, dass nicht alle Rundungsmodi implementiert sind...
Was wesentlich interessanter ist, ist die Tatsache, das sowohl NVidia als auch ATI angekündigt haben in ihrer nächsten Generation IEEE Double Precision zu unterstützen. Dann könnte es für einige Firmen äußerst schlecht aussehen.
Was wesentlich interessanter ist, ist die Tatsache, das sowohl NVidia als auch ATI angekündigt haben in ihrer nächsten Generation IEEE Double Precision zu unterstützen. Dann könnte es für einige Firmen äußerst schlecht aussehen.
Es kommt auch auf die Geschwindigkeit an und das wird dann eher so laufen wie bei int.
Fein wäre noch eine Aufstellung was die unterschiedlichen Generationen wirklich bieten, z.B. konnte ja die Geforce FX ("PS 2.0+") durchaus auch FP32, wenn ich recht informiert bin.
NV kann seit dem NV30 mit FP32-genauigkeit rechnen, alternativ auch noch mit PP in FP16-genauigkeit wenn es der shader erlaubt. das gleiche gilt auch für die NV4x und G7x-serie. die G8x-serie rechnet ebenfalls mit FP32, wobei die PP-befehle meines wissens allerdings ignoriert werden und trotzdem mit FP32 gerechnet wird. denorms werden beim NV3x-G7x allerdings nur bei FP16 verwendet, FP32 muss ohne auskommen. wie es sich beim G80 verhält weiß ich nicht
bei ATI rechnen R(V)3xx und R(V)4xx mit FP24, seit R5xx wird auch bei ATI mit FP32 gerechnet. PP-flags werden bei ATI generell ignoriert und immer mit voller genauigkeit gerechnet.
ich glaube eigentlich sind sie konform, jedoch aufgrund von zusammenlegung von befehlen dann zu ungenau bzw falsch (z.b. ist mad ungenauer als mul+add und dot4 wird oft akkumuliert als (x+y)+(z+w) was falsch ist und ((x+y)+z)+w sein muss.)
MAD ist möglicherweise genauer als MUL+ADD, weil mehr Bits des Zwischenergebnisses beibehalten werden. Ungenauer sollte es in keinem Fall sein.
Skalarprodukte werden von IEEE754 nicht spezifiziert und können deshalb auch in anderer Reihenfolge ausgeführt werden. Zumindest G80 sollte aber immer ((x+y)+z)+w rechnen.
Ich könnte schwören, dass nicht alle Rundungsmodi implementiert sind...
Ja, genauso wie Denorm-Support nicht erforderlich ist.
micki
2007-05-15, 16:43:47
MAD ist möglicherweise genauer als MUL+ADD, weil mehr Bits des Zwischenergebnisses beibehalten werden. Ungenauer sollte es in keinem Fall sein. ist es aber, weil zwischenschritte ausgelassen werden. das ist dann nicht mehr der IEEE geforderten genauigkeit entsprechend.
Skalarprodukte werden von IEEE754 nicht spezifiziert und können deshalb auch in anderer Reihenfolge ausgeführt werden.soweit ich weiss ist spezifiziert dass die mathematische ordnung eingehalten werden muss bei rechenoperationen, was eine ausrede von intel ist weshalb sie kein dot einbauen und stattdessen "manuelles" akkumulieren forcieren (weil die latenz ewig lang waere, weil sie immer IEEE conform sein wollen/muessen intel-bla...).
Zumindest G80 sollte aber immer ((x+y)+z)+w rechnen.muss nicht mit der tatsaechlichen reihenfolge ubereinstimmen, es gibt latenzen zu verstecken und niemand sagt, dass die ALU keine latenz hat.
ist es aber, weil zwischenschritte ausgelassen werden. das ist dann nicht mehr der IEEE geforderten genauigkeit entsprechend.
Welche Zwischenschritte sollen das Ergebnis denn genauer machen?
soweit ich weiss ist spezifiziert dass die mathematische ordnung eingehalten werden muss bei rechenoperationen, was eine ausrede von intel ist weshalb sie kein dot einbauen und stattdessen "manuelles" akkumulieren forcieren (weil die latenz ewig lang waere, weil sie immer IEEE conform sein wollen/muessen intel-bla...).
a dot b = a.y * b.y + a.z * b.z + (a.x * b.x + a.w * b.w)
ist eine absolut zulässige definition des Skalarprodukts für vec4. Eine von vielen.
muss nicht mit der tatsaechlichen reihenfolge ubereinstimmen, es gibt latenzen zu verstecken und niemand sagt, dass die ALU keine latenz hat.
Natürlich gibt es Latenzen, aber diese werden durch Threading versteckt.
micki
2007-05-15, 17:09:28
Welche Zwischenschritte sollen das Ergebnis denn genauer machen?z.b. einhalten des rundungsmodus zwischen mull und add.
a dot b = a.y * b.y + a.z * b.z + (a.x * b.x + a.w * b.w)
ist eine absolut zulässige definition des Skalarprodukts für vec4. Eine von vielen.
schoen, jetzt musst du nur noch verstehen dass es um diese definition geht: x+y+z+w und diese nicht von der cpu in einer anderen reihenfolge gemacht werden darf.
Natürlich gibt es Latenzen, aber diese werden durch Threading versteckt.
nicht vollkommen.
z.b. einhalten des rundungsmodus zwischen mull und add.
Beibehalten der Guardbits statt runden ist genauer, nicht ungenauer.
schoen, jetzt musst du nur noch verstehen dass es um diese definition geht: x+y+z+w und diese nicht von der cpu in einer anderen reihenfolge gemacht werden darf.
Und wer schreibt dies vor?
nicht vollkommen.
Die reine MAD-ALU-Latenz schon. Diese ist ja nicht zufällig sondern immer gleich, und das Threading bzw. Batching ist darauf ausgelegt, genau diese Latenz zu verstecken. Deswegen kann man pro Takt eine abhängige skalare Operation berechnen.
micki
2007-05-15, 18:16:26
Beibehalten der Guardbits statt runden ist genauer, nicht ungenauer.und ich dachte wir sprechen hier ueber g80 der grundsaetzlich truncated. bezogen auf das zwischenergebnis bei madd
Und wer schreibt dies vor?
soweit ich weiss ist spezifiziert dass die mathematische ordnung eingehalten werden muss bei rechenoperationen, was eine ausrede von intel ist weshalb sie kein dot einbauen und stattdessen "manuelles" akkumulieren forcieren (weil die latenz ewig lang waere, weil sie immer IEEE conform sein wollen/muessen intel-bla...).
Die reine MAD-ALU-Latenz schon. Diese ist ja nicht zufällig sondern immer gleich, und das Threading bzw. Batching ist darauf ausgelegt, genau diese Latenz zu verstecken. Deswegen kann man pro Takt eine abhängige skalare Operation berechnen.
und was ist mit den faellen bei denen man die latenz nicht verstecken kann, weil z.b. zuwenig threads benutzt werden aufgrund von registerpressure?
Was hat denn die Latenz bitte mit der Reihenfolge der Instructions zu tun?
Sorry, aber das kapier ich gerade überhaupt nicht.
micki
2007-05-15, 18:42:41
Was hat denn die Latenz bitte mit der Reihenfolge der Instructions zu tun?
Sorry, aber das kapier ich gerade überhaupt nicht.ach das eklaere ich dir gerne, ich weiss nur nich wie genau du das brauchst :)
instructions haben eine gewisse latenz. du kannst also z.b. jeden takt ein add aufrufen, das heisst aber noch nicht dass jeder add in einem takt durch ist, greifst du also direkt auf das ergebnissregister vom vorherigen add, stallt die pipe solange wie die latenz ist (falls diese nicht versteckt werden kann weil z.b. zuwenige threads laufen).
rechnest du ((x+y)+z)+w, dann riskierst du 2 stalls, weil erst +z gerechnet werden kann, wenn (x+y) fertig ist, das gleich bei +w.
rechnest du (x+y)+(z+w), dann hast du nur einen dieser data hazards.
deswegen ist die reihenfolge wichtig.
Mom, das muss ich mir überlegen.
Für den 2. Fall brauchst du ein Register mehr. Ich glaube kaum, dass nVIDIA das macht.
micki
2007-05-15, 18:50:04
GPUs haben aber keine Out-Of-Order-Execution und damit wird es bei beiden Fällen gleich stallen.
du kannst latenz auch in order haben, du musst nur genug unabhaengige dinge zu tun haben, deswegen die "megathreads" (512 oder so bei r520?) und nur relativ weniger "workerthreads"
(edit:bestes beispiel cell, sowohl ppu als auch spu sind in order, haben aber 32 bzw 128register damit du viel unabhaengiges arbeiten ermoeglichen kannst, sonst hast du hazards und 0 performance)
Ja hast recht, aber siehe Edit. Es wird sicher trotzdem nicht gemacht. Das G80-Registerfile ist eh klein genug.
micki
2007-05-15, 19:01:06
Ja hast recht, aber siehe Edit. Es wird sicher trotzdem nicht gemacht. Das G80-Registerfile ist eh klein genug.das haengt von vielen dingen ab und ist nicht so generell festzulegen. die anzahl der benutzen register wird nur einmal pro shader gesetzt und nicht im laufe dynamisch zugeordnet. es gibt also neben dem "peak" register verbrauch viele stellen die nicht register limitiert sind, es gibt auch stellen an denen das quellregister garnicht mehr benutzt wird usw. sodass es von fall zu fall abhaengt ob registereinsparen oder latenzeinsparen performanter ist.
und ich dachte wir sprechen hier ueber g80 der grundsaetzlich truncated. bezogen auf das zwischenergebnis bei madd
Wenn das MUL-Ergebnis schon abgeschnitten wird, wie soll es am Ende dann gerundet werden?
soweit ich weiss ist spezifiziert dass die mathematische ordnung eingehalten werden muss bei rechenoperationen, was eine ausrede von intel ist weshalb sie kein dot einbauen und stattdessen "manuelles" akkumulieren forcieren (weil die latenz ewig lang waere, weil sie immer IEEE conform sein wollen/muessen intel-bla...).
Wir reden aber nicht von Intel sondern von D3D10.
und was ist mit den faellen bei denen man die latenz nicht verstecken kann, weil z.b. zuwenig threads benutzt werden aufgrund von registerpressure?
Pixelbatches sind beim G80 32 Pixel groß. Damit kann eine Instruktion über 4 Takte auf einer Vec8-Einheit ausgeführt werden.
Karatekatze
2007-05-15, 19:16:00
Wie schaut es eigentlich mit einem FP32 Tiefenpuffer aus?
Wird das endlich von der D3D10 hardware komplett durch die pipeline unterstützt?
micki
2007-05-16, 00:23:25
Wenn das MUL-Ergebnis schon abgeschnitten wird, wie soll es am Ende dann gerundet werden?
hmm... ist das ironie oder sarkasmus oder sowas? ich sage dir nur wie es ist, das zwischenergebnis wird truncated.
Wir reden aber nicht von Intel sondern von D3D10.und ich dachte wir reden ueber IEEE worauf sich intel bezog, dazu waren all meine aussagen, weil du dich da ("http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5496442&postcount=10') noch drauf bezogen hast.
aber gut, wenn es dir nur um d3d10 geht hast du natuerlich recht.
Pixelbatches sind beim G80 32 Pixel groß. Damit kann eine Instruktion über 4 Takte auf einer Vec8-Einheit ausgeführt werden.
1.dir ist schon klar dass ein paar hundert pixel simultan verarbeitet werden und es ne absolute resourcenverschwendung waere ALUs zu bauen die in 8takten fertig sind nur damit die pixel dann idle rumliegen fuer hunderte von takten bis sie wieder dran sind, statt einfach ne laengere pipe fuer die ALUs zu machen.
2.wieso sind pixelshader langsammer die mehr tmp-register nutzen obwohl sie keine texturen samplen, wenn es wie du behauptest keine latenz in der pipe gibt von mehr als das ist was was ein pixelpatch fuer einen durchgang braucht. dann duerfte es doch egal sein, ob du gerade die 512 "threads" hast oder nur z.b. soviel wie pixelshaderpipelines vorhanden sind.
In IEEE754 wird doch gar nichts über die Reihenfolge der Operationen gesagt, da da kein MAD und DOT definiert ist.
Ich könnte schwören, dass nicht alle Rundungsmodi implementiert sind...
Was wesentlich interessanter ist, ist die Tatsache, das sowohl NVidia als auch ATI angekündigt haben in ihrer nächsten Generation IEEE Double Precision zu unterstützen. Dann könnte es für einige Firmen äußerst schlecht aussehen.Soweit ich weiß, werden die Rundungs-Modi unterstützt. Allerdings gibts ggü. IEEE 754 Abstriche an der Genauigkeit (1 ULP statt 0,5 ULP, bei SFUs sogar nur 2 ULP) und bei FP32 wird Denorm-Support nicht verlangt.
micki
2007-05-16, 09:41:11
In IEEE754 wird doch gar nichts über die Reihenfolge der Operationen gesagt, da da kein MAD und DOT definiert ist.es sagt aber ueber genauigkeit, rundung usw etwas. deswegen muessen auch gruppen von operationen die selben resultate liefern wie die operationen einzeln. da gibt es keine freiraeume um die operatorenreihenfolge anders zu machen. natuerlich kann intel eine dot product approximation instruktion machen, nur ist diese dann nicht mehr nach IEEE.
da spielt timsweeny auch darauf an:
Most 3D programmers been requesting a dot product instruction (similar to the shader assembly language dp4 instruction) ever since the first SSE spec was sent around, and the HADDP is piece of a dot product operation: a pmul followed by two haddp's is a dot product.
This isn't exactly the instruction developers have been asking for, but it allows for performing a dot product in fewer instructions than was possible in the previous SSE versions. Intel's approach with HADDP and most of SSE in general is more rigorous than the shader assembly language instructions. For example, HADDP is precisely defined relative to the IEEE 754 floating-point spec, whereas dp4 leaves undefined the order of addition and the rounding points of the components additions, so different hardware implementing dp4 might return different results for the same operation, whereas that can't happen with HADDP.
Da steht genau das drin was ich gesagt hab. 754 spezifiziert keine Reihenfolge für DOT und MAD, deshalb kannst du die auch implementieren wie du willst und dir selber eine Spec festlegt.
Microsoft hat dazu sicher auch was festgelegt, in D3D10 ist sowas strenger als zuvor und wenn Intel es machen würde könnten sie auch ganz genau sagen, es wird zuerst x+y akkumuliert, dann z+w und schließlich beide zusammen. Der der eine Instruction einführt bestimmt das Verhalten dieser, nicht die Spec.
Wenn es Probleme geben würde, dann das Compiler sie später nicht einsetzen können, weil sie eine bestimmte Instruction-Order einhalten wollen.
Karatekatze
2007-05-16, 12:57:15
Jopp kann man erstellen.Ohne dass er nach Ganzzahlwerten konvertiert wird und dadurch ein imenser Genauigkeitsverlust entsteht?
Also das auch wirklich der komplette FP32 Zahlenraum vom Tiefenpuffer für die ganze Pipeline nutzbar gemacht wird?
micki
2007-05-16, 13:08:25
Da steht genau das drin was ich gesagt hab. 754 spezifiziert keine Reihenfolge für DOT und MAD, deshalb kannst du die auch implementieren wie du willst und dir selber eine Spec festlegt.da steht das gegenteil, IEEE legt fest wann gerundet wird, wenn MAD nicht mehr MUL+ADD oder DOT nicht mehr ADD(ADD(ADD(MUL(,),MUL(,)),MUL(,)),MUL(,)) entspricht, ist der MAD/DOT nicht standard-conform. klar, es ist irgendein MAD/DOT, aber eben keiner mehr der IEEE entspricht.
Microsoft hat dazu sicher auch was festgelegt, in D3D10 ist sowas strenger als zuvor und wenn Intel es machen würde könnten sie auch ganz genau sagen, es wird zuerst x+y akkumuliert, dann z+w und schließlich beide zusammen. Der der eine Instruction einführt bestimmt das Verhalten dieser, nicht die Spec.so einfaelltig ist intel nicht, sonst haetten sie schon laengst mehr befehle eingebaut als nur dot. wissenschaftler sind fuer intel eine wichtige zielgruppe und ein befehl der keine IEEE konformitaet hat wird dort einfach nicht benutzt, also pure verschwendung. konform heisst, dass er das selbe resultat liefert wie die einzelbefehle innerhalb der IEEE fehlertolleranz, unabhaengig von CPU und befehlssatz. es mag sein dass es dir oder mir egal ist, aber es gibt auch sehr viele (eben wissenschaftler) die darauf setzen dass sie sich auf diese dinge verlassen koennen. fuer sie ist diese genauigkeit so wichtig wie fuer uns vielleicht performance, wir wissen wie wir befehle umstellen muessen damit es schneller laeuft und sie wissen wie sie berechnungen genauer macht.
haette intel keinen wert auf diese zielgruppe gelegt, haetten sie fuer viele befehle viel schnellere implementierungen machen koennen und eben auch sehr viele dinge zusammenlegen koennen wie es jede billig-fpu/simd hat, aber es ist genau das gegenteil der fall, extra FPUs verbaut die 80bit rechnen und SSE mit pair-doubles ausgestattet fuer komplexe zahlen.
hmm... ist das ironie oder sarkasmus oder sowas? ich sage dir nur wie es ist, das zwischenergebnis wird truncated.
Nein, das ist eine ernsthafte Frage. Wenn das MUL-Ergebnis abgeschnitten wird, wie bekomme ich dann ein MUL mit Round-to-Nearest? Oder wird von D3D10 kein fester Rundungsmodus gefordert (das weiß ich gerade nicht)?
und ich dachte wir reden ueber IEEE worauf sich intel bezog, dazu waren all meine aussagen, weil du dich da (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5496442&postcount=10) noch drauf bezogen hast.
aber gut, wenn es dir nur um d3d10 geht hast du natuerlich recht.
Dort schrieb ich doch dass Skalarprodukte in IEEE754 nicht spezifiziert werden, also ich mich gerade nicht auf IEEE754 beziehen kann. Das ist doch auch was Tim Sweeney anmerkt, es gibt keinen Standard für DP4, weswegen die Gefahr besteht dass es unterschiedlich implementiert wird.
1.dir ist schon klar dass ein paar hundert pixel simultan verarbeitet werden und es ne absolute resourcenverschwendung waere ALUs zu bauen die in 8takten fertig sind nur damit die pixel dann idle rumliegen fuer hunderte von takten bis sie wieder dran sind, statt einfach ne laengere pipe fuer die ALUs zu machen.
Je mehr Pipeline-Stages, desto größer die ALU. Es ergibt keinen Sinn, eine ALU-Pipeline beliebig Tief zu machen, wenn man mit einer bestimmten Anzahl an Stages bereits den Zieltakt erreicht.
2.wieso sind pixelshader langsammer die mehr tmp-register nutzen obwohl sie keine texturen samplen, wenn es wie du behauptest keine latenz in der pipe gibt von mehr als das ist was was ein pixelpatch fuer einen durchgang braucht. dann duerfte es doch egal sein, ob du gerade die 512 "threads" hast oder nur z.b. soviel wie pixelshaderpipelines vorhanden sind.
Ab wievielen Temp-Registern ist dies denn der Fall?
micki
2007-05-16, 17:07:10
Nein, das ist eine ernsthafte Frage. Wenn das MUL-Ergebnis abgeschnitten wird, wie bekomme ich dann ein MUL mit Round-to-Nearest?wie ich schon die ganze zeit sage, das zwischengergebnis bei MAD wird grundsaetzlich truncated, deswegen ist es nicht IEEE-conform (du hast auch keine moeglichkeit es zu nearest zu runden).
(ich hoffe du verwechselt das nicht mit dem normalen mul.)
Oder wird von D3D10 kein fester Rundungsmodus gefordert (das weiß ich gerade nicht)?hmm... hat glaube ich eh keine relevanz fuer unser IEEE thema, oder?
Dort schrieb ich doch dass Skalarprodukte in IEEE754 nicht spezifiziert werden, also ich mich gerade nicht auf IEEE754 beziehen kann. Das ist doch auch was Tim Sweeney anmerkt, es gibt keinen Standard für DP4, weswegen die Gefahr besteht dass es unterschiedlich implementiert wird.nein, da vermischt du zwei sachen, skalarprodukt ist definiert, dp4 so wie es d3d fordert ist undefiniert. deswegen (wie er auch sagt) macht bei dp4 das jeder wie er lustig ist, waehrend intel weiter streng nach IEEE arbeitet.
Je mehr Pipeline-Stages, desto größer die ALU. Es ergibt keinen Sinn, eine ALU-Pipeline beliebig Tief zu machen, wenn man mit einer bestimmten Anzahl an Stages bereits den Zieltakt erreicht.es ist eher andersrum, die langsamste stage gibt den maximalen takt vor, es macht also keinen sinn das kuenstlich auf z.b. 8 zu limitieren, statt die stagezahl zu erweitern.
Ab wievielen Temp-Registern ist dies denn der Fall?hast du diese zahlen nicht schon laengst aus den quellen die du nicht angeben darfst?
da steht das gegenteil, IEEE legt fest wann gerundet wird, wenn MAD nicht mehr MUL+ADD oder DOT nicht mehr ADD(ADD(ADD(MUL(,),MUL(,)),MUL(,)),MUL(,)) entspricht, ist der MAD/DOT nicht standard-conform. klar, es ist irgendein MAD/DOT, aber eben keiner mehr der IEEE entspricht.
Es gibt beide Ops nicht in IEEE754. In IEEE754r soll deshalb extra ein MAD definiert werden.
Ich sag's dir nochmal: Intel könnte das ganz einfach selber festlegen und gut wäre.
Ohne dass er nach Ganzzahlwerten konvertiert wird und dadurch ein imenser Genauigkeitsverlust entsteht?
Also das auch wirklich der komplette FP32 Zahlenraum vom Tiefenpuffer für die ganze Pipeline nutzbar gemacht wird?
Ja und Ja.
micki
2007-05-16, 17:19:44
Es gibt beide Ops nicht in IEEE754. In IEEE754r soll deshalb extra ein MAD definiert werden.das haben wir oft genug geklaert.
Ich sag's dir nochmal: Intel könnte das ganz einfach selber festlegen und gut wäre.ich antworte dir gerne normal: sie koennen irgend ein befehl festlegen wie sie wollen, aber kein IEEE konformes MAD, da MAD aus MUL+ADD besteht und diese eindeutig definiert sind.
vielleicht verstehst du das besser auf anderem gebiet z.b. mathematik.
es gibt rechenvorschriften auf deren basis du formeln definieren kannst, diese sind dann weiter mathematisch korrekt. du darfst dir natuerlich auch formeln definieren die nach deinen eigenen regeln funktionieren und die machen was auch immer du willst, die sind dann aber nicht mehr zwangslaeufig mathematisch korrekt.
so ist das auch mit Intel und IEEE.
nein, da vermischt du zwei sachen, skalarprodukt ist definiert, dp4 so wie es d3d fordert ist undefiniert. deswegen (wie er auch sagt) macht bei dp4 das jeder wie er lustig ist, waehrend intel weiter streng nach IEEE arbeitet.
Es gibt keinen IEEE754-Standard für ein Dot-Product. Es gibt höchstens Compiler die von sich aus garantieren, dass von links nach rechts aufsumiert wird. Sonst gar nichts.
Ich hab keine Ahnung was der C-Standard dazu sagt, ob man die Reihenfolge der Adds in einer FP-Formel umsortieren darf oder nicht, aber das wäre an dieser Stelle das einzig maßgebliche für ein C-Programm.
Falls er links nach rechts garantiert, wäre ein DP4, dass das nicht so macht eine nicht sichere Optimierung, falls nicht ist die Reihenfolge völlig egal auf dem Chip. Dann muss der "Wissenschaftler" halt seine Numerik so anpassen dass es in allen Fällen passt - müsste er in diesem Fall ohnehin, weil es gar keine Garantie für die Reihenfolge geben würde.
das haben wir oft genug geklaert.
Haben wir nicht. Du wiederholst dich bloß. Ich will die Stelle in der IEEE754 sehen wo irgendwas über die Reihenfolge der Summe gesagt wird in einem Dot-Product, ansonsten lass das Gelaber bleiben.
ich antworte dir gerne normal: sie koennen irgend ein befehl festlegen wie sie wollen, aber kein IEEE konformes MAD, da MAD aus MUL+ADD besteht und diese eindeutig definiert sind.
Dann bräuchte man es nicht definieren:
http://de.wikipedia.org/wiki/IEEE_754r
"ein zusätzliches kumulierendes Produkt (fused multiply-add: FMA(A, B, C) = A·B + C)"
Momentan müssen sie nach IEEE die Präzision von dem Mul und dem Add einhalten, aber ob nach dem Add abgeschnitten wird oder nicht ist nicht festgelegt.
vielleicht verstehst du das besser auf anderem gebiet z.b. mathematik.
es gibt rechenvorschriften auf deren basis du formeln definieren kannst, diese sind dann weiter mathematisch korrekt. du darfst dir natuerlich auch formeln definieren die nach deinen eigenen regeln funktionieren und die machen was auch immer du willst, die sind dann aber nicht mehr zwangslaeufig mathematisch korrekt.
so ist das auch mit Intel und IEEE.
Ich weiß ganz genau was du meinst, aber ich sehe das trotzdem anders.
micki
2007-05-16, 18:54:10
Es gibt keinen IEEE754-Standard für ein Dot-Product. Es gibt höchstens Compiler die von sich aus garantieren, dass von links nach rechts aufsumiert wird. Sonst gar nichts.wie oft willst du das noch tippen?
Ich hab keine Ahnung was der C-Standard dazu sagt, ob man die Reihenfolge der Adds in einer FP-Formel umsortieren darf oder nicht, aber das wäre an dieser Stelle das einzig maßgebliche für ein C-Programm.
Falls er links nach rechts garantiert, wäre ein DP4, dass das nicht so macht eine nicht sichere Optimierung, falls nicht ist die Reihenfolge völlig egal auf dem Chip. Dann muss der "Wissenschaftler" halt seine Numerik so anpassen dass es in allen Fällen passt - müsste er in diesem Fall ohnehin, weil es gar keine Garantie für die Reihenfolge geben würde.es gibt eine garantierte reihenfolge bei c. (es gibt aber auch optimierungsswitches bei manchen compilern die das bei primitiven umgehen,bei anderen compiler wiederrum kannst du IEEE conformes madd forcieren, was bedeutet, wenn die cpu das nicht IEEE conform kann, wird mul+add benutzt)
Haben wir nicht.na gut, wenn es dir spass macht dann schreib es hier halt so oft rein wie du willst dass in IEEE irgendwelche funktionen nicht definiert sind.
ansonsten lass das Gelaber bleiben.wuerd ich sehr gerne, sobald es bei dir ankommt.
Dann bräuchte man es nicht definieren:
http://de.wikipedia.org/wiki/IEEE_754r
"ein zusätzliches kumulierendes Produkt (fused multiply-add: FMA(A, B, C) = A·B + C)"klar kann man es definieren, sogar als A+B+C. aendert nichts daran das MAD als substitution fuer MUL+ADD den selben IEEE regeln folgen muss bzw. die selben resultate innerhalb der tolleranz die in IEEE definiert ist liefern muss mit den selben rundungsregeln, falls es ein IEEE konformes MAD sein soll.
IEEE definiert instruktionen damit es einfacher ist sei zu imlpementieren. intel hat ein sehr genaues MAD (eigentlich FMA) doch weil es nicht die operationen durchfuehrt die MUL+ADD machen, ist es selbst beim Intelcompiler unbenutzt, falls IEEE-conformitaet verlangt wird.
Momentan müssen sie nach IEEE die Präzision von dem Mul und dem Add einhalten, aber ob nach dem Add abgeschnitten wird oder nicht ist nicht festgelegt.wenn MAD conform zu IEEE sein soll, ist das runden nach dem ADD (und sogar nach dem MUL) genau so zu machen wie bei den einzelbefehlen.
Ich weiß ganz genau was du meinst, aber ich sehe das trotzdem anders.
naja, ich sage dir nur was intel dazu gesagt hat. mir ist die ganze IEEE sache wumpe solange es schnell waere.
wie oft willst du das noch tippen?
So oft bis du mir irgendwo das Gegenteil beweist. Ich finde im ganzen Internet nichts dazu.
wenn MAD conform zu IEEE sein soll, ist das runden nach dem ADD (und sogar nach dem MUL) genau so zu machen wie bei den einzelbefehlen.
Mit höherer Präzision darfst du immer rechnen.
es gibt eine garantierte reihenfolge bei c.
Also. Dann ist das das Problem und nicht das IEEE.
EOD.
wie ich schon die ganze zeit sage, das zwischengergebnis bei MAD wird grundsaetzlich truncated, deswegen ist es nicht IEEE-conform (du hast auch keine moeglichkeit es zu nearest zu runden).
(ich hoffe du verwechselt das nicht mit dem normalen mul.)
Ich fragte, wie man ein konformes MUL-Ergebnis bekommt wenn das MUL-Zwischenergebnis abgeschnitten wird.
hmm... hat glaube ich eh keine relevanz fuer unser IEEE thema, oder?
Das Thema ist doch, was von D3D-Hardware gefordert wird.
nein, da vermischt du zwei sachen, skalarprodukt ist definiert, dp4 so wie es d3d fordert ist undefiniert. deswegen (wie er auch sagt) macht bei dp4 das jeder wie er lustig ist, waehrend intel weiter streng nach IEEE arbeitet.
Skalarprodukt ist von wem definiert? IEEE754 definiert es nicht. Mathematiker definieren nicht die Ausführungsreihenfolge, bei der Addition gilt für sie immer noch das Assoziativgesetz.
es ist eher andersrum, die langsamste stage gibt den maximalen takt vor, es macht also keinen sinn das kuenstlich auf z.b. 8 zu limitieren, statt die stagezahl zu erweitern.
Was ist daran jetzt andersrum?
Der Takt wird nicht nur durch den kritischen Pfad der ALU-Pipeline-Stages limitiert, und es ist auch nicht sinnvoll ALUs in beliebig viele Stages aufzuteilen.
hast du diese zahlen nicht schon laengst aus den quellen die du nicht angeben darfst?
Ich arbeite nicht bei NVidia.
micki
2007-05-18, 15:30:33
So oft bis du mir irgendwo das Gegenteil beweist. Ich finde im ganzen Internet nichts dazu.
da ich weiss dass es keinen expliziten standard fuer dot gibt im IEEE, bin ich die ganze zeit deiner meinung darueber und hab nicht das verlangen entgegen der tatsache etwas zu beweisen.
standardconform zu sein heisst nicht dass alles im standard definiert ist, sondern dass etwas den standard nicht bricht. du kannst auch 5+3 nach den regeln der mathematik rechnen ohne dass irgendwo explizit 5+3 definiert ist.
Mit höherer Präzision darfst du immer rechnen.ich schreibe etwas ueber den rundungszwang und du uber praezision, hoe?
Also. Dann ist das das Problem und nicht das IEEE.
nein, das ist kein problem. c richtet sich nur nach der mathematik und das dotproduct ist als sume der faktoren in der mathematik definiert. die summenfunktion ist dabei auch wohl definiert.
Was soll das? Xmas hat's doch auch schon gesagt:
Skalarprodukt ist von wem definiert? IEEE754 definiert es nicht. Mathematiker definieren nicht die Ausführungsreihenfolge, bei der Addition gilt für sie immer noch das Assoziativgesetz.
Wo ist irgendwo in "der Mathematik" definiert in welcher Reihenfolge ich meine Summen auszurechnen habe? Richtig: Nirgends.
micki
2007-05-18, 15:54:57
Ich fragte, wie man ein konformes MUL-Ergebnis bekommt wenn das MUL-Zwischenergebnis abgeschnitten wird.axo, sorry, zu diesem thema hab ich mich nie geaeussert und kann dir da auch nicht weiterhelfen.
Das Thema ist doch, was von D3D-Hardware gefordert wird.
der ausgang unserers dialoges ist intels behauptung MAD+DOT ist nicht IEEE konform wenn nach den einzelnen (sub)instruktionen nicht genau so gerundet wird in den zwischenergebnissen wie es bei seperaten aufrufen von MUL+ADD usw. gemacht wird und dein einwurf dass MAD+DOT garnicht IEEE konform sein koennen weil sie nicht explizit definiert sind. siehe:
ich glaube eigentlich sind sie konform, jedoch aufgrund von zusammenlegung von befehlen dann zu ungenau bzw falsch (z.b. ist mad ungenauer als mul+add und dot4 wird oft akkumuliert als (x+y)+(z+w) was falsch ist und ((x+y)+z)+w sein muss.)MAD ist möglicherweise genauer als MUL+ADD, weil mehr Bits des Zwischenergebnisses beibehalten werden. Ungenauer sollte es in keinem Fall sein.
Skalarprodukte werden von IEEE754 nicht spezifiziert und können deshalb auch in anderer Reihenfolge ausgeführt werden. Zumindest G80 sollte aber immer ((x+y)+z)+w rechnen.
Skalarprodukt ist von wem definiert? IEEE754 definiert es nicht. Mathematiker definieren nicht die Ausführungsreihenfolge, bei der Addition gilt für sie immer noch das Assoziativgesetz.skalarproduct ist mathematisch definiert und baut fuer CPUs auf IEEE auf.
Was ist daran jetzt andersrum?
dass der takt von den ALUs(bzw andere komponenten) vorgegeben wird und nicht dass man nen zieltakt hat und die ALUs werden angepasst. solche iterationen waeren zu teuer. natuerlich gibt es berechnungen wie man etwas designen soll, damit der takt so ist wie gewuenscht, aber gerade deswegen macht man (zumeist) unkritische dinge nicht extra knapp wie z.b. die ALUs-stage-anzahl.
Der Takt wird nicht nur durch den kritischen Pfad der ALU-Pipeline-Stages limitiert, und es ist auch nicht sinnvoll ALUs in beliebig viele Stages aufzuteilen.
aber es ist wirklich bloedsinnig die stagezahl irgendwie zu limitieren sodass sie jemals zur kritischen stelle werden koennten fuer den takt. deswegen hat man eben eine ziemlich grosse latenz die fast immer nicht stoert.
Ich arbeite nicht bei NVidia.sagt ja auch niemand, ich dachte nur, wenn du schon die cachearchitektur und effiziens so genau errechnen zu koennen glaubst und dann hier (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5494862&postcount=109) meinst quellen zu haben, dann wirst du doch ueber sowas verbreitetes ebenfalls wissen.
micki
2007-05-18, 15:55:50
Wo ist irgendwo in "der Mathematik" definiert in welcher Reihenfolge ich meine Summen auszurechnen habe? Richtig: Nirgends.
hmmm
in dem punkt habt ihr wohl recht, ich weiss nicht wie i... drauf kam das zu behaupten, vielleicht haben sie es doch auf die meisten programmiersprachen bezogen.
dass der takt von den ALUs(bzw andere komponenten) vorgegeben wird und nicht dass man nen zieltakt hat und die ALUs werden angepasst. solche iterationen waeren zu teuer. natuerlich gibt es berechnungen wie man etwas designen soll, damit der takt so ist wie gewuenscht, aber gerade deswegen macht man (zumeist) unkritische dinge nicht extra knapp wie z.b. die ALUs-stage-anzahl.
aber es ist wirklich bloedsinnig die stagezahl irgendwie zu limitieren sodass sie jemals zur kritischen stelle werden koennten fuer den takt. deswegen hat man eben eine ziemlich grosse latenz die fast immer nicht stoert.
Beim Takt sind auch solche sachen wie Stromverbrauch und Hitzeentwicklung zu beachten, außerdem wollen die ALUs ja auch gefüttert werden. Daswegen hat man durchaus eine gewisse Region als Zieltakt. Da man den Takt nicht beliebig hoch treiben kann, lohnt es sich auch nicht die ALU-Stages extrem kurz zu machen, sondern man macht sie so lange dass sie gerade nicht limitieren.
sagt ja auch niemand, ich dachte nur, wenn du schon die cachearchitektur und effiziens so genau errechnen zu koennen glaubst und dann hier (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5494862&postcount=109) meinst quellen zu haben, dann wirst du doch ueber sowas verbreitetes ebenfalls wissen.
Ich kenne Simulationsergebnisse bestimmter Architekturen. Natürlich verhalten sich andere Architekturen anders, ich fände es aber vermessen anzunehmen dass diese mehrfach höhere Bandbreitenanforderungen pro Texturzugriff hätten.
Wie sich ein G80 bei vielen benötigten Temp-Registern verhält ist mir allerdings nicht bekannt.
(z.b. ist mad ungenauer als mul+add und dot4 wird oft akkumuliert als (x+y)+(z+w) was falsch ist und ((x+y)+z)+w sein muss.)
Warum ist das falsch?
Das Ergebnis ist doch das selbe.
Erste Berechnung hat sogar den Vorteil, daß sie schneller ist,
da man (x+y) und (z+w) parallel in einem eigenen Thread berechnen kann, während man bei letzterer jedesmal auf das Ergebnis warten muß.
Mit Parallelisierung sind es bei der ersten Formel nur 2 Schritte, bei der letzteren 3.
Das Ergebnis ist doch das selbe.
Ist es für Fließkommazahlen nicht immer.
Da es sonst in der Diskussion um Spezifikationen geht ist es ganz einfach:
Link her oder es kann jeder machen wie er lustig ist.
skalarproduct ist mathematisch definiert und baut fuer CPUs auf IEEE auf.
Mathematische Definitionen sind üblicherweise die von notwendigen und hinreichenden Eigenschaften. So ein mathematisches Skalarprodukt gibt es aber nicht auf Fließkommazahlen.
Man kann irgendeine operationelle Definition nehmen und die dann per IEEE auf Fließkommazahlen abbilden, aber welche operationelle Form man nimmt ist grundsätzlich offen und es gibt unendlich viele mögliche.
Warum ist das falsch?aufgrund von Rundungen.
Das Ergebnis ist doch das selbe.kann leicht abweichen.
Erste Berechnung hat sogar den Vorteil, daß sie schneller ist,
da man (x+y) und (z+w) parallel in einem eigenen Thread berechnen kann,das machen schon speziell ausgelegte recheneinheiten so, ein extra Thread ist zuviel overhead.
während man bei letzterer jedesmal auf das Ergebnis warten muß.genau das war der punkt bei dieser Diskusion.
Mit Parallelisierung sind es bei der ersten Formel nur 2 Schritte, bei der letzteren 3.wegen der Latenz ist letztere sogar noch schlimmer.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.