ATi is ch**t**g in Filtering

from the DirectX documentation:

 

it is a 100% defined way of filtering (the box filtering, that is).

because of that, the optimisation ati presents is 100% working, or not working. it is algorithmically and statistically profable how good, or bad, compared to basic trilinear filtering it works. if you want trilinear, no mather how good or bad THAT is, you can force it, by setting it up yourself. if you don't set it up yourself its up to dx, opengl, and the driver, on what to do (and always was, and always will be). they can do what ever they want (colour reductions on textures are another stated example by me wich get done).

if you don't specify exactly what you want, you get simply the best you can expect done by the driver developers. trilinear, btw, is (by FAR) NOT best. (that is why we today often have a combination of high count anysotropic + trilinear).

bether filters are normally more expensive. in case of atis work here, not. it's just the best filter ati presents you, if you don't care yourself, and present them standart mipmaps. if you have some special mipmaps, ati doesn't understand, and falls back to generic trilinear.

is it really that difficult to grasp?

 

If i understand correctly, brilinear filtered areas on screen are either bilinear filtered (when it is half way between two mipmaps) or trilinear filtered (when it is close to switch between mipmaps). bilinear part is filtered from higher resolution map, that's why it appears sharper. Let's assume mipmaps don't differ much - what would be possible issues in that case? texture shimmering? Bands visible in motion?

 

as trilinear has to lerp in both directions, brilinear happens, to do that, too (judging from images), and does not only sample from the sharper (resulting in slight flickering theoretically there), but from the blurrier one, too.. (just depends from wich side you come from)..

should be adjustable with the bias actually.. so yes, it does not simply hurt. it changes the image.. problem is, it changes it quite visible, and not always to a good result. thats why people noted it, thats why people reacted on it. on the other hand, atis implementation would not ever have been noted if people would not have relied on per pixel equality checks because of issues we had last year mainly in nv3x days. shown by the r3x0 fact.

oh, and, the main problem of brilinear is, it's not adaptive to texture. if it would be, similar to ati ones, it would not have been visually hurting. and nobody would have noted it...

 

No, I think it'll be closer to Matrox' FAA.

 

I don't really know what your saying here but BOX FILTERING HAS NOTHING TO DO WITH ATI'S ALGORITHIM well other then the driver detection.

Great prove it. You don't even have to prove it just tell us the algroithim.

If I tell my application I want trilinear filter by saying

Code:

g_pDevice->SetSamplerState(0, D3DSAMP_MINFILTER, D3DTEXF_LINEAR);
g_pDevice->SetSamplerState(0, D3DSAMP_MAGFILTER,D3DTEXF_LINEAR);
g_pDevice->SetSamplerState(0, D3DSAMP_MIPFILTER, D3DTEXF_LINEAR);

Thats what I expect I am explictly saying trilinear filter. Linear magnification. Linear minifcation. Linear mipmap filter. I am totally telling the driver what It should be doing.

Great except already mentioned by everyone about 50 times ATI is disabling the trilinear filter so we can't have anistropic filter with trilinear filtering.

The generation of the mip-maps has NOTHING WHAT SO EVER TO WHAT FILTERING SHOULD BE DONE. I ask for trilinear I should get it.

Where in the DX specs does it say that you can't use the box filter when trying to apply tri-linear filtering. OH wait it doesn't AT ALL.

So until you actually go out their and do some programing and learn the developers are already *removed* telling the drivers to do trilinear filters shut the hell up

Sorry for the language readers but I'm sick of this guy saying that every developer out there are doing the wrong when trying to request trilinear filtering.

Edit: yeah yeah smart ass courless thats setting up only one stage

 

Bad example, but I don't think I'll mention why.

 

bah, really braindump. my belief in beyond3d fucked up on this topic completely.

"AHH ITS NEW ***CHEEEEEEAAAAAT*****".

learn your stuff, please. learn it. NOW.

 

breathe, take your lithium and lay down for a while... Everything will be O.K.


P.S. If it says in your signature your not a Fanboi then you must realize that most people will assume you are a Fanboi, just a word of advice. Also most people judge people by what they recently not what was said days ago.

 

1. It's not trilinear.
2. While it's very close, it theoretically has the potential to reduce quality versus trilinear.
3. It was not disclosed.
4. There is no option to disable it.
5. When developers specifically request Vanilla Trilinear Filtering, they get this goofy transition trlinear.

See, I can say that about either NV or R420 brilinear. That's a problem, and that means that transition-only trilinear is a cheat.

 

For some weird reason this post absolutely slayed me!!!

 

1)It isn't that means the engineers lied to us on the chat is that true? Where is trilinear defined???

2)It also has the potential to increase quality versus naive or legacy trilinear

3)Agree

4)Agree but this is only an issue as we learn more about points 1 and 2

5)See point 1

 

there is an option to disable it: create mipmaps where the algorithm would NOT give equal results. i'm not talking about bitwise equal because that doesn't mather (wich image is bitwise equation on different geforces or radeons at all? or gf<->radeon cross-comparison? NONE).

the algorithm they use only gets in use where measurements show, that the mipmaps are in the constraints where the algorithm results in the same result as ordinary linear filtering. this is, and whas, never the case for brilinear, wich simply fucked up there, where brilinear doesn't work.

just imagine a huge texture wich is just white, and all mipmap levels are white, too. can't the driver detect that and instead of the actual texld, simply put a mov const into the shader? it will be a performance enhancement, and just that. it will not have to sample 8 samples of a texture (8 samples x anyso samplecount), it will not even have to touch it. instead, it can spil the info out of a constant register, and not have to work with the texturing unit at all.

is that a cheat? it is NOT. it would be, if it would only do that in doom3 shaders and hl2 shaders. but if it does it EVERYWHERE where it detects the texture can get a complexity degradation due that, it is an optimisation.

these sort of micro-optimisations are what gave us performance improvements in all newer detonators, in all newer catalists, in all newer forcewares. this is what driver developers do all the time.




but some people....

 

I'm pretty sure Tri-linear is linear magnification + linear minifaction + linear interpolation of mipmaps. Where is bilinear defined?

Anyway the corresponding name for tri-linear in opengl for minification which is "LINEAR MIPMAP LINEAR" has a formal mathematical definition. You can find it on 151 and 152 of the 1.5 OpenGl spec. Mind you ATI isn't following the spec.

The driver doesn't do this but all the driver does is say is it a box filter or is it not a box filter end of story. That is the whole adaptiveness of the ati algorithim. Thats alright you don't have to believe me ask ati to provide you a copy of the algorithim. Oh wait they won't what a pitty.

 

So the following is untrue??

 

2. As was said, in theory it can, but no one has shown it to do so... and in theory it can look better.

 

it fits all well into the opengl spec and thus it should well fit into the dx specs, too..

the spec just defines it should be comparable to this pseudocode, and result in about equal result. it is allowed to get to this result HOW EVER IT LIKES TO.

this is why drivers can do texture-replacements, sampler-mode-replacements, shader-replacements, state-setting-replacements, and much more changes, when ever they want, how ever they want.

oh, and, btw, the z-buffer is simply a 2dimensional linear array directly accesible and NOTHING ELSE. oh, wait.. hyper-z, and other hw implementations do it different, with different performance characterisists! IIEHK CHEAT AGAIN!


just get it: you only know what the output is of what you define. not, how it does it.

and the output in the case of ati is, as far as i can see, fine. and i let that be part of the ati's own quality-departement, to judge that. till now, it worked great. proof: r3x0.

 

Yes as I already said in another thread their is conditional operation in their algroith which makes it no linear. Peopel choose to argue its linear over small regions. Or they split the algorithm up into multiple pieces.

Great so the Nvidia wasn't cheating with future mark by replacing shaders putting in clipping planes ect?

 

Does anyone else concur with this opinion and how do you no that it becomes conditionally not linear??

and how does it tie to this statement.

I am really trying to understand this..

 

I wonder if ATI is able to expand or shrink those regions in function of mipmaps difference? or is it simple turn on/turn off brilinear? Anyone?