[Tygrus_Artesiaoa]

I've read a lot on this board...and accordingly the r200 anisotropic method is based on rip-mapping and there have been posts and little gifs and programs about it as such...
Though this is from Hardocp latest gf4 4200 review

~When we apply Anisotropic filtering it goes a long way to improve the image quality, but also goes a long way to decrease performance. The first thing you will notice is how well ATI's cards are doing with Anisotropic enabled. It's important to note that ATI is not doing "True" Anisotropic filtering. The ATI cards are using a method known as Rip-Mapping which is not as accurate as a true Anisotropic renderer.

(editor's note: "Rip-mapping" is the not the technique used as stated above. Here is a statement from ATi with some very good information that dispel the rip-mapping myths. Sorry for adding to the confusion that is already there.)

I was just reading through your recent GeForce4 Ti4200 preview. On page 2 under the Serious Sam benchmarks you mention that the RADEON 8500/8500LE "are using a method known as Rip-Mapping which is not as accurate as a true Anisotropic renderer." Despite what you may have heard, this is not true. The RADEON 8500 & 7500 products use true anisotropic filtering, not rip-mapping. They achieve the high performance they do with AF because they have the unique ability to dynamically select the number of texture samples taken for each pixel. Thus, pixels that would get no visual benefit from AF use only a single bilinear texture sample, while those that are at very sharp angles and would get the most benefit can use up to 16 bilinear samples (in 16x mode). Since 16x samples requires 16x bandwidth, and only a small fraction of the pixels on the screen ever require this many samples, the RADEON products can offer the full visual quality improvement with almost no performance hit.

David Nalasco
Technology Marketing Manager
Desktop Business Unit
ATi Technologies Inc.

This sounds like they state that it is some sort of adaptive anisotropic?
So what's the actual truth...as this being that it's from their marketing manager...is it PR BS* or is their anisotropic method in actuality-adaptive on the fly

[aths]

"True" AF should be usuable with trilinear filtering enabled. The Radeon-AF apply the filtering only in X or Y-direction. This is RIP-Mapping. May be they dont call it "RIP-Mapping" because it's not a trademark by ATI :-)

The performance hit is so small because they take 4 texels for each pixel. Every AF implementation is dynamic and dont use the maximum amout of texels in every case yet, only if its needet.

edit: It is possible to confirm or deny the RIP-Mapping-Theory: You need a texture with a texelwise checker-pattern. (Every "checkerfield" is only 1 texel!)
A (linear filtered) RIP-Map has no checker-pattern anymore.

"True" unidirectional bilinear AF shows some more details than RIP-Mapping.

[Xmas]

Originally Posted by Tygrus_Artesiaoa

They achieve the high performance they do with AF because they have the unique ability to dynamically select the number of texture samples taken for each pixel.

LOL, in how far would that be "unique"? Considering only ATI products...?

[Mintmaster]

Originally Posted by aths

"True" AF should be usuable with trilinear filtering enabled. The Radeon-AF apply the filtering only in X or Y-direction. This is RIP-Mapping. May be they dont call it "RIP-Mapping" because it's not a trademark by ATI

The performance hit is so small because they take 4 texels for each pixel. Every AF implementation is dynamic and dont use the maximum amout of texels in every case yet, only if its needet.

Actually, you're wrong. ATI applies the filtering in all directions. I have made a program with a star texture (many intersecting lines at various angles) and all lines get filtered correctly. ATI cards have the ability to do proper anisotropic filtering, and don't do rip-mapping.

However, they do have a problem in determining WHEN it should be used. If the polygon is at a 45 degree angle to the screen on the roll axis (not the alignment of the texture as in rip-mapping), then there is a problem. This is not a symptom associated with rip-mapping, but an oversight in their calculation of anisotropy.

As for using trilinear, they probably did not implement AF with the ability to take samples from two textures (or mip-maps) simultaneously. If the speed issue is only due to the lack of trilinear with ATI, why doesn't NVidia just disable the trilinear from their AF? Chances are that it wouldn't do much for NVidia, as they can do trilinear samples fine, but struggle with extra anisotropic samples.

ATI probably has the ability to take extra samples for anisotropy in exchange for the second mip-map samples used in trilinear filtering. This may be part of what they mean by 'dynamic', as they are using the texture sampling silicon that is normally used in trilinear, but for AF instead

Besides, on most textures the bilinear mipmap transitions are hardly noticeable anyway with AF on. Why? A mip map is just a downsampled texture. If ATI takes up to 16 texture samples, they will have a similar blend to the result you get with blending samples from two mip-maps in trilinear filtering.

[aths]

There is not only a problem at 45 degree.

The quality grows while the angle is goto 90° and get more worse while it goes to 45°. In fact at 45° its only bilinear mipmapping. Of course the texture is filtered correctly, but in the near of 45° its very blurry, while no longer AF effects. The Radeon is not able to filter anisotropic in 45 degree direction. (Or this feature is not enabled yet.)

[Bambers]

Yes because of the way it detects the aniso needed, not becuase of the aniso it uses.

From the results it gives I think that the 8500 takes four measurements from each pixel to work out the anisotropy needed.

1. The u distance on the texture covered by the width of the pixel
2. The v distance """"
3. The u distance covered by the height of the pixel
4. The v distance """"

For something like the floor in a game then this works fine:

If the texture coordinates are lined up with the veiwer then:

2 and 3 are zero, 1 is small and 4 is large so anisotropy is used

If the texture coords are at 45 degrees then 1 and 2 are small but 3 and 4 are large so anisotropy is still used.

The problem comes when the plane is angled. As the camera is rolled then the differences between the values become smaller and so ess anisotropy is used even though it is actually needed.

At 45 degrees then regardless of the orientation of the texture then 1,2,3 and 4 are all the same, no anisotropy is detected so none is used.

I'm fairly sure you can force the gf3 and 4 into using bilinear aniso.

My gf1 certainly could and it still took a noticable performance hit considering it was only doing 2x aniso.

[Mintmaster]

Originally Posted by aths

There is not only a problem at 45 degree.

The quality grows while the angle is goto 90° and get more worse while it goes to 45°. In fact at 45° its only bilinear mipmapping. Of course the texture is filtered correctly, but in the near of 45° its very blurry, while no longer AF effects. The Radeon is not able to filter anisotropic in 45 degree direction. (Or this feature is not enabled yet.)

Yes I know, that's what I meant by 45 degrees. Perfect at right angles, nothing at 45 degrees, and a blend of the two inbetween.

Still, these are are angles of the polygon on the camera roll axis. Rip-mapping has problems when you don't look along the texture axes (generally called U and V axes, not X and Y like you called them), and its worst at 45 degrees to the texture axes. ATI cards don't have this problem - the texture is filtered anisotropically no matter what direction you look at the texture, provided the texture is horizontal or vertical. The problem arises when the polygon that the texture is on is not horizontal or vertical, but its normal lies at an angle to both of the coordinate screen axes.

There is a discussion about this in another thread. We've established that it is not rip-mapping, but a problem in how ATI determines what to apply anisotropic filtering to.

http://216.12.218.25/domain/www.beyo...opic.php?t=564[/url]

[Doomtrooper]

Bambers,

I thought your Quake 3 shot showed ripmapping was not being used at the 45 degree angle on the floor. Possibly posting that shot would prove that point.

[aths]

Mintmaster,

in my opinion there is an easy way to check if it is RIP-Mapping or not. Easely look, if the Radeon uses RIP-Maps

A Texel-by-Texel-Checkerboard (black and white) RIP-filtered should be gray - without any pattern.

[Mintmaster]

Originally Posted by aths

Mintmaster,

in my opinion there is an easy way to check if it is RIP-Mapping or not. Easely look, if the Radeon uses RIP-Maps

A Texel-by-Texel-Checkerboard (black and white) RIP-filtered should be gray - without any pattern.

The problem is that even normal mip-maps would wind up being gray once they are created, so it doesn't matter what method you use. You average all texels in a 2x2 block to get a texel in the next mip-map, so a checkerboard pattern would give you gray. Even Nvidia cards would be going all gray. Unless, of course, you mean the same texel-by-texel checkerboard pattern for all mip-maps, but you would get a screwed up image then since the mip-maps wouldn't correspond with each other.

The star pattern is best. If it is rip-mapped, the lines of the star that aren't aligned with the U or V axes would look just like bilinear filtering, and blur. However, I told you they don't. I'll try to find some web space to show you some screenshots.

[aths]

Mintmaster,

hm, you are right: Mipmaps are also gray (next time I should think twice before posting :))

[Tygrus_Artesiaoa]

So all in all...it is anisotropic that just screwed in some senses...doesn't do tri when aniso though NV can...which
then explains why there performance doesn't go down as much...
and I won't even get into the level/ how many taps it can go as that gets really confusing...
?

[Bambers]

I've added a shot without aniso to show the difference:

Without aniso:


and with:


The second shot is clearly more detailed (although the texture used wasnt the best) so the 8500 does do aniso at 45 degrees to the u and v axes.

[nggalai]

Hi Bambers,

thanks for the screenshots.

Question: do you have any idea what's going on in the SS:SE screenshots posted by jb, here?

ta,
.rb
________
XV700

[Bambers]

The screenshots in the other thread show the weakness of the way the 8500 detects the anisotropy needed.

I think it works as I've said in my first post in this thread. This is the 3rd case where all 4 values it takes are the same so it does not detect any need for anisotropy and just uses bilinear filtering.

[Xmas]

Thanks for the shots, Bambers.
Could you please do the same shots with color mipmaps on?

[Colourless]

Yeah colour mipmaps would be great for those sorts of screenshots. You don't need to see the detail to see if the anisotropic filtering is working then.

Regardless is seems to be that anisotropic is working in that second shot.

[jb]

Originally Posted by Colourless

Yeah colour mipmaps would be great for those sorts of screenshots. You don't need to see the detail to see if the anisotropic filtering is working then.

Regardless is seems to be that anisotropic is working in that second shot.

Ok sorry for this question, but what do you hope to see with the color maps on? Alls I have noticed is that it pushes the mip map back. Also with ATI's Ansio you will not see any trilnear :

Here are some older screen shots I took with SS:FE:

http://www.pc-gamers.net/jb/reviews/...tri_waniso.jpg

http://www.pc-gamers.net/jb/reviews/...ri_waniso1.jpg

Again I was just wondering what to look for...

Thanks

[Colourless]

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.

[Bambers]

um.. how do I do coloured mip-maps?

[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/showthrea...eadid=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]

Originally Posted by 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

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.