Trilinear single mip level Optimization not always cheating

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

 

ROFL

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

 

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.

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

 

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.

 

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?

 

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.

 

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.

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

 

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

yeah, the same i suggested. so we agree

 

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.

 

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

 

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

 

Actually, D3D 9 does.

 

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.

 

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

 

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.

 

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.

 

Re: Trilinear single mip level Optimization not always chea

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

 

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.