Speicherung FX12, und weitere Fragen (FP24, FP32)

[aths]

Wie ist FX12 aufgebaut? Sign, Vorkomma, 10 Bits Nachkomma, so dass man +0 und -0 hat? Oder wird mittels Zweierkomplement-Darstellung gearbeitet?

[Demirug]

Ich habe jetzt extra nochmal nachgeschaut wie FX12 genau definiert ist.

values in the range [-2,+2) are represented as signed values with 10 fraction bits.

und nochmal genauer:

numbers are represented as signed 12-bit two's complement integers with 10 fraction bits. The range of representable values is [-2048/1024, +2047/1024].

Es gibt also genau eine 0. (Ich weiss das ich mir da vor kurzem nicht sicher war)

[aths]

Danke. Also 1,0 sieht dann so aus:

0 1 0000 0000

und 1,996 sieht so aus:

0 1 1111 1111

und -2 sieht so aus:

1 1 0000 0000

Stimmt das alles?



Unterstützt FP24 im R300 eine denormalisierte Mantisse? Welches Bias wird für den Exponenten genommen?

Welches Bias hat FP32 bei NV? -127 nach IEEE-Standard?

[Demirug]

NV FP32:

32-bit floating point precision (fp32) uses the IEEE single-precision standard with a sign bit, 8 exponent bits, and 23 mantissa bits.

In the 32-bit float (fp32) representation, each component is represented in floating-point with eight exponent and twenty-three mantissa bits, as in the standard IEEE single-precision format. If S represents the sign (0 or 1), E represents the exponent in the range [0,255], and M represents the mantissa in the range [0,2^23-1], then an fp32 float is decoded as:

(-1)^S * 0.0, if E == 0,
(-1)^S * 2^(E-127) * (1 + M/2^23), if 0 < E < 255,
(-1)^S * INF, if E == 255 and M == 0,
NaN, if E == 255 and M != 0.

INF (Infinity) is a special representation indicating numerical overflow.
NaN (Not a Number) is a special representation indicating the result of illegal arithmetic operations, such as division by zero. Note that all normal fp32 values, zero, and INF have an associated sign. -0.0 and +0.0 are considered equivalent for the purposes of comparisons.
This representation is identical to the IEEE single-precision floating-point standard, except that no special representation is provided for denorms -- numbers in the range (-2^-126, +2^-126). All such numbers are flushed to zero.

NV FP16:

16-bit floating-point precision (fp16) uses a similar floating-point representation, but with 5 exponent bits and 10 mantissa bits.

In a 16-bit float (fp16) register, each component is represented similarly, except with only five exponent and ten mantissa bits. If S represents the sign (0 or 1), E represents the exponent in the range [0,31], and M represents the mantissa in the range [0,2^10-1], then an fp32 float is decoded as:

(-1)^S * 0.0, if E == 0 and M == 0,
(-1)^S * 2^-14 * M/2^10 if E == 0 and M != 0,
(-1)^S * 2^(E-15) * (1 + M/2^10), if 0 < E < 31,
(-1)^S * INF, if E == 31 and M == 0, or NaN, if E == 31 and M != 0.

One important difference is that the fp16 representation, unlike fp32, supports denorms to maximize the limited precision of the 16-bit floating point encodings.

NV Überläufe und Konvertierung:

In case of overflow, the original value is clamped to the +/-INF (fp16 or fp32) or the nearest representable value (fx12). In case of imprecision, the conversion is either to round or truncate to the nearest representable value.

NV Denorms:

For 32-bit data types, hardware support for denorms was considered too expensive relative to the benefit provided. Computational results that would otherwise produce denorms are flushed to zero. For 16-bit data types, hardware denorm support will be present. The expense of hardware denorm support is lower and the potential precision benefit is greater for 16-bit data types.

So jetzt hast du mich leergesaugt.

Für ATIs FP24 habe ich nichts zur Hand.

[Xmas]

Original geschrieben von aths
Danke. Also 1,0 sieht dann so aus:

0 1 0000 0000

und 1,996 sieht so aus:

0 1 1111 1111

und -2 sieht so aus:

1 1 0000 0000

Stimmt das alles?
Die ersten beiden stimmen, das letzte ist -1, nicht -2.

[Chris Lux]

zu den ganzen habe ich gleich auch noch eine frage.

wenn ich in einem (nv-) fragmentprogram eine texture im fixed format (12bit fixed) sample kann es bei einer simplen addition schon zu rundungs (besser saturierungs)-fehlern kommen. sehe ich das richtig?

[Demirug]

Original geschrieben von Hans Ohlo
zu den ganzen habe ich gleich auch noch eine frage.

wenn ich in einem (nv-) fragmentprogram eine texture im fixed format (12bit fixed) sample kann es bei einer simplen addition schon zu rundungs (besser saturierungs)-fehlern kommen. sehe ich das richtig?

Du kannst gar nicht im Fixed Format samplen. Das Ergebniss einer Textureoperation ist ein FP16 oder ein FP32 Wert.

Zudem kommt es ja auch noch darauf an in welchem Format die textur vorliegt. Beim 32Bit RGBA Format ist der Zahlenraum ja sowieso nur von 0 bis 1. Da kann man also durchaus auch mit FX12 noch eine Addition durchführen ohne das etwas passiert.

[aths]

Texturen werden ohnehin gefiltert. Ob man das Ergebnis als FX9 oder FX12 speichert, ist praktisch egal, FX12 ist aber genauer.

[Chris Lux]

Original geschrieben von Demirug
Du kannst gar nicht im Fixed Format samplen. Das Ergebniss einer Textureoperation ist ein FP16 oder ein FP32 Wert.

Zudem kommt es ja auch noch darauf an in welchem Format die textur vorliegt. Beim 32Bit RGBA Format ist der Zahlenraum ja sowieso nur von 0 bis 1. Da kann man also durchaus auch mit FX12 noch eine Addition durchführen ohne das etwas passiert.

im FP30 profil (nv30) kann man das (x4texRECT()). der witz dabei ist, dass man eben die textur sample im fixed format hat und damit gleich rechnen kann (ohne konvertierungen).

fx12 ist ja wie oben geschrieben s1.10, also wird es bei werten 0.9 + 0.9 fehler geben oder? weil ja auf 1 geclampt wird. (es geht im interne berechnungsfehler wie bei filtern).

edit: die cg doku widerspricht sich an dieser stelle, im introduction teil steht s1.10 und im language spec (appendix a) steht bereich von mindestens [-2,2) und 10bit nachkomma genauigkeit.

[aths]

Original geschrieben von Hans Ohlo
im FP30 profil (nv30) kann man das (x4texRECT()). der witz dabei ist, dass man eben die textur sample im fixed format hat und damit gleich rechnen kann (ohne konvertierungen).

fx12 ist ja wie oben geschrieben s1.10, also wird es bei werten 0.9 + 0.9 fehler geben oder? weil ja auf 1 geclampt wird. (es geht im interne berechnungsfehler wie bei filtern).0.9 ist in FX12 00.1110011010 (bzw. 0.900390625, genauer geht es nicht.) 00.1110011010 + 00.1110011010 = 01.1100110100 (entspricht ja shl 1, bzw. << 1), also 1.80078125. Mit FX12 kann man Zahlen von -2 .. 1.999 darstellen. BTW wird es bald einen Artikel auch zu diesem Thema geben :)

[Chris Lux]

Original geschrieben von aths
0.9 ist in FX12 00.1110011010 (bzw. 0.900390625, genauer geht es nicht.) 00.1110011010 + 00.1110011010 = 01.1100110100 (entspricht ja shl 1, bzw. << 1), also 1.80078125. Mit FX12 kann man Zahlen von -2 .. 1.999 darstellen. BTW wird es bald einen Artikel auch zu diesem Thema geben :)

oh gott ;) wuzu studier ich schon 4 jahre? ich saß wohl auf meinem hirn wie ich das gefragt habe.

aber danke für die artikel sind immer sehr hilfreich und aufschlussreich. weiter so!