R520 - no FP texture filtering?

[skynet]

I just want a confirmation on this...
So ATI supports now FP blending (what about alphatesting?) and antialiasing on FP-rendertargets, but no filtering on FP textures? If that is true, what is the reasoning behind this?

[Twixn]

Im not sure why, but i know that the new ATI cards dont support all of SM3.0 either, Vertex Texturing apparantly wasnt included in the 'minimum' SM3.0 spec, so ATI have skipped it.

-Twixn-

[Korval]

If that is true, what is the reasoning behind this?

That ATi has slacked off since the R300? The fact that they care far more about performance than they do about functionality, because you can't test functionality in a benchmark?

[SirKnight]

ATI's new cards are definately not worth it. No FP filtering, a vertex texture cap but no texture formats that work (very sleazy), and cross-fire... ha hahahaha come on now. Why spend all that money on ATI right now when you can get the same (or better) performance with new cool features from NVIDIA. It's a no brainer really.

-SirKnight

[Humus]

Originally posted by skynet:
I just want a confirmation on this...
So ATI supports now FP blending (what about alphatesting?) and antialiasing on FP-rendertargets, but no filtering on FP textures? If that is true, what is the reasoning behind this?

Alpha testing should work AFAIK (haven't tested). The reasoning is simple. For all HDR related stuff, FP filtering was one of the most expensive to support, yet is the least important one. Instead focus has been put on hard to emulate features, such as full multisampling support on FP16, FP16 blending, displayable FP16 surfaces with tonemapping in the display engine etc. Blending could reasonably be emulated with ping-ponging, but that's quite cumbersome.
Floating point filtering on the other hand is easily emulated in the shader. Also, FP16 is hardly the best way to store HDR assets. A much better way is to use something like RGB in DXT1 and exponent as L16. This costs less than 1/3 the bandwidth and storage space.

Personally, while FP16 is a convenience, I'd rather spend the transistors on supporting multisampling. Users shouldn't have to turn off AA to play with HDR. That pretty much makes HDR useless IMHO.

[Humus]

Originally posted by Korval:
That ATi has slacked off since the R300? The fact that they care far more about performance than they do about functionality, because you can't test functionality in a benchmark?

Uhm, the X1K cards has the best feature set out there. To mention a few that Nvidia don't support: FP16 multisampling, displable FP16 and RGB10_A2, RGB10_A2/R16/RG16/RGBA16/R16F render targets, fetch4, floating point HiZ, 3Dc+ (now with a single channel format as well), unlimited MRT support, angle invariant AF (well, they used to, but now they don't).

Or how about that dynamic branching now is actually fast enough to be useful? Like the X1800 being over twice as fast as the 7800GTX in the dynamic branching heavy samples to be included in the next ATI SDK, and the X1600 competing very well with it. Or instancing that's fast enough to be useful. The X1600 spanked the 7800GTX in my tests (heck even my mobility 9700 does).

[gybe]

What about Vertex Texturing? Are you at least going to support a render-to-vertex-array in OpenGL in a near future?

[kehziah]

Another reason I saw mentioned on review sites regarding lack of FP16 filtering is that developpers are expected to implement custom filters via shaders anyway, meaning virtually no one would use the built-in box filter. The site gave UnrealEngine3 as an example; the engine uses a custom filter on all cards (ie including NVIDIA, which hardware filtering is wasted in this case).

[gybe]

Even if you implement a custom filter, often you will be able to have better performance if you use the built-in box filter to implement this custom filter, since it samples 4 or 8 texture samples instead of one.

[Zulfiqar Malik]

I believe that the reason why Unreal Engine 3 implements its own filtering is because of non-availability of SM3.0 capable hardware and/or sucky driver support when they were developing this technology. I don't see much reason for implementing your own filtering if the hardware filter is good enough and produces good results. From the looks of it i don't think that Epic are doing any fancy stuff in their own filtering code.