ATI Filter tricks at 3Dcenter

Althornin said:
rwolf said:
aths said:
Take the the shader limitations, i. e. It may be sounds a bit heavy, but for calculating texture coordinates, i consider FP24 as "lowered precision", too.

Can you show an example of how this could be true? What kind of texture coordinates would you not be able to address with FP24? :?
Texture coordinate calcs are done in 32bit, i thought.

AFAIK, The texture-interpolators are computed with FP32 for both ATI and Nvidia. But if you then use these (or anything else) for a dependent lookup, you'll get FP24 on ATI and should get FP32 (no _pp) or FP16 (_pp) on Nvidia.
 
ChrisW,

There seems to be a semantic problem with the german/english translation.

A 'trick' in german is not natively something negative, it can be. It can also be meant as "stunt" or, if that sounds better to you, 'clever optimization'.

The idiom 'to (play a) trick (on) someone' does not exist in german in this form, also. We have and use an equivalent but without the word 'trick'.

So please do not judge the article an it's intention by one word, which is (in this translated form at least) highly debatable.
 
There will always be problems like this with translated articles - the vagaries of language mean that direct translations can often come across with a very different connotation to the original. In this case we have a situation where the author seems to be trying to present some interesting information, but even the title of the article ends up coming across with an implied negative spin.

Use of the phrase 'textbook' also seems rather ill advised - as far as I know there is no strict textbook requirement for the implementation of LOD filtering, or even for in-level filtering. Really it just comes down to being 'sufficient for the task'. Certainly unless you are trying to produce effects which fall well outside the traditional meanings of trilinear filtered mipmapping then 5-bits of LOD precision is sufficient. If you are trying effects that fall outside of the traditional uses of trilinear mipmapping then you need to be aware that you may run into implementation-dependent edge cases. At some point any implementation will run out of precision, so it's just a matter of degree. In general the hardware is there to support specified effects, and not necessarily 'clever' re-interpretations thereof.

The article certainly brings up some interesting points and it appears a lot of research has been done. I certainly wouldn't necessarily agree with all the conclusions, particularly what appears to be a very peculiar use of the term 'ethics', and the title as-is sucks IMHO ;), but that's not to say that there isn't merit in the article itself.
 
Quasar said:
ChrisW,

There seems to be a semantic problem with the german/english translation.

A 'trick' in german is not natively something negative, it can be. It can also be meant as "stunt" or, if that sounds better to you, 'clever optimization'.

The idiom 'to (play a) trick (on) someone' does not exist in german in this form, also. We have and use an equivalent but without the word 'trick'.
You mean "verarschen", don't you?
I don't think "trick" is too negative. Picture Trinity saying "Now that's a nice trick." :D

But I think the translation went online as "ATI filter cheats" or similar, which was, of course, just wrong. The original title is "ATIs Filtertricks" and was completely overlooked during translation :oops:
This has been corrected in the meantime.

andypski said:
Use of the phrase 'textbook' also seems rather ill advised - as far as I know there is no strict textbook requirement for the implementation of LOD filtering, or even for in-level filtering. Really it just comes down to being 'sufficient for the task'.
Interestingly, aths caught a lot of flak for the same thing from the German audience.
 
Interesting screenshots, but I think you're probably jumping to conclusions a bit too quickly

Yes, might be the case, especially since my understanding of inner workings of 3dmark and ati/nv drivers isn't perfect. Should have of course noted that earlier but i was kind of tired and thrilled about the idea of how these two findings might match...

[EDIT - just did a few experiments, and I'm now pretty convinced that the differences are not anything to do with LOD or filtering precision issues in R300 or Refrast. Try dumping out the same image from a 5800 using patch 340]

Are you implying the turtle texture was shader based and changed by Nvidia shader placement? That wouldn't seem logical, would it now? Why would Nvidia make shader replacement to make something look better than spec and therefore slowing down their 3dmark and getting lower score?! That would be nice but as it has been seen they are pretty much doing everything they can to boost the scores...

I don't have a FX card (I'm quite a happy R300 owner actually) so I can't test it. Maybe someone could provide a screenshot to tell us what is changed here since that scenegroup pic was taken?

edit: speculation that now comes to mind, maybe NV was rendering in FP32 earlier, thus resulting to lesser aliasing, and now it would use FP16 and be as bad or worse than refrast and r300. Another speculation that was presented to me when i originally posted the refrast shots was that maybe NV is/was cheating in lighting calculation too, therefore causing different looking turtle shell.
 
Mendel said:
Are you implying the turtle texture was shader based and changed by Nvidia shader placement? That wouldn't seem logical, would it now? Why would Nvidia make shader replacement to make something look better than spec and therefore slowing down their 3dmark and getting lower score?! That would be nice but as it has been seen they are pretty much doing everything they can to boost the scores...

I don't have a FX card (I'm quite a happy R300 owner actually) so I can't test it. Maybe someone could provide a screenshot to tell us what is changed here since that scenegroup pic was taken?
I am not implying anything in terms of what is actually causing differences in the images, as that would require more research. I dumped out the shot from patch 340 on a 5200Ultra and it looked like the R300 and Refrast image, I dumped it out from patch 320 and it seems to look like the 5800Ultra image that you linked to. This is using driver version 52.16. If someone else could confirm this then that would be good - I think you might need to use a 5200/5600/5800 and not a 5700/5900/5950.

Don't think about it as looking 'better' or 'worse' you should instead think about it as looking different. It may look better to you in the still screenshot, but that doesn't mean that it is the effect that the author intended to see, which is the whole point really. Why is it that you assume that whatever it is that makes it seem 'better' to you isn't necessarily wrong and possibly faster?

In the original 3DMark2001 the water in the Nature test aliases really heavily (perhaps from a large negative LOD being applied which I assume is to create a 'sparkling' effect). If you were to ignore the negative LOD bias and use a bias of 0 then the aliasing would go away, the image would almost certainly look better/smoother in still shots, and the performance would increase (because negative LODs are really bad for texture cache performance), yet at the same time the effect would not be what the authors of the application wanted you to see...
 
Mendel,
I don't see how the NVIDIA rendering is inherently "better" than ATI (/Refrast). It's different, that's for sure.
1)The lighting is more uniform
2)The detail texture is more prominent

Point 1 is clearly worse in my book. The sides of the head appear to be the only place the turtle gets 'darker', lighting doesn't work this way.
Point 2 is debatable. I have a rather negative theory about that but I'd really like to see the shader code for the surface first.

Also, the large difference to Refrast really points toward shader simplification (!=optimization ...). Filtering stuff may be visible upon close inspection, but it just wouldn't jump in your face like that.

edit:
Another thing to keep in mind, PS1.4 as implemented on R200 offers a [-8 ... +8] range. Numeric range on NV3x and PS1.x is much smaller, and I seem to remember that FM have somehow 'forgotten' about that. Lost the link ;)
 
Ailuros said:
I find it at least worrysome from my POV that people are missing your original intentions and start carrying around your article as proof of ATI supposedly cheating with texture filtering.
I am not accusing ATI to cheat.

rwolf said:
Can you show an example of how this could be true? What kind of texture coordinates would you not be able to address with FP24? :?
Read the article. BTW, I am not saying that its "not able to address with FP24".

ChrisW said:
Several problems with this article:
First of all, the constant use of "textbook" and "standard" when describing nVidia's implementation. You defined these terms because nVidia uses this method despite 5 bit is the minumum spec.
8 Bit is afaik 'SGI-Standard', also used by 3DLabs, afaik too.

The 5 Bit trilinear LOD-fraction is not the biggest problem. This is the point, where I said (translated by zeckensack) "Eight bits may be slightly overkill but then there's no disadvantage to precise texture filters." and "5 bit LOD fraction" issues are hard to demonstrate using screen shots, significantly harder than pointing out the issues with Nvidia's "brilinear" filtering."

I consider the strange BF-Artifacts as more annoying. There is not only the matter of the 6-Bit-LERP, as you know. I asked Xmas to send me a Screenshot of this Tester with his Radeon 9800 with particular settings, an saw this:

Image1.png


Where GeForce shows that:

dschiforge-qualitaet.png


(For funny's sake, I kept the very silly filename here.)

BF is the base of all today. TF, AF, all techniques are based on BF. So I expect the best quality possible, limited only by the resolution of the color depth in frame buffer.

No matter what u:v-Ratio, no matter how deep I zoom, I want the finest and most linear grades viable for 8:8:8:8-Color storing.
 
zeckensack said:
But I think the translation went online as "ATI filter cheats" or similar, which was, of course, just wrong. The original title is "ATIs Filtertricks" and was completely overlooked during translation :oops:
This has been corrected in the meantime.

I changed the thread title to reflect this.
 
andypski said:
I am not implying anything in terms of what is actually causing differences in the images, as that would require more research. I dumped out the shot from patch 340 on a 5200Ultra and it looked like the R300 and Refrast image, I dumped it out from patch 320 and it seems to look like the 5800Ultra image that you linked to.

Very interesting indeed. That yet again makes my original conclusion wrong. If the Nvidia seemingly "better" texture antialiasing in this case really is beaten by Futuremark swapping register names, I can't any more consider this to be effect of any greater precision in FX's way of rendering. And so it seems it might have actually even increased Nvidias fps to render the turtle this way. But better for me to not to jump any conclusions any more since I am now confused as I can ever be about this whole thing :)

Don't think about it as looking 'better' or 'worse' you should instead think about it as looking different. It may look better to you in the still screenshot, but that doesn't mean that it is the effect that the author intended to see, which is the whole point really. Why is it that you assume that whatever it is that makes it seem 'better' to you isn't necessarily wrong and possibly faster?

Good point there. I gotta bang myself to head for a while and repeat "assumption is the mother of all *ups."

Main question in my head seems to now be like: Why does refrast draw the turtle so poorly, what causes the texture aliasing here?

In the original 3DMark2001 the water in the Nature test aliases really heavily (perhaps from a large negative LOD being applied which I assume is to create a 'sparkling' effect). If you were to ignore the negative LOD bias and use a bias of 0 then the aliasing would go away, the image would almost certainly look better/smoother in still shots, and the performance would increase (because negative LODs are really bad for texture cache performance)

My head really hurts now but I guess I have to accept your theory. Couldn't have thought anything along those lines earlier. I guess I still have lot to learn.

yet at the same time the effect would not be what the authors of the application wanted you to see...

Yes. In benchmark its obviously critical to render what authors wanted. My theory was that it was possible for some hardware to render better than refrast and I thought that was the case here. But as Futuremark patch beats what i thought was "better rendering" then I have no more case.
 
aths said:
8 Bit is afaik 'SGI-Standard', also used by 3DLabs, afaik too.
Maybe so, but not to put too fine a point on it "So what?". :?

Nobody that I'm aware of made either SGI or 3DLabs the final arbiters of the 'correct' specifications for LOD fraction or filter kernel precision.

I am not arguing that more bits of precision are not better, clearly more bits are better in an absolute sense, but just because SGI or 3DLabs did it doesn't mean that it's right. Where are SGI's or 3DLabs's current consumer graphics cards? I certainly agree with your stance on the future, and in future hardware no doubt you will get more bits and more precision in all areas, as is inevitable, but saying that "SGI did it so it's the 'right thing'" is a bit of a cop out - it may be the author's opinion, but that doesn't make it a fact. Similarly those who believe that a 5-bit LOD fraction is a cause of visible aliasing are entitled to that opinion, but in reality it's very unlikely that this is really the cause of whatever effect they are seeing.

On the other hand the regular blocking pattern on the bilinear artifact picture is very interesting - I'm assuming the methodology in generating the image is sound because a great deal of care seems to have been taken over the article.
 
aths said:
BF is the base of all today. TF, AF, all techniques are based on BF. So I expect the best quality possible, limited only by the resolution of the color depth in frame buffer.

No matter what u:v-Ratio, no matter how deep I zoom, I want the finest and most linear grades viable for 8:8:8:8-Color storing.
So if you are rendering to an intermediate buffer that is 16:16:16:16 do you want an 8-bit filter coefficient or a 16-bit filter coefficient or something in-between, knowing that the final output is to an 8:8:8:8 framebuffer? I assume you actually want the coefficient precision limited by the bit-depth of the render target, rather than the frame buffer. I'm not saying that this is infeasible or a bad target to aim for, but the 8-bit filter coefficient that was the "SGI standard" that you suggest is now clearly insufficient by the same criteria for a 16-bit per-component target, since in the extreme case you cannot access all the colourspace. Since we are now allowing rendering to 32-bit floating point buffers I guess our filter kernel precision should actually be even more than 16 bits.
 
While I can notice the anomaly on the turtles back is noticeable, particularly with the close up, it is interesting I think that the lighting in that same frame is applied in different places. Is it possible that the lighting is randomly generated to a degree like the smoke from the door in GT2 and the hair and fire shaders in GT3? In these two screens you can see that the light seems to be focused on different parts of the turtles back in some instances washing out detail while in others making details more apparent.

http://jt7-315a.tky.hut.fi/mendel/ref450.jpg

http://www.skenegroup.net/common/images/5800_ultra_vs_R300/3dmark_450_5800_ultra.jpg

Shouldn't the light be illuminating the same area or no?
 
Re: ATI Filter cheats at 3Dcenter

nggalai said:
It's a theoretical / technical analysis of filtering behaviour on ATI hardware.

No, it is not. Its full of personal judgements of the author ("textook quality" burb, complaints about ATIs priorities, that he is disappointed about R300 technology, ...).
 
Sabastian said:
While I can notice the anomaly on the turtles back is noticeable, particularly with the close up, it is interesting I think that the lighting in that same frame is applied in different places. Is it possible that the lighting is randomly generated to a degree like the smoke from the door in GT2 and the hair and fire shaders in GT3? In these two screens you can see that the light seems to be focused on different parts of the turtles back in some instances washing out detail while in others making details more apparent.
The lighting seems to be completely consistent every time when I dump out frames on a 9700, so I don't think there's any random element in the lighting direction.
 
Re: ATI Filter cheats at 3Dcenter

Mephisto said:
nggalai said:
It's a theoretical / technical analysis of filtering behaviour on ATI hardware.

No, it is not. Its full of personal judgements of the author ("textook quality" burb, complaints about ATIs priorities, that he is disappointed about R300 technology, ...).
agreed
 
andypski said:
So if you are rendering to an intermediate buffer that is 16:16:16:16 do you want an 8-bit filter coefficient or a 16-bit filter coefficient or something in-between, knowing that the final output is to an 8:8:8:8 framebuffer? I assume you actually want the coefficient precision limited by the bit-depth of the render target, rather than the frame buffer. I'm not saying that this is infeasible or a bad target to aim for, but the 8-bit filter coefficient that was the "SGI standard" that you suggest is now clearly insufficient by the same criteria for a 16-bit per-component target, since in the extreme case you cannot access all the colourspace. Since we are now allowing rendering to 32-bit floating point buffers I guess our filter kernel precision should actually be even more than 16 bits.
I consider it a difference, to demand the precision for a single pass, or for a multipass-rendering with special intermediate buffer formats. PS.3.0 will allow jumps, so I feel no need for multipass-rendering. Again, there is not only the matter of the 6-bit-simplification, there is this another artifact (still unexplainable for me.)
 
andypski said:
So if you are rendering to an intermediate buffer that is 16:16:16:16 do you want an 8-bit filter coefficient or a 16-bit filter coefficient or something in-between, knowing that the final output is to an 8:8:8:8 framebuffer?
Texture filtering is only supported on 8-bit textures, as far as I know.

And I don't see much reason to have hardware texture filtering for higher-precision textures, as the largest reason to have higher-precision textures is for more advanced shaders that won't use standard texture filtering anyway.

As for the output, one day we may go as high as 10-bit or 12-bit output, but there shouldn't be any reason to go higher than that (unless a display method is developed that actually has enough brightness differential to make use of FP color...but then a custom FP16 mode that only uses positive values should be quite enough).
 
Chalnoth said:
andypski said:
So if you are rendering to an intermediate buffer that is 16:16:16:16 do you want an 8-bit filter coefficient or a 16-bit filter coefficient or something in-between, knowing that the final output is to an 8:8:8:8 framebuffer?
Texture filtering is only supported on 8-bit textures, as far as I know.
It's supported on all integer formats, but not on floating point, and the question was actually about the destination buffer, since a criteria for filtering mentioned in the original article was that the entire colorspace should be available through the texture filtering into the bit-depth of the destination buffer - in this case that means you need a 16-bit filter coefficient if you are rendering into a 16-bit per component destination as otherwise you will not be able to fully populate the colourspace in the case of an extreme zoom between neighbouring texels with values 0 and 1.

And I don't see much reason to have hardware texture filtering for higher-precision textures, as the largest reason to have higher-precision textures is for more advanced shaders that won't use standard texture filtering anyway.
The need for filtering on textures doesn't go away just because the source data is at higher precision. There are many reasons to use higher precision source textures, and advanced shaders do not necessarily eliminate the need for filtering at the input. Currently custom filtering using shaders is still expensive in terms of time compared to filtering hardware, and linear filtering is enough in many cases (as witnessed by its longevity).

As for the output, one day we may go as high as 10-bit or 12-bit output, but there shouldn't be any reason to go higher than that (unless a display method is developed that actually has enough brightness differential to make use of FP color...but then a custom FP16 mode that only uses positive values should be quite enough).
Frankly the bit-depth of the final output is fairly irrelevant to the situation I talked about above, depending on what you might be doing with intermediate buffers. If I rendered some data into an intermediate buffer that I later use to offset a lookup into another texture then even small differences in the rendering to the first buffer could cause unbounded differences in the values I eventually retrieve from the texture. This again faces us with the problem - what precision of filtering is 'enough'? It comes down to the fact that declaring that an 8-bit filter coefficient is 'enough' is simply an arbitrary choice - you could produce cases where it isn't enough, just as with any other precision choice.
 
Back
Top