[HFR] Actu : Tests GPU, fluidité: faut-il utiliser FCAT?

Actu : Tests GPU, fluidité: faut-il utiliser FCAT? [HFR] - HFR - Hardware

Marsh Posté le 23-04-2013 à 21:00:02   0  

Depuis quelques temps il est de plus en plus question de l'abandon des mesures de types FPS pour représenter les performances des cartes graphiques au profit ...
Lire la suite ...

Reply

Marsh Posté le 23-04-2013 à 21:00:02   

Reply

Marsh Posté le 23-04-2013 à 21:07:53   7  

"alors que nous prévoyons de publier demain un test qui ne pourra pas éviter la question de la fluidité"
 
Le dossier de la HD 7990 en approche, j'ai hâte :D

Reply

Marsh Posté le 23-04-2013 à 21:12:53   1  

Doux jésus si c'est ce test là j'ai trop hâte :D

Reply

Marsh Posté le 23-04-2013 à 21:18:55   2  

"Multi-GPU stuttering has become an important issue for AMD just as single-GPU stuttering has, and AMD is working on a resolution for it. That resolution will come in or around a July driver drop, at which point AMD will introduce some new driver options to control how their cards deal with the issue."
 
http://www.anandtech.com/show/6857 [...] ap-fraps/6


Message édité par kalidrimmm le 23-04-2013 à 21:20:03
Reply

Marsh Posté le 23-04-2013 à 21:19:15   1  

le coté logiciel de fcat est d'un certain coté indispensable. sans overhead logiciel, il existe aucun moyen de connaître la latence inter-trame.
 
j'attendais un mouvement de votre part dans ce sens, les fps ne veulent plus vraiment dire grand chose.
 
Perso j'ai pris l'habitude de jouer en mode triple buffering, mais es-ce mieux ?
 
aucune idée réelle de la chose.
 
Le seul moyen réel de connaître les perfs serait d'avoir accès au code source du moteur, de le modifier pour insérer des points de mesure. et de faire faire les mesure en externe par un fpga connecté en dvi.
 
ça peut paraître fou, mais je ne vois aucun autre moyen.
 
En attendant fcat donne des infos précieuses de comparaison entre mode multi gpus et mono gpus. Je ne dis pas que c'est précis, c'est juste intéressant.
 
Sinon j'ai dev un algo basé les latences inter-trames pour donner un indice de performance. Certes compliqué, mais donnant un indice réaliste.
 
il me manque des fichier cvs avec des tests long, pour vérifier que ça fonctionne

Reply

Marsh Posté le 23-04-2013 à 21:38:26   10  

Cet article m'a fait réaliser le temps que vous devez passer à faire des tâches répétitives pour faire les tests sur des dizaines de GPU... Impressionnant et je comprends mieux pourquoi peu de sites sont aussi détaillés et précis que vous!
Moi je dis bravo.

Reply

Marsh Posté le 23-04-2013 à 22:00:39   2  

barbare128 a écrit :

le coté logiciel de fcat est d'un certain coté indispensable. sans overhead logiciel, il existe aucun moyen de connaître la latence inter-trame.
 
j'attendais un mouvement de votre part dans ce sens, les fps ne veulent plus vraiment dire grand chose.
 
Perso j'ai pris l'habitude de jouer en mode triple buffering, mais es-ce mieux ?
 
aucune idée réelle de la chose.
 
Le seul moyen réel de connaître les perfs serait d'avoir accès au code source du moteur, de le modifier pour insérer des points de mesure. et de faire faire les mesure en externe par un fpga connecté en dvi.
 
ça peut paraître fou, mais je ne vois aucun autre moyen.
 
En attendant fcat donne des infos précieuses de comparaison entre mode multi gpus et mono gpus. Je ne dis pas que c'est précis, c'est juste intéressant.
 
Sinon j'ai dev un algo basé les latences inter-trames pour donner un indice de performance. Certes compliqué, mais donnant un indice réaliste.
 
il me manque des fichier cvs avec des tests long, pour vérifier que ça fonctionne


 
Pour moi la mesure de performances doit rester des FPS non trafiqués pour compenser un manque de fluidité. Par contre un indice qui représente la fluidité serait le bienvenu en complément. Actuellement j'ai surtout vu beaucoup de n'importe quoi et rien de très probant, mais il y a probablement qqch à faire de ce côté. Moi aussi j'ai quelques idées à ce sujet à expérimenter notamment en retournant le problème pour observer non plus l'évolution des frames par seconde ou des latences inter-frames mais plutôt des frames par refresh écran.

Reply

Marsh Posté le 23-04-2013 à 22:01:28   2  

j'ai tout lu (ouch), +1 avec lagman :jap:

Reply

Marsh Posté le 23-04-2013 à 22:14:31   0  

barbare128 a écrit :


Le seul moyen réel de connaître les perfs serait d'avoir accès au code source du moteur, de le modifier pour insérer des points de mesure. et de faire faire les mesure en externe par un fpga connecté en dvi.


 
Je vois pas du tout en quoi ca va aider.
Tu restes complètement dépendant de l'OS non temps réel et du driver.
Tu peux arrriver au point où tu demandes le switch de frame, la suivante commence sur ton CPU, il enquille même des ordres pour le GPU (au niveau du driver), mais ce dernier est encore en train de dépiler les ordres d'avant.
 
Il me semble.

Reply

Marsh Posté le 23-04-2013 à 22:25:33   2  

Il faudrait un log des actions souris/clavier, il faudrait que le moteur du jeu log les temps de simulation qui correspondent à chaque image et de pouvoir injecter tout ça dans l'analyse fcat :o

Message cité 1 fois
Message édité par tridam le 23-04-2013 à 22:26:00
Reply

Marsh Posté le 23-04-2013 à 22:25:33   

Reply

Marsh Posté le 23-04-2013 à 22:32:52   2  

Merci pour ce focus :jap:

Reply

Marsh Posté le 23-04-2013 à 22:38:09   3  

Sympa comme article! :jap:

Reply

Marsh Posté le 23-04-2013 à 22:55:46   0  

tridam a écrit :

Il faudrait un log des actions souris/clavier, il faudrait que le moteur du jeu log les temps de simulation qui correspondent à chaque image et de pouvoir injecter tout ça dans l'analyse fcat :o


 
Bof.
Que le jeu utilise le dernier frametime "fraps", ou lisse sur X valeurs, y'a toujours un cas où ca veut rien dire :o
Il faut un OS temps réel et pas de driver. Une console quoi :D

Reply

Marsh Posté le 23-04-2013 à 23:00:34   1  

Très intéressant ; j'ai hâte de lire vos tests !
J'utilise aussi "RivaTuner Statistics Server" en multi-gpu ; c'est très utile ; çà témoigne bien des micro-saccades en jeu je trouve.

Reply

Marsh Posté le 23-04-2013 à 23:18:39   0  

Très intéressent et c'est avec se genre d'article que l'on réalise votre extrême sérieux et votre long travail !  
Hâte de voir votre test de la 7990 ! :jap:


Message édité par fire du 57 le 23-04-2013 à 23:18:51
Reply

Marsh Posté le 24-04-2013 à 00:00:03   0  

Intéressant votre Notions d'hyper Threading des CPU Intel il serait intéressant de voir comment l'Hyper Threading peux nuire ou non à la fluidité des jeux ou même à la performance lorsqu'il est activé ou non.

Reply

Marsh Posté le 24-04-2013 à 00:02:32   0  

Petite question.
FCAT avantage-t-il les cartes Nvidia ou ont-ils été corrects et neutres ?

Reply

Marsh Posté le 24-04-2013 à 00:04:27   0  

3615Buck a écrit :

Petite question.
FCAT avantage-t-il les cartes Nvidia ou ont-ils été corrects et neutres ?

 

D'après ce que j'ai compris :
Il est neutre niveau mesure (il ajoute juste une bande de couleur à chaque frame), après niveau interpretation, il avantage par effet de bord les nvidia car elles ont une meilleure variance de frame à frame, et semble décider à la place de l'utilisateur ce qui est fluide ou pas (point où tridam préfère décider lui même donc).

 

edit : je parle en crossfire, en simple GPU, plus de pb particuliers avec les AMD d'après les derniers tests de techreport.


Message édité par darkstalker le 24-04-2013 à 00:05:23
Reply

Marsh Posté le 24-04-2013 à 00:18:51   0  

Citation :

cosmétiques : il est par exemple plus facile de représenter 0 ms qu'une infinité de FPS.  
La latence inter-image sans vsync
Sans synchronisation verticale, la latence inter-image prend une signification particulière, qui fait d'ailleurs que nous estimons son nom mal adapté. Elle représente alors la visibilité de l'image calculée par le GPU qui correspond au temps d'affichage * la proportion de l'écran qu'elle a couverte. Par exemple, en 60 Hz, une latence inter-image de 8 ms ne veut pas dire que vous verrez une nouvelle image tous les 8 ms, mais bien que cette image sera visible pendant 16.7 ms sur à peu près la moitié d'un écran.


 
Je suis la copine qui a juste utilisé cet ordinateur pour faire une recherche
sur 'cosmétiques' ... Et c'est très très difficile à comprendre votre truc,  
vous pouvez pas faire plus simple ? " Allo ... mais Allo quoi !"

Reply

Marsh Posté le 24-04-2013 à 00:46:59   0  

Citation :

Si vous nous avez suivis jusqu'au bout, n'hésitez pas à nous donner votre avis sur les méthodes de tests dans les commentaires !
 
 


les yeux, avant tout , si le ressenti est positif , on peu se demander à quoi ça peut servir  
ces test sont intéressant , mais les données qui en résultent sont au final difficile à interpréter  
elle peuvent mettre en évidence des facteurs limitant externes comme bien d'autres choses si j'ai bien compris  
je n y verrais un intéret que sur des cas à problèmes avérés au final :/


Message édité par Profil supprimé le 25-04-2013 à 18:19:32
Reply

Marsh Posté le 24-04-2013 à 00:53:16   0  

tridam a écrit :

Pour moi la mesure de performances doit rester des FPS non trafiqués pour compenser un manque de fluidité. Par contre un indice qui représente la fluidité serait le bienvenu en complément. Actuellement j'ai surtout vu beaucoup de n'importe quoi et rien de très probant, mais il y a probablement qqch à faire de ce côté. Moi aussi j'ai quelques idées à ce sujet à expérimenter notamment en retournant le problème pour observer non plus l'évolution des frames par seconde ou des latences inter-frames mais plutôt des frames par refresh écran.


On sent un peu de rémanence d'un test de Virtu [:gratgrat]

 

Les outils de développement d'AMD et nVidia ne donnent pas accès à des registres dédiés à ces informations? Ca me semble quand même curieux, étant donné que sans ça, justement, il devient difficile d'optimiser les perfs...

 

Quoi qu'il en soit, la multitude de paramètres à prendre en compte est effectivement problématique, mais ça c'est malheureusement le résultat de l'évolution au cours de ces 20 dernières années, avec un asynchronisme toujours plus poussé au point qu'il devient difficilement gérable.


Message édité par Gigathlon le 24-04-2013 à 02:00:19
Reply

Marsh Posté le 24-04-2013 à 01:58:10   0  

Tony_capriani a écrit :

"alors que nous prévoyons de publier demain un test qui ne pourra pas éviter la question de la fluidité"
 
Le dossier de la HD 7990 en approche, j'ai hâte :D


 
Le test de la suprématie ATI :)

Reply

Marsh Posté le 24-04-2013 à 05:55:23   0  

Merci pour ce focus. Plaisant a lire et montrant le serieux des journalistes de HW.fr


Message édité par D-Ther le 24-04-2013 à 05:56:28
Reply

Marsh Posté le 24-04-2013 à 06:51:09   0  

En même temps à partir du moment où le programme de tests est développé par l'entreprise qui fabrique les composants, il est à proscrire parce que ça semble évident que l'entreprise va fournir des résultats qui l'avantage ou qui au moins de l'a désavantage pas ^^

Reply

Marsh Posté le 24-04-2013 à 08:15:33   1  


 
Et c'est justement ce que tout le monde veut éviter. Utiliser ses yeux pour juger d'une fluidité est le pire test possible. Par exemple, je perçois de manière très sensible tout clignotement de lumière à 50 hz et en deçà, et tout jeu qui affichera 50 FPS me semblera une véritable horreur. Mais pourtant pour la plupart des gens, c'est indécelable. Ou pour certains, la fréquence peut être plus élevée ou plus basse, ou dépendre de l'état de fatigue, conditions d'éclairage, exposition préalable à la lumière, etc...
Un avis technique doit être le plus éloigné possible du subjectif, mais actuellement le manque d'outils ne le permet pas. Les yeux restent donc le pire des moyens de contrôle.

Reply

Marsh Posté le 24-04-2013 à 08:24:09   0  

kent1du68 a écrit :

En même temps à partir du moment où le programme de tests est développé par l'entreprise qui fabrique les composants, il est à proscrire parce que ça semble évident que l'entreprise va fournir des résultats qui l'avantage ou qui au moins de l'a désavantage pas ^^


 
Pas vraiment d'accord. Déjà, qu'est ce qui empêche AMD de fournir des outils similaires ? Ce n'est pas le cas, et pourtant ils bossent eux aussi sur le problème, car ils sont (généralement) plus impacté sur leur système multi GPU que NVidia.
Ensuite, la technique de NVidia est différente de celle d'AMD pour gérer le calcul des images en multi GPU. Leur méthode est plus orienté vers la fluidité et celle d'AMD sur la performance. Il est donc normal qu'ils poussent leur choix en avant, alors même qu'on parle de fluidité d'affichage.
Enfin, FCAT n'est pas la panacée loin s'en faut, mais il a le mérite d'exister et d'ouvrir la voie vers d'autres outils qui devraient apparaitre dans l'avenir. Et rien que pour ça, c'est déjà très bien.

Reply

Marsh Posté le 24-04-2013 à 08:26:37   0  

jellyboy74 a écrit :

Tony_capriani a écrit :

Le dossier de la HD 7990 en approche, j'ai hâte :D

Le test de la suprématie ATI :)


Tu crois qu'elle résistera a un SLI de Titan ? :) :)
/joke

Reply

Marsh Posté le 24-04-2013 à 08:38:48   0  

Je viens de regarder le test de la HD7990 sur "tom's hardware". Ils ont choisi de faire tester en aveugle sur un panel de joueurs (5, ce qui fait peu) pour évaluer la qualité du rendu.

Reply

Marsh Posté le 24-04-2013 à 08:41:03   0  

tridam a écrit :

 

Pour moi la mesure de performances doit rester des FPS non trafiqués pour compenser un manque de fluidité. Par contre un indice qui représente la fluidité serait le bienvenu en complément. Actuellement j'ai surtout vu beaucoup de n'importe quoi et rien de très probant, mais il y a probablement qqch à faire de ce côté. Moi aussi j'ai quelques idées à ce sujet à expérimenter notamment en retournant le problème pour observer non plus l'évolution des frames par seconde ou des latences inter-frames mais plutôt des frames par refresh écran.

 

Je ne vois pas trop l'intérêt d'avoir plusieurs frames par refresh d'écran. Donc au dela de 1 ce n'aurait aucun sens.

 

Par contre en dessous, ça serait utilisable. et à condition de travailler en vsync on, pour ne pas compter les demi frames.

 


Mais perso je trouve que la latence inter-frame se suffit à elle même. C'est plus ou moins l'inverse du fps. Avec surtout beaucoup de subtilité qui sont utilisable dans les fichiers cvs.

 

Après c'est sur, que si on veut utiliser ces fichiers de façon intelligente, il y a des calculs savants à faire dessus. C'est pour ça que j'ai fais un algo qui donne un indice de performance basé sur du cvs avec bcp d'échantillons. ( environs 5k frames ).

 

Et c'est bien entendu un algo qui peu prendre en compte le tau de rafraichissement de l'écran. Le calcul fait comme s'il y avait un rafraichissement, il suffit de donner la valeur en hz, et se démerde pour trouver un indice en fonction de ce taux, de façon intelligente. Il supprime les frames écrasés.

 

Ce qui est logique, ce qui n'es pas affiché, est forcément à supprimer. C'est pourquoi il faut le faire en mode vsync off pour en apprécier les performances de cet indice.

 

Edit:

 

J'ai demandé des cvs pour vérifier la pertinence de mes algo mais je n'ai rien reçu à ce jour.
Si je reçoit ces cvs, je pourrais publier une application environ une 15 aines de jours après. Je mettrais la formule bien sur en libre accès pour les testeurs après la publication de l'appli.

 

La formule est très complexe, mais elle a un sens mathématique et physique. Environ 3 pages sous un fichier matlab.

 

Et quand je vois celle de thomshardware ( excel ) :

 

"=ABS(B20-(TRIMMEAN(B2:B38, 0.3)))"

 

J'ai bien envie de rigoler. ou plutôt de faire un rire jaune, ...

 

J'ai besoin de données mono GPU et bi-GPU, de n'importe quel GPU, ça fera l'affaire. C'est mieux que de pondre ces données de façon aléatoire soi même, j'obtiens que du bruit par cette méthode, et difficile de juger si c'est valable.


Message édité par barbare128 le 24-04-2013 à 08:59:56

---------------
Feed my back : http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
Reply

Marsh Posté le 24-04-2013 à 09:31:44   0  

Au risque de dire une bêtise (noob inside), le meilleur outil pour analyser la fluidité ne serait-il pas une caméra (qui tournerait à autant d'img/s que de fps max, soit avec les écrans actuels de l'ordre de 120 im/s) et un logiciel d'analyse et de reconnaissance de mouvements, qui pourrait suivre les sprites à l'écran et indiquer les (micro-)saccades dans leur déplacement ?

Reply

Marsh Posté le 24-04-2013 à 10:23:54   0  

The_Long_John a écrit :

Au risque de dire une bêtise (noob inside), le meilleur outil pour analyser la fluidité ne serait-il pas une caméra (qui tournerait à autant d'img/s que de fps max, soit avec les écrans actuels de l'ordre de 120 im/s) et un logiciel d'analyse et de reconnaissance de mouvements, qui pourrait suivre les sprites à l'écran et indiquer les (micro-)saccades dans leur déplacement ?


 
Tu inclues les défaults de l’écran, autant que introduits d'autre problèmes techniques de faisabilité. Faire du calculs sur de l'image en mouvement, c'est très compliqué et ici peut être un peu inutile.
 
Le mieux ce serait de mesurer sur le dvi lui même via un fpga à mon avis.
 
En faisant en sorte que la caméra du jeu soit toujours en mouvement, et tu compares l'image avec l'image précédente, si identique alors même image, sinon image différente, donc nouvelle image. triple buffer pour éviter de compter les demi images. Et la tu inclues de façon naturelle le problème de la syncro verticale.
 
Mais bon ça reste pas simple à mettre en œoeuvre. Il faut un FPGA plutôt rapide, ...
 
et il faut connaitre le vhdl ;)


Message édité par barbare128 le 24-04-2013 à 10:25:23
Reply

Marsh Posté le 24-04-2013 à 10:35:37   0  

C'est un sujet très intéressant, pour l'instant personne n'a trouvé la méthode idéal pour mesurer le niveau de fluidité d'une carte graphique, peut être qu'on va finir par conseiller au gens de faire comme pour les casque ou les souris : allez tester en magasin !  :D  
 
Sinon le mieux serait une carte d'acquisition vidéo directement branché sur la carte graphique à tester, et régler le taux de rafraichissement au max (environ 144Hz pour du FHD).
 
Je sais que ca existe en HDMI, mais vous seriez limité au FHD 60Hz... Peut être que ce genre de carte existe pour du display port ou du DVI-D ? (faut quand même supporter un débit d'environ 10Gbps...)
 
Ou sinon comme dit The_Long_John, mettre une caméra slow motion, mais avec le double de FPS que celui de l'écran (288FPS pour un écran 144Hz).
 
Edit : Grilled  :D  
Sinon je viens de me rendre compte que toute les connectiques actuel seront bientôt obsolète, elles tournent toutes autour de 10Gbps (DVI-D, DP...) alors qu'il faut du 40Gbps pour le 4K (144Hz) voir 160Gbps pour le 8K (144Hz)...


Message édité par Keser le 24-04-2013 à 10:44:45
Reply

Marsh Posté le 24-04-2013 à 10:48:19   0  

Ne faudrait'il pas simplement faire les tests de jeux avec la vsync toujours activé et donner la proportion de temps ou la vsync n'est pas tenue ?

Reply

Marsh Posté le 24-04-2013 à 10:52:57   0  

Bah une carte qui tournerait en moyenne à 60FPS serait beaucoup pénalisé qu'une carte qui tournerait en moyenne à 70FPS.
Sur un bench de 60sec, on va dire que la carte qui affiche 60FPS aura 30sec sans la vsync, et la carte avec 70FPS aura 2 sec sans la vsync. On aura donc l'impression que la carte à 70FPS est 15 fois plus perf alors qu'elle n'est que 17% plus perf...


Message édité par Keser le 24-04-2013 à 10:58:54
Reply

Marsh Posté le 24-04-2013 à 11:11:08   0  

Keser a écrit :

Bah une carte qui tournerait en moyenne à 60FPS serait beaucoup pénalisé qu'une carte qui tournerait en moyenne à 70FPS.
Sur un bench de 60sec, on va dire que la carte qui affiche 60FPS aura 30sec sans la vsync, et la carte avec 70FPS aura 2 sec sans la vsync. On aura donc l'impression que la carte à 70FPS est 15 fois plus perf alors qu'elle n'est que 17% plus perf...


 
on parle de fluidité, pas de fps, dans ton example la carte 70FPS ne sera pas fluide 3% du temps alors que la 60FPS ne le sera pas 50% du temps et ça, ça ce ressent carrément...
 
On ne remplace pas la mesure de FPS mais on donne une info supplémentaire... C'est entre 2 carte fluide 100% du temps qu'on ne verra pas de différence car elle sont réellement fluide toute les 2...


Message édité par Fanfan71 le 24-04-2013 à 11:15:27
Reply

Marsh Posté le 24-04-2013 à 11:11:48   0  

Keser a écrit :

Bah une carte qui tournerait en moyenne à 60FPS serait beaucoup pénalisé qu'une carte qui tournerait en moyenne à 70FPS.
Sur un bench de 60sec, on va dire que la carte qui affiche 60FPS aura 30sec sans la vsync, et la carte avec 70FPS aura 2 sec sans la vsync. On aura donc l'impression que la carte à 70FPS est 15 fois plus perf alors qu'elle n'est que 17% plus perf...


 
dans ce cas il suffit de faire un comparatif par rapport a un VSYNC a 120Hz... ce sera + proche...

Reply

Marsh Posté le 24-04-2013 à 11:53:59   0  

Fanfan71 a écrit :

on parle de fluidité, pas de fps, dans ton example la carte 70FPS ne sera pas fluide 3% du temps alors que la 60FPS ne le sera pas 50% du temps et ça, ça ce ressent carrément...

Pas forcément, car si tu règle la synchro verticale à 50Hz sur la carte à 60FPS et que tu as 0% de perte de synchro, alors la carte à 60FPS devient plus fluide que la carte à 70FPS.

Reply

Marsh Posté le 24-04-2013 à 12:00:47   0  

Keser a écrit :

Pas forcément, car si tu règle la synchro verticale à 50Hz sur la carte à 60FPS et que tu as 0% de perte de synchro, alors la carte à 60FPS devient plus fluide que la carte à 70FPS.


Avec des si...
Il est évident qu'il faut comparer avec la même fréquence verticale, un même CPU, etc...

Reply

Marsh Posté le 24-04-2013 à 12:19:09   0  

barbare128 a écrit :

le coté logiciel de fcat est d'un certain coté indispensable. sans overhead logiciel, il existe aucun moyen de connaître la latence inter-trame.


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

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed