AMD/Richard Huddy need to lie about tessellation

Recently, AMD has been attacking nVidia and Ubisoft for their HAWX 2 benchmark, which would be unfair to AMD hardware, by ‘over-tessellation’, like certain other tessellation benchmarks. AMD tries to convince us that we need adaptive tessellation, and we don’t want to go smaller than 16 pixels per triangle.

The whole point of tessellation is that it is adaptive. If it’s all fixed anyway, why not just precalc it all, like games have always been doing?
Unigine Heaven is adaptive, and so is HAWX 2. They don’t just bruteforce all triangles down to the maximum level of tessellation. Run Unigine Heaven in wireframe mode, and you’ll see how it dynamically adds and removes triangles when objects get closer or move further away, even on the extreme setting. The setting merely dictates how detailed the adaptive tessellation should be. At lower settings, it will stop subdividing the triangles sooner, resulting in lower detail. But other than that, the algorithm is exactly the same: always adaptive.
Where AMD is hurt is in their limited throughput.
I mean, if you take one triangle over the entire screen, and tessellate it down to triangles of about 16 pixels, as AMD suggests… then that is still adaptive tessellation…
It will not work well on AMD’s hardware though, because the pain is in the conversion of 1 triangle to such a large number.
AMD can only do limited amplification of triangles, so you need to feed it pretty detailed geometry to begin with, and then have limited subdivision done by the tessellator, eg each triangle converted to 4 smaller ones.
But that is not how tessellation is meant. Tessellation is meant to serve two purposes:
1) Reduce the overall memory/bandwidth required for geometry, by generating details on-the-fly.
2) Improve image quality by smoothly moving from lower levels of detail to higher levels of detail, and avoiding any kind of undersampling/oversampling problems.
But in order to achieve these two things, you need to be able to handle a large range of tessellation factors, so you can start with very low detail geometry, and have it tessellated down to almost per-pixel details when required (again, this is all adaptive).
Since AMD’s range is so limited, you can’t really achieve either of the purposes for tessellation. You need to feed it highly detailed geometry in the first place, which means you still need a lot of memory/bandwidth. And you still need to rely on ‘oldskool’ multiple levels of fixed geometry, with their popping and undersampling/oversampling issues.
Bottom line is just: AMD’s tessellation is a bit of a failure. Just like the geometry shader was a failure for both AMD and nVidia in DX10. You couldn’t do what you wanted to do, because throughput was too slow.
AMD fell for the same trap again in DX11, nVidia went with a complete redesign, which apparently works much better (although we’re still not quite there yet).
AMD is trying to put up a smokescreen by trying to make the focus on triangle size, but that is not the REAL issue here. The real issue is that their tessellator is a bottleneck. It cannot subdivide triangles and spit them out fast enough to keep the rest of the GPU busy. That’s why nVidia chose to do a fully parallelized implementation, rather than a serial one (as I said, that’s the mistake made with the geometry shader, which theoretically could already do a bit of tessellation, it just couldn’t spit out the triangles fast enough).

According to Ubisoft, the tessellation aims to go for 6-pixel wide triangles. If you look closely at AMD’s own example:

As you can see, their sample 16-pixel triangle is 6 pixels high and 5 pixels wide. Now if HAWX 2 is aiming for 6-pixel wide triangles, it could be doing exactly what AMD’s sample is suggesting, only 90 degrees rotated! Apparently it is aiming for the same ballpark in terms of triangle sizes.

Aside from that, both nVidia and AMD would suffer from the same efficiency problems with small triangles, so that is obviously just a smokescreen. It’s not the rasterizer that’s AMD’s problem, and it’s not the triangle sizes, it’s the tessellator.

This entry was posted in Direct3D, Hardware news, Software development, Software news, Uncategorized. Bookmark the permalink.

12 Responses to AMD/Richard Huddy need to lie about tessellation

  1. Pingback: John Fruehe finally does the sensible thing and comes up with an excuse | Scali's blog

  2. Pingback: Meet AMD’s Mike Houston | Scali's blog

  3. Pingback: AMD Radeon 7970: Graphics Core Next debuts | Scali's blog

  4. Pingback: Richard Huddy comments on my blog | Scali's blog

  5. Pingback: Haswell Hasarrived | Scali's OpenBlog™

  6. Godfather says:

    Crysis 2 tesselation scam (nvidia’s way meant te be played):

  7. Diceman says:

    hey scali, looks like you’re gunna need to get blogging again, Richard Huddy’s come out with his accusations and deflections again with Witcher 3 now.

    • Scali says:

      I know, people have been linking to my old blogs a lot again in the past days… I don’t really have anything to add… AMD’s tessellation is still underperforming, and AMD still uses the driver hack to reduce tessellation.

  8. Pingback: DirectX 12 is out, let’s review | Scali's OpenBlog™

  9. Pingback: AMD tries to do more damage-control for tessellation | Scali's OpenBlog™

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s