Trilinear single mip level Optimization not always cheating

Good pr is never "good pr" (at least i've yet to see 'fair' pr)

theoretically, yes. but this could be fixed by ati then, and stated as a bug (wich it would be, too, because they worked hard at making it bugfree to prevent this, and its their goal to make it bugfree.. thats not from pr, but from actual driver developers).

they know best their algorithms, and know when they can use wich optimisation without hurting/changing output. they eighter get it to work, or not. this has yet to be proven. but they have over a year now, and it never visibly failed on the 9600, wich hints they know their stuff.

 

It always struck me that NV's patent looked remarkably similar to the much earlier one by S3...

 

Yeah well they probably shouldn't have gottent it but hey thats the US patent office isn't it.

 

Is this a good time to point out that the true trilinear filtering for free the KYRO does is by reading the upper mip-map compressed then producing the lower level mipmap from that information. You have to read 16 texels per pixel but the cache helps enourmously with this as only 4 new ones are needed each adjacent pixel, when tri's are small, even less. It also helps when the texture can be precached.

 

Re: Trilinear single mip level Optimization not always chea

I wonder why this has hardly been discussed yet.

Just nitpicking, but one doesn't lead to the other

 

I guess you mean D3DUSAGE_AUTOGENMIPMAP.
It's made to expose hardware mip-map generation.

IMHO, using it for regular textures is a serious misuse of the API.
I don't think there's too many applications that use that.

And it doesn't work for compressed textures at all (even in refrast).

 

What happens when the mipmaps are not box filtered (eg. coloured) ?

 

On Kyro, it breaks. I.e. it still uses the same method, rendering full color bands.

 

hehe.. think again

 

Yeah you'd be forgiven for thinking KYRO doesn't do trilinear if you go by the coloured mipmaps, but you may notice when swapping between the two that the colour boundaries move.

 

No you don't - well not in the normal sense

 

Yep, since the DXT1 decompression means that you have a 2-bit index into a linear color gradient, you can as well "filter" the index values and look up the color as a last step...

Was that your idea, Simon?

 

Pass.
[Edit: I see my answer confused Xmas. Ok, how about "I refuse to comment on the grounds that it might incriminate me"? ]

 

I think this is one of the most complex issues in computer graphics. Is a pixel an area or an atomic point? Same for texels. And if it's a point, what's in between? I'd rather like to think about it as a duality of area and point. And the texture filter I see as part of the content. It depends on how the texture was created.