Crysis 2 DX11, performances et tessellation à la loupe

La tessellation à la loupe

Après nous être assurés que la tessellation était bien responsable de la chute de performances importante observée sur les Radeon avec le mode DirectX 11 Ultra, nous avons voulu observer de plus près où en pratique elle était utilisée. Voici quelques exemples qui profitent de la tessellation, le premier étant selon nous le plus utile. Pour obtenir l'image en en pleine résolution, cliquez sur sa description :


[ Sans tessellation ]  [ Avec tessellation ]

[ Sans tessellation ]  [ Avec tessellation ]

[ Sans tessellation ]  [ Avec tessellation ]

Si le gain visuel est sans discussion au niveau du mur, qui profite de la tessellation pour garantir une qualité optimale sous tous les angles, tous les murs ne reçoivent malheureusement pas ce traitement. Etant donné que la mise en place de cet effet doit se faire manuellement par les artistes et que ceci a été fait après coup, seuls quelques murs en profitent, ce qui est dommage pour la cohérence de l'ensemble. Autre problème lié au fait que la tessellation n'était pas prévue au départ, certains objets, les pierres principalement, peuvent afficher un aspect étrange en se transformant presque en stalagmites. Certes il y a alors plus de polygones, mais le rendu ne gagne pas réellement en fidélité.

Pour rappel, la plupart des sentiers profitent non pas de la tessellation mais du Parallax Occlusion Mapping, y compris pour les pavés ou pour les briques qui les composent :


[ Sans POM ]  [ Avec POM ]

Ceci étant dit, sur notre scène de test, en dehors de la première seconde sur laquelle nous pouvons apercevoir quelques briques tessellées, il n'y a ni mur, ni pierre, ni eau ni autre objet qui semble être candidat à la tessellation. Et pourtant, nous avons observé un impact important lié à cette technique de rendu. Pour en savoir plus, nous avons fait appel à GPU Perf Studio, l'outil d'analyse d'AMD qui permet de se plonger dans la construction du rendu graphique.

Nous avons pu confirmer que les briques du début de notre scène étaient bien tessellées et que le niveau de tessellation est plutôt très élevé :


Ensuite nous avons pu constater qu'un objet lui aussi fortement tessellé était passé inaperçu : la bordure du sentier que nous parcourons :


[ DirectX 11 Extrême ]  [ DirectX 11 Ultra ]  [ Tessellation wireframe ]
En dehors du sentier en lui-même qui profite du POM, le passage au mode Ultra se fait sans que la tessellation ne fasse une différence visuelle. Et pourtant comme vous pouvez le constater avec une vue de la géométrie de la bordure de gauche, un niveau de tessellation extrême (voire ultra :p) lui est appliqué. Celui-ci est bien entendu difficilement justifiable…

C'est cette bordure qui représente l'un des draw calls les plus gourmands de la scène ou plutôt deux des draw calls les plus gourmands puisque contrairement à d'autres moteurs au rendu déféré (tels que celui de 3DMark 11), le CryENGINE 3 passe en revue deux fois la géométrie (sans compter les shadow maps). Le fait que le rendu soit architecturé de la sorte est probablement lié à une limitation de DirectX 9 ou à des impératifs de performances quand la tessellation n'est pas utilisée. Tout ceci ayant été ajouté par-dessus le reste, la base du rendu n'a bien entendu pas été adaptée pour prendre en compte cette nouvelle donne, ce qui a pour conséquence de rendre l'utilisation de la tessellation deux fois plus gourmande.

Nous avons ensuite remarqué une autre surface tessellée traitée tout à la fin du rendu. D'une manière plutôt étonnante, Crysis 2 effectue un rendu de la mer sur la presque totalité de notre scène de test alors que la mer n'est jamais visible, ni même dans le champ de vision et masquée. Cette énorme surface n'écrit pas un seul pixel et ne représente qu'une charge géométrique :


[ La mer… ]  [ … dans cette scène ? ]
Ceci explique pourquoi nous avions noté page 5 une perte de performances de 3% par rapport au mode Extrême lors de l'activation de l'eau Ultra sur la Radeon HD 6950 alors qu'il n'y avait pas d'eau dans notre scène. Bug ? Manque d'optimisation au niveau de l'utilisation la tessellation ? Dans tous les cas les Radeon souffrent.

Notez que nous avons également voulu en savoir plus, à l'aide de GPU Perf Studio, sur la raison des performances plus faibles que prévues pour les Radeon HD 6900. Malheureusement, quand cet outil observe la scène et mesure le temps de rendu de chaque draw call, il ajoute une charge supplémentaire ou réduit le parallélisme, ce qui influence les performances et empêche de répondre précisément à cette question. Ainsi, selon GPU Perf Studio 2.5.1, l'ensemble des draw calls qui font appel à la tessellation représente :

15.4% du temps de rendu sur la Radeon HD 6950
14.5% du temps de rendu sur la Radeon HD 6850
15.7% du temps de rendu sur la Radeon HD 5870

Sachant que ces draw calls ne sont pas 100% limités par les performances en tessellation et que l'influence que nous avons observée sur les performances est plus élevées, ces chiffres sont de toute évidence sous-évalués, probablement parce que les calls plus simples sont d'une manière relative plus impactés par le surcoût de l'instrumentation.

Pour les amateurs de détails et bien que cela ne permette pas de répondre à nos interrogations, notez que GPU Perf Studio indique (ou plutôt nous l'avons calculé nous-mêmes, les développeurs d'AMD ayant un problème avec les %…) que lors du traitement de l'ensemble de ces calls, le tessellateur est occupé durant :

89.7% du temps pour la Radeon HD 6950
95.3% du temps pour la Radeon HD 6850
95.8% du temps pour la Radeon HD 5870

Par ailleurs, la mémoire LDS, utilisée lors de l'expansion géométrique, limite les unités de calcul durant :

7.0% du temps pour la Radeon HD 6950
7.8% du temps pour la Radeon HD 6850
8.7% du temps pour la Radeon HD 5870

Enfin, cette mémoire LDS est limitée en partie par des conflits d'accès à ses différentes banques :

38.9% du temps pour la Radeon HD 6950
35.9% du temps pour la Radeon HD 6850
38.4% du temps pour la Radeon HD 5870