Reprise du message précédent :

Je crois que tu as mal compris, l'overlay n'est pas pointé du doigt.

Nan mais ce que je veux t'expliquer, c'est que la fréquence de la synchro verticale optimale varie suivant la carte graphique, et que si tu mets une fréquence fixe pour toutes les cartes, ca va avantager certaines cartes et en désavantager d'autre... (cf l'exemple plus haut)

Article très complet et intéressant, bravo    
 
Pour ma part j'avais essayé avec fraps de prendre les Frametimes, puis de soustraire le FT avec celui qui le précède, (sous excel), afin corroborer les micro saccade, mais le résultat n'été pas probant du tout.
 
En mono gpu, pour éviter ce manque de fluidité, parfois le Vync On ne suffit pas je suis obligé de prendre un limiteur de fps (server de MSI After Burner) et là c'est bon, mais cela vient surement du moteur du jeu...
 
Sinon, en attendant de trouver un solution technique afin de mesurer ces microlag, vous pouvez toujours utiliser des petit smiley en fonction de votre ressenti :
 

 
D'accord, mais il bon de savoir qu'une carte est optimale avec tel ou tel fréquence verticale et après choisir en fonction de ce que supporte son écran. Et je ne comprends pas pourquoi tu voudrais qu'il y ait le même écart entre une valeur de FPS et une valeur de "fluidité" entre 2 même cartes? C'est pas la même chose. C'est comme comparer le taux de CO2 d'un moteur de 100ch et d'un autre de 200ch: Il y a un moteur 2x plus puissant mais le taux de CO2 n'est surement pas le double...

 
C'est ce qu'ils ont fait avec plus de couleurs

Même sur nos consoles "modernes" ?

 
Je ne sais pas.
L'OS reste actif derrière, mais je n'ai aucune idée de ses caractéristiques.
 
(mais je pense pas que ca soit une version temps réel pour être franc )

Ca pourrait effectivement être pas mal, mais il reste tout de même un problème, sur les carte hdg on test les derniers jeux en ultra, et il est très rare que les cartes graphique même récente arrive à tenir la synchro verticale (on va dire à 60 FPS) dans de tels conditions.
 

Bah la fluidité d'un jeux est normalement exprimé en FPS.
Si une carte ne tient pas la synchro verticale, ca ne prouve pas que cette carte ne sera pas fluide une fois la synchro désactivé.
Pour moi entre 50FPS et 60FPS c'est fluide, et pourtant ca ne tient pas une synchro à 60Hz.
 
Edit : Si tu veux tu as le site techreport.com qui t'indique le temps passé en dessous d'un certain nombre de FPS (20, 30 et 60FPS) pour chaque carte.
Par exemple : http://techreport.com/review/24539 [...] reviewed/5
C'est le graphique du bas.

 
Pas d'accord, je sens la différence entre une limitation à 65 FPS et de la V-Sync, pas qu'un peu.

Finalement c'est bien dommage que ça n'avance guère, je me suis fais plusieurs fois piégé par les test de CG en croyant que 40 à 60fps annoncé dans les test HFR permettrait un jeu correct.
En réalité j'ai pu constater que pour ne pas avoir de drop, mini lag etc on peut diviser suivant les jeux et config équivalente(plus sensible suivant le matos et leurs réglages, forcement) entre 2 et 4x les chiffres annoncés pour être bien dans l'ensemble du jeu.(et pire encore sur anno 2070)
Un logiciel de type FCAT aurait évité ce genre de désillusion.
Je trouve dommage qu'il ne soit pas inclus au moins à titre indicatif, ça me semble plus représentatif que des fps pour avoir un jeu fluide.
Le subjectif me parait pas forcement ce qu'il à de mieux, chacun est différent. Moi je peux pas jouer V sync off j'ai horreur du tearing, en 120hz c'est encore plus flagrand(le testeur semble trouver le contraire, sur le papier il à pas tord mais pourtant ça flash plus).
D'autre ne veulent pas du v sync ON car ça engendre de la latence.
Moi ça me convient, de toute façon le LCD est tellement mauvais dans ce domaine et le temps de réponse, que la différence me semble peu perceptible.
Après il y a ceux qui trouve fluide avec 40 fps et d'autres qui à 120fps n'est pas parfait. Certains sont sensible au flicker, d'autres pas. Franchement on est pas sortis de l'auberge si on reste dans le subjectif.
 
Ceci étant, ces problèmes ont toujours été la mais les programmeurs travaillant de plus en plus vite pour maximiser les gains en terme d'argent, l'optimisation en prend un coup.
Idem pour l'architecture des GPU(moins les cpu surtout depuis l'abandon du P4) de plus en plus orienté parallélisme pour le calcul brute mais de moins en moins en rapport à ce que l'on demande de faire pour un jeu(affichage en temps réél).
FCAT semble un bon moyen de "reveiller" les programmeurs comme les constructeurs pour coller davantage à la réalité et ce qu'on demande à un jeu: afficher du temps réel.

Justement non, l'absence d’irrégularité sous FCAT ne veut pas dire qu'il n'y en a pas (Tech Report a d'ailleurs montré un exemple à ce sujet), tout comme la présence d'irrégularités ne veux pas dire qu'il y'a un souci à l'usage (cf. le cas "irrégularité régulière" énoncé par Damien dans la news à ce sujet).

Je me demandais si ça viendrait dans sur hfr un de ces quatres.
Il y a du mouvement depuis pas mal de temps.
 
voici l'article qui a tout déclenché.
http://techreport.com/review/21516 [...] nchmarking
 
Il se trouve que j'avais déjà émis ces hypothèses et solutions par écrit à une date encore antérieure sur un forum où je traînais.
 
Il y a nombre d'articles passionnants qui développent tout ça, surtout récemment.
On capture effectivement le flux dvi taggé.
 
http://www.pcper.com/reviews/Graph [...] nce-Metric
 
http://www.pcper.com/reviews/Graph [...] d-Thoughts
 
http://techreport.com/blog/24133/a [...] ng-methods
 
http://anandtech.com/show/6857/amd [...] dmap-fraps
 
http://www.pcper.com/reviews/Graph [...] onclusions
 
http://techreport.com/review/24051 [...] peed-video
 
http://www.pcper.com/reviews/Graph [...] nce-Testin
 
http://anandtech.com/show/6862/fca [...] g-part-1/3
 
Pour information dès 2009 des gens mesuraient physiquement le lag, et les résultats ne sont pas brillants.
http://www.anandtech.com/show/2803/6
 
http://techreport.com/review/24553 [...] ture-tools
 
 
 

Nous avons bien entendu suivi cela depuis le début. Il y a à boire et à manger dans tout cela malheureusement, plus d'opportunisme que de compréhension de la problématique chez certains. Il faut je pense garder Techreport à part.
 
Techreport a le mérite d'avoir initié ces analyses plus poussées, de s'être posé des questions et d'avoir essayé d'y trouver des solutions. Malheureusement elles restent toutes imparfaites, certes ce qui n'enlève pas tout leur intérêt. Le problème est que juger de la fluidité est complexe. D'ailleurs ce que Techreport publie comme données revient surtout à remplacer la valeur ridicule des fps min reportés par certains testeurs par quelque chose de plus réaliste. Mais cela ne représente pas la fluidité.
 
Pour cela, à l'heure actuelle Techreport publie des données Fraps et Fcat brutes... mais doit les relativiser par rapport à son ressenti. En d'autres termes, en elles-mêmes ces données ne permettent pas de juger de la fluidité. En fait elles permettent surtout de donner une explication au ressenti et d'ajouter une illustration objective. Certes une donnée chiffrée donne plus facilement confiance qu'un avis, un chiffre c'est objectif. Cependant pour qu'elle reste objective une donnée doit être utilisée d'une manière stricte par rapport à sa signification. Les données de fraps et générées par les scripts Fcat de Nvidia ne représentent pas la fluidité.  
 
En fait j'ai souvent l'impression qu'il y a un peu trop d'envie de trouver à tout prix, de bricoler, un chiffre prétendument "scientifique" pour illustrer un ressenti. A ce jour nous n'avons rien observé dans les tests publiés ni dans nos nombreux essais qui atteigne cet objectif. C'est la raison pour laquelle nous n'utilisons ni les "frametimes" reportés par Fraps ni ceux reportés par Fcat. A quoi bon passer des heures à collecter des données uniquement pour illustrer un ressenti tout en devant expliquer dans de nombreux cas qu'en fait ces données donnent une fausse impression ?
 
Car tout cela n'est pas sans conséquence. Si ces données étaient gratuites, pourquoi ne pas les publier ? La plupart des testeurs qui ont opté pour Fcat ont dû sacrifier le nombre de jeux testés. Pour moi c'est une erreur. Quand Techreport est seul à le faire, cela apporte une information supplémentaire. Si tout le monde utilise aujourd'hui Fcat, cela va avoir pour conséquence d'appauvrir les tests.
 
Il y a une autre conséquence : optimiser pour Fcat et optimiser pour la fluidité sont deux choses différentes. Il serait dommage que la fluidité réelle soit en partie négligée sur l'autel du "score Fcat". Cela se ressent déjà en bi-GPU, mais cette nuance est nettement accentuée en tri et en quadri-GPU, soit quand le buffer de frames prêtes à être rendues se réduit voire devient nul relativement au nombre de frames calculées en parallèle. Avec son pilote alpha, AMD obtient de très bons résultats sous Fcat parce que la cadence d'affichage est très régulière, mais la cadence ressentie est dans certains cas moins bonne parce que le moteur du jeu ne suit pas cette régularité "artificielle". Il en va de même avec les GeForce, surtout en tri et en quad : régularité presque parfaite sous Fcat mais ressenti différent dans certains jeux.
 
La solution correcte demanderait que le moteur du jeu indique pour chaque frame quelle était son intention et de mettre en parallèle le respect de cette intention et la régularité d'affichage.

Je l'avais déjà proposé il y a un moment, mais la solution la plus simple point de vue fps serait d'attribuer une "note" en fonction du render time de chaque image : moins de 33ms = 1/(30*min(frame_time,1/60)). Tout ce qui dépasse des 60fps est écrêté, toute frame prenant plus de 33ms a un "score" de 0.

Après, il reste le souci du "lag" sur toute la chaîne, de l'entrée au rendu (particulièrement difficile à mesurer) et du rendu à l'affichage (donné indirectement par FCAT).

Je suppose que c'est ce lag entrée/rendu qui pose problème avec les solutions multi-GPU?  (4/8 images "pré-calculées", mais avec les mêmes données).

Render time calculé comment ? Avec Fraps ?

C'est pas idéal, mais ça peut faire l'affaire si on admet que la dernière passe de l'image précédente est comptée à la place de la dernière passe de l'image en cours. Il persiste une erreur, mais elle devrait être relativement faible.

Tridam dit justement que ça ne fait pas l'affaire

Oui, parce que tu peux avoir des frames mettant toutes 16.67ms à êtres rendues, si le jeu pense pour une raison x ou y qu'en fait elles alternent 8 ms et 24 ms, il sera pas fluide malgré la régularité parfaite et donc le score FCAT au top.

 
Tu veux donner une note aux frames pour représenter la fluidité en te basant sur des données qui ne représentent pas la fluidité ?
 
Les données Fraps ne sont ni équivalentes à l'avancement de la simulation, ni à la régularité d'affichage. Elles peuvent être proches de l'une ou de l'autre, donnée une idée sur l'une ou l'autre... ou pas.

Et c'est justement l'objet de la question qui suit : l'input lag (ou "simulation", mais je trouve pas que ce terme colle avec le domaine, c'est un autre problème).

C'est quoi justement ta question ?

Reste la seule et unique solution.

Coller un FPGA en sortie DVI. lire directement les images, et comparer à la précédente. Si différente alors nouvelle image.

Faire en sorte dans le test que le chemin de la cam est toujours mobile. => enregistrer le chemin en mode low def low details pour être bien sur qu'il soit continu.

Après il faudra corréler avec les hz, peu de gens travaille au delà de 60hz donc tester avec du 60hz sur du dvi est ce qui semble le mieux.

Sur la carte du fpga ( prenons une carte de dev c'est plus simple et pas trop cher ), tu as souvent des afficheurs led, et tu mets dedans le décompte de tes mesures.

A priori si tu utilises des grosses résolutions ça va demander un très gros FPGA.

A moins d'utiliser un CRC ou quelque chose du genre.

Je ne vois pas en quoi l'utilisation d'un FPGA apporterait quoi que ce soit. Le n'aurait strictement aucune information de plus en entrée que le flux vidéo enregistré avec fcat...
 
Par ailleurs qu'une image soit différente de la précédente ne donne une indication que quand on tourne à 60 FPS avec vsync et avec un moteur dont on sait qu'il fait avancer la simulation d'une manière fixe tous les 1.60ème de seconde. C'est rarement le cas.

Ne plus être limité à un certain nombre de logiciel c'est déjà un plus

Je suis pas sur d'avoir compris.  

Selon ce qu'on fait dudit FPGA, ça pourrait permettre de se passer de FCAT, ceci dit ça me semble bien compliqué (au lieu de chercher un tag, on fait une comparaison d'image ligne à ligne pour "construire" l'équivalent du tag).

Après, il y a effectivement l'input lag à considérer, mais là je sèche, faudrait limite avoir accès à une démo spécifique du moteur, et du coup ça rentrerait pas dans le cadre... intercepter les commandes est relativement facile, mais l'analyse derrière me semble particulièrement difficile à automatiser.

En gros, si t'es en Vsync avec 60 images différentes par secondes, on pourrait penser qu'on est dans le cas idéal et que c'est très fluide, sans aucun MS possible. Sauf qu'il peut tout à fait y avoir des variation de "temps de jeu" (liés à l’horloge interne du jeu) par rapport à l'horloge réelle qui font qu'on peut ressentir du MS. Pour le bien faudrait que le jeu puisse horodater chaque image afin d'identifier un tel phénomène.
Si j'ai bien compris, il faut vérifier que 2 conditions sont réunies pour qu'il n'y ait pas de MS :
 - vérifier visuellement que les différentes images affichées le sont de manière très régulières
 - que le temps écoulé entre 2 images différentes corresponde à la différence de temps écoulé selon l'horloge du jeu
Or le point 1 est difficile à mettre en œuvre et le point 2 est à priori impossible à vérifier puisqu'on ne peut pas obtenir certaines informations propres au moteur du jeu. Et Fraps ne permet rien de tout cela !
Du coup, Tridam semble en avoir conclu que ça ne valait pas le coup de vérifier le point 1 car insuffisante et très chiante à mette en œuvre : la classique moyenne accompagnée d'un ressenti du testeur est pour l'instant la moins mauvaise méthode sans être trop contraignante dans l'élaboration d'un comparatif riche et complet.

edit: que Tridam me corrige si je me trompe

Le point 1 est plus facile à réaliser qu'on pourrais le penser. Justement, j'ai fais quelques trucs sympas en fpga dernièrement et je pense que c'est pas trop dur.

En fait comparer une image à une autre ce n'est pas difficile en soit, sauf que ça peut prendre des proportions assez importante en taille d'image, du fait de nos écrans importants.

Capturer sur le dvi avec un fpa => très simple, il suffit de brancher n'importe quelle carte qui cadence assez vite pour pouvoir lire du DVI, jusque la rien de compliqué.
Ensuite coder un code qui compare les deux images =>

L'idée d'utiliser un code pour identifier l'image, est je pense la solution aux problème de taille très importante de nos écran et aux capacités limités des fpgas en terme de nombre de bascules.

En fait j'ai dis CRC, mais je me suis gouré, je voulais dire md5 ou sha, pour donner l'empreinte numérique de l'image. Les algos sont connu, et coder le tout en vhdl est donc faisable. Avec cette méthode on peut avoir un code identifiant l'image différents entres deux images successives quelque soit la résolution, et avec un niveau de confiance très élevé.

Comparer un code d'empreinte à un précédent et pas non plus compliqué.

Donc on peut avoir le nombre d'images réelles affichés depuis le début si on ajoute un compteur.

Pour moi c'est techniquement faisable et sans y passer des mois.

Et si ce qui nous intéresse est pas le nombre de frames affichés réelles, mais le microshutter, il suffit de cadencer plus haut la fréquence du DVI.

Genre monter à 144 voir même 200hz si on peut.

Et la tu pourras observer les MicroShutter de façon très précises.

( par la régularité des frames que le gpus te donnera )

Mais quel intérêt par rapport à l'analyse du flux vidéo capturé par le port DVI ?

c'est plus ou moins la même chose

sauf qu'on se fait pas ch*er avec des To de données ...

 
Autant coder un plugin pour traiter ces données en temps réel alors, c'est plus simple que passer par un FPGA

Y'a juste pas de surcouche logicielle, donc c'est "indéniablement impartial", bien qu'il y ait toujours moyen de tricher (décalage d'1 pixel à droite/gauche ou encore changement du gamma pour faire croire à une image différente ou des conneries du genre).
 
Mais effectivement, ça n'enlève pas le besoin d'analyse évènement/affichage, que je vois très mal automatiser (genre supercalculateur hybride bourré de FPGA spécialisés et processeurs massivement parallèle juste pour déterminer si oui ou non c'est cohérent? )

 
Non c'est intrinsèque au GPU, si pas de nouvelle image alors image identique. Donc pas moyen d'augmenter artificiellement autrement que en créant une nouvelle image.
 

 
tu peux rever    
 
c'est pas possible en temps réel.
 
 
Perso je pense à un truc pas mal, de renvoyer les temps des frames sur un second PC via l'uart. Histoire d'avoir les temps des trames et de pouvoir analyser les microshuters. Enfin moi je dis ça, c'est une proposition pas chère et pas trop compliqué à mettre en œuvre.
 
Et surtout plus efficace que ce qui se fait actuellement. Après le parfait, malheureusement il y a pas. Le parfait, c'est introduire du code dans le code du moteur et c'est pas possible.

Tu veux dire que des techniques de triche, comme l'HyperFormance de Lucidlogix Virtu MVP, ne seraient pas possibles ?
http://www.hardware.fr/articles/85 [...] -sync.html

bien vu, je n'y avais pas pensé ... mais bon ça se détecte très vite non ?  

Et puis je pense qu'il y a d'autres techniques intéressantes pour vérifier que la frame change. Avec une cam toujours en mouvement, les bords de l'écran change systématiquement par ex. Tu peux faire une double vérification par ex.

Dinosaure spotted  

 
Ouer mais c'est facile à coder en vhdl