FP blending in R420?

[KimB]

FP16 is not an industry standard. There's no IEEE spec for it. That goes for FP24 as well but at least it is the minimum spec for full precision in DX9.

-FUDie

And FP16's the minimum spec for partial precision. I don't see how your statement means anything.

 

[KimB]

If the shader contains a divide operation and infinity (divide by zero) is written to the FP framebuffer, how is this handled? How are these values then filtered? How are they blended? Andy's question is quite valid.

Well, if the buffer format supports +inf, then it's going to have to write +inf to the framebuffer. If not, then it'll have to write the maximum floating point value.

 

[andypski]

In relation to the filtering: I know that you were talking about FP filtering, so was I - I'm saying that if you pretend R420's FP texturing capabilities were integer ones, then even a Virge has it beat capability wise. In other words I don't think the R420's FP texturing is worth a crumpet in the real world.

So any card that, for example, didn't support the full D3D texture addressing capabilities (you know, wrap, clamp, non-pow2 etc.) also has texturing that isn't worth a crumpet, right? After all, these addressing modes have been around for a long time now, so you would expect them to be pretty much fully supported for all formats, yes?

 

[ERP]

nVidia has brought FP framebuffers and FP filtering anf HDR rendering to consumers by way of proven, established, standardized technologies that have a track record of working.

How do they handle divide by zero?

Just curious, as I have to admit that I actually don't know yet...

Why would you ever deal with a divide by zero when talking about blending and filtering?

If the shader contains a divide operation and infinity (divide by zero) is written to the FP framebuffer, how is this handled? How are these values then filtered? How are they blended? Andy's question is quite valid.

I would expect that since the blend is just math ops, it should work the same way it does in the shader.

And how is that? On a CPU, you can generate an exception if you divide by zero. Also, underflow and overflow can be handled. How are these same problems solved in the shader?

However from my standpoint if I were generating infinity as the output of a shader I personally wouldn't care what the blending logic did with it after that. Although it would be nice to have some defined functionality in the standard.

Actually, I think you would care very much. Some values can make sense, but drawing NAN as a color probably isn't going to be helpful.

My point is that it's not any more undefined in the buffer than it is in the shader. If you support NaN's fine, if you support Infinities fine, if you just return maxFloat when divide by Zero happens that's probably fine too.

It would be nice to have a standard, and IMO the standard should be consistent between the blending/filtering logic and the shading logic.

As to your second point, from my standpoint I'd rather know about the infinity as soon as possible, so bright pink pixels would be a good thing. To quote someone else "Accidental success is worse than failure".

 

[KimB]

So any card that, for example, didn't support the full D3D texture addressing capabilities (you know, wrap, clamp, non-pow2 etc.) also has texturing that isn't worth a crumpet, right? After all, these addressing modes have been around for a long time now, so you would expect them to be pretty much fully supported for all formats, yes?

As long as the format is functionally identical to another available format, that is, as long as any algorithm that works on format X that isn't supported could be written just as well for format Y that is supported, then there is no problem.

(edit: I'd also like to exclude workarounds as making the format functionally identical. That is, if RGBA is supported but ARGB isn't, then there's no problem. If, by contrast, FP filtering is not supported, but point sampling from the same FP texture format is, then you can't realistically do the filtering in the shader, as it'd take too long to be called functionally identical)

 

[andypski]

As long as the format is functionally identical to another available format, that is, as long as any algorithm that works on format X that isn't supported could be written just as well for format Y that is supported, then there is no problem.

If format X supports the full set of texture addressing modes and format Y does not then this does not hold true, because you can use texture X in a way that cannot be expressed as well by texture Y.

It is analogous to the case where format X supports filtering, and format Y does not.

 

[Doomtrooper]

Why waste your time guys, you would have a better chance winning a debate with a chia pet.

 

[KimB]

If format X supports the full set of texture addressing modes and format Y does not then this does not hold true, because you can use texture X in a way that cannot be expressed as well by texture Y.

It is analogous to the case where format X supports filtering, and format Y does not.

That's a very specific case, and you'd have to cite an example for your point to be of any use. I seriously doubt that many of the "old" unsupported texture addressing modes of either the NV4x or R4xx are terribly useful at all.

 

[3dcgi]

Same as programming in C++ ... you can choose float or double, depending on the amount of precision you require. Seems like a good idea to me, but I'm not sure of the possible drawbacks in the actual architecture for implementing this.

I think the possible drawback is a bad product cycle, NV30.

 

[3dcgi]

FP16 may not be an IEEE standard, but, it is a professional CGI standard and has been for many years. Why do you think nVidia's FP framebuffer etc are OpenEXR compliant?

The OpenEXR standard is actually fairly new and has not been around for many years. Since January 2003 to be exact. After R300. ILM developed it internally before that though.

 

[radar1200gs]

FP16 may not be an IEEE standard, but, it is a professional CGI standard and has been for many years. Why do you think nVidia's FP framebuffer etc are OpenEXR compliant?

The OpenEXR standard is actually fairly new and has not been around for many years. Since January 2003 to be exact. After R300. ILM developed it internally before that though.

My point is/was that nVidia uses established technologies rather than invent their own in most cases (Cg being the notable exception, even then Cg was developed in collaboration with Stanford University).

 

[KimB]

Same as programming in C++ ... you can choose float or double, depending on the amount of precision you require. Seems like a good idea to me, but I'm not sure of the possible drawbacks in the actual architecture for implementing this.

I think the possible drawback is a bad product cycle, NV30.

The NV40 has shown pretty clearly that FP32/FP16 had nothing to do with the poor floating-point performance of the NV3x line.

 

[Heathen]

I'm taking Martox's advice with Radar.

 

[radar1200gs]

Poor fanATics! Don't like having the truth pointed out, do you?

 

[Evildeus]

nVidia has brought FP framebuffers and FP filtering anf HDR rendering to consumers by way of proven, established, standardized technologies that have a track record of working.

FP16 is not an industry standard. There's no IEEE spec for it. That goes for FP24 as well but at least it is the minimum spec for full precision in DX9.

-FUDie

Depends on what part of DX9 you are talking, at least, it's not on SM 3.0.

 

[FUDie]

Poor fanATics! Don't like having the truth pointed out, do you?

You mean the truth about IEEE 754? With logic like yours, it's impossible to win an argument.

-FUDie

 

[I.S.T.]

Poor fanATics! Don't like having the truth pointed out, do you?

*Hits radar.* Shut up, n00b.

 

[pat777]

Poor fanATics! Don't like having the truth pointed out, do you?

You mean the truth about IEEE 754? With logic like yours, it's impossible to win an argument.

-FUDie

Are you saying radar is like these flame warriors:
http://www.winternet.com/~mikelr/flame63.html
http://www.winternet.com/~mikelr/flame78.html

Radar is just posting his opinion. FP32 will eventually be important. FP16 blending has been used in movies. Perhaps radar should say 6800U uses movie standards while X800 XT uses Microsoft standards.

 

[KimB]

http://www.winternet.com/~mikelr/flame78.html

Ah, that's great Reminds me soooo much of hovz in this thread:
http://www.beyond3d.com/forum/viewtopic.php?t=12679&start=0

 

[radar1200gs]

Poor fanATics! Don't like having the truth pointed out, do you?

You mean the truth about IEEE 754? With logic like yours, it's impossible to win an argument.

-FUDie

Are you saying radar is like these flame warriors:
http://www.winternet.com/~mikelr/flame63.html
http://www.winternet.com/~mikelr/flame78.html

Radar is just posting his opinion. FP32 will eventually be important. FP16 blending has been used in movies. Perhaps radar should say 6800U uses movie standards while X800 XT uses Microsoft standards.

Acutally I'd say nVidia uses 3D industry (includes movie) AND microsoft standards. The use of FP16 does not negate the use of FP32 where and when required.