FP blending in R420?

Mintmaster

Veteran
It seems everyone has been caught up in either performance numbers or shader models. However, even Chalnoth was saying that FP-blending is likely the most important feature to be introduced this generation.

Does anyone know if R420 supports:
- FP16 blending?
- FP32 (well actually, FP24 internally) blending?
- Blending with other formats, like I16?
- FP filtering?

If they are supported, has anyone tested them?
 
The chance that R420 supports FP blending/filtering is very tiny.

But there're ways to simulate these effects through pixel shader, I think R420 has enough power for such a fall back solution.
 
Mintmaster said:
It seems everyone has been caught up in either performance numbers or shader models. However, even Chalnoth was saying that FP-blending is likely the most important feature to be introduced this generation.

Does anyone know if R420 supports:
- FP16 blending?
- FP32 (well actually, FP24 internally) blending?
- Blending with other formats, like I16?
- FP filtering?

If they are supported, has anyone tested them?
Yes but Chalnoth said that becuase Carmack said that about his next engine, and becuase he was pretty sure only Nvidia was supporting it.. :LOL:
 
HB, I know Chalnoth is biased sometimes, but he's right this time. Even Chalnoth will agree that FP-blending is much more important than PS 3.0.

FP-blending is what's needed for widespread use of HDR. It's not easy to do HDR without it, because nearly all games use alpha blending. There are ways to circumvent it, but they generally cost a lot of performance, are a pain in the ass to implement, and won't produce the same picture all the time.
 
I'd just like to mention that, as a developer, I'd rather have FP blending than PS3.0 if I had to choose between the two. It's really going to become important as we start to use high dynamic range lighting and do global illumination.

Like another poster said, you can emulate this blending by rendering to a floating point texture and running that back through the pipeline to blend it with the current pass in a fragment program, but this is inefficient, wasteful of memory (you have to have at least 1 additional floating point buffer the size of the screen - almost 30 MB at 1600x1200 not including a possible depth/stencil buffer), and a pain in the butt to program.
 
Zeno,

Isn't FP blending only (theoretically) available through OpenGL at the moment ? I *think* we have top wait until DX-Next to get it in that API ?

That limits its appear. But I agree,a developer, it's damn cool :)
 
Mintmaster said:
HB, I know Chalnoth is biased sometimes, but he's right this time. Even Chalnoth will agree that FP-blending is much more important than PS 3.0.

FP-blending is what's needed for widespread use of HDR. It's not easy to do HDR without it, because nearly all games use alpha blending. There are ways to circumvent it, but they generally cost a lot of performance, are a pain in the ass to implement, and won't produce the same picture all the time.
Hey i am to.. I was just messing around.

I agree it is a good feature that should see wide spread use as soon as possible.
 
Zeno said:
I'd just like to mention that, as a developer, I'd rather have FP blending than PS3.0 if I had to choose between the two. It's really going to become important as we start to use high dynamic range lighting and do global illumination.

Like another poster said, you can emulate this blending by rendering to a floating point texture and running that back through the pipeline to blend it with the current pass in a fragment program, but this is inefficient, wasteful of memory (you have to have at least 1 additional floating point buffer the size of the screen - almost 30 MB at 1600x1200 not including a possible depth/stencil buffer), and a pain in the butt to program.
Which is why as soon as its properly exposed and put to use the F-Buffer Technology of the R420 and its efficiency should be as good, in fact better than a limited hardware implimentation at this point.

(unless i am totally smoking crack,,, which i could be)
 
pocketmoon66 said:
Zeno,

Isn't FP blending only (theoretically) available through OpenGL at the moment ? I *think* we have top wait until DX-Next to get it in that API ?

That limits its appear. But I agree,a developer, it's damn cool :)

I don't know what the DX spec says about it....I use OpenGL almost exclusively. NVIDIA has been very good in the past about quickly exposing features of their cards through OpenGL extensions. I expect that this one will be available as soon as the cards are.

Hellbinder said:
Which is why as soon as its properly exposed and put to use the F-Buffer Technology of the R420 and its efficiency should be as good, in fact better than a limited hardware implimentation at this point.

So far, this F-buffer is vaporware. Supposedly my R300 has it, but I still run into the instruction and texture indirection limits all the time. Even if the F-buffer were enabled and/or working it wouldn't remove the need for high precision blending. It would help in that you could do as many lights per pass as you needed (so you wouldn't need to accumulate light into a high precision buffer), but it wouldn't help if you wanted to accumulate particles or do motion blur, for instance.
 
Zeno said:
So far, this F-buffer is vaporware. Supposedly my R300 has it, but I still run into the instruction and texture indirection limits all the time.
Nope, F-buffer was a feature added to R350. Still not exposed by drivers AFAIK.

-FUDie
 
FUDie said:
Nope, F-buffer was a feature added to R350. Still not exposed by drivers AFAIK.

After so much time, it qualifies as a VapourFeature (TM) to me ( kinda (!) like the T&L on Savage2K ).
 
anaqer said:
FUDie said:
Nope, F-buffer was a feature added to R350. Still not exposed by drivers AFAIK.

After so much time, it qualifies as a VapourFeature (TM) to me ( kinda (!) like the T&L on Savage2K ).
heeeyyy sucka... You best be takin that back... :devilish:

I really liked how T&L on my savage2k made these really pretty streaky lines and very Colorful and fun blinking yet strechy colored boxes blink around all over the place in Q3.

It was very spiritual...
 
Mintmaster said:
It seems everyone has been caught up in either performance numbers or shader models. However, even Chalnoth was saying that FP-blending is likely the most important feature to be introduced this generation.

Does anyone know if R420 supports:
- FP16 blending?
- FP32 (well actually, FP24 internally) blending?
- Blending with other formats, like I16?
- FP filtering?

If they are supported, has anyone tested them?

If fp16 frame-buffer blending is indeed supported on nV4x, has anyone tested it? Seems a good and proper question to me. But, as it did with its introduction of ps3.0 support in nV40, perhaps nVidia will get a 3rd-party mod for Far Cry done which shows the differences between 8-bit integer frame-buffer blending and 32-bit integer blending, and then stand up and say:

"Behold! The differences between ordinary blending and nVidia fp blending in Far Cry!"

Yea, and then later when it comes out that people weren't seeing what they thought they were seeing, they'll say that they never said "fp" in the first place and that it was all a big "misunderstanding" and everyone will go back and edit their posts and articles accordingly so as to make it appear that, indeed, nVidia never did actually say what it actually said...;)

Cynical? Perhaps. But then I worry that nVidia had no official demos lined up to illustrate all of this amazingly important stuff like PS3.0 and fp blending, so that reviewers could run them, analyze them, and praise them, if deserving of it. I mean, if it's so "important" and so forth, then WHERE ARE THE IN-HOUSE nVIDIA DEMOS to illustrate it???? I think a bit of empirical evidence is definitely in order.
 
Hellbinder said:
It was very spiritual...

Maybe ATi will someday emulate that effect with a SmartShader so ridiculously long it won't even run unless you have ... F-BUFFER !!! :LOL:
 
FUDie said:
Zeno said:
So far, this F-buffer is vaporware. Supposedly my R300 has it, but I still run into the instruction and texture indirection limits all the time.
Nope, F-buffer was a feature added to R350. Still not exposed by drivers AFAIK.

-FUDie


I thought I read it was operational in opengl?
 
Back
Top