Les LCD en retard à l'affichage sur les CRT ? Oui !

1 retard, + 1 retard, +... (souris, carte graphique...)

Ce retard aurait peu de conséquence s’il était isolé. En fait, il ne vient que conclure celui de toute une chaîne, qu’on devrait chercher à minimiser.


Ça commence avec les périphériques de saisie. Qu’on soit en souris filaire ou sans fil, aucun modèle ne réagit immédiatement. Les souris "normales" sont en principe limitées à une fréquence d’échange de 125 Hz sur le bus USB. Soit un échange toutes les 8 ms. Soit encore un retard systématique de 1 à 8 ms à chaque commande. Et encore, on parle là des bonnes souris. Nous en avons trouvées qui communiquaient bien moins souvent, on peut facilement atteindre les 16 ms de retard. Maintenant, une "nouvelle" génération de souris s’est affranchie de cette limite à 125 Hz et profite du plus haut débit offert par l’USB 2, pour monter sur certaines (Razer) à 1000 Hz. Soit une latence optimale de 1 ms. En fait, nos essais ont révélé une certaine instabilité de ces système. On ne reste jamais à 1000 Hz, le débit varie alors de 50 à 1000 Hz, avec une moyenne tout de même sensiblement supérieure aux 125 Hz des souris USB 1. La gamme gamer de Logitech atteint elle 500 Hz, elle aussi avec une certaine instabilité.

Vient ensuite la carte graphique. Là j’ai deux options...

1 : je ne me casse pas la tête, on part sur l’idée d’un processeur ultra puissant couplé à une carte graphique très haut de gamme. Bref, on minimise les temps de calcul, qu’on en vient même à négliger pour certains. Entre autre, j’estime que la carte graphique fournira toujours plus de 60 fps dans les jeux, et même 100 fps : ça m’arrange pour l’une des mesures à venir.

2 : je me rappelle que je suis sur Hardware.fr, que si moi je n’y connais rien en cartes graphiques j’ai deux monstres à mes côtés, Damien Triolet et Marc Prieur. Je leur en parle et... je regrette. Car ils me compliquent la vie. Forcément avec eux, on rentre dans les détails. Mon calcul est juste, oui mais si on veut être un peu précis... Je vous mets le début de leurs sombres pensées pour ceux qui veulent réfléchir un peu plus, compléter les calculs, les affiner et évaluer un peu mieux l’étendue des dégâts :

Une carte graphique utilise 2 buffers, un buffer dans lequel elle calcule l’image et un autre dans lequel est lue l’image à afficher. Une image ne peut donc commencer à être affichée qu’après avoir été entièrement calculée.

En Vsync OFF, quand la carte graphique a calculé l’image dans le buffer A, elle inverse les buffers A et B directement, peu importe si le buffer B était en train d’être lu en vue d’être affiché. Si c’était le cas, alors l’image affichée sera une moitié de l’image n-1 et une moitié de l’image n. On a donc deux morceaux d’images différentes, et de ce fait deux retards différents. Entre 2 rafraîchissements de l’écran, plusieurs images peuvent avoir été calculées si la carte graphique et le processeur sont très performants. Dans ce cas le retard induit par la carte graphique est compris entre 2x le temps de calcul de l’image et 1x le temps de calcul avec une différence possible entre différents blocs de l’image affichée. Tout dépend donc ici de la puissance de la carte graphique et du processeur.

En Vsync ON, ce problème est évité puisque les buffers A et B ne peuvent être inversés que quand l’écran vient d’être rafraîchit. Quand la carte graphique a calculé l’image dans le buffer A, elle attend d’arriver à ce moment avant d’inverser les buffers. Ensuite le buffer A devient le buffer B et vice versa. Sur un écran 60 Hz, le buffer B est lu 60 fois par seconde mais ça ne veut pas dire qu’il a été mis à jour 60 fois par seconde ! Si la carte graphique est toujours capable de calculer l’image en moins de 1/60ème de seconde, très bien, le retard induit sera toujours de 1/60ème de seconde. Si la carte graphique prend plus de temps, elle va terminer après la fin du rafraîchissement, seul moment où elle peut inverser les buffers, elle devra donc attendre le rafraîchissement suivant, ce qui veut dire qu’une même image va être affichée 2 fois. La première fois elle aura un retard de 2/60ème de seconde et la seconde fois de 3/60ème de seconde. Le problème est accentué par le fait que le temps de calcul d’une image est variable dans le jeu, on peut ainsi passer d’un retard de 1/60ème à 3/60ème en avançant dans la scène ce qui cause un décalage important en plus de la baisse de fluidité. En Vsync ON il est crucial d’avoir un système capable de tenir au moins autant de FPS que le taux de rafraîchissement. On ne passe pas de 60 à 50 FPS mais directement de 60 à 30 même si la moyenne peut le masquer.

Il est également utile de préciser que le moteur du jeu a lui aussi un rôle à jouer et que le triple buffering permet de réduire le décalage qui se produit en VSync ON mais au prix d’un retard plus élevé généralisé.

Bien, tout ça pour dire que vous pouvez compliquer le calcul suivant à l’envie, en changeant l’hypothèse de départ. Si ça vous amuse, vous pouvez tout reprendre en estimant que la carte graphique ne tiendra pas les 60 ou 100 fps supposés acquis dans mes exemples suivants. Mais pour ma part, j’ai retenu l’option 1...