AMD V Nvidia by Richard Huddy

[Dark_Archonis]

Crysis 2 will be crippled by being a console game as well, so it will be nothing near the benchmarking game of Crysis 1. It might be like MW2...

Wrong. Crysis 2 is using CryEngine 3, which is extremely scalable. Crytek themselves admitted that the PC version would look much better than the console versions. Crytek also has not publicly shown what the full PC version looks like compared to the console versions.

Crytek also has said that the PC version of Crysis 2 would become the new benchmarking king, and it would be extremely stressful on PC hardware.

 

[Janooo]

Tessellation Factor 5:

Tessellation Factor 9:

I don't think it makes any sense to go beyond that.

 

[Scali]

I don't think it makes any sense to go beyond that.

I don't think you quite understand how it works then.
Firstly, why is adaptive tessellation OFF? It should be ON (in which case the tessellation factor would just serve as a maximum (or an average), and not a constant).
It would be much like AF... why bother setting it ton anything lower than 16x, when the hardware will figure out how much to use depending on the level of anisotropy anyway? Most of the scene is generally done with 2x-4x AF, so going up from 4xAF to 8xAF or 16xAF will generally have little or no impact on performance... It just puts the finishing touches on your image quality in those few spots where you need it.

Secondly, the amplification factor depends a lot on what your source geometry looks like. On one extreme, tessellation can turn a cube into a perfect sphere, but you'd need quite a high amplification factor. When you are using more complex geometries, such as human characters, you will generally need more detailed source geometry, so in that case the level of amplification to get pixel-perfect detail will be relatively lower.
It all depends on what you're doing.

Look at how Unigine works, for example:
http://www.youtube.com/watch?v=bkKtY2G3FbU
Look at the wireframes. You'll see they're low-poly when objects are far away, and when you zoom in, the dynamic tessellation kicks in and starts adding detail progressively. Without the wireframes on, you don't even see it happening, because unlike traditional LOD techniques, there is no 'popping', the geometry just smoothly 'flows' into detail.

So your teapot with static has two problems:
1) It uses too much detail on the top, which we can barely see from this angle.
2) If we were to zoom in very closely on a single detail, it would still have a faceted look, because it does not progressively add triangles to smooth out the geometry (which is exactly what tessellation should be doing).

I guess there's your problem... Huddy tries to make people think that tessellation is just randomly throwing triangle overkill at the screen, while in reality it is a way to optimize your geometry, dynamically adjust it so you can use LESS when it is not required, and use MORE when it is. With proper use of dynamic tessellation, you will simply get higher image quality with the exact same polycount.
Here is another one, made by AMD themselves (did you know that, Huddy?), using a very similar approach:
http://www.youtube.com/watch?v=LGrCOj-BQfo

 

[Janooo]

I don't think you quite understand how it works then.
Firstly, why is adaptive tessellation OFF? It should be ON (in which case the tessellation factor would just serve as a maximum (or an average), and not a constant).
It would be much like AF... why bother setting it ton anything lower than 16x, when the hardware will figure out how much to use depending on the level of anisotropy anyway? Most of the scene is generally done with 2x-4x AF, so going up from 4xAF to 8xAF or 16xAF will generally have little or no impact on performance... It just puts the finishing touches on your image quality in those few spots where you need it.

Secondly, the amplification factor depends a lot on what your source geometry looks like. On one extreme, tessellation can turn a cube into a perfect sphere, but you'd need quite a high amplification factor. When you are using more complex geometries, such as human characters, you will generally need more detailed source geometry, so in that case the level of amplification to get pixel-perfect detail will be relatively lower.
It all depends on what you're doing.

Look at how Unigine works, for example:
http://www.youtube.com/watch?v=bkKtY2G3FbU
Look at the wireframes. You'll see they're low-poly when objects are far away, and when you zoom in, the dynamic tessellation kicks in and starts adding detail progressively. Without the wireframes on, you don't even see it happening, because unlike traditional LOD techniques, there is no 'popping', the geometry just smoothly 'flows' into detail.

So your teapot with static has two problems:
1) It uses too much detail on the top, which we can barely see from this angle.
2) If we were to zoom in very closely on a single detail, it would still have a faceted look, because it does not progressively add triangles to smooth out the geometry (which is exactly what tessellation should be doing).

Thank you for proving Huddy's point.
The adaptive tessellation is off in order to demonstrate how useless is too much detail on handles. There is no visible wireframes. It's pure white in those areas.
You said it yourself there should be a maximum. What value would you recommend?
What value is an average in today's games?

 

[Scali]

Thank you for proving Huddy's point.
The adaptive tessellation is off in order to demonstrate how useless is too much detail on handles. There is no visible wireframes. It's pure white in those areas.
You said it yourself there should be a maximum. What value would you recommend?
What value is an average in today's games?

Read my post again, I already answered it, but you don't seem to understand.
I've added another video to show what I mean.
Huddy doesn't have a point. His own developers implement it the way I explained, which is nothing like what Huddy is talking about.

 

[Janooo]

Read my post again, I already answered it, but you don't seem to understand.
I've added another video to show what I mean.
Huddy doesn't have a point. His own developers implement it the way I explained, which is nothing like what Huddy is talking about.

What's the factor in your second example?
... and what value would you recommend?

 

[Scali]

What's the factor in your second example?
... and what value would you recommend?

There is no factor, look at the controls on the screen:
You select the "Desired triangle size", not the amplification factor.
It's *dynamic* and *adaptive*, see? The amplification factor is estimated by the tessellation algorithm itself, based on the desired triangle size. What that amplification factor is, depends more on where your camera is, and how much detail your base geometry has, than anything else, as I already said before.

 

[Janooo]

There is no factor, look at the controls on the screen:
You select the "Desired triangle size", not the amplification factor.
It's *dynamic* and *adaptive*, see?

What's the third and the fourth line from the bottom?

 

[Scali]

What's the third and the fourth line from the bottom?

Those are grayed out, because they aren't used when I use the screen-based adaptive algo. They are used for the other, simpler algos in the sample (adaptive off, or distance-based... the distance-based one uses the tessellation factor as a maximum, and reduces it for polygons in the distance).
See here for more information:
http://msdn.microsoft.com/en-us/library/ee416564(VS.85).aspx

 

[Janooo]

Those are grayed out, because they aren't used when I use the screen-based adaptive algo. They are used for the other, simpler algos in the sample (adaptive off, or distance-based).

Nice try, I just stop right there.
I think we are done.

 

[Scali]

Nice try, I just stop right there.
I think we are done.

I've added a link to the MSDN page for this sample. I think we're done indeed.
The AMD sample is freely available to anyone in the Microsoft DirectX SDK. It would be rather silly of me to lie about it, when it is so easy to verify how it works, having the actual binary and source code available for free and all.

Implementation

In its simplest form, detail tessellation is a combination of tessellation combined with displacement mapping. The Vertex Shader calculates position and tangent space light/view vectors before passing them to the Hull Shader along with texture coordinates. The Hull Shader triggers “pass-through” mode by outputting three control points that are a direct copy of the input data (position, texture coordinates and light/view vectors), while the HS Patch Constant function applies a uniform tessellation factor to triangle edges and its inside. The new vertices generated by the fixed-function tessellator are input to the Domain Shader, which calculates their position and displace them using the height map provided. All lighting is performed in the pixel shader using the interpolated tangent space light vector (and view vector if specular is enabled) and normal.

Density-based Tessellation

This sample supports “density-based tessellation”, whereby larger tessellation factors are applied onto geometry mapped to high-frequency regions of the displacement map. Lower-frequency regions have smaller tessellation factors applied to them in order to preserve performance. The computation of the vertex density is an offline process which consists in comparing adjacent values in the displacement map, with large variations resulting in higher densities. All density calculation is eventually performed on a per-edge basis in order to avoid discontinuities when tessellating. This sample uses a simple function for edge density calculation, and better algorithms could be implemented.
When density-based tessellation is enabled the HS Patch Constant function performs the additional task of fetching edge vertex densities from a Buffer resource, and assigns them to the tessellation factors to apply to the geometry for tessellation.

Distance-adaptive Tessellation

Another optimization is to scale the tessellation factors by a distance function. In principle, more details are needed when the camera is close to the geometry. When geometry is further away fewer triangles can be produced without an obvious loss of image quality. This allows performance savings by reducing the tessellation factors to apply as the camera gets away from the geometry. This sample implements distance-based tessellation, and clamps the minimum tessellation factor to a value of half the selected edge tessellation level in order to preserve the minimum level of detail required to accurately represent silhouettes edges from a distance. The distance scaling function should of course be adapted to the needs of each application.
When distance-adaptive tessellation is enabled the Vertex Shader calculates the distance from the current vertex to the camera, and outputs a distance factor into an additional Vertex Shader output (Hull Shader input). The HS Patch Constant function then calculates the distance factor for each edge, and use it to scale the tessellation factors.

Screen-space adaptive Tessellation

In this mode the overall length of each screen-space triangle edge is calculated in the Hull Shader, and the tessellation factor to apply on each edge is a factor of the desired triangle size in pixels. This adaptive scheme is similar to distance-based tessellation, although it requires more instructions in the Hull Shader.

See, that's the problem. People hate me and want to argue with me all the time. Problem is, I am not talking nonsense. I'm just stating facts, facts which can easily be verified by anyone. I know what I'm talking about and I back up what I say too. That's more than I can say of some people, including Richard Huddy.
You should think twice before you try to argue with me, and just end up making a fool out of yourself.

 

[HurleyBird]

as well as actionable misrepresentation of facts (JHH is a liar..., etc).[/B]

I think that's very debatable. Correct me if I'm wrong, but didn't he state in September 2009 that Fermi would launch in November that year? Given the short amount of time between those two dates, and the long amount of time between that date and the time Fermi actually launched, it's a bit of a tough sell to say "JHH was just optimistic". Holding up a fake board and saying "this puppy is Fermi" is at least slightly shady as well, even if the intention was to spare us looking at a messy engineering sample it still implies the product is further along than it really is (and the size of the heatsink implied that power consumption was an order of magnitude better than it really was). Whether JHH outright lied to us or not is, of course, a matter of debate. And that's the operative word: debate. It's Anand's forums, and if he is so incredibly silly enough to worry about JHH turning around and suing him for what people say on his forums, then that is his right. But the fact remains, whether or not JHH is an outright liar, a truth stretcher, or just far too optimistic, he is *not* reliable going by past actions.

 

[Janooo]

I've added a link to the MSDN page for this sample. I think we're done indeed.
The AMD sample is freely available to anyone in the Microsoft DirectX SDK. It would be rather silly of me to lie about it, when it is so easy to verify how it works, having the actual binary and source code available for free and all.



See, that's the problem. People hate me and want to argue with me all the time. Problem is, I am not talking nonsense. I'm just stating facts, facts which can easily be verified by anyone. I know what I'm talking about and I back up what I say too. That's more than I can say of some people, including Richard Huddy.
You should think twice before you try to argue with me, and just end up making a fool out of yourself.

What's an average calculated tessellation factor when you use Distance-adaptive Tessellation?

 

[Scali]

But the fact remains, whether or not JHH is an outright liar, a truth stretcher, or just far too optimistic, he is *not* reliable going by past actions.

Jack Sparrow would disagree with you on that one: You can always trust a dishonest man to be dishonest.

 

[Seero]

Tessellation Factor 5:

Tessellation Factor 9:

I don't think it makes any sense to go beyond that.

Lets take several step back to basics. How many straight lines is needed to from a perfectly round circle? If the number of straight lines is not infinite, than it really isn't a perfect circle, isn't it? Now of course, their are finite number of pixels on the screen and you may argue that it is pointless if the degree of tessellation exceeds the resolution, but the example you give clearly have not exceeded the resolution. If the tea pot starts to rotate, you will see the surface of the tea pot moving, where as if it is perfectly round, you won't.

So in your option, what tessellation factor is needed to make the scene perfect such that the tea pot is perfectly round? If you know the answer than you will also know that the degree of tessellation is independent to the resolution, especially when the tea pot is rotating.

The point of dynamic tessellation is so that object skin does not need to be tessellated. I can use Dx9 to generate a perfectly round cycle, all I need to do is to pre-tessellate the skin. The different isn't about the quality of the object itself, but the amount of data required to be send through those thin buses. So the degree of tessellation is like the speed of GPU/CPU, the higher, the better.

How does this affect gaming you may ask, well there are lots of gamers who will like to max out everything even though the quality is not visible to them 95% of the time. Everquest2 is a good example where the maximum quality exceed any cards at the time of release. It even have a warning message to warn user about it. Now the tessellation factor can be fix, but the number of objects can not. As the number of objects that requires dynamic tessellation increases, the more dynamic tessellation power is needed. Does this make any sense?

Richard Huddy actually covered that part too as a) objects outside of the viewport doesn't need to be tessellated, and b) objects behind objects doesn't need to be tessellated. The statement looks legit, but it isn't. Shadows and reflections one of the reasons that means the statement above invalid. Just because an object isn't in the viewport doesn't mean its shadow isn't, just because an object is blocked by another object doesn't mean its reflection isn't.

 

[Scali]

Lets take several step back to basics. How many straight lines is needed to from a perfectly round circle? If the number of straight lines is not infinite, than it really isn't a perfect circle, isn't it? Now of course, their are finite number of pixels on the screen and you may argue that it is pointless if the degree of tessellation exceeds the resolution, but the example you give clearly have not exceeded the resolution. If the tea pot starts to rotate, you will see the surface of the tea pot moving, where as if it is perfectly round, you won't.

Thing is, it depends on where your object is on screen.
For example, if it is very far in the distance, the size being about 1 pixel or smaller, then theoretically you'd only need 1 triangle to represent the entire object. So your tessellation factor can be VERY low.
On the other hand, if you zoom in VERY closely, you will need to have a LOT of tessellation in order to have a reasonably round representation of the object.

The thing to take away from this is that the tessellation factor is completely dependent on what you're doing, and there can be no 'rules' as to what a good low, high or average value is.

And that's where AMD's hurt is, which Huddy is trying to cover up. AMD only has a single serial tessellator, which means it cannot exploit the massive parallelism of the shader units that actually perform the tessellation (hull and domain shaders, both AMD and nVidia use their unified shaders for the actual tessellation, that's how it's designed in D3D/OpenGL).
nVidia has designed a parallel tessellator, where up to 16 triangles can be processed in parallel, and the unified shaders can be fed much more efficiently. This allows nVidia's hardware to scale to far higher levels of tessellation. This means you can actually do tricks like using a cube (made of only 12 triangles) to generate a 'perfect' sphere on screen, even when zooming in.
And that's how tessellation is meant to be used. Read up on NURBS, and how Maya/RenderMan use these exclusively to make those famous Pixar/Disney movies. The source control meshes are actually incredibly lowpoly. Lower than your average game. It's the tessellation that makes everything look pixel-perfect, even on the big screen.

 

[Lonbjerg]

Nice try, I just stop right there.
I think we are done.

Yup, you got owned pretty hard...better stop before you totally humilitate yourself..oh wait :hmm:

 

[Seero]

Thing is, it depends on where your object is on screen.
For example, if it is very far in the distance, the size being about 1 pixel or smaller, then theoretically you'd only need 1 triangle to represent the entire object. So your tessellation factor can be VERY low.
On the other hand, if you zoom in VERY closely, you will need to have a LOT of tessellation in order to have a reasonably round representation of the object.

We can go very technical on this, but I don't think many will be able to follow. In short, yes, there is, and should be a relationship between the distance and tessellation factor.

The thing to take away from this is that the tessellation factor is completely dependent on what you're doing, and there can be no 'rules' as to what a good low, high or average value is.

I agree.

And I won't ask you to prove anything.

 

[Scali]

We can go very technical on this, but I don't think many will be able to follow. In short, yes, there is, and should be a relationship between the distance and tessellation factor.

Well, more accurately, there should be a relationship between the size of the polys on screen and the tessellation factor.
If you just use distance, you are ignoring the aspect ratio of the triangle, caused by the viewing angle. A triangle can be close, but still be very small because you are watching it from a nearly perpendicular angle. In that case it's useless to tessellate it.
The idea is very similar to anisotropic filtering. which also tries to filter based on how the geometry is projected on the screen. If you ignore the anisotropy of the projection on screen, you will either undersample or oversample in most cases.

Ideally (Pixar/RenderMan/reyes rendering) you want to have one triangle for each pixel (or technically less than one, for supersampling/AA reasons, but you get the idea). This is known as 'micropolygons'. You have 'perfect' geometry this way.
So basically you want to avoid undersampling your geometry, because then you will still not get perfectly round objects nearby... But you also don't want to oversample your geometry and fit too many polygons in a single pixel.

But as AMD's own sample demonstrates: it's not too difficult to tessellate based on polygon screen size with DX11.

 

[Janooo]

Yup, you got owned pretty hard...better stop before you totally humilitate yourself..oh wait :hmm:

Yes, right. My last question was not answered.

 

[Scali]

Yes, right. My last question was not answered.

It was, actually. See the discussion between me and Seero.

 

[Janooo]

It was, actually. See the discussion between me and Seero.

I don't see any average or max tessellation factor mentioned anywhere. A real value. How do you limit that?

 

[Scali]

I don't see any average or max tessellation factor mentioned anywhere. A real value. How do you limit that?

If you read the discussion, you'll understand why you can't get the answer you want.
I get the distinct impression that you just don't understand it.
Why don't you start by asking questions on what you don't understand from this discussion?

 

[Janooo]

If you read the discussion, you'll understand why you can't get the answer you want.
I get the distinct impression that you just don't understand it.
Why don't you start by asking questions on what you don't understand from this discussion?

The tessellation factors are being adjusted dynamically when adaptive tessellation is used.
What value do you get on average? What is the max value?

 

[Scali]

The tessellation factors are being adjusted dynamically when adaptive tessellation is used.
What value do you get on average? What is the max value?

As I said, that depends on both your source geometry, your camera positions, your screen resolution and your AA settings (aside from the fact that there are various ways to estimate polygon size, distance etc, so there will be different tessellation factor estimates depending on the implementation etc yaddayadda).

Too many unknowns to make any kind of useful estimates whatsoever.