So is ATI's aniso method rip-mapping or not?

[psurge]

Question :

Does the fact that the 8500 in certain cases doesn't take enough samples when using anisotropic filtering explain the performance hit difference between it and the GF3/4 ? Would it be possible to run some kind of test in which the 8500 will detect the correct amount of anistropy for every pixel - I'm thinking something along the lines of a Doom level (floors flat, all walls are vertical)... Isn't there a public version of Doom which has had the graphics code rewritten to use OpenGL? perhaps this could be used to see how much impact the screwy anistropy detection of the 8500 has on performance. I.e. if in this case the performance hit of the 8500 is bigger than the average hit in other games, then one could get an idea of how much faster the actual filtering really is on the 8500.

Serge

 

[Joe DeFuria]

I had suggested this before, and I think it's a good idea. Anyone with Quake3 (Or Quake2 for that matter) Mapping experience?

The only thing I wouldn't like about using some GL Doom engine is that it's likely the drivers not really teste with it, so there may be some unrealted optimizations (or lack therof) that could impact the performance difference between the cards not related to filtering.

Someone Just make a room or rooms with a bunch of 100% vertical and horizontal walls.

 

[Ante P]

http://63.231.44.178/board/showthread.php?s=&threadid=33613189

 

[jb]

I could do a UT map for you in a matter of minutes...but thats the wrong engine..sorry
To set the color mip levels try typing this in the console

r_colorMipLevels 1

 

[Mintmaster]

Question :

Does the fact that the 8500 in certain cases doesn't take enough samples when using anisotropic filtering explain the performance hit difference between it and the GF3/4 ? Would it be possible to run some kind of test in which the 8500 will detect the correct amount of anistropy for every pixel - I'm thinking something along the lines of a Doom level (floors flat, all walls are vertical)... Isn't there a public version of Doom which has had the graphics code rewritten to use OpenGL? perhaps this could be used to see how much impact the screwy anistropy detection of the 8500 has on performance. I.e. if in this case the performance hit of the 8500 is bigger than the average hit in other games, then one could get an idea of how much faster the actual filtering really is on the 8500.

Serge

If you watch nearly any demo, especially FPS games like Q3, there are barely any polygons near a 45 degree roll angle to the camera. The majority of the anisotropic filtering is done on the floors and walls. These are the biggest areas in the screen, by FAR. If ATI could detect everything that needed aniso, they likely wouldn't lose more than a couple of percent.

The peculiarities are, as Bambers and Basic (in the other thread) pointed out, in the determination of the NEED for anisotropic filtering. ATI can do anisotropic filtering very well - they just seem to have been too simplistic in their calculations on how to find out where it is needed.

Some people also suspected that it was because of the trilinear, but in Ante P's link they disables trilinear on the GF3, and there was no significant increase in performance on the GF3/4. This theory is clearly false.

My theory is that GF3/4 takes additional clock cycles to do aniso, whereas the majority of the time ATI just uses the same sampling hardware of the trilinear unit to do the additional samples, without needing extra clocks. This would explain why trilinear can't be done simultaneously. However, when you disable trilinear on the GF3/4, you actually disable it, and don't free up any resources. This is probably why there is no performance change between trilinear aniso and bilinear aniso on the GF3/4.

 

[Althornin]

Colour mipmaps will show if anisotropic was actually working or not. If it was not working that mipmaps would be closer in. When it's working they are pushed further back.

The 45 degree case when anisptropic is enabled where things don't work will have same mipmaps being used as bilinear at the same place.

Maybe it always pushes them back, but doesnt Aniso them...it could still be rip mapping, those shots could (i doubt it, but its possible) be just really high LOD.
Bambers, if you could revert to regular bilinear filtering and crank the LOD up a lot and take a Screenshot at the same place, that would set my mind at ease. I'd like to see how different that shot looks with aniso compared to just high LOD.

 

[LeStoffer]

My theory is that GF3/4 takes additional clock cycles to do aniso, whereas the majority of the time ATI just uses the same sampling hardware of the trilinear unit to do the additional samples, without needing extra clocks. This would explain why trilinear can't be done simultaneously. However, when you disable trilinear on the GF3/4, you actually disable it, and don't free up any resources. This is probably why there is no performance change between trilinear aniso and bilinear aniso on the GF3/4.

This makes sense and is the best bet so far (IMHO anyway). The bad thing about it though is, that nVidia cannot make a "fast" ATI-like version of aniso if correct.

 

[pcchen]

To check if GF3/GF4 are fillrate limited when using high level anisotropic filtering, just benchmark them with the same amound of memory bandwidth but different core clock rate. If rising clock rate without rising memory bandwidth can help performance a lot, GF3/GF4's anisotropic filtering performance may be limited by their "eight texel per clock for each pixel pipeline" engine.

 

[Reverend]

I don't have a 8500, neither have I researched this quite enough but I keep reading from many individiuals a simple "No trilin when aniso" (whatever "aniso" means).

Is this a hardware limitation fact or is this based on simple user investigations/observations?

Isn't it possible that trilin + "aniso" is possible in hardware but for performance reasons ATI simply felt that with their "aniso", most folks wouldn't mind seeing mipmap bands as per bilin? Note that I've read some interview somewhere (I think it's HardOCP in their GF4 Ti4200 preview) where an ATI guy actually said bilin is used when "aniso" is also used (as well as ripmap being not the case) but this doesn't state categorically whether trilin + aniso is actually possible.

Please excuse my ignorance if this has been accurately clarified before.[/b]

 

[Humus]

Is this a hardware limitation fact or is this based on simple user investigations/observations?[/b]

It's a factual hardware limitation. ATi has confirmed this.

 

[Dave Baumann]

Rev, puh-lease!

From our ECTS ATi Interview:

Can it [Radeon 8500] do Trilinear filtering at the same time [as anisotropic]?

No. It samples from one map.

This was basically an algorithmic choice. The anisotropic filter kernel by definition is not a square; it’s got a height and a width and we select the mip level based on the small dimension and then sample according to the large dimension of the filter kernel shape. It’s a way to do anisotropic filtering, there’s no true way to do it – true is generally not a word to use in graphics!

 

[Reverend]

Wavey, I know about our own interview! However, an interview is an interview. I was asking for actual proof, perhaps based on user investigations, not what ATI tells the public.

 

[Humus]

Back when I had my Radeon 64mb vivo I ran into this when coding an app, I noted that trilinear would go off as soon as I enabled anisotropic. So I contacted ATi about it. Jeff Royle at ATi was unaware of it too, so he made a bugreport to the driver team. After a few days he got back to me with what the driver team said, that the driver was punting it back to bilinear because it can't do trilinear at the same time. This was with my old Radeon though, but I would expect the same to be the case with the Radeon 8500. I don't see any reason why ATi would disable trilinear with anisotropic if it was possible.

 

[Galilee]

But is anisotrophic filtering implemented generally in the hardware or software? ATI says it's a algorith choice. Well, if it is a choice in the drivers, maybe it's possible to code the algorith different.

 

[Dave Baumann]

Galilee,

An ‘algorithmic choice’ does not mean it’s a driver thing – it an algorithmic hardware design choice. All 3D chips are, is a bunch of silicon that’s very fast at working out specific mathematical algorithms.

 

[noko]

Maybe the R300 8 pipes will address this issue with two pipes, each pipe is rendering from one mip-map blending the multiple bilinear filtered textures in the frame buffer, hence a very fast hardware anisotropic filtered method using trilinear filtered samples. Who knows???

 

[Bambers]

Colour mipmaps will show if anisotropic was actually working or not. If it was not working that mipmaps would be closer in. When it's working they are pushed further back.

The 45 degree case when anisptropic is enabled where things don't work will have same mipmaps being used as bilinear at the same place.

Maybe it always pushes them back, but doesnt Aniso them...it could still be rip mapping, those shots could (i doubt it, but its possible) be just really high LOD.
Bambers, if you could revert to regular bilinear filtering and crank the LOD up a lot and take a Screenshot at the same place, that would set my mind at ease. I'd like to see how different that shot looks with aniso compared to just high LOD.

Never found a way to adjust LOD large amounts on the 8500, not even with a tweak utility.

I'm certain it isn't just a high LOD though as that would make it shimmer really badly and it doesn't.

 

[Mintmaster]

Colour mipmaps will show if anisotropic was actually working or not. If it was not working that mipmaps would be closer in. When it's working they are pushed further back.

The 45 degree case when anisptropic is enabled where things don't work will have same mipmaps being used as bilinear at the same place.

Maybe it always pushes them back, but doesnt Aniso them...it could still be rip mapping, those shots could (i doubt it, but its possible) be just really high LOD.
Bambers, if you could revert to regular bilinear filtering and crank the LOD up a lot and take a Screenshot at the same place, that would set my mind at ease. I'd like to see how different that shot looks with aniso compared to just high LOD.

Never found a way to adjust LOD large amounts on the 8500, not even with a tweak utility.

I'm certain it isn't just a high LOD though as that would make it shimmer really badly and it doesn't.

Althorinin, Bambers is right. Making LOD high would create horrible shimmering, because if the texel sampled would really just be a random choice from the many texels of the larger mip-map covered by a pixel.

The performance would also be really bad with a high LOD, because the texture bandwidth requirements skyrocket. There's a lot of thrashing, and the cache of the 8500 wouldn't work well at all (which is very important to the 8500's performance). Again, it's the randomness associated with sampling from a higher than normal LOD mip-map.

You can probably test this separately. See what the FPS is with a really high LOD, and see what it is with anisotropic filtering. My bet is the high LOD would actually be slower.

 

[noko]

Can the LOD be adjusted with the Radeon8500?
In the game SeriousSam Second Edition, does the Texture Level of Detail affect the LOD? On the GF3 it adjusts the LOD or Mip-Maps.

 

[Althornin]

Guys, i know it would cause shimmering - i'm not an idiot
But all i've seen are Still screencaps, so i have no way of knowing wether or not it shimmers at those angles...I'll take your word for it that it doesnt.