Trilinear single mip level Optimization not always cheating

[davepermen]

Good pr never lies it only stretch the truth.

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

ATI have lied to us if somebody can show the optimizied filter in a case were no ordinary box filtering is used? I did not mean small single bit differences between the box filtering and the values in the mipmaps.

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.

 

[Simon F]

Take a look:

http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6452603

http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6304268

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

 

[bloodbob]

Take a look:

http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6452603

http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6304268

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.

 

[Dave B(TotalVR)]

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.

 

[Xmas]

Re: Trilinear single mip level Optimization not always chea

In our discussions, David Kirk suggested that the texture units on NV40 will operate not at the pixel level, but at the quad level, such that if it was determined that the texture sampling requirements of the entire quad were less than the overall sampling abilities of the quad of texture units then potentially trilinear sampling may be achievable in a single cycle over the entire quad, where two cycles would be required with each texture sampler fixed to a pipeline. Indeed, such a texturing mechanism sounded similar to 3dfx's fabled "Rampage" chip, and it didn't come as much of a surprise to find that Rampage's chief architect was in charge of NV40's texture and shader engine. We asked Emmett if this was the case with NV40 and he replied that "some in the NV4x range would feature this as it has benefits and drawbacks".

I wonder why this has hardly been discussed yet.

Lets think about a polygon with a texture, that is paralell with the screen, so that no anisotropy is involved.

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

 

[Hyp-X]

D3D doesn't support driver generated mip-maps.

Actually, D3D 9 does.

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

 

[Hyp-X]

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.

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

 

[Xmas]

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.

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.

 

[davepermen]

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.

hehe.. think again

 

[Dave B(TotalVR)]

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.

 

[Simon F]

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

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

 

[Xmas]

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

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?

 

[Simon F]

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

 

[Xmas]

 

[Xmas]

That's a question of perspective, I guess. A texture map is an array of discrete samples, with step discontinuities between every pair of samples, if you insist that each texel is a rectangular region and there's no distance between neighbors.
However, you can fit a frequency bounded curve over that array that will exactly touch each texel center. This represents another view on the map: a texel is a single point on the surface of the map, and there's non-zero distance between texels.

This model has no discontinuity concerns, and IMO this is the right way to look at it (not from an implementation's POV, but from a signal theory POV). After all, if the flush rectangle theory were correct, point sampling would be the preferred technique for texture magnification. It isn't.

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.