WinHEC slides give info on early spec of DX in longhorn

which is preciesly why it doesnt matter which is closer... if they can't do it then they can't do it. We're not talking SM2 to SM3 here, we're talking fixed function to SM2.

 

What is that supposed to mean? The fact that the numbers add up to 16 is supposed to mean something? I guess then that the Porsche 911 only has 11 horsepower?

Why not try to back up your claim with a link? I looked around and found nothing to imply that FP16 is covered by IEEE 754, only FP32 and FP64.

-FUDie

 

The fact is totally irrelevent. It won't support it. It won't support any part of the New 3D Features Introduced In DX Next Like SM4.0 And What Have You. It'll be the same old SM3.0 card. So NV40 is possibly a better stepping stone to a DX Next card than R420--point? Remember that PS2.0 card called the NV3(takeyourpick) that came right before the NV40? It's totally irrelevent.

 

Sage, apologies if my comment came off as abrupt - I actually wasn't intending to support/rebut any FP related arguments.

Anyway it will also be interesting to see what integer precision is supported (since integer mul/div are going to make it).

 

I hope Ilfirin or someone else will have the time to write an article about it

 

whodawhat?

 

it doesnt actually cover any precision..."IEEE 754-1985 governs binary floating-point arithmetic. It specifies number formats, basic operations, conversions, and exceptional conditions"...dont take number format to equate to precision, it is actually referring to the layout of it (ie: sign bit, exponent, mantissa)

 

GPU to potentially become the future prime number crunchers?

Well since they are going to have signed 32 bit int support in DX Next couldn't we start using Arbitary precision libaries on them? ( of course 64bit int support would be better ).

 

Whoa, whoa, whoa--back that truck up. 7 + 5 + 4 + 1 + 9 + 8 + 5 = 39. FP39!

Wait....

Seriously, I think it's more important to note that SM2.0 is the minimum spec for Longhorn than it is to bicker over who's less noncompliant. Look, UE3 is supposed to crystallize into a game in 2006, circa Longhorn. Do you think 20-30fps on a 6800U will be a big deal then? Do you think DX Next-oriented games will be easier on the GPU than UE3, or will even show up around Longhorn's debut?

Most imoprtantly, what does the fan sniping over who's less of a loser when it will come to DX Next have to do with this topic? Wow, the Radeon 8500 was a visionary in the SM1.0 generation. Fat lot of good it did it for SM2.0.

 

It might be for the people that keeps their cards for more then 2 years.
Just look at the R9700, is that not a card to reckon even to this date ? It's a much better card then current budget cards.

I think that the next gen consoles will dictate what most games will support over the upcoming 3-4 years. I hope that they'll be DX Next though so that we'll get a quick ramp with DX Next supporting games.

 

Very interesting slides. So we will be getting the topo processor for sure!
The new features are really great, esp the way memory can be used.

 

Based on some information at those slides, it does not matter if you are partially compliant. Only full compliancy will be remarkable from DirectX Next. (No Cap Bits, would indicate that partially compliant devices will be handled as an older HW with full support some lower level DX.)


you can fight to end of the world about partial compliancy. for example, if we start looking back, Even GF4MX was only partially compliant with DX6, because DX6 Bump Mapping was not supported. (on the ATI's side it's much harder to find these kind of problems, because they at least tried to support everything new as soon as API revealed it. EDIT: until SM 3.0 came... )

 

Do you even know what full IEEE FP compliance is?

Bye bye FMAC. FMAC is NOT fully IEEE FP compliant.
That full NAN and INF propagation capability will sure come in handy I tell ya.
Oh, gotta love those denormals, without denormals the world would fall over....

In no way do CPUs NOR GPUs need to be fully IEEE FP compliant. They should trap on NAN and INF and they should trap on denormals.

The main point of the IEEE FP standard is to have a consistant and somewhat mathmatically correct modal for FP calculations. They went a little overboard though in the actual implementation.

Aaron Spink
speaking for myself inc.

 

Neither FP16 nor FP24 are defined in the IEEE specification...

The formats that are specified are:

Single precision FP 1+7+24 32b FP format.
Double Precision FP 1+10+53 64b FP format.
Extended Double precision 1+10+>53 <64b FP format

Can't remember is Quad precision is actually defined. Been a couple of years since I looked at the spec.

The important point for graphics though isn't the defined formats, but the methods and apparatus used to calculate the results and preserve the mathmatical integrity of the calculations.

Aaron Spink
speaking for myself inc

 

You're not serious are you? I'd hate for you to be so stupid to actually believe this... the full name of the standard is IEEE 754-1985 so it obviously covers 7+5+4+1+9+8+5=39 bit floating point numbers.

Or just maybe, 754 is the standard's number and 1985 is the year it was published and you don't have a clue what you're talking about.

IEEE 754 covers both single and double precision floating point formats, 32 and 64 bits respectively and specifies the exact bit layout of these formats.

 

Absolutely not.

I have the IEEE Std 754-1985 specification "IEEE Standard for Binary Floating-Point Arithmetic" sitting open in front of me and I can safely say that it does not discuss an "FP16" standard.

It does, however, list:

• Single (i.e. 32Bit giving a mantissa precision of 24 bits),
• Single Extended (i.e. mantissa >= 32 bits)
• Double (64bits so mantissa precision of 53 bits) AND
• Double Extended (mantissa >= 64 bits precision)

 

Arghh! I hate them. I don't know about the world, but with denormals my texture compressor code fell over.

Why weren't they symmetrical in terms of reciprocals? I'd do a check for (X!=0) and then compute (1/X) only to find that because X was a denorm I got INF instead of a valid answer. Bleaghhh.

 

Well, I was being sarcastic. Denorms are a nightmare without benefit. The original point was to gracefully degrade to the value of Zero, but the end result is programming issues like you've outlines as well as significantly more hardware complexity and corner cases. Most architectures (ie anything not x87 which the standard was based on), have the option to either trap on denorm or flush to zero. The feeling being that if you really want denorms then you can do them in software.

Aaron Spink
speaking for myself inc.

 

Vertex Shaders, Fragment Shaders and Trap Shaders?

-mr. bill