Another blog from AMD has surfaced, once again trying to ‘explain’ everyone how tessellation is done ‘the right way’. The right way, according to AMD, is obviously the way that hides their tessellation deficiencies best. They try to make it sound noble and all that:
As gamers, we know that you just want a game that plays well. At AMD, we are committed to delivering the best possible gaming experience for all gamers, not just those using AMD hardware.
But is that really true? Without even looking at AMD’s arguments in this post, it should already be obvious that the best possible gaming experience for gaming on nVidia hardware is different from that of AMD hardware. After all, it has already been established by Beyond3D that there’s a significant performance difference between nVidia and AMD when it comes to geometry throughput. So if AMD wants to achieve what they claim above, then the obvious answer would be to have different tessellation levels, tuned to the capabilities of different hardware. Not only for nVidia’s current high-end, which is in a league of its own with tessellation… But also for the different performance levels of both nVidia and AMD hardware, high-end, mainstream and low-end. What it will basically boil down to is that AMD’s current hardware will simply have to run one or two levels lower than nVidia’s hardware. Then both nVidia and AMD hardware will deliver the best possible gaming experience, relative to their performance characteristics.
So, let’s look at what AMD’s solution is then. Is it anything like the above? No, it is not. In fact, the arguments seem to be exactly the same as the ones I already debunked from Richard Huddy earlier: AMD is afraid of small triangles, and uses rasterizer efficiency as an excuse, when their real problem is triangle throughput. The Beyond3D analysis fully supports this, as I already said.
Aside from that, AMD implies that < 1 pixel triangles are the reason for their poor tessellation performance… But is that true? No it’s not. If you take Unigine Heaven for example… This is with the Extreme Tessellation setting:
It doesn’t try to render < 1 pixel triangles everywhere. A lot of the screen contains very large triangles actually. Only certain details contain small triangles, and even then you can mostly still see the wireframes, which would not be possible with < 1 pixel triangles, as the wireframes themselves are already 1 pixel wide. So AMD is misrepresenting the problem.
Likewise with Endless City, which can now also be run on AMD hardware:
Yes, that’s a lot of triangles, but still you can clearly see the contours of the triangles, and they are clearly much larger than 1 pixel. in fact, assuming 4xAA, these triangles are probably larger than 16 pixels on average.
AMD suggests one other ‘solution’:
We have also developed techniques that can help balance tessellation workloads by doing a limited amount of pre-tessellation in vertex shaders, which can help to reduce the impact of bottlenecks in the rendering pipeline.
Well, I would like them to demonstrate how well this works in Endless City. I see a few obvious problems with this solution… If you pre-tessellatate some of the geometry, then you cannot scale back down to the fully non-tessellated detail… so with distant objects or objects at extreme orientations, you’ll actually be using triangles that are smaller than what you want. Exactly what AMD said they wanted to avoid! Another thing is that this pre-tessellated geometry would have to be stored in videomemory, which cancels out some of the main advantages of tessellation:
- Reducing the memory footprint
- Reducing the bandwidth requirements
- Reducing the amount of work required for certain animation, such as skinning, because it can be performed prior to tessellation, on a low-res mesh
So really… it sounds like more damage control and poor excuses for AMD’s hardware deficiencies… The fact that AMD feels the need to reiterate these points again, shortly before the release of the 6900 series doesn’t exactly fill me with confidence about the 6900’s allegedly improved ‘scalable’ tessellator (whatever that means).