WinHEC slides give info on early spec of DX in longhorn

[Sage]

But when talking about specification of futre requirements having a "better vision" makes little difference if that vision can't achieve compliance.

Let me put it more clearly: the NV40 has a featureset that is more in tune with DirectX Next than the R420, period. That is a fact. A fact can be downplayed, but it is a fact nonetheless. I think it has already been clearly established that both the NV40 and R420 will not be "fully" compliant with DirectX Next.

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.

 

[FUDie]

I believe IEEE 754 covers FP16, not FP24

Nope, it doesn't cover either.

IEEE 754 : 7+5+4 = 16

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

 

[Tim Murray]

But when talking about specification of futre requirements having a "better vision" makes little difference if that vision can't achieve compliance.

Let me put it more clearly: the NV40 has a featureset that is more in tune with DirectX Next than the R420, period. That is a fact. A fact can be downplayed, but it is a fact nonetheless. I think it has already been clearly established that both the NV40 and R420 will not be "fully" compliant with DirectX Next.

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.

 

[psurge]

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).

 

[Ailuros]

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

 

[Ilfirin]

whodawhat?

 

[gokickrocks]

I believe IEEE 754 covers FP16, not FP24

Nope, it doesn't cover either.

-FUDie

IEEE 754 : 7+5+4 = 16

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)

 

[bloodbob]

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 ).

 

[Pete]

IEEE 754-1985

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.

 

[Bjorn]

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?

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.

Do you think DX Next-oriented games will be easier on the GPU than UE3, or will even show up around Longhorn's debut?

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.

 

[krychek]

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.

 

[Nappe1]

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... )

 

[aaronspink]

I'd like to invite those who in the past have argued in these forums that IEEE FP compliance is unnecessary and a waste of performance/transistors to justify their arguments in the light of the above slide. I'd also like them to address their statements that certain cards would continue to be more capable than others in the future.

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.

 

[aaronspink]

I believe IEEE 754 covers FP16, not FP24

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

 

[GameCat]

IEEE 754 : 7+5+4 = 16

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.

 

[Simon F]

I believe IEEE 754 covers FP16, not FP24

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)

 

[Simon F]

Oh, gotta love those denormals, without denormals the world would fall over....

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.

 

[aaronspink]

Oh, gotta love those denormals, without denormals the world would fall over....

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.

 

[Ailuros]

whodawhat?

 

[mrbill]

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