FP blending in R420?

[andypski]

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

 

[London Geezer]

I thought Electricity was the bare minimum. Oh, and the ON/OFF switch on ON.

 

[Heathen]

Well, if you are content with worse than S3 virge functionality then I guess it doesn't matter...

Well trying to Ignore Dave's response to this comment Greg, I wasn't talking about Int filtering & blending I was talking about Floating Point Blending and Filtering. I would have hoped the title of the thread would have given you a clue.

I thought Electricity was the bare minimum. Oh, and the ON/OFF switch on ON.

Naah, that would be breathing. Some people haven't mastered much beyond that though which is a shame.

 

[Joe DeFuria]

If you want to take that stance, Joe, FP32 is superior to FP24 in all respects.

Sure....so then...ATI and nVidia are BOTH retarding the industry now!!

(I'm now just left wondering when my point will actually sink in....)

 

[PeterAce]

It was Richard Huddy's "Save the nanosecond" pres "Notes" that surgested R420 would still be SM2.0.

But is also surgests that ATI's SM3.0 part (R5XX) will have FP Blend :

Blend etc will be on NV40 and on our own SM3.0 parts

Steer people away from flow control in ps3.0 because we expect it to hurt badly. [Also it’s the main extra feature on NV40 vs R420 so let’s discourage people from using it until R5xx shows up with decent performance...]

So is ATI really holding back the industry very long? - Answer: Probably Not.

 

[Bjorn]

Right, just as is true for fp24 vs. fp16. The problem in the NV4x pipeline is not fp32, but fp16, since fp16 is the reason nV4x cannot be said to always render to a higher precision than R4x0, but often renders to a lower precision than R4x0, instead, despite the fact that it supports fp32.

That doesn't make any sense at all. FP16 is not a problem, it's an option. That doesn't apply for the NV3X though

It's kind of funny to hear comments like, "Sometimes it makes more sense to run fp16 instead of fp32 within nV3/4x," when you consider that fp16 doesn't make any sense at all in R3/4x0...

Of course it does. As has already been mentioned, why use more precision then you need ? As long as full precison runs at acceptable speeds (!= NV3X then), offering a bit faster performance with lower precision is not a bad thing.

 

[Scott_Arm]

It's kind of funny to hear comments like, "Sometimes it makes more sense to run fp16 instead of fp32 within nV3/4x," when you consider that fp16 doesn't make any sense at all in R3/4x0...

Of course it does. As has already been mentioned, why use more precision then you need ? As long as full precison runs at acceptable speeds (!= NV3X then), offering a bit faster performance with lower precision is not a bad thing.

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.

 

[ERP]

The only real problem is that most programmers wouldn't know how to do numerical analysis on floats of any precision.

The solution is always "just jack it up to doubles", when the problem is the algorythm itself.

 

[LeStoffer]

Why do some people imply that using FP16 blending (or doing filtering of FP16 textures for that matter) mean that operations in the pixel shader have to be used at FP16 and cannot be run at full precision?

Please show me the limitation in NV4x where it is stated that you cant do your ops in FP32 in the PS before outputting the 'result' in FP16 to the colour buffer for blending or to a FP16 texture.

 

[FUDie]

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

 

[KimB]

Right, just as is true for fp24 vs. fp16. The problem in the NV4x pipeline is not fp32, but fp16, since fp16 is the reason nV4x cannot be said to always render to a higher precision than R4x0, but often renders to a lower precision than R4x0, instead, despite the fact that it supports fp32.

I see that statement as incredibly misleading. The NV4x renders at FP32 when requested. It runs at FP16 when requested. Since the final output is at much lower precision than either FP16 or FP32, judicious use of FP16 can lead to output that is nearly identical to full FP32 output, but at higher performance (nearly identical meaning no greater than single-bit errors).

By contrast, since there is no choice to use FP32 on ATI hardware, if an algorithm comes along that shows a difference between FP32 and FP24, there is no choice in the matter: quality is simply degraded.

Where nVidia gives fp32 on one hand, they take it away on the other with fp16. If nVidia wants to legitimize its claim to "fp32 precision throughout the pipeline," it's simple enough to do so--just drop fp16 support completely and run everything at fp32 precision.

nVidia takes nothing away: the developer has the choice.

 

[KimB]

If you want to take that stance, Joe, FP32 is superior to FP24 in all respects.

Sure....so then...ATI and nVidia are BOTH retarding the industry now!!

(I'm now just left wondering when my point will actually sink in....)

Oh, I know what you're point is. I just think it's rather meaningless. Put simply: nVidia's NV40 is vastly more technologically capable than ATI's R420, no matter which way you look at it.

We know that ATI had the option of supporting more advanced technologies in the R4xx, but chose to delay implementing those technologies. nVidia did not. Therefore, ATI is holding the industry back.

 

[KimB]

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?

 

[OpenGL guy]

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.

 

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

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.

It's an interesting question I agree (and I don't know the answer as it applys to NV40), but hardly one who's answer invalidates the usefullness of the functionality.

 

[OpenGL guy]

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.

 

[radar1200gs]

Well, if you are content with worse than S3 virge functionality then I guess it doesn't matter...

Well trying to Ignore Dave's response to this comment Greg, I wasn't talking about Int filtering & blending I was talking about Floating Point Blending and Filtering. I would have hoped the title of the thread would have given you a clue.

I thought Electricity was the bare minimum. Oh, and the ON/OFF switch on ON.

Naah, that would be breathing. Some people haven't mastered much beyond that though which is a shame.

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.

 

[radar1200gs]

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

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?

 

[whql]

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

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?

So, its not an industry standard but it is a standard in your eyes because its used for cgi. Games developers (lots of them) use DirectX 9 and its FP24 requirements - why isn't that a standard?

 

[radar1200gs]

Its exactly the same principle as T&L for instance