When enough is enough (AF quality on g70)

Bob said:
How does HQ mode on G70 with the 78.xx drivers compare to HQ mode on NV40?

I'm convinced output isn't the same (difference output from screenshots, both using 78.03), but I'm not sure I can see it in motion at all, either. Someone else with both parts should have a go and see what they think, I'm sick of farting around with it all now, haha!

From the other reports round the web, it definitely seems like a well received fix, that's for sure.
 
Hmmmm, is this an ode to Jawed's pipe-dream? :LOL:

Texture samplers in NV40 are bound to their containing fragment units, so you can't assign any idle samplers to the filtering task being performed by one of the four fragment quads. Idle quad that's not texturing? Idle texture samplers, sadly. With a usual 16x anisotropic filter taking 256 texel samples per pixel, you can see how without a separate dedicated array of units that can texture, finding ways to limit the performance of a tied-to-shader-hardware configuration is prudent.
 
Great work Rys. Pity I have to spread rep around before giving you some more... Darn, can't even give neg rep to make the task easier.

Jawed
 
trinibwoy said:
Hmmmm, is this an ode to Jawed's pipe-dream? :LOL:
The thing is, Xenos already uses this technique - and my proposal that it might be used in R5xx was simply because I wasn't initially prepared to believe that a complex Xenos-like scheduler is in R5xx. Now that I do believe that, the TMU-array concept is a given, and isn't, in itself, as dramatically interesting as it once was ;) The scheduler, if true, is big news and the nice TMU utilisation is just one big gain out of many.

In truth, due to the SIMD quad-organisation of NV4x, I don't believe that it's possible to find a quad that's not texturing.

But in G70, which is 6-way MIMD over its quads, there's no doubt that some TMUs may well be idle.

The same goes for R3xx...R4xx, except for the single-quad SKUs, of course.

Jawed
 
I've certainly noticed less flickering at Quality mode than before - if you disable the anisotropic optimisations it reduces a little more, too.
 
I hope somebody does a thorough comparison across several games once official drivers are released with the shimmering fix (Rys,Tim, Dave). I don't play any of the games that exhibit it the most but it would be nice to know what kind of performance hit we're looking at overall.
 
trinibwoy said:
Then why is there a performance drop in Quality mode in your results?

That the texel sampling fix is in the driver for HQ mode doesn't mean there's not other bugfixes and other performance changes in there that have global effects. I don't think it's just the 77.77 codebase with only that single fix, at any rate.

Regardless, I've quickly redone the benchmarks in HL2 and updated that part of the article. Reviewer bug: I left TAA and gamma-correction on while testing for some other stuff, when benching the 78.03s and the drop is even less than first reported.
 
Rys said:
Regardless, I've quickly redone the benchmarks in HL2 and updated that part of the article. Reviewer bug: I left TAA and gamma-correction on while testing for some other stuff, when benching the 78.03s and the drop is even less than first reported.
In the original article, the second benchmark showed quite different results. Are you redoing the second benchmark too?
 
Blastman said:
In the original article, the second benchmark showed quite different results. Are you redoing the second benchmark too?

I could do I guess. Results should be predictable, though: slightly more drop off than the usual benchmark, but nothing massive. I'll try and run Splinter Cell and a couple of others through both drivers to show a bigger spectrum of titles, as well as the second HL2 timedemo.
 
WaltC said:
Yes, and a good reviewer should also know right off the bat to ignore official nVidia instructions as to how to "best benchmark" a nVidia product, right? Of course, since nVidia goes to so much trouble to spell out a particular method reviewers should use expressly for benchmarking, we have to assume that nVidia doesn't have as high an opinion of reviewers in general as you do...;) (If nVidia didn't believe they could be manipulated they wouldn't even try, right?)

A good reviewer would investigate as deeply as possible any hardware without taking any recommendations from the manufacturer into account.

As for the manipulation part I'll come back to that one.

Yes, its so boring not to be a revisionist, isn't it? I guess I'll have to be boring, then...;)

More than you can imagine.

Wonderful news--and that's yet another reason I don't use nV today--the fact is that everything nVidia has ever made "will be fine with an upcoming driver release"...;) I know that I must be peculiar, but I'm a present-tense kind of guy.

Don't even attempt telling me that other IHVs drivers since the dawn of 3D didn't contain "fixes" for bugs, optimisations or anything else in their driver sets. Nor try to tell me either that everything and I mean everything works as expected with any hardware from the first driver sets either.


I didn't say anything about B3d reviews and I agree they have always been fine. I was talking about the atmosphere in the B3d *forums* where some people are still confused on the difference between optimizations and cheating on benchmarks...;)

I'd expect you to loopside here and that's why I kept a full answer from the first paragraph for the end. I have severe doubts that B3D's reviews contain performance numbers from ForceWare high quality filtering modes in all their GeForce (p-)reviews. With that possibility in mind I'd like to hear more about weird indirect manipulation attempts or any other sort of wild conspiracy theory.

Last but not least: define cheating with texture filtering; current GPU drivers from both IHVs contain angle-dependency with AF, texturing stage optimisations (whereby only the primary texturing stage 0 gets trilinear - or brilinear if that is also enabled - and all others from 1 to 7 receive garden variety bilinear), something in between trilinear and bilinear often named bri- or trylinear etc etc. If that's not doing half the work or less already then I don't know what it is. Here it's expectable that either/or will constantly try to reduce workload in order to compensate for performance especially with the constantly rising shader-load and since I don't really have much of an alternative I'll just close an eye to the less obvious optimisations and react and protest against those that are way too obvious. There the line between optimisation and cheat is already so blurry, that almost anything is allowed these days and we just sit there and tolerate most of it.
 
trinibwoy said:
I hope somebody does a thorough comparison across several games once official drivers are released with the shimmering fix (Rys,Tim, Dave). I don't play any of the games that exhibit it the most but it would be nice to know what kind of performance hit we're looking at overall.

I've started testing a variety of games with high quality vs. quality, but not all of them exhibit shimmering either to be honest. Normally I wouldn't had included games like UT2k4 for instance, but since it's one of the problematic cases I won't skip it. I'm a slow poke though, because I play more than I benchmark ;)
 
Ailuros said:
I've started testing a variety of games with high quality vs. quality, but not all of them exhibit shimmering either to be honest. Normally I wouldn't had included games like UT2k4 for instance, but since it's one of the problematic cases I won't skip it. I'm a slow poke though, because I play more than I benchmark ;)

Take your time. Just get it out before the 80 series gets here :)
 
trinibwoy said:
Take your time. Just get it out before the 80 series gets here :)

I'm already at 30% in two days; but that's tortoise speed under normal conditions. I'd wish actually I had games like Serious Sam2 for instance to play with and not the same old boring stuff *sigh*
 
Last but not least: define cheating with texture filtering; current GPU drivers from both IHVs contain angle-dependency with AF, texturing stage optimisations (whereby only the primary texturing stage 0 gets trilinear - or brilinear if that is also enabled - and all others from 1 to 7 receive garden variety bilinear), something in between trilinear and bilinear often named bri- or trylinear etc etc. If that's not doing half the work or less already then I don't know what it is. Here it's expectable that either/or will constantly try to reduce workload in order to compensate for performance especially with the constantly rising shader-load and since I don't really have much of an alternative I'll just close an eye to the less obvious optimisations and react and protest against those that are way too obvious. There the line between optimisation and cheat is already so blurry, that almost anything is allowed these days and we just sit there and tolerate most of it.

I find your definition of cheating very narrow...;)

Here's the way I define the two terms:

Optimization: Structuring the code to run most efficiently on your hardware. Generally, all pre-nV30 optimization was considered to simply get the most out of the hardware while still delivering the optimal IQ possible.

Cheating: Structuring the code to detect when specific benchmarks are run, and then writing the code so that when that condition is true a *false impression* of the general performance of the hardware benchmarked occurs when the benchmark is run, creating a false impression as to the value of the hardware under the benchmarks run. Generally, such cheating can be said to occur when IQ is less than normally possible in a specific benchmark(s) but is otherwise fine at the same settings in when applied in global operation. In these cases the reduced IQ directly results in faster framerates than would otherwise be possible under the same IQ settings when running software other than the targeted benchmarks.

This is just such a simple concept. I see an enormous difference between the two conditions, regardless of when either has ever occurred.
 
ChrisRay said:
It looks like the drivers are available on nzone now.

I have to say cheers to Chris and Ailuros who gave me a hand with some stuff in the beginning and validated some testing I was doing. Thanks chaps. ChrisAndAilurosDo3D.com would rock ;)
 
Rys said:
I have to say cheers to Chris and Ailuros who gave me a hand with some stuff in the beginning and validated some testing I was doing. Thanks chaps. ChrisAndAilurosDo3D.com would rock ;)


No problem :) It was good there were others out there actually willing to take the time to cooridinate with nvidia on the issue. I honestly feel good communication with Nvidia had an impact on the swiftness of this beta driver release. :)
 
Back
Top