Trilinear single mip level Optimization not always cheating

[Randell]

One of the things I love about B3d is that when someone throws out "Nyquist theorem", it doesn't put the whole room to sleep, or cause a chorus of abusive "wtf!". Here eyes squint, hands start inching slowly toward belts, and a Sergio Leone soundtrack starts up. . .

thats is good. However some use that knowledge to bolster their bias into a form of intellectual bullying (not that I'm accusing anyone in this thread).

 

[Ailuros]

One of the things I love about B3d is that when someone throws out "Nyquist theorem", it doesn't put the whole room to sleep, or cause a chorus of abusive "wtf!". Here eyes squint, hands start inching slowly toward belts, and a Sergio Leone soundtrack starts up. . .

ROFL

Ironically I've developed a "not again-allergy" every time I read the term optimisation lately.

 

[KimB]

I think ATI should be praised for including extra hardware on chip for free trilinear. it is a first for 5 Years (?) that any IHV includes hardware for trilinear.

A. We still don't know if ATI's using this technique. I highly doubt it, personally, as you wouldn't have any sort of "levels" of accuracy, and, according to the interviews, ATI's aniso/trilinear "optimization" can be adjusted.
B. It's not free.

Nv3x doesn't count because it included specialized hardware for not doing trilinear. (that was for Chalnoth)

This means absolutely nothing to me. It's a pretty stupid statement, whichever way you look at it (whether judging what I would say: I've never defended nVidia's "brilinear," and it is, in fact, one of the reasons why I never purchased an NV3x, or even just looking at the actual statement: anybody who believed that the NV3x had "free" trilinear would be, well, wrong, for more than one reason).

 

[bloodbob]

Re: Trilinear single mip level Optimization not always chea

I didn't have time to wade through several hundred posts, (I despise this forum format for any sort of catch-up on discussions) but my point is simple.

If ATI is "disabling" the bilinear anisotropic or trilinear modes when color mip maps are used, this may not be cheating.

It is PERFECTLY ACCEPTABLE to sample from only one mip-map (the larger one) rather than linearly interpolate between two if trilinear is on, provided enough samples are taken on the larger mipmap, provided the smaller mipmaps are linear downsamples of the larger one, and provided the algorithm is correct.

Ehh exactly how many samples should be taken? cause atm they are taking one Bilinear sample ( 4 texels ).

Lets do some math with the 1 bilinear sample

Lets say A is the LOD of the Higher Mipmap and B is the lod of the lower mip map.

Now let X be the actual lod.

As X tends towards B from A the bilinear sample will remain constant. Because you are taking the same exact sample from the higher mipmap every time.

So when X is infinitaly close to B it is still fine by your therom. So unless their is some major jump between "infinitaly close to B" then sample at B should be the same as a sample at A.

So now we can subsitute B for A and we can now use the Next lower MipMap C.
Repeat and we find out as long as we are doing linear downsampling we don't need mipmaps at all.

Your theory isn't correct when using 1 blinear sample it probably is correct when using 16 or 20 tap sample ( 4/5 wieghted bilinear samples ) but at that point it is far far far worse preformance wise.

 

[davepermen]

depends, because if there is chance that you only need to load in one mip-layer into cache you can sample much quicker around on it.

ah, there are just too much factors. we need, quickly, another solution. api wise:

two ways to specify the filtering. eighter exact: i want pointsample, i want bilinear, i want trilinear, i want what ever.
or quality based: this texture needs good quality, this one nobody bothers, etc.

and then, for the exact ones, cards have to provide it. for the quality based ones, cards/drivers are free to do what ever they want. depending on the quality slider in the driver, and what the application requested, they can deliver. then, we can make fair comparisons to find out, at a certain visual quality, how good wich card performs.

that would be nice, not?

 

[nAo]

that would be nice, not?

That would be nice. But it would be nicer if with a given (selected by the developer) filtering scheme all the IHVs would do the same thing.
Some time ago I thought about doing some physics calculation in pixel shaders..and I thought about using trilinear filtering to speed up things..well..there's no need to say I don't think about doing it that way anymore

ciao,
Marco

 

[davepermen]

that would be nice, not?

That would be nice. But it would be nicer if with a given (selected by the developer) filtering scheme all the IHVs would do the same thing.
Some time ago I thought about doing some physics calculation in pixel shaders..and I thought about using trilinear filtering to speed up things..well..there's no need to say I don't think about doing it that way anymore

ciao,
Marco

why? if you use floatingpoint, floatingpoint errors in your calculations hurt more than the errors measured in this case. so what?

it would NOT be much nicer if we have to choose an exact algorithm. not always. it depends on if we NEED an exact algo to do the job, or not. in most cases, we don't. and then, quality based and implementation dependent is great.

 

[nAo]

why? if you use floatingpoint, floatingpoint errors in your calculations hurt more than the errors measured in this case. so what?

Cause in my specific case only the 'classic' trilinear implementation would make sense, cause in my physics shader setup mip maps are not generated via box filtering a previous mip map.

it would NOT be much nicer if we have to choose an exact algorithm. not always. it depends on if we NEED an exact algo to do the job, or not. in most cases, we don't. and then, quality based and implementation dependent is great.

I'm not advocating to have a specific, fixed, implementation of every kind of filtering on each hw. I would like to have some fixed, standarized, filtering technique...and then other techniques..with fuzzy classifcations

ciao,
Marco

 

[davepermen]

why? if you use floatingpoint, floatingpoint errors in your calculations hurt more than the errors measured in this case. so what?

Cause in my specific case only the 'classic' trilinear implementation would make sense, cause in my physics shader setup mip maps are not generated via box filtering a previous mip map.

and in this case, only classic trilinear works. please inform yourself instead of following the "CHEAT" cries...

I'm not advocating to have a specific, fixed, implementation of every kind of filtering on each hw. I would like to have some fixed, standarized, filtering technique...and then other techniques..with fuzzy classifcations

yeah, the same i suggested. so we agree

 

[nAo]

and in this case, only classic trilinear works. please inform yourself instead of following the "CHEAT" cries...

This kind of chatting is getting quite irritating, I believe moderators should do something about that. I never mentioned the word 'cheat' nor a specific IHV. In fact I'm very well informed and I do understand what I'm talking about, much more then some 'expert'. Try just to read what I wrote and don't try to read between lines.

 

[davepermen]

if you do custom filtering, and not use the ordinary box filtering, you get full trilinear on ati hw. thats what ati states. the only reason it would NOT work that way would be if they lied to us (but thats job of the pr part).

lets see again what you stated.. slowly..

 

[davepermen]

hm, possibly i got it wrong way around. you now believe tri is too slow, and thus don't want to speed up your work?

i can suggest you one thing: profile. i bet its still faster than doing in software. wether its worth moving on gpu because of it, thats another topic.

is it that way around? if so, sorry..

 

[Colourless]

D3D doesn't support driver generated mip-maps.

Actually, D3D 9 does.

 

[Demirug]

if you do custom filtering, and not use the ordinary box filtering, you get full trilinear on ati hw. thats what ati states. the only reason it would NOT work that way would be if they lied to us (but thats job of the pr part).

lets see again what you stated.. slowly..

Good pr never lies it only stretch the truth.

Only to make sure I understand you right.

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.

 

[Enbar]

And as some people have pointed out, the purpose of trilinear is to merely make the mipmap transitions not visible.

ATI may say so, but that doesn't suffice to make it true.
The whole purpose of texture filtering is to maximize material frequency within the constraints given by the Nyquist theorem. AFAIK there's exactly nothing wrong with "legacy" (?!) trilinear filtering in this respect.

"Legacy" trilinear uses linear ramping this causes a discontinuous 2nd derivative. If their changes to trilinear smooth out this discontinuity then in theory things could be more appealing to the eye. In addition to looking better this approach would be less expensive since a few less lookups would be required. This sort of fits what ati changes look like to me, but I can't tell for certain. I can't see why this wouldn't work well with non-box filtered mipmaps, but I might be overlooking something.

 

[bloodbob]

"Legacy" trilinear uses linear ramping this causes a discontinuous 2nd derivative. If their changes to trilinear smooth out this discontinuity then in theory things could be more appealing to the eye.

I would suggest if anything it would require a higher order filter to smooth it out which needs more work rather then less work. I could very well be wrong.

 

[Scott C]

Re: Trilinear single mip level Optimization not always chea

Ehh exactly how many samples should be taken? cause atm they are taking one Bilinear sample ( 4 texels ).

Lets do some math with the 1 bilinear sample

Lets say A is the LOD of the Higher Mipmap and B is the lod of the lower mip map.

Now let X be the actual lod.

As X tends towards B from A the bilinear sample will remain constant. Because you are taking the same exact sample from the higher mipmap every time.

So when X is infinitaly close to B it is still fine by your therom. So unless their is some major jump between "infinitaly close to B" then sample at B should be the same as a sample at A.

So now we can subsitute B for A and we can now use the Next lower MipMap C.
Repeat and we find out as long as we are doing linear downsampling we don't need mipmaps at all.

Your theory isn't correct when using 1 blinear sample it probably is correct when using 16 or 20 tap sample ( 4/5 wieghted bilinear samples ) but at that point it is far far far worse preformance wise.

You must take more than 4 samples in order to have both spacial filteringo n one detail level and smooth detail level transitions to prevent mip level discontinuities.

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

How many samples are needed ? If sampling from one mip level, you will need between 4 (exact LOD match) and 16.
Trilinear was created because weighting the 16 samples correctly, and both the bandwith and computations needed are twice as much if using 16 smaples than the 8.

A lower level mip map in this case represents a pre-processing computation to average blocks of 4 texels into one at a lower LOD.

So, lets say you have higher level (higher detail) mip level A. Then you have the next one at exactly half resolution at detail level B.

You start at a point where the polygon is at a LOD larger than A, thus magnification. You bilinearly filter this, because at every pixel there are four texels surrounding it to weight.

As you approach detail level A, the texels get closer together in pixel space. At exactly detail level A, bilinear filtering is still OK and produces no aliasing. once past level A, moving to level B you have a few options:
"classic" bilinear, which just jumps to doing bilinear samples of B, and has a very obvious discontinuity.
Or "classic" Trilinear: Sample bilinearly from A and B, and linearly blend them by weight. This removes the aliasing that you would get if you used just A.
Single mip level Trilinear equivalnet:
Sample 16 pixels from A, the 4 that you would for bilinear in addition to the 12 surrouding ones. The weights are identical to what you would get if you created B by a straght linear downfilter of A and did classic trilinear.

Why do this if there are 16 samples while classic trilinear has the 'advantage' of only 8? Because those texels were probably just used by neighboring pixels, and when traversing a block of pixels the number of texels that must be fetched into the cache from an external source is much smaller than the 16 that are mostly alreay in the cache.

Trilinear has similar cache benefits, but involves two mip levels, and can be more complicated to manage in a cache than one mip level.

Additionally, these extra texels are similar to the extras that are needed for anisotropic filtering... and a combined strategy for doing a really good job of caching the needed texels from one mip level might be easier to impiment.

The two patents linked earlier here spell out the equivalence better than I do.

The reality is, if you are doing trilinear for traditional purposes (texture filtering) then it doesn't matter if you use 16 samples from a higher level mip or 4 from each of two mips and blend them.

 

[DemoCoder]

I think ATI should be praised for including extra hardware on chip for free trilinear. it is a first for 5 Years (?) that any IHV includes hardware for trilinear.

What hardware are we talking about? This is a software technique done in the driver for determining when to not use trilinear. The decision is not made by the hardware.

 

[bloodbob]

Re: Trilinear single mip level Optimization not always chea

Your theory isn't correct when using 1 blinear sample it probably is correct when using 16 or 20 tap sample ( 4/5 wieghted bilinear samples ) but at that point it is far far far worse preformance wise.

You must take more than 4 samples in order to have both spacial filteringo n one detail level and smooth detail level transitions to prevent mip level discontinuities.
.....
The reality is, if you are doing trilinear for traditional purposes (texture filtering) then it doesn't matter if you use 16 samples from a higher level mip or 4 from each of two mips and blend them.

Yeap thats all great and wonderful but what I said it they are only taking 4 samples not "between 8 and 16 samples" I said it could be valid with 4 or 5 bilinear sampels ( so 16 or 20 ). You have said its fine with 16 samples which is fine but ATI aren't doing this. I have no problem with the implementation you suggested just its a moot point since ATI haven't implemented it they are trying to flog off they can get more quality doing less sames on average. As far as caching I really don't know and although I didn't specify here I generally examine all these things without cache to simplify things as caching is very implementation specific I guess its my bad for not saying that before.

Oh and good to see nice quality posts coming for you Scott I always good to have people like you around

 

[davepermen]

I think ATI should be praised for including extra hardware on chip for free trilinear. it is a first for 5 Years (?) that any IHV includes hardware for trilinear.

What hardware are we talking about? This is a software technique done in the driver for determining when to not use trilinear. The decision is not made by the hardware.

actually, its a hw feature, too, since r3x0.. else my 9700 pro could have it, too.. but as always, its a good combination of hw feature and driver design, to make it a good working thing.