When enough is enough (AF quality on g70)
- Thread starter tEd
- Start date
EasyRaider
Regular
I would like to check this out for myself, but since I don't have a 7800 to play with, I'll just not buy NVidia until the mess has been resolved (for better or worse).
I hope R520 can match NV2x texture filtering, cause G70 clearly cannot. The GeForce 3 arguably had a filter quality ahead of its time, but today it should be standard, at least in the high-end.
I hope R520 can match NV2x texture filtering, cause G70 clearly cannot. The GeForce 3 arguably had a filter quality ahead of its time, but today it should be standard, at least in the high-end.
EasyRaider said:
They sure as hell got a lot of credit for that also.. eeeh.
And regarding the article: good. We need more stuff like this. Examine everything, put it out in public. And don't be kind on the IHV's, make them sweat a bit so that perhaps it won't happen a second time. Well, who am i kidding..
Last edited by a moderator:
...I remember certain games that let you set LOD bias. Except, instead of calling it LOd bias they called it "texture sharpening" and there was an unmarked slider from positive("softer") to negative LOD bias("sharper").
Trying this on a few friends of mine, many PREFFERED a little "sharper" textures even though you could clearly see increased aliasing. Could nV be settings a small negative LOD bias because they think people would actually want "sharper" textures with more aliasing?
Trying this on a few friends of mine, many PREFFERED a little "sharper" textures even though you could clearly see increased aliasing. Could nV be settings a small negative LOD bias because they think people would actually want "sharper" textures with more aliasing?
No. If you look at the animated screenshot on the second page, you can see what's happening: Aggressive use of brilinear. If you look closely, you can see that the spot that would correspond to a transition between mipmaps doesn't move. However, the region over which two mipmaps are sampled is shortened dramatically. This has the effect of causing aliasing on the region before the mip transition as the previous (i.e. more detailed) level has a larger contribution than with normal trilinear. Of course, sampling a single mipmap is faster than sampling two mipmaps because trilinear is not free on NVIDIA cards.soylent said:
-FUDie
I just wonder how NV let this happen??? Since the shimmering did appear on the G6xxx series, thus engineeringly... this would be on the error check lists by the time they designed this G7xxx series (just don't let it happen again). And now, I myself start having a question that NV knew or not before throwing this 7800GTX into the world. One point that can be possible the ease the problem for them is that by putting on vert high frame rate as possible so that this could play trick on our sight... or we just simply miss it since our eye is not fast enough to catch it (the image was changed before we diagonsed it). But this is not the case for everyone. Just only wondering so...
Wouldn’t running textures a little sharper allow one to reduce AF somewhat and still attain relatively the same “sharpness” of textures. Sort of like … sharper + 6AF = normal + 8AF. One could get an overall speed increase (maybe 3-5% overall ..???). But then in certain situations you get texture aliasing.soylent said:
caboosemoose said:
I'm not a reviewer and I'm not working for any site, so that puts me in a totally different category.
Long story short: in June 2004 I re-played the games (not entirely but a couple of maps/tracks of each) listed up to page 14 in the write-up I linked to a couple of posts ago. Out of that bunch of games I ran across the shimmering issue in Asbestos/UT2k4, what I did and what not is stated in the article. In parallel I contacted a couple of people that are more experienced than me asking if they notice anything, just to make sure that any mistake from my side hasn't slipped in. I send off an e-mail to NVIDIA afterwards describing in detail my findings and didn't receive an answer and just gave the green light for publishing.
People started pointing at that page here in the forums and other applications like BF1942 and Painkiller were reported to show similar if not worse problems and there were quite large debates about it here at B3D.
Written with 61.45, LOD clamp introduced in fall 2004 with the 71.20 ForceWare driver.
6800 release driver was 60.72 I think. I never checked that one out, since when I got the 6800 the 61.19 was available already.
Here is actually a comparison between the SM2.0 and SM3.0 path and a quite detailed description (and a quite valuable one IMO and hence I added it into the text) from Demirug at the end of the page:
http://www.mitrax.de/?cont=artikel&aid=24&page=10
Later drivers delivered further increases in performance as can be seen in the part of the update of the article here (10-15%):
http://www.mitrax.de/?cont=artikel&aid=24&page=15
I have some questions to ask about the problem of angle dependent AF as explained in the article.
There is a reason that explains why some angles get more AF samples than others. The algorithm used by ATI, and now by NVidia, is quite simple and works taking multiple texels/samples along a single axis. Those axis are at 0º, 45º, 90º and 135º as the tunnel test shows. The algorithm is simple and easily implementable in hardware because it just needs to calculate the ratio (related to the texture sample shape when projected onto the texture and calculated using the texture access derivatives on texture space u,v over screen space x,y) for each pair of perpendicular axis and then calculate the texel/sample offsets/addresses along the chosen axis.
I don't know what the algorithm for NV2x, even though I tried to discover it, (that may only means that I'm not that good discovering such algorithms though) but at some point I was starting to suspect that given the squarish looking form (it's more easy to see the squarish form when lowering the quality parameter or selecting bilinear) in the tunnel test that they were just forcing maxAF/2 or something similar for any texture access that wasn't getting maxAF with the algorithm described above (using only the 0º and 90º axis, as ATI was doing at the time with the R2xx), or perhaps other function that was increasing 'artificially' the number of samples to take. I never tested if that was correct.
In any case unless the GF3 is taking the AF samples on a grid and with a calculated non a rectangular shape (that is, a process way more complex that taking samples along a selected axis), which I doubt, the extra AF samples shouldn't be helping that much to improve the image quality as they are just more samples, but not following the irregular/anisotropic shape or the texture sample. The tunnel is just showing how many samples (which mipmap as the mipmap selected is dependant in the number of AF samples) is the AF algorithm taking, not if it looks better or it's more mathematically correct.
There is a reason that explains why some angles get more AF samples than others. The algorithm used by ATI, and now by NVidia, is quite simple and works taking multiple texels/samples along a single axis. Those axis are at 0º, 45º, 90º and 135º as the tunnel test shows. The algorithm is simple and easily implementable in hardware because it just needs to calculate the ratio (related to the texture sample shape when projected onto the texture and calculated using the texture access derivatives on texture space u,v over screen space x,y) for each pair of perpendicular axis and then calculate the texel/sample offsets/addresses along the chosen axis.
I don't know what the algorithm for NV2x, even though I tried to discover it, (that may only means that I'm not that good discovering such algorithms though) but at some point I was starting to suspect that given the squarish looking form (it's more easy to see the squarish form when lowering the quality parameter or selecting bilinear) in the tunnel test that they were just forcing maxAF/2 or something similar for any texture access that wasn't getting maxAF with the algorithm described above (using only the 0º and 90º axis, as ATI was doing at the time with the R2xx), or perhaps other function that was increasing 'artificially' the number of samples to take. I never tested if that was correct.
In any case unless the GF3 is taking the AF samples on a grid and with a calculated non a rectangular shape (that is, a process way more complex that taking samples along a selected axis), which I doubt, the extra AF samples shouldn't be helping that much to improve the image quality as they are just more samples, but not following the irregular/anisotropic shape or the texture sample. The tunnel is just showing how many samples (which mipmap as the mipmap selected is dependant in the number of AF samples) is the AF algorithm taking, not if it looks better or it's more mathematically correct.
Wrong, there aren't enough samples to really show large differences between different the angles. But in fact if you look carefully you can already see which angles will get max aniso when you more samples are allowed. Is really 2xAF so much better than trilinear? How many samples are being used per access in average in the test that shows no shimmering? 1?
That may be right and obviously changing the lod bias will change the displayed mipmaps in the AF test application. However you always compare with the displayed mipmaps for 1xAF and if the lod bias doesn't change with the AF level (and would be noticeable as there are angles where only 1 sample is taken) you should be able to roughly calculate the number of samples taken for any access.
The texture access calculated lod is divided by the calculated number of AF samples to take. That's why the mipmap selected is lower when more AF samples are taken. Of course an IHV could do the division and keep from taking the calculated number of samples (in fact if the division is not integer, as it isn't for those flower looking shapes, the number of samples to take is rounded and may be different from the division factor, if someone wants to know how I would look with an integer division I could try to render a frame with a modified version the algorithm basically is very squarish and with a larger are using less AF samples). However I think such trick should be noticeable when displaying the tunnel without colored mipmaps, at some point the change from the colored mipmap display from level to level wouldn't be shown in the non colored version of the tunnel. And that trick would seem targeted just to trick the colored mipmap tests not the propper AF quality ones. When you don't take the samples in the propper anisotropic shape or direction even if you use a smaller mipmap there should be noticeable blurring as it would be just like trilinear with an aggressive lod.
In any case I want to explain that I'm only arguing against the angle dependent algorithm being impropper, incorrect or a hack. I have the maths for the algorithm, they are very clear and explain why it is implemented in such a way. I don't have the maths for the NV2x algorithm so I can't say for sure what it does. I'm not actually talking about the shimmering problems in the G70 (I don't own one and I haven't even properly looked to the reviews) and I don't know their causes.
Anyone can try to suggest an alternative AF algorithm that is relatively inexpensive when implemented in hardware and looks better. May be the IHV will be interested too.
The texture access calculated lod is divided by the calculated number of AF samples to take. That's why the mipmap selected is lower when more AF samples are taken. Of course an IHV could do the division and keep from taking the calculated number of samples (in fact if the division is not integer, as it isn't for those flower looking shapes, the number of samples to take is rounded and may be different from the division factor, if someone wants to know how I would look with an integer division I could try to render a frame with a modified version the algorithm basically is very squarish and with a larger are using less AF samples). However I think such trick should be noticeable when displaying the tunnel without colored mipmaps, at some point the change from the colored mipmap display from level to level wouldn't be shown in the non colored version of the tunnel. And that trick would seem targeted just to trick the colored mipmap tests not the propper AF quality ones. When you don't take the samples in the propper anisotropic shape or direction even if you use a smaller mipmap there should be noticeable blurring as it would be just like trilinear with an aggressive lod.
In any case I want to explain that I'm only arguing against the angle dependent algorithm being impropper, incorrect or a hack. I have the maths for the algorithm, they are very clear and explain why it is implemented in such a way. I don't have the maths for the NV2x algorithm so I can't say for sure what it does. I'm not actually talking about the shimmering problems in the G70 (I don't own one and I haven't even properly looked to the reviews) and I don't know their causes.
Anyone can try to suggest an alternative AF algorithm that is relatively inexpensive when implemented in hardware and looks better. May be the IHV will be interested too.
Last edited by a moderator:
RoOoBo said:
I'm not sure I'm following you entirely; if I look at 3DCenter's "mouse over pic" and the NV3x's pic (granted that's 8x AF), then it doesn't look identical to the above either. To your questions: 1. not really 2. I was talking about games where the problem usually occurs and not filtering testing applications.
What we might need (even more me as a layman) are more sophisticated filtering testing applications, because one thing many will agree on is that the current don't analyze all prospects of an algorithm properly.
I must have overlooked something; did anyone say that it's a "hack"?
Just for the record and as a sidenote, albeit I don't consider AF angle-dependency ideal, I can live it with it. I can't "live" though with dancing meanders across my screen.
Oh come on, don't waste our time. I can't believe that you didn't understand what I meant. Several companies (including NVIDIA) have offered single-cycle trilinear in the past. This can be implemented in a manner that makes it nearly "free" and certainly has a much lower impact on performance than two-cycle trilinear.Chalnoth said:
-FUDie