GeForce GTX 460 SLI vs. Radeon HD 5970: Two Against One

[Scali]

Yes, the problem is with AF, and there’s no real-time implementation that will resolve all texture and shader aliasing. Even 512x ALU-rendered AF shows similar problems, and that’s not available outside of tester apps and similar. Therefore the only available solution is to use SSAA which visibly reduces shader and texture aliasing.

I don't think you understand where I'm coming from.
I'm not talking about *current* games and *current* hardware, because obviously that has flaws, so it's pointless discussing that.
I'm talking about how we are going to move forward and find the best possible balance between image quality and performance.

I get the distinct impression that what I've said simply went *woof* over your head. You don't seem to understand how a rasterizer works *at all*, or why tessellation can have a significant effect on texture filtering and MSAA because you move back to strictly *linear* surfaces.

Do you understand that for a perfectly planar surface (say a triangle), supersampling can easily be simplified because you know where your neighbouring pixels are, when you sample a texture? And that it is therefore quite pointless to render complete pixels, if you can get a perfect texture sample from a single pixel anyway (and perfect surface normal etc)?
There will not be any discontinuities in texturing or shading because the surface is perfectly flat.

This is simply untrue; any surface can be undersampled if there are not enough pixels. That’s a by-product of converting from world space to screen space.

That's not the point. The point is that the undersampling can be dealt with without supersampling the lot, if you can assume that the surface is planar (or at least continuous, like with smoothed normals and other gradients).
You do not seem to understand what a linear surface is. I'm just not getting through to you.

I’m starting to wonder whether you have any significant gaming experience at all.

I've written a lot of real-time renderers over the years, both software and hardware. I know the ins and outs of rasterizing, raytracing and REYES rendering.
What do you know about the inner workings of a triangle rasterizer and how shading is and filtering are implemented? Not a whole lot, it seems... Most of what I said goes straight over your head it seems.

 

[bryanW1995]

yes scali, you're too smart for the rest of us. maybe another forum would be better suited to your immense coding skillz.

Personal attacks/insults are not acceptable in VC&G. Please vent elsewhere: PFI, mod discussions, reported post, pm, etc.

Moderator Idontcare

 

[BFG10K]

I'm talking about how we are going to move forward and find the best possible balance between image quality and performance.

We already have evidence that your way doesn’t work, specifically in games that don’t use shaders to simulate geometry but still show texture and shader aliasing. Again, I can demonstrate games as old as from 1999 that use fixed function T&L, but still benefit from SSAA.

It can also be demonstrated that even polygon edges in today’s games aren’t smooth because MSAA isn’t affecting shaders or textures along such edges. This has become quite prolific since 2004 or so, and anyone with even the most basic experience gaming with AA knows this.

I get the distinct impression that what I've said simply went *woof* over your head. You don't seem to understand how a rasterizer works *at all*, or why tessellation can have a significant effect on texture filtering and MSAA because you move back to strictly *linear* surfaces.

You’re saying that if you don’t use shaders to approximate geometry and instead use polygons on the same plane (whose counts are increased with tessellation), you won’t have shader or texture aliasing. I’m stating this is wrong and can be readily demonstrated it’s wrong.

So here we are: a completely flat surface with no shaders, yet SSAA still shows a huge difference. But according to you, the “undersampling can be dealt with”, or some-such nonsense.

Of course I expect you to ignore this and continue arguing.

I've written a lot of real-time renderers over the years, both software and hardware. I know the ins and outs of rasterizing, raytracing and REYES rendering.
What do you know about the inner workings of a triangle rasterizer and how shading is and filtering are implemented? Not a whole lot, it seems... Most of what I said goes straight over your head it seems.

I’ve done both OpenGL and RenderMan programming, and I’ve also implemented triangle rasterizers and custom anti-aliasing techniques. But that’s not really relevant here because what I’m stating is so basic, anyone with gaming experience that knows how to use an AA slider can prove it.

 

[SirPauly]

imho,

I would just like to see improved texturing without aliasing but with more efficiency.

However, I am very thankful to have tools to address these issues now even though the hit is high. I have read the reasons why super-sampled doesn't make sense and from a future forward or developer point-of-view -- certainly understand many of the points.

But considering we're not there yet -- and some gamers don't desire "good enough" and all titles are not created equal -- Super-sampled to me is a "Mr Fix it" if one has enough performance to enjoy the feature considering all systems are not created equal as well.

I was playing the older title "Giants" for an old blast-from-the-past and the texture aliasing at times was so annoying. Add super-sampled -- gone. It didn't improve game-play but improved immersion. That's what it does for me -- to eliminate distractions so I can see and enjoy the imagination of what the developers have created.

It's wonderful to see this flexibility from both ATI and nVidia. For a poster, not here, have been clamoring for super-sampled flexibility for some time.

 

[Scali]

We already have evidence that your way doesn’t work

As I already said:
1) The problem is not caused by MSAA, but by less-than-perfect implementations of AF and mipmapping. Therefore the solution is better AF, not bruteforce AA.

Your 'evidence' merely proves that texture filtering is less-than-perfect on current hardware, which I had already stated before.
Don't even get me started on how drivers mess around with mipmap LOD biasing and that sort of thing.
It is possible to have different texture filtering results using the same settings between D3D and OpenGL, simply because the driver decides to do something different.
Sometimes even different applications using the same API get different results, because the driver is 'tweaked'.
Heck, in some cases you don't even get the texture format you think you're getting, because the driver silently applies (lossy) texture compression. And then there's pure hardware limitations. Eg, the Radeon 9500+ series had pretty poor angle dependency. Good that we didn't write off AF just because some early implementations weren't perfect, isn't it?

But can any of that be classed as shader aliasing? No.
Can SSAA make such cases look better? Yes.
Does that mean that SSAA is the only way to make these cases look better? No.
Or even the best way? No.

You’re saying that if you don’t use shaders to approximate geometry and instead use polygons on the same plane (whose counts are increased with tessellation), you won’t have shader or texture aliasing.

Incorrect.
Why would you use more than one polygon when they're all in the same plane?
You only use polygons when things are NOT in the same plane.
The result is that inside your polygons, everything is based on linear/continuous functions.
Now what is the main characteristic there? Very low frequency, no aliasing problems.
Any possible aliasing can perfectly be predicted with simple first-order derivatives, and thus can be avoided inside a texture sampler, not requiring supersampling of the entire shading equation.
Any discontinuities will be at polygon edges (centroid sampling is your friend here).
The geometry-factor is removed from the pixel shader, and can no longer cause aliasing.
Interpolated gradients such as normals and texture coordinates and such never had aliasing to begin with (they are smooth continuous functions).
So you've once again reduced the problem to:
1) Good texture filtering
2) Good antialiasing at polygon edges
Instead of with normal mapping where discontinuities could occur at EVERY pixel in a polygon and therefore you HAD to supersample everything.

So here we are: a completely flat surface with no shaders, yet SSAA still shows a huge difference. But according to you, the “undersampling can be dealt with”, or some-such nonsense.

Yes, I say it can be dealt with. I never claimed that current hardware deals with it perfectly, on the contrary (see above).
However, getting back to the fact that you can spend each cycle only once, and you always have to trade-off between image quality and framerate, I maintain that tessellation + MSAA will give a better balance of performance and image quality than normalmapping + SSAA, even on current hardware (being Radeon 5000-series and especially GeForce 400-series, given their more powerful tessellation).

I’ve done both OpenGL and RenderMan programming, and I’ve also implemented triangle rasterizers and custom anti-aliasing techniques.

I'd like to see some of your work.