Crysis 2 DX11, a closer look at performance and tessellationby Damien TrioletPublished on August 3, 2011

A closer look at tessellation

After ascertaining that tessellation was indeed responsible for the significant drop in performance observed with the Radeons with DirectX 11 Ultra, we wanted to take a closer look at where it is in fact used. Here are a few examples which benefit from tessellation, in order of what we estimate to be the most useful. To obtain the image in full resolution, click on its description:

While the rendering of the wall is obviously greatly improved by tessellation, giving it optimal quality from every point of view, not all walls get the same treatment. Given that the effect must be introduced manually by the artists and that this was done after the original design process, only some walls benefit from tessellation, which is a shame in terms of overall coherence. Another problem, linked to the fact that tessellation wasn’t planned at the start, is that some objects, mainly stones, can sometimes take on a strange appearance and almost transform themselves into stalagmites. Of course, there are then more polygons, but the rendering isn't necessarily more accurate.

To recap, tessellation isn’t used on most pathways but rather Parallax Occlusion Mapping is, including the paving stones or bricks that paths are made with:

That said, in our test scene, beyond the first second during which we can make out tessellation on some bricks, there aren‘t any walls, stones, water or any other objects that would seem likely to be chosen for tessellation. Nevertheless, we did note a significant impact on performance linked to this rendering technique. To find out more about what’s going on here, we got hold of GPU Perf Studio, the AMD analysis tool that allows you to get a view of how graphics rendering is built.

We were able to confirm that tessellation had been used on the bricks at the beginning of our scene and that the level of tessellation was rather high:

Next we noted that we had missed one highly tessellated object: the border of the path that we were on:

Above and beyond the pathway itself, on which POM is applied, switching to the Ultra Upgrade and enabling tessellation doesn’t make any visual difference on the border. As you can see in our view of the geometry on the left border however, an extreme (or ultra :p) level of tessellation has been applied. It looks like basic planar subdivision without any added detail or edge smoothing. This is of course difficult to justify…

This border represents one of the most resource hungry draw calls in the scene, or should we say two of the most resource hungry draw calls because in contrast to some other deferred rendering engines (such as the 3DMark 11 engine), CryENGINE 3 runs through the geometry twice (this is without factoring in the shadow maps). The fact that the rendering is structured in this way is probably linked to a limitation of DirectX 9 or to performance imperatives when tessellation isn’t used. As tessellation has been added on top of the rest, the base of the rendering hasn’t been adapted to take account of the new addition, which results in making the use of tessellation twice as costly in terms of resources.

Next we noted another tessellated area that is processed at the end of the scene. Rather astonishingly, Crysis 2 carries out a rendering of the sea across almost the entire test scene though the sea is never visible or even in the field of view but masked. Not a single pixel is written and yet this enormous surface represents a significant geometry load:

This explains why we noted a 3% drop in performance on page 5 in comparison to Extreme mode when the Ultra water was activated on the Radeon HD 6950, even though there was no water in our scene. Is this a bug? Or poor optimisation in terms of the use of tessellation? In any case, the Radeons suffer.

Note that we also wanted to find out more, again using GPU Perf Studio, about why the Radeon HD 6900s give a lower level of performance than expected. Unfortunately, when this tool observes the scene and measures the rendering time of each draw call, it adds an additional load or reduces parallelism, which has an impact on performance and prevents us from giving an accurate answer to this question. According to GPU Perf Studio 2.5.1, all draw calls using tessellation represent:

15.4% of the rendering time on the Radeon HD 695014.5% of the rendering time on the Radeon HD 685015.7% of the rendering time on the Radeon HD 5870

Given that these draw calls are not only limited by tessellation performance and that the impact we observed on performance was higher, these figures are obviously over-evaluated, probably because the simplest calls are relatively more impacted by the additional cost of instrumentation.

For the real enthusiasts among you and although this doesn't give us an answer to our questions, note that GPU Perf Studio shows (or rather we calculated ourselves, as the AMD developers have an issue with percentages…) that during the processing of all of these calls, the tessellator is occupied during:

89.7% of the time on the Radeon HD 695095.3% of the time on the Radeon HD 685095.8% of the time on the Radeon HD 5870