New D3D FSAA Viewer

You enable it by creating/modifying the STRING value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{SOME_GUID}\0000\TemporalAAMultiplier

where SOME_GUID (and maybe the 0000) can change depending on the installation (you should check all of them to make sure you are changing the right one).

And as has been mentioned to you then need make the D3D drivers be reloaded.
 
Chalnoth said:
101 said:
bloodbob said:
*bloodbob Hugs his 18X AA
I think 18x is an awfully strong term for 6xAA w/3 sample patterns
Well, it is effectively that for nonmoving images at high framerates.
...

But the label "18x" will end up being applied regardless of the movement of the image or framerates being high enough. There are plenty of ways to market it without misinforming users, even <samples>x<temporal divisions>, and making sure to discuss the basis for it in a release "marketing technical paper" like that which accompanied the R300.
What I'm concerned about is hiding it or engineering it's presentation towards the end of being a benchmark stacker. I seem to recall that something of the type was done before.
 
Wouldn't using a dual framebuffer counter the low fps problems and possibly this is therefore a feature to be implemented for R420+ cards?
 
THe_KELRaTH said:
Wouldn't using a dual framebuffer counter the low fps problems and possibly this is therefore a feature to be implemented for R420+ cards?

Yes , I was wondering if the big hit in framerates MuFu mentioned with v-sync on were the same sort of problems that got Ati to introduce the triple buffering option in the OGL driver.

Is that the same sort of thing you are talking about ?

Mark
 
I'm sitting here happily benching me heart out to 3dm2k1se thru the various AA settings, but a couple of questions:

-I have to reboot between changing the settings still or they just won't "stick" for me.

-V-sync is set to app preference and it is not on while benching but the AA is. (3dm2k1se; no comments please, it's my personal fave)

I must say the 2xT3 & 4xT3 have looked pretty sweet to me and seem to be quick, but I got more benching to do before I got anything conclusive. :)
 
Morning. :)

DemoCoder said:
Yes, for a perfectly still image, it would essentially be equivalent to the app submitting geometry 3 times and doing accumulation buffer AA -- except -- no blending is being done. It's relying on the human eye to do the downsample, and that requires high refresh rates. 90-120Hz would essentially be equivalent to 12xAA at 45-60Hz. Of course, how many games can run rocksolid locked at 90-120Hz at reasonable resolutions?

Well probably lots with R420/R423; I think that's the idea. We don't know that this will ever actually be made available to R3x0 users (although it seems likely, IMHO).

demalion said:
Chalnoth said:
101 said:
bloodbob said:
*bloodbob Hugs his 18X AA
I think 18x is an awfully strong term for 6xAA w/3 sample patterns
Well, it is effectively that for nonmoving images at high framerates.
...

But the label "18x" will end up being applied regardless of the movement of the image or framerates being high enough. There are plenty of ways to market it without misinforming users, even <samples>x<temporal divisions>, and making sure to discuss the basis for it in a release "marketing technical paper" like that which accompanied the R300.
What I'm concerned about is hiding it or engineering it's presentation towards the end of being a benchmark stacker. I seem to recall that something of the type was done before.

Yah, while I share Chalnoth's scepticism, I started calling it "(2x number of samples)xT" for a reason. It will most likely be marketed this way - 12xT being "12 samples in delta t", of course. I doubt the higher multipliers will be exposed at all.

I hope they produce a good (and wholy objective) whitepaper to go with it - would be interesting to read their findings. Particularly empirical testing - I wonder how many undergrad engineers had their eyeballs fried thanks to the research. :LOL:

kipper67 said:
THe_KELRaTH said:
Wouldn't using a dual framebuffer counter the low fps problems and possibly this is therefore a feature to be implemented for R420+ cards?

Yes , I was wondering if the big hit in framerates MuFu mentioned with v-sync on were the same sort of problems that got Ati to introduce the triple buffering option in the OGL driver.

Is that the same sort of thing you are talking about ?

Mark

I didn't mean big FPS hits - the "huge frame rate drops" were just the expected consequence of having v-sync on (but you could tell it was happening more often with T-AA on because of the reported average FPS). The performance hit seems minimal - if I had a slightly faster CPU (for example), the 6x and 12xT benchmarks would probably be almost identical.

I'm not sure having a dual framebuffer (if I understand what you mean correctly) would be advantageous over simply doubling the refresh rate. Unless, of course, you render two "subframes" and blend before output.

Digi, I'm pretty sure this will override even 3DM and enable v-sync.

MuFu.
 
I've uploaded a new version (same URL as the first post) which fixes a few problems, and added a few extras too. The version number is updated to 5.1.

Firstly i added in a trick so when using the step by step mode it will not revert back to the default sample positions. This only works in windowed mode though.

I also changed the frame capturing a little bit. Before it would render 2 more frames before capturing the output, now however it will capture the exact current output on the screen.

I also added 2 more point size modes. These are 1/12 and 1/24. I added them because the ATI chips have their sample positions alligned to a 1/12 grid. Default is still 1/8.

I also enabled the 128x128 Grid size mode. It will only work on cards that actually support it, which is pretty much anything modern (option will be disabled on cards that wont support it). Default is still 64x64.

Lastly the Settings menu will now actually reflect the current settings.
 
The Baron said:
incurable said:
The Baron said:
incurable said:
*making up clever plans to -errr- borrow *cough* the RV360 from my nephews PC later today*
I thought the RV cards didn't have programmable sample patterns.
They don't? :oops: Damn! :cry:
Thought I read that on here somewhere. Not entirely sure. I'll check.
Apparently it works :), somewhat. :?

I could only confirm 4xT2 and 2xT2 using 5.0, might try it later with the new 5.1.

During the limited amount of testing, I had a hard time seeing much of a difference on screen, though that might have been through the very suboptimal conditions (limited time, TFT connected through D-SUB, lack of good test scenes at hand).

I need to test it more thouroughly ... gotta get that spare HDD up and running in my Nephew's PC now. ;)

cu

incurable
 
FSAAViewer shows up the effect very well in fullscreen mode (very badly in windowed mode, of course). 12xT looks very good and 4xT is a bit flickery - at least at 60Hz.

It's the same in games. 12xT looks great, IMHO. A baseline of 6x FSAA when moving and effectively 12xMSAA when stationary - not bad for little/no performance hit.
 
StarGazer said:
Quick with those benchmarks & screenshots :!:

Read the thread - both are practically impossible (although it'd be easy to give a "simulated" sample of the latter).
 
I did but at least it would be nice to compare games with Vsync on and the new AA modes, just to check the perfomance impact.
 
Now, isn't this PR heaven?

A feature that you can label with high numbers like 12xT AA, and 16xT AA, and you can honestly say that it's impossible to benchmark or produce screenshots? :LOL:
 
Well considering the minimal performance hit, do you think that the fact it can't be benchmarked is good for ATi?

Can you imagine what 8xT vs nVidia 8x quantitative comparisons would be like if they were at all feasible?! LOL.
 
Ylandro said:
Now, isn't this PR heaven?

A feature that you can label with high numbers like 12xT AA, and 16xT AA, and you can honestly say that it's impossible to benchmark or produce screenshots? :LOL:

They could really say its cheating since the workload is falling on our eyes and visual parts of our brain. I guess brain benching will be the new thing in the coming years..... :LOL: :LOL: LMAO
 
StarGazer said:
I did but at least it would be nice to compare games with Vsync on and the new AA modes, just to check the perfomance impact.
I just spent a little over an hour comparing 2xAA, 4xAA, 6xAA to 2xT3, 4xT3, 6xT3 ("T3" being temporalthingyregvalue at 3) and after all that freaking work I found it to be exactly the same or within the margin for error on 3dm2k1se.

The T3 AA looks a lot better to me though, but I wanna go re-run some tests on 640x480 to really see the aliasing differences. I'm bugging me boss to let me put a viddy together to show off the difference between 2xAA & 2xT3 since I feel that's the most dramatic difference one, but I'm waiting to find out how he feels about getting slammed with the bandwidth on that one. (We got the new server, might as well use it... ;) )

From my opinion so far the 2xT3 is comparable to the 4xAA, it really is....but I haven't even tested it with v-sync on yet! (All me benchies were run without v-sync)
 
What refresh rates are you using? I find it hard to imagine 2x3T looking acceptable at less than 150-180Hz.

2x2T@60Hz doesn't look all that great, IMHO, due to a combination of the flicker and distracting aliasing along high contrast, moving edges.
 
Back
Top