[no-X]

Originally Posted by Novum

That's a clear case of "brilinear" filtering. It's a performance cheat.

That's not brilinear filtering. Brilinear filter doesn't create breaks/hard transitions. It's trilinear, but one stage seems to be filtered bilinearly. Because the neighbouring stage is filtered trilinearly, and the bilinear stage isn't undersampled, the break doesn't appear as hard as with typical bilinear/bilinear transition, but it can be noticed in specific situations. I don't think it's a cheat, R8xx GPUs have enough texturing/filtering power (in fact more than R7xx - ALU:TEX ratio remained the same, but R8xx SPs are loaded higher because they perform interpolation). I think it can be a result of some change in TMUs' architecture... maybe a HW bug?

[CarstenS]

Originally Posted by no-X

I think it can be a result of some change in TMUs' architecture... maybe a HW bug?

I'm having a hard time imagining how a certain texture stage could receive only bilinear filtering due to a hw bug.

BTW, i am just upoloading SGSSAA-vids, the banding's still there, the overall image appearance is much nicer though.

[Novum]

Originally Posted by no-X

That's not brilinear filtering. Brilinear filter doesn't create breaks/hard transitions.

If the trilinear band is very small it can. A real bilinear AF mip transition would be harder than what is visible in the screenshot.

The only strange thing is the darker color in the smaller mips. Could also be a driver bug.

[Jawed]

Does renaming the tester to commonly-benchmarked games lead to variations in filtering?

[Novum]

It didn't when I last tried on RV770. I suspect they do the app detection more intelligent by now.

[caveman-jim]

Originally Posted by Jawed

The absolute silence of AMD in this thread's pretty deafening, huh?

[caveman-jim]

Originally Posted by Novum

Angle dependence is a non-issue since R5xx. You can only see the difference between the reference rendering and RV770 with colored mips. If you can't tell them apart in this synthetic case there is no way this is visible in games.

The perfect angle independence of RV870 is just a red herring to distract from the real problems.

For those of us playing along at home, why don't you spell out those problems clearly for, if you'll excuse the pun, better visibility. What I think the issues are might be different from what you consider them to be.

[Novum]

There are more than enough AF quality comparision videos to find online. I'm sick of having to justify myself every single time. The problem is that ATI is doing everything they can to hide this. They confuse the users with a nonfunctional "A.I." on/off switch that doesn't do anything nowadays and "fixes" problems in synthetic tools by driver detection.

I tell you the facts: ATI is using brilinear filtering and is undersampling the line of anisotropy. You would be suprised how much samples you can save with some textures without much visual impact. If you don't believe them then I couldn't care less.

Oh and btw. I am the author of the tool we are talking about, so I should know one or two things about anisotropic filtering. And yes I like to have strong opinions about that subject, because it just plainly annoys me like hell that we are still talking about that issue in the year 2010 while computational power skyrockets.

I had hopes that Microsoft will specify the filter algorithm for D3D11, but it didn't happen, so they have no way to force it with WHQL.

[caveman-jim]

Whoa dude, I wasn't saying you needed to justify yourself, just asking for clarification.

Nevermind then, I'll leave it alone...

[Broken Hope]

Originally Posted by Novum

And yes I like to have strong opinions about that subject, because it just plainly annoys me like hell that we are still talking about that issue in the year 2010 while computational power skyrockets.

I had hopes that Microsoft will specify the filter algorithm for D3D11, but it didn't happen, so they have no way to force it with WHQL.

It's even more annoying that Nvidia has had a HQ option in the driver since the 8x00 series cards which were released in 2006, that's 4 years ago! Yet ATI still want to ignore the issue and not provide their customers that are paying hundreds for new cards the option for full quality AF.

[CarstenS]

Originally Posted by fellix

Could you capture the same scene with some SSAA -- 4 and 8 samples?

Done - as promised, it help quite a bit but primarily against the shimmering. The banding on the (I`m guessing!) normals' (texture stage) is still clearly visible. Maybe I shouold file a bug report with catalyst driver feedback - and also for Crysis (Warhead)?
4x SGSSAA:
http://www.youtube.com/watch?v=MDx0V_Er2WA
http://www.youtube.com/watch?v=zLkd1O8233k

8x SGSSAA:
http://www.youtube.com/watch?v=sp2bB2LXp08
http://www.youtube.com/watch?v=WGYs-6MEnOg

I am still not decided, where i can upload the original files.

[no-X]

Originally Posted by Novum

If the trilinear band is very small it can. A real bilinear AF mip transition would be harder than what is visible in the screenshot.

That's beacuse it isn't bilinear to bilinear transition, but trilinear to bilinear

Originally Posted by CarstenS

I'm having a hard time imagining how a certain texture stage could receive only bilinear filtering due to a hw bug.

example: I can imagine a bug related to texture caching. Is it possible that a part of texture cache is unaccessible due to a design bug? The remaining capacity wouldn't be sufficient for full trilinear, but replacing one stage with bilinear would make the capacity sufficient. I'm not saying this is the case of Evergreen, it's only an example.

I can't imagine why would it ATi use to increase performance. Why would they use full-quality trilinear for all stages except one, which would be bilinear? Wouldn't it be better to undersample all stages slightly and equally (as on RV7xx) than to perform high quality filtering on most stages and cripple the last one?

[Novum]

Originally Posted by no-X

That's beacuse it isn't bilinear to bilinear transition, but trilinear to bilinear

I can't see how that fits to the screenshot. After fiddeling with the tester I can almost reproduce the results by using bilinear filtering without AF. There is something very strange happening here.

[CarstenS]

Originally Posted by no-X

example: I can imagine a bug related to texture caching. Is it possible that a part of texture cache is unaccessible due to a design bug?

I of course don't know either, but let's assume this as a working thesis.
We already know that TC officially was scaled back to 8 kiB per quad-TMU, don't we?

Originally Posted by no-X

The remaining capacity wouldn't be sufficient for full trilinear, but replacing one stage with bilinear would make the capacity sufficient. I'm not saying this is the case of Evergreen, it's only an example.

Hm, I was under the impression that different stages use (mostly) different textures and those are likely to evict each other from the cachelines. But maybe it's a possibility that Evergreen could make do for some kinds of textures, like compressed normals, where the information has to be retrieved using shader math anyway, without using TMUs at all and is done completely in the shader. But to keep costs under control is limited to bilinear? Dunno.

Originally Posted by no-X

I can't imagine why would it ATi use to increase performance. Why would they use full-quality trilinear for all stages except one, which would be bilinear? Wouldn't it be better to undersample all stages slightly and equally (as on RV7xx) than to perform high quality filtering on most stages and cripple the last one?

That concept baffles me too.
We shouldn't rule out the possibility of a driver bug also. Maybe it's just that.


---
Did you realize that this strange banding occurs in Novum's filter tester only on anisotropys higher than 2:1, i.e. starting from 4x AF?
Ah, no. It's there also at 2x. If you drop texture scale to 0.1, it's clearly visible.

[Neb]

Originally Posted by Broken Hope

It's even more annoying that Nvidia has had a HQ option in the driver since the 8x00 series cards which were released in 2006, that's 4 years ago! Yet ATI still want to ignore the issue and not provide their customers that are paying hundreds for new cards the option for full quality AF.

There is a line in registry for CCC to allow "HQ" anistropic filtering. Am I assuming it right that this is for angle independant AF and also might not be functional for ATI GPUs beyond x1xxx series?

[CarstenS]

Yeah, there are a couple of entries that seemingly deal with Aniso, also the X1K-option of AreaAniso. But when i last tried it, it didn't have any apparent effect. Maybe they just forgot to delete them?

There are other interesting options, though: ExportBumpMappedTex, ExportCompressedTex and ExportCompressedTex_DEF. Maybde Dave can tell us more?

[OpenGL guy]

Originally Posted by CarstenS

There are other interesting options, though: ExportBumpMappedTex, ExportCompressedTex and ExportCompressedTex_DEF. Maybde Dave can tell us more?

Some very old games wouldn't work properly if you exposed too many texture formats, or if the formats were in the wrong order. Prior to DX8, all the texture formats were returned as a list. Some apps would have an allocation that was too small for the list and then try to copy the returned list into the smaller buffer... Crash! Or some games would assume that texture format 5 was A8G8B8R8, etc., leading to rendering problems if the ordering was not what they expected.

DX8 improved this as apps had to query for formats, but there was still the occasional app that would take the first 32-bit format they found and assume it had the properties they needed.

Fortunately, these issues are very rare nowadays, but people using really old apps can still have issues.

[CarstenS]

Ah-ha! Thanks a lot OpenGL guy, that'll save me some time; assuming in the first place google would have even returned that information.

Since you didn't write something wrt to the "banding issue" discussed in this thread, i take it you're not ready/allowed to share additional insights into that?

[ninelven]

We shouldn't rule out the possibility of a driver bug also. Maybe it's just that.

This has been happening *in games* at least since the X800 series; I seriously doubt it is a bug.

[Lightman]

Originally Posted by ninelven

This has been happening *in games* at least since the X800 series; I seriously doubt it is a bug.

On a brighter side, if it's not a bug it's a feature

I agree though, ATI needs to at least level field with nVidia in this regard.
Giving an option in driver to enable some kind on HQ Aniso, even with 50% performance drop, would be welcome because some older games I play wouldn't care!

[Random Digital]

So is ATI sacrificing image quality to increase performance or is this a software/hardware limitation?

[homerdog]

If it's a hardware limitation then they've sacrificed IQ to save transistors. If the hardware is capable of good filtering then they've sacrificed IQ to increase performance. Doubtful that we'll ever know which is the case.

[no-X]

What kind of cheating would it be, if this result is caused by HW bug?

[homerdog]

A hardware bug that they haven't managed to fix since R600?

[no-X]

The issue which is discussed in this thread (hard mip-map transition) appears only with R8xx GPUs.