Lucidlogix Virtu MVP en pratique

Publié le 29/03/2012 par
Imprimer
HyperFormance

Pour sa version MVP, Lucid introduit deux nouvelles fonctionnalités qui avaient été entrevues précédemment, Hyperformance et Virtual V-Sync. Commençons par la première. Pour tous les tests suivants nous avons utilisé la GeForce GTX 480, l'écran étant connecté sur la carte mère (mode I), nécessaire pour profiter d'HyperFormance et Virtual V-Sync.


Sur son site , Lucid décrit Hyperformance de la manière suivante, "éliminer les tâches de rendu redondantes, prédire les problèmes de synchronisation potentiels et les enlever ou les remplacer pour améliorer les contrôles". Dans la documentation (que vous pouvez télécharger en PDF sur le site d'Asrock ) ou dans l'interface du logiciel, l'explication est plus lapidaire, il s'agit d'augmenter les performances et le framerate. Si un "white paper" est disponible (PDF) , il se contente d'évoquer principalement Virtual V-Sync. Lorsqu'il s'agit d'entrer dans des détails sur l'implémentation précise, le document indique qu'elle ne sera pas détaillée "pour des raisons de brevets".

D'un point de vue pratique, toutes les applications ne sont pas supportées, la liste comporte principalement des benchmarks, ou des jeux disposants de benchmarks intégrés. Tenter d'activer HyperFormance sur Batman Arkham City aura provoqué des clignotements et des erreurs d'éclairage à titre indicatif.


Une fois activé, HyperFormance augmente bel et bien le framerate dans les applications supportées, mais augmente également les scores 3D Mark (nous avons dépoussiéré la version 2006 pour l'occasion). Jugez plutôt :


Nous reviendrons sur l'astérisque concernant Mass Effect un peu plus loin. Pour les autres titres, comment expliquer ces augmentations miraculeuses ? La carte graphique a-t-elle réellement créé plus d'images ? Oui et non. Nous avons utilisé Fraps pour mesurer le temps de calcul des images sous Lost Planet 2, avec et sans HyperFormance.


Attention ! Ce graphique indique le temps de calcul successif d'une série d'images. L'axe horizontal n'est pas un axe temporel, on ne peut donc pas comparer un à un le temps de rendu des images. Ceci étant posé, on peut remarquer quelques tendances. D'abord en mode normal, le temps de rendu d'une image est relativement constant, variant entre 10 et 16 millisecondes. En mode HyperFormance, on distingue deux cas :
  • des images rendues en environ 5 ms (A)
  • des images rendues entre 10 et 16 ms (B)

Visiblement donc, si le nombre d'images calculés augmente, toutes les images calculées ne sont pas égales.

A l'aide de GPU Perf Studio , outil développeur fourni par AMD, nous avons pu voir, pour au moins une application, le type d'optimisation utilisé par Virtu MVP. Malheureusement GPU Perf Studio est très pointilleux, nécessitant par exemple des applications DX10 ou 11 qui ne font pas la majorité des titres accélérés par HyperFormance. Nous avons cependant réussi à illustrer ce qui se passe sous 3D Mark Vantage. Nous ne pouvons pas confirmer que le même type d'optimisation soit systématiquement utilisé dans tous les titres HyperFormance, même si cela semble probable.

Afin de simplifier la tâche à notre pauvre Radeon bloquée à 100 MHz (les outils d'overclocking tels MSI Afterburner, s'ils détectent correctement les fréquences 3D une fois un profil Virtu créé, et permettent de les changer, ne les rendent pas pour autant actives), nous nous sommes contentés pour ce test du mode Entry en 640 par 480. Voici une fois de plus le temps de calcul par frame, pour une série de 25 frames avec et sans HyperFormance :


Une fois de plus on peut noter que si en mode normal, toutes les frames se ressemblent, il y'a encore au moins deux types distincts de frames en mode HyperFormance. Avant d'aller plus loin, permettez nous de rappeler que le rendu d'une image sous DirectX est subdivisé en étapes, chacune étant ce que l'on appelle un draw call, un ordre envoyé par le CPU à la carte graphique pour réaliser une tâche. Pour plus de détails nous vous renvoyons à ce dossier où nous avions décomposé le rendu graphique par étape de 3D Mark, en version 11.

Ici, GPU Perf Studio nous a permis de voir qu'en mode Entry sous Vantage (test graphique 1), les images du début de la scène nécessitent toutes un peu plus de 200 draw call en mode normal. Avec HyperFormance, les frames "B" sont du même type, il s'agit bien d'images normales. Mais quid de ces frames qui se calculent magiquement en moins de 5 millisecondes ?

En pausant sur l'une de ces frames, nous pouvons voir via le Frame Debugger que seulement quatre draw call sont effectués. Contrairement à ce que nous évoquions dans notre article, et qui est la pratique normale (appliquée sur les frames B), ici la remise à zéro des mémoires tampons ne se fait pas. L'image précédemment calculée est ainsi récupérée.

Les quatre draw call vont ainsi :
  • Placement du bandeau en bas de l'écran
  • Ecriture du nombre de FPS
  • Ecriture du temps
  • Ecriture du nombre d'images total calculées



Bien évidemment, on ne peut que qualifier de tricherie cette pratique. Virtu MVP intercepte les draw calls envoyés par le CPU pour ces images de type A et supprime tous les draw calls "utiles" pour ne garder que ces quatre call du bandeau. Ainsi l'image précédemment calculée est bel et bien répétée, sauf pour le compteur en bas de l'écran. Ces images intercalées ne font ici que grossir artificiellement le framerate, si l'on compte le nombre de frames "utiles" réellement calculées par seconde, HyperFormance en produit un nombre inférieur.

Le subterfuge doit donc être adapté à chaque jeu ou benchmark, et nous supposons que la suppression des draw calls doit être soit quasi totale, soit se limiter dans certains titres à des rafraichissements minimes (on peut imaginer par exemple supprimer tous les calls sauf le dessin du HUD ou de la croix de visée pour un FPS par exemple). Cela explique aussi pourquoi HyperFormance est ainsi limité à si peu de titres : ces "optimisations" doivent être écrites au cas par cas pour les jeux.

Notez que cela ne marche pas en permanence puisque Mass Effect, pourtant marqué comme supporté nous a donné des clignotements constants. En pratique nous avons pu capturer ces deux images qui alternent en permanence pour causer le clignotement :


Des images partiellement rendues apparaissent à l'écran, indiquant un problème de synchronisation dans le choix des images à afficher.

En théorie, via l'utilisation de deux framebuffer (celui de la carte graphique et celui de l'IGP), le pilote de Virtu MVP pourrait sélectionner les images à transférer vers l'écran. Ainsi, des images partiellement rendues peuvent très bien ne jamais arriver vers l'écran.

Visiblement dans Mass Effect, soit le mécanisme de tri des draw call ne fonctionne pas correctement ici, soit le mécanisme de choix des images à afficher est défectueux. Dans tous les cas, le jeu est injouable.

Avec cette tricherie, HyperFormance manipule la notion de ce qu'est réellement une frame, pour afficher des scores plus hauts dans les benchmarks. Comment justifier une telle pratique ? Dans son "white paper", Lucid explique qu'augmenter le framerate augmente la réactivité de l'application par rapport aux entrées souris/clavier avec ce schéma :


Ici, c'est le point A, à gauche, qui nous intéresse, il rappelle effectivement que c'est le CPU qui pilote le GPU et lui demande de rendre les images (via les draw call évoqués plus haut). Cependant par la suite Lucid nous semble faire un raccourci en expliquant qu'augmenter le framerate augmente la réactivité des entrées sorties. Nous pensons que cela est relativement incorrect pour de multiples raisons.

D'abord, il faut rappeler que les périphériques comme le clavier et la souris sont limités dans leur réactivité par l'interface sur laquelle ils sont connectés. Dans le cas de l'USB, la souris et le clavier ne sont interrogés que 125 fois par seconde par défaut (on parle de poll rate) par Windows. Passer de 140 à 300 images par seconde n'augmente donc pas la réactivité de lecture des entrées sorties quand ces dernières sont limitées elles mêmes à 125.

Ensuite, les joueurs qui ont manipulé le poll rate de l'USB sous Windows le savent (certains pilotes de souris "gamer" le permettent par exemple, même si d'autres utilitaires existent), l'augmentation de la sensibilité n'est pas directement lié au nombre d'images par secondes affichées. Comme l'indique pourtant le schéma de Lucid, c'est bien le CPU qui au final pilote la carte graphique, et sa rapidité de rendu est (en partie) accessoire dans la fluidité des entrées.

Les moteurs de jeux modernes sont en effet multithreadés. La gestion des entrées comme le clavier et la souris (mais aussi le réseau) sert à réaliser, côté CPU, un modèle de la simulation en mémoire. Ce modèle est une représentation du monde dans lequel évolue le joueur, sous la forme de coordonnées (pour la position) et de vecteurs (pour la direction/mouvements) et d'autres données diverses (nombre de balles restantes dans le chargeur, etc).

Au moment de rendre une image, ce modèle est interrogé par le thread CPU qui récupère ces informations avant d'envoyer les draw calls à la carte graphique qui effectuera de son côté son travail. Ainsi, on peut considérer qu'en augmentant (réellement) le framerate de 80 à 120 FPS, le temps de latence entre l'interrogation du modèle (que l'on peut placer à la fin du calcul de l'image précédente) et la fin de calcul de l'image peut passer de 12 à 8 millisecondes dans le cas le plus avantageux possible.

Cependant, l'écran ne pouvant afficher (généralement) que 60 images par secondes (la dernière image complète si le VSync est activé, ou un mélange d'image dans le cas ou la copie dans le framebuffer n'est pas terminée lorsque l'écran réclame son image sans Vsync - ce qui cause le tearing), le gain pratique se retrouve réduit.

Mais que se passe-t'il en réalité avec Virtu MVP ? Si l'on prend le cas le plus avantageux, en intercalant une image "vide" entre chaque image réelle, on profite effectivement d'un petit avantage de latence à cet endroit, mais ce n'est pas exactement ce qui se passe. En effet, parfois deux images "normales" sont calculées à la suite, c'était plus particulièrement le cas dans Lost Planet 2 un peu plus haut. Dans ce cas, on se retrouve avec un avantage de latence fluctuant qui peut se transformer soit en très légère avance, soit en très léger retard selon les cas.

Dans l'absolu cependant, nous parlons au mieux de deux à trois millisecondes sur cette étape seule. Qu'il faut placer en perspective dans le pipeline complet du jeu et de l'affichage, la latence totale entre l'appui sur une touche jusqu'à ce que l'image soit visible par l'œil à l'écran est plus proche des 100 millisecondes dans sa globalité. Et dans le cas du mode I, le transfert par le PCI Express ajoute une latence supplémentaire de l'ordre d'un peu plus d'une milliseconde.

En étant largement sous 60 fps, comme c'est le cas dans notre exemple sous 3DMark Vantage, la latence peut être raccourcie comme l'indique Lucid lors du premier affichage de l'image, mais étant donné qu'elle est dédoublée, la latence moyenne n'est pas réellement réduite et moins d'images réelles sont affichées. En pratique dans ce cas, HyperFormance n'a qu'une utilité à nos yeux : augmenter artificiellement les scores dans les benchmarks. L'argument de la latence ressemble alors plus selon nous à une justification pour cette pratique qui reste avant tout une tricherie dans les benchmarks.

Virtual V-Sync

Reprenons ce schéma pour évoquer ce que propose Lucid avec Virtual V-Sync, il s'agit ici du point B :


A l'image du V-Sync traditionnel, l'idée de Virtual V-Sync est d'éliminer les effets de tearing, les images incomplètes placées dans le framebuffer qui sont parfois envoyées à l'écran. Le VSync s'assure que seules des images complètes sont ainsi envoyées à l'écran en gardant une image calculée à l'avance (le double buffering). Virtual V-Sync profite du fait qu'en mode "I", deux buffers sont bel et bien disponibles, d'un côté celui de la carte graphique, de l'autre celui de l'IGP.

Comme nous l'avons vu avec HyperFormance, le pilote de Lucid a donc la possibilité de choisir quelles images sont envoyées vers le framebuffer réellement connecté à l'écran (à l'image de ce que l'on évoquait avec la souris et le clavier, l'écran fonctionne avec un taux de rafraichissement fixe, 60 fois par seconde le framebuffer est envoyé vers l'écran pour être affiché).

Le framebuffer de l'IGP n'est ici plus mis à jour en permanence, mais uniquement 60 fois par seconde si le framerate dans le jeu le permet. De là deux cas se produisent :
  • Dans le cas ou l'on repasse en dessous des 60 images calculées à la seconde, si une nouvelle image n'est pas arrivé dans le temps imparti, c'est l'ancienne qui est de nouveau affiché. En clair, dans ce cas, rien ne change par rapport au VSync classique avec Virtual VSync, l'effet de pallier du à la répétition des images continue d'être présent, même si Fraps indiquera par exemple que 37 images par secondes sont calculées. Seules les images complètes le sont, et en admettant qu'elles ont un temps de rendu identiques, 30 images, doublées, seront envoyées vers l'écran.
  • Dans le cas ou le GPU principal est capable de calculer plus de 60 images à la seconde c'est là que Virtual V-Sync se distingue. Sans, la carte graphique ne tentera pas de calculer plus d'images que nécessaire, ce qui a pour avantage entre autre de limiter sa consommation électrique, son échauffement, et le bruit produit. Avec Virtual V-Sync, la carte graphique continuera de calculer des images supplémentaires qui ne seront en pratique pas affichées.


Quel est alors l'intérêt ? Il revient toujours au même, selon Lucid, augmenter le framerate permet d'augmenter la réactivité de l'application. L'algorithme de Virtu choisit alors lesquelles des images calculées durant un intervalle de 16 ms (1 seconde divisé par 60) devra transiter jusqu'au framebuffer de l'IGP. En pratique notre constatation reste la même que pour HyperFormance, si l'augmentation du framerate peut avoir un rôle sur une partie de la latence, le fait d'activer la synchronisation verticale, et donc un double (ou triple) buffering rallonge encore la latence totale. Le gain théorique est insignifiant et en pratique, nos jeux n'étaient pas plus réactifs qu'avec un simple VSync activé, alors qu'ils l'étaient légèrement une fois le Vsync desactivé.
Sommaire
3 - Hyperformance, Virtual V-Sync
4 - Conclusion
Vos réactions

Top articles