ATi claims 174.6 GB/s for Radeon 9700 Pro

[arjan de lumens]

Not entirely true. It's incredibly unfeasible to ever produce an architecture that will be capable of producing its maximum level of anisotropy in a single clock in each pixel pipeline.

I'm sure they said the same thing about trilinear filtering a few years back.

There is one crucial difference between trilinear and aniso: trilinear takes a fixed number of texture samples per pixel - 8, while aniso takes a variable number - sometimes more than 100 for current state-of-the-art aniso. That would make for one really expensive pipeline. Also, don't Geforce3/4 still take a 50% texel fillrate hit from just enabling trilinear?

 

[Dave Baumann]

Also, don't Geforce3/4 still take a 50% texel fillrate hit from just enabling trilinear?

No.

 

[Althornin]

There is one crucial difference between trilinear and aniso: trilinear takes a fixed number of texture samples per pixel - 8, while aniso takes a variable number - sometimes more than 100 for current state-of-the-art aniso. That would make for one really expensive pipeline. Also, don't Geforce3/4 still take a 50% texel fillrate hit from just enabling trilinear?

If you are goiong to apply aniso to every pixel anyways, so what?
aniso is going to become the defacto standard.

 

[arjan de lumens]

If you are goiong to apply aniso to every pixel anyways, so what?
aniso is going to become the defacto standard.

Yes, and so? The work needed per pixel for good results still varies from one pixel to the next, and making hardware to consistently handle the worst case in 1 cycle per pipe is still ridiculously expensive. With aniso becoming standard, what will happen is that hardware will be optimized for the common case (like, say, up to 4x aniso, which should cover ~80-90% of all pixels) and then run some slower fallback/loopback method for the pixels that need a higher degree of anisotropy.

 

[KimB]

This seems like a really dumb move to me because at best id engines account for 50% of the FPS market, with the rest going to other engine developers such as Epic, Monolith and of course in house engines.

And that's just the FPS games market, never mind flight sims, racing games, etc. So if Nvidia is optimizing their cards for a single engine made by a single developer, even one with some influence, they are being really stupid.

I don't think this is optimization for just a single engine developer. With the more flexible nature of fragment programs, it just makes more sense to not tie down processing resources in a fixed-function way (i.e. multi texturing). It makes more sense to have the GPU be as flexible as possible, where it will usually perform better with lots of smaller processing units that are more flexible than with fewer less flexible processing units. Despite the fact that you may potentially get more total possible processing power out of a more fixed-function pipeline, this is not the way the industry is going, and it would be foolish to pursue.

 

[mboeller]

If you are goiong to apply aniso to every pixel anyways, so what?
aniso is going to become the defacto standard.

Yes, and so? The work needed per pixel for good results still varies from one pixel to the next, and making hardware to consistently handle the worst case in 1 cycle per pipe is still ridiculously expensive. With aniso becoming standard, what will happen is that hardware will be optimized for the common case (like, say, up to 4x aniso, which should cover ~80-90% of all pixels) and then run some slower fallback/loopback method for the pixels that need a higher degree of anisotropy.

I thought the R300 already does this. I have read here that the R300 is able to "render" or combine 4 bilinear filtered "pixels" per clock per pipeline; but is only able to output one pixel per pipeline and cycle ( =16tap per pipeline per cycle ). This should be enough for 2x aniso (but only bilinear filtered not trilinear ).