Is partial precision dead?

[Dave Baumann]

I have no idea yet what D3D10 requires and/or allows to be frank, but it has been my understanding so far that Microsoft doesn't take those decisions alone (rather M$ + IHVs) and that NVIDIA wasn't the only party that was in favour of split precision formats in the past.

Is SGX FP32 across the board by the way (yes that's an honest question, because the PR's mentioned "up to"....).

I believe, although I'm not certain, that SM4.0 will be FP32 only. However, that doesn't mean that partial precision will just disappear because SM2.0 and SM3.0 dont just disappear with SM4.0 - they will continue to operate and, presumably, continue to be viable compile targets under HLSL. I'd say that its an ineviability that all IHV's will target floating point performance will be primarily targetted to FP32 at some point - the question will be, should SM4.0 be single precision, whether all IHV's gen 1 DX10 hardware target that, or still target to get performance increases with partial precision.

 

[Xmas]

I believe, although I'm not certain, that SM4.0 will be FP32 only. However, that doesn't mean that partial precision will just disappear because SM2.0 and SM3.0 dont just disappear with SM4.0 - they will continue to operate and, presumably, continue to be viable compile targets under HLSL. I'd say that its an ineviability that all IHV's will target floating point performance will be primarily targetted to FP32 at some point - the question will be, should SM4.0 be single precision, whether all IHV's gen 1 DX10 hardware target that, or still target to get performance increases with partial precision.

The docs from the December SDK don't give a clear answer, but I also believe that D3D10 will require the basic math operations to be performed with IEEE float precision. Special operations like normalize might be different, though.
Half still exists as a HLSL datatype (double and int as well, and integer support in HW is required) and compiler fxc10 still accepts the /Gpp force partial precision flag, but that might be just for backwards compatibility.

Back to the other one since I found the PR snippet:

http://www.imgtec.com/news/Release/index.asp?ID=259

Awaiting possible clarification from any PVR employee, if I'm reading the above correctly.

Hmmm, I like the part about "arbitrary pixel colour precision"... I guess few people think FP29 is very useful

 

[Ailuros]

You might as well ask the gentleman who wrote that PR yourself

 

[Ailuros]

Are there two? Is this one different than the one that existed before it was G80 and then became NV50 again?

It's my understanding that NV-whatever codenames disappeared after NV40. INQ might have reported that NV47 and NV50 were "cancelled", yet Rivatuner (as you probably know for a long time now) reports the G70 here as a "NV47". Now give me a good reason why I should expect a NV50 and not a G80 instead

 

[JHoxley]

The docs from the December SDK don't give a clear answer, but I also believe that D3D10 will require the basic math operations to be performed with IEEE float precision.

Well the documentation is for the API, you'd have to look at the functional specification for this sort of information. To answer the question though - it's a subset of IEE754 at 32bit/single precision. All calculations are done this way and the only variation is in storage not processing.

I'm also pretty sure that SM1/SM2/SM3 profiles are not valid targets under D3D10. I'm sure the hardware will still support them (for legacy reasons), but I don't see any point for D3D10 applications to use anything other than SM4.

hth
Jack

 

[Xmas]

Well the documentation is for the API, you'd have to look at the functional specification for this sort of information. To answer the question though - it's a subset of IEE754 at 32bit/single precision. All calculations are done this way and the only variation is in storage not processing.

Storage in registers or in buffers? If it's the former, it still means that processing can be done with reduced precision.

I'm also pretty sure that SM1/SM2/SM3 profiles are not valid targets under D3D10. I'm sure the hardware will still support them (for legacy reasons), but I don't see any point for D3D10 applications to use anything other than SM4.

Yes SM4 should be the only valid target. But fxc10 does still have the /Gpp force partial precision switch. And half is still in HLSL.

 

[Mintmaster]

There is one case where FP16 precision may continue to find value -- normalization.

One aspect of shaders increasing ALU : TEX ratio is the replacement of cube map normalization (or no normalization at all) with ALU normalization. It turns out, that in most cases, no more than 17-bits is needed to represent all the normals you will need in the vast majority of cases. Because normals don't need much precision, and because normals have 48-fold symmetry, the total number of unique normals are about 2,000 (which are blown up to ~100k via symmetry) This is a small enough number to enable hardware lookup table implementations.

You won't get anywhere near 17 bits accuracy with FP16, will you? Near the 8 (+-a, +-a, +-a) directions (a = 1/sqrt(3)) you only get around 1/4000 spacing for each component. Near axis at least one component will have only 11 bit accuracy.

I also have a hard time believing 100k unique normals are enough for the whole sphere. 10^-4 steridians creates an cone which spans an angle of just under 1 degree. A specular surface can change from full brightness to complete darkness angles in a few degrees, so you'll get single digit shades of grey. If you're doing a reflection calculation for a texture lookup, you'll easily see discontinuities in the reflected image.

On a highly bumpy surface where the highlights are tiny, I'll agree with you. But any smooth specular surface that's gone through polybump will be ugly with only 100k unique normals. I can't imagine you getting even 8-bit accuracy here (one degree is huge!). If you're talking about linearly intepolating afterwords, that makes sense, but you still need to do some high precision math to determine your interpolation weights. It seems like you got this information from some sort of paper, so I'd love to see your source or rationale.


Anyway, I think special hardware for normalization won't be that useful in the future. Most of the time you don't need to do a lot of normalizing in long shaders (at least not low precision). It'll be most useful for short lighting shaders with low specular exponents where normalizations form an appreciable percentage of the calculations, but these are executed quickly now anyway. NV40/G70 were introduced when short lighting shaders were very common, e.g. the whole screen in Doom3.

 

[Geo]

Now give me a good reason why I should expect a NV50 and not a G80 instead

I can't give you a "good" reason. However, it's been my observation over the last two months or so that "NV50" has been reappearing as the preferred code name in public discussion/reports, rather than "G80". Personally, I hope it does stay "G80" as I'm not a big fan of switching-up twice in so short a time. We'll see, I guess.

I also tend to wonder --tho I haven't seen reports on it-- if one or both IHVs will take the opportunity of Vista to change "GeForce" and/or "Radeon" as the name of their graphics line. If it is going to be done at all, this would seem to be the time to do it.

 

[Ailuros]

We are obviously in a Gx0-"era" when it comes to NV's codenames.

As for name changes, how about GPVPU and GPGPU accordingly? *snicker*

 

[Martin Eddy]

Coincidently Hanners over at Elite Bastards just posted news about partial precision going the way of the dodo with DX10.

 

[Farid]

FP16 and FP24 are getting the axe.

BTW, let's not post links to filthy Ati fansites like EB.

 

[Martin Eddy]

FP16 and FP24 are getting the axe.

BTW, let's not post links to filthy Ati fansites like EB.

No worries "Fetch4 Moderator"

 

[Hanners]

BTW, let's not post links to filthy Ati fansites like EB.

That's a bit harsh... We happen to be a very clean and shiny ATI fansite.

 

[JHoxley]

Storage in registers or in buffers? If it's the former, it still means that processing can be done with reduced precision.

I suppose it's pointless to bring it up now that it's been confirmed, but I meant storage as in buffers. Textures with the DXGI_FORMAT_R16G16B16A16_FLOAT format for example.

Yes SM4 should be the only valid target. But fxc10 does still have the /Gpp force partial precision switch. And half is still in HLSL.

Doesn't necessarily mean anything - from what I understand, the API is still in a state of change and various bits and pieces haven't been finalised yet. It's quite possible that flag is a left-over for legacy reasons or from before they finalised the FP conformance.

Jack

 

[Rys]

We are obviously in a Gx0-"era" when it comes to NV's codenames.

I'd say we're obviously in nothing of the sort.

 

[digitalwanderer]

That's a bit harsh... We happen to be a very clean and shiny ATI fansite.

Well to be fair it has been a rather long weekend for me and I am a bit gamey...

 

[Geo]

I'd say we're obviously in nothing of the sort.

I'm beginning to wonder if the only reason we saw "G70" was because they'd burned "NV45" for something inconsequential from a performance increase pov, and just didn't feel "NV47" did justice to what eventually became "G70".

 

[HaLDoL]

I can't give you a "good" reason. However, it's been my observation over the last two months or so that "NV50" has been reappearing as the preferred code name in public discussion/reports, rather than "G80". Personally, I hope it does stay "G80" as I'm not a big fan of switching-up twice in so short a time. We'll see, I guess.

I also tend to wonder --tho I haven't seen reports on it-- if one or both IHVs will take the opportunity of Vista to change "GeForce" and/or "Radeon" as the name of their graphics line. If it is going to be done at all, this would seem to be the time to do it.

Nvidia changed NV to the G prefix to diffentiate graphic processors from motherboard chipsets.
G for gpu's, C for chipsets. Can't see any reason to change it all back to NV.

 

[Razor1]

I think they just changed the names around to confuse the hell out of everyone lol, seems like they did a very good job and getting people to guess

 

[Geo]

http://www.digitimes.com/news/a20051219A2007.html

Here's an example of what I'm talking about. All those G code names in this article, six months after G70 release, and yet "NV50" pops up at the end.

Definitive? Hell no. Indicative? Could be. Digitimes certainly isn't perfect, but they aren't Inq either (and, btw, Inq has been leaning back towards NV50 too).