Well, you can. I'm just not sure it would be that good of a thing to do. In particular, there's a lot of texture filtering logic that you would need to duplicate in such a shader, which would reduce performance.Laa-Yosh said:I was under the impression that you don't have to "force" SS, but can manually compute the neccessary amount of samples and blend them in the pixel shader instead. This should for example conserve framebuffer memory and increase precision as well AFAIK.
Notation: alpha blended textures are anti-aliased. It's the alpha test that causes problems.SA said:It would be great if the texture sampler returned a bitmask (say 4 bits for 4x AA) for alphablended textures indicating to the multisampler which (opaque) samples should store their z values and which (transparent) samples should not. This would provide for anti-aliasing of alpha blended textures with multi-sampled performance.
No, it doesn't. Alpha blending has the problem of blurring in the near-range, and alpha blends are not order independent (you must sort alpha-blended surfaces on the CPU).SA said:Alpha testing is the major culprit of course. However, alpha-blending can have the same aliasing problems as alpha-testing,
But they'd also need to have an appropriate sample pattern for that to help any.nobie said:They should enable the 6x mode in the drivers. It seems to get decent performance.
Chalnoth said:I think it'd be even better if the developer was given the option to switch between MSAA and SSAA (with the same number of samples, of course) on a per-traingle basis. This way SSAA could be used for those shaders that really need antialiasing, without dramatically reducing performance.Ailuros said:How about leaving anti-aliasing entirely to ISVs and let the developer decide wherever MSAA, SSAA or a combination of the two in the same scene would make more sense?
Even better would be to specify a minimum desired amount of SSAA: so that applications could use mixed-mode FSAA if available. Now, this would require completely programmable FSAA sample patterns to implement properly.
Sxotty said:Do any boards still do fsaa? I was just wondering I realize it is ridiculously slow, but considering how perful these boards are, it would look nice on older games.
Ailuros said:That's more or less what I had in mind; I just oversimplyfied it. Using SSAA selectively on parts of the scene where it's actually needed would properly antialias all "problematic" cases and a lot of fill-rate would be saved since the majority of the scenery would actually get MSAA.
Please note:Geeforcer said:
Laa-Yosh said:JohnH said:Its probably bandwidth, MSAA typically allows you to losslessly compress the FB by up to 4:1, this can't (easily) be done when applying SS.Kombatant said:What I find odd is the HUGE drop in performance. I know it does SS, but still...70-90% drop? I was like "wow" when I read Dave's review.
You'e right and wrong - it is true that with SS your samples are usually different and cannot be compressed efficiently.
However the main performance problem is fill rate - with SS you actually have to render 2-4-n times as many pixels, complete with texture reads and shader calculations.
Thats not always as easy as you'd think, at least in terms of minimising performance impact, but yes its one possible solution.I'd also say that brute force SSAA is not the answer to shader aliasing. It's better to implement some sort of AA in the pixel shader, as it can then be adaptive, which SS isn't.
StealthHawk said:Sxotty said:Do any boards still do fsaa? I was just wondering I realize it is ridiculously slow, but considering how perful these boards are, it would look nice on older games.
Apparently NV40 is capable of 16x SSAA. And it's faster than 8xS :?
Chalnoth said:No, it doesn't. Alpha blending has the problem of blurring in the near-range, and alpha blends are not order independent (you must sort alpha-blended surfaces on the CPU).
Certainly. But the "reg0C" mode isn't 16x OGSS. Last time I saw 16x OGSS was in a Det3 series driver.mikechai said:Does 16x SSAA looks better than 8xS ?
Xmas said:Certainly. But the "reg0C" mode isn't 16x OGSS. Last time I saw 16x OGSS was in a Det3 series driver.