New selective supersampling demo

Another cool demo

my results
6800LE 354 824 16vp 79.11, 754 3000+ @ 250fsb
26-35fps @ 1600x1200 8xS AA, 11 samples

 

7800GT and x2 3800+ @2.4GHz
1280x1024 4xAA/16xAF 11 samples (HQ)
Around 70-110fps.

 

Well, FSAA is relatively simple to support. In consoles it may be slightly more difficult, but it's not such a big deal.

What's really important for ISV's to work on, however, is anti-aliasing within the shader. Basically, lots of shaders alias really badly. Simple bump mapping is one obvious example (as shown in this demo).

Now, I do largely agree with Rev's post, but there is a simple solution: robust shader libraries. It looks like UE3 is going to ship with a good shader library, so hopefully they'll catch on soon.

 

I wonder, how feasible would it be for the shader libraries in UE3 offer the option of SS in the shaders similar to Humus' demo? Probably not very, I'd guess.

The next-gen engines should allow a big leap in image quality over the current stuff so it would be nice if there were options to reduce aliasing to the highest degree possible as well.

 

'

Yeah CCC AF. Thanks for the clarification.

 

The limitation was probably mostly on dependant texture read and number of instructions (if you already reach the limit of instructions of ps2.0 without supersampling that gives you an idea).
With all ihv supporting PS3.0 now, that may be easier. Or they may decide to add more complicated shaders instead. Hey!

LeGreg

 

Well, I would expect it'd be very feasible. Just don't know if Epic has spent any time developing anti-aliasing versions of the various pieces of code.

Anyway, bear in mind that not all algorithms require supersampling. There are, for example, methods of making use of texture filtering information to provide approximate MIP mapping for bump mapped surfaces with very little added cost.

 

With DB it is up to 120 frames faster

 

on 11ss and DB iget 142, with out 114.

 

Seems to be a bit slower with dynamic branching on my 7800 GT SLI.

 

Just so I know what Tim Sweeney as a developer thinks about doing something like this (SS directly in shaders, in/on specific surfaces within a scene) :

 

BTW, and I forget and is too lazy to check, XB360's Xenos does 2xMSAA "for free" right?

How feasible would it be for it to have 2xSSAA?

Sorry if this question is in the wrong forum.

 

I can't resist being a smart ass, so I apologize in advance for this post.

Dual Core 2.3 Power Mac G5
7800 GT
2 GB RAM
Mac OS 10.4.4

.exe file won't run.



But thank you for all your incredible work Humus. You are the undisputed king when it comes to actually showing all of us what the hell it is we discuss and feebly attempt to visualize in this forum.

 

Here is an IQ compariosn with different AA modes and combos:

No AA (reference non-AA image)
7xSSS*
16xS, 8xS
16xS + 7xSSS
4x4 SS, 4x4 SS + 7xSSS

*SSS - Selective SSAA
Note: AF was forced to x16

 

Run's fine om my 6600 GT. Makes a huge difference with only a few samples. 11 samples still shows some aliasing on certain angles though.

 

Dynamic branching has a big performance hit on a 6150 (about 30%). I might try it with a 6600GT later but I expect the result to be similar.

 

I went ahead and tested this on my rig. ((Motherboard managed to be stable long enough to run the test)) ^^ The system is an A64 3800+ @ 2.4 Ghz, Geforce 7800GTX 256 SLI setup. I tested used 7 sample super sampling for both pictures. 1600x1200 resolution. ((dont mind the LoD I have it slightly adjusted))

Single Card

http://www.3declipse.com//images/stories/ChrisRay/single7sample.jpg

SLI 7800GTX

http://www.3declipse.com//images/stories/ChrisRay/sli7sample.jpg

 

One thing I've been considering when speculating about the future, is that monitor size cannot grow infinitely and stay practical at the same time. So yes I can see the reasoning that resolutions won't scale as much as processing power.

What seems a bit more difficult to believe at this stage is where the fillrate and bandwidth will come from for SSAA, especially if you encount float HDR.

Hmmmm someone correct me if I'm wrong but I wouldn't think that Xenos would have any problem with 2xSSAA in terms of memory footprint and/or bandwidth. Main consideration would obviously be fillrate. If such a design would for instance have twice the fillrate it has today but the same bandwidth, then I can see it make more sense. And maybe Sweeney does think that fillrates will scale in the future way more than bandwidth compared to today's architectures.

 

Just out of curiosity

Other than the DB part, Humus, why does this demo require SM3.0?

Is it mandatory due to the technology you use or is it simply because you coded your app with SM3.0 in mind?