GPU stuttering / FRAC, le vrai FPS / Update 2013-03-29

http://www.anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps

J'en suis à la 3e pade du l'article. TRÈS intéressant. J'en parle depuis longtemps queles drivers AMD sont plus touché par le stuttering, surtout à cause des reviews de HardOCP qui en parle de façon objective en décrivant le feeling du gameplay qui semble mieux chez Nvidia, surtout en multi GPU.

Bien hate de lire la suite d el'article, à date ils parlent beaucoup de toutes la logique derrière le rendu d'une image.

À suivre

Edited March 31, 2013 by Boulard83

Des pics d'un tools de développeurs, GPUview. Assez complex mais en bout de ligne si on ne regarde pas toutes les datas ça devient relativement simple.

Voici ce qui se passe pendant qu'on joue a Crysis 3.

Et ici Unigine Heaven

En simples et de ce que j'y comprend, les datas verte/orange de celui du haut et bleu/orange de celui du bas représente le rendering. Les barres du bas représentes des logiques CPU. Quand on dit que Unigine Heaven n'est pas très pesant sur le CPU... c'est assez clair ici ! Le CPU semble passer le plus clair de son temps à attendre des commandes alors que sous Crysis 3 ... le CPU en a du boulot

Edited March 26, 2013 by Boulard83

Dans l'article, ils parlent aussi du fait que Fraps n'est pas nécessairement le bon tool pour enregistrer le stuttering puisque Fraps prend sa "mesure" au début de la chaine et donc ne tient pas en compte les "workaround" que le driver peut faire. AMD et Nvidia sont d'accord pour dire que Fraps n'est pas le meilleur tool, MAIS ... selon les test fait pas techreport voilà déjà un bon moment et plus récement en utilisant le frametime, Frpas démontre quand même un plus grand problème chez AMD. Donc problème il y avait quand même.

Perhaps the most interesting thing about this entire process – and the most embarrassing thing for AMD – is not just that stuttering was occurring and they weren’t looking for it, but by not looking for stuttering they were leaving performance on the table. Stuttering doesn’t just impact the frame intervals, but many of those stalls where stuttering was occurring were also stalling the GPU entirely, reducing overall performance. One figure AMD threw around was that when they fixed their stuttering issue on Borderlands 2, overall performance had increased by nearly 13%, a very significant increase in performance that AMD would normally have to fight for, but instead exposed by an easy fix for stuttering. So AMD’s fixing their stuttering has not only resolved that issue, but in certain cases it has helped performance too.

Danc cete pics on voie le frametime enregistré par Fraps. Ce qu'AMD nous dit, c'est que ce que Fraps voie n'est pas nécessairement ce qu'il se passe puisque le driver peut corriger ce qu'on voie ici avant de l'afficher.

The above is what AMD is calling the heartbeat pattern, and it’s something FRAPS is reporting even in some of the games they’ve fixed. This highlights one of the problems with trying to monitor frame intervals based on Present calls, as the context queue is absorbing the uneven frame dispatch, but FRAPS doesn’t realize it.

In a heartbeat situation the next Present gets delayed coming out of the application for whatever reason, which results in the rendering pipeline feeding from the context queue for a bit while nothing new comes in. Eventually the block is cleared and the application submits the next Present, at which point FRAPS records the Present as having come relatively later. Furthermore, since the context queue has been at least partially drained, there’s still room for one more frame, so rather than idling for a bit the application immediately gets to work on the next frame. As a result the next Present hits the context queue sooner than average, resulting in the early frame as picked up by FRAPS.

In this scenario, at the end of the rendering pipeline every frame could be displayed at an even pace despite the unevenness at the input, but FRAPS would never know. This doesn’t mean it’s not an issue, as uneven presents will cause the gap in time between the simulation steps to suddenly become uneven as well. But unless the heartbeat pattern occurs with high regularity or the size of the beat is enough to let the context queue drain completely, the impact from this scenario is far less than having the frames come out of the end of the rendering pipeline unevenly. Ultimately it’s another form of stuttering, but in the case of FRAPS looks far worse than it would be if we were measuring the end of the rendering pipeline and what the user was actually seeing.

Edited March 26, 2013 by Boulard83

Bonne nouvelle par contre, AMD disent travailler très fort au problème et le driver prévue pour juillet devrait permettre une très grande amélioration.

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. In the meantime however micro-stuttering and how AMD’s multi-GPU technology compares to NVIIDA’s multi-GPU technology is likely to become a bigger issue before AMD can push out their new driver. So AMD may be spending the next couple of months on the defensive.

In a typical AMD move, AMD will ultimately be leaving this up to the user. In their July driver AMD will be introducing a multi-GPU stuttering control that will let the user pick between an emphasis on latency, or an emphasis on frame pacing. The former of course being their current method, while the latter would be their new method to reduce micro-stuttering at the cost of latency.

The end result of all of this is that change is in the air. Just as how quickly as Scott Wasson and others changed the nature of GPU reviewing by using FRAPS to measure frametimes, things must change again for GPU reviewers. If FRAPS is no longer an adequate tool to measure stuttering and frame intervals – as both AMD and NVIDIA insist – then new methods and new tools must be created to measure those factors at the end of the rendering pipeline, where the results would match what the end user is seeing. Though on the subject of tools, AMD for their part is favoring double-blind trials as the ultimate method of detecting stuttering. They’re fundamentally right since the perceptibility of stuttering depends on the person, but admittedly this is also the least objective/qualitative way of evaluating stuttering.

In any case, just as how change is in the air for GPU reviews, AMD has had to engage in their own changes too. They have changed how they develop their drivers, how they do competitive analysis, and how they look at stuttering and frame intervals in games. And they’re not done. They’re already working on changing how they do frame pacing for multi-GPU setups, and come July we’re going to have the chance to see the results of AMD’s latest efforts there.

For us this is what we hope to be the start of our own changes. There are tools in development that meet our criteria for better measuring frame intervals, and hopefully in the not too distant future we’ll be able to discuss those tools to a much greater degree, and to use those tools to go about measuring frame intervals in the manner we’ve always wanted to. But that is a story for another day, so until then you’ll have to stay tuned to find out.

Une heure de bonne lecture avec de la bonne musique.

Maintenant, attendons de voir ce que les futurs drivers ainsi que de nouveaux tools pour mesurer le micro-stuttering auront à dire.

Edited March 26, 2013 by Boulard83

C'est déjà mieux que ça l'a été avec AMD, je me souvient du crossfire de HD3870 de mon chum de gars dans crysis vs mon SLI de 8800GT, c'était terrible.

Le 1er croffire que j'ai expérimenté c'est avec 1 X1900XT 512mb et une X1950XT 256mb (en software), j'avais un bon gain de FPS mais après 1 h ou un peu + de gameplay dans Oblivion, le jeu commençait à rusher, il falait rebooter le jeu pour être bon 1 autre heure. C'était pas le best mais ça fonctionnait.

Edited March 26, 2013 by RicMX3

Dans l'article, ils parlent justement que depuis les test de techreport qui ont ensuite explosé un peu partout sur le net, AMD ont réagis et dans les derniers 6mois/1an ils aurait corrigé beaucoup de ces problèmes de stuttering qui semblait les affecter même en single GPU.

Au moins ça montre que AMD travail la dessus

Edited March 26, 2013 by Boulard83

Voici un nouvel article de techreport, le site web même qui à lancé l'analyse du frametime VS le frame per second dans leurs reviews.

The fundamental problem is that, in terms of both computer time and human visual perception, one second is a very long time. Averaging results over a single second can obscure some big and important performance differences between systems.

To illustrate, let's look at an example. It's contrived, but it's based on some real experiences we've had in game testing over the years. The charts below show the times required, in milliseconds, to produce a series of frames over a span of one second on two different video cards.

GPU 1 is obviously the faster solution in most respects. Generally, its frame times are in the teens, and that would usually add up to an average of about 60 FPS. GPU 2 is slower, with frame times consistently around 30 milliseconds.

However, GPU 1 has a problem running this game. Let's say it's a texture upload problem caused by poor memory management in the video drivers, although it could be just about anything, including a hardware issue. The result of the problem is that GPU 1 gets stuck when attempting to render one of the frames—really stuck, to the tune of a nearly half-second delay. If you were playing a game on this card and ran into this issue, it would be a huge show-stopper. If it happened often, the game would be essentially unplayable.

The end result is that GPU 2 does a much better job of providing a consistent illusion of motion during the period of time in question. Yet look at how these two cards fare when we report these results in FPS:

Whoops. In traditional FPS terms, the performance of these two solutions during our span of time is nearly identical. The numbers tell us there's virtually no difference between them. Averaging our results over the span of a second has caused us to absorb and obscure a pretty major flaw in GPU 1's performance.

Since we published that first article, we've seen a number of real-world instances were FPS averages have glossed over noteworthy performance problems. Most prominent among those was the discovery of frame latency issues in last Christmas' crop of new games with the Radeon HD 7950. When we demonstrated the nature of that problem with slow-motion video, which showed a sequence that had stuttering animation despite an average of 69 FPS, lots of folks seemed to grasp intuitively the story we'd been telling with numbers alone. As a result, AMD has incorporated latency-sensitive methods into its driver development process, and quite a few other websites have begun deploying frame-latency-based testing methods in their own reviews. We're happy to see it.

http://techreport.com/review/24051/geforce-versus-radeon-captured-on-high-speed-video

There's still much work to be done, though. We discovered a couple of problems in our initial investigation into these matters, and we haven't been able to explore those issues in full. For instance, we encountered concrete evidence of a weakness of multi-GPU setups known as micro-stuttering. We believe it's a real problem, but our ability to quantify its impact has been affected by another problem: the software tool that we've been using to capture frame times, Fraps, collects its samples at a relatively early stage in the frame rendering process. Both of the major GPU makers, AMD and Nvidia, have told us that the results from Fraps don't tell the whole story—especially when it comes to multi-GPU solutions.

Happily, though, in a bit of enlightened self-interest, the folks at Nvidia have decided to enable reviewers—and eventually, perhaps, consumers—to look deeper into the question of frame rendering times and frame delivery. They have developed a new set of tools, dubbed "FCAT" for "Frame Capture and Analysis Tools," that let us measure exactly how and when each rendered frame is being delivered to the display. The result is incredible new insight into what's happening at the very end of the rendering-and-display pipeline, along with several surprising revelations about the true nature of the problems with some multi-GPU setups.

Allez lire le review au complet pour la suite

http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools

Sérieusement, allez lire tout ce review, c'est HYPER intéressant. Nvidia ont développé un tool pour mesuré le frametime et sortir une tonnes de data sur le rendu d'uin setup. Le setup ne peut vraiment avantagé Nvidia meme s'il l'ont développé eux même, ça enregistre du data qui est ensuite interprété. Du bon bon cet article !

Edited March 29, 2013 by Boulard83

Ouch, ça peut faire mal à AMD ce genre de data !

Above is an illustration of another snag we encountered with the 7970 CrossFire config in multiple games. This is a three-video frame sequence from BF3 with the FCAT overlay enabled. The expected color sequence for the overlay here is red, teal, navy, green, and aqua. What you see displayed, though, is red immediately followed by navy and then aqua. The teal and green frames aren't even runts here—they're simply not displayed at all. They're just dropped.

So what do we make of the problems of runt and dropped frames? They're troublesome for performance testing, because they get counted by benchmarking tools, helping to raise FPS averages and all the rest, but they have no tangible visual benefit to the end user.

So .... si on regarde le FPS, un CF de 7970 fait ~90fps à BF3, mais IRL, il y à plein de frame qui sont droppé par le driver/etc qu'en fait il n'y a que ~65fps qui sont affiché .... Nvidia SLI, tout beigne.

Edited March 29, 2013 by Boulard83

Ils vont améliorer leur stock ça c'est sur. Au moins ça va faire bouger les choses.

J'espère ! Sinon ma prochaine carte sera encore une Nvidia

D'autres site produisent des reviews avec le matériel de techreport. Ils sont peut-être lié entre eux mais bon, d'autres data quand même.

TK ... moi qui regardais de plus en plus les 7970 pour faire un petit CF bientôt .... je crois que ce sera une 2e 670 all the way .... Tous ces nouveaux articles avec le FRAC démontre très clairement que la technologie multiGPU de AMD est dans le champ présentement ... En plus, ça démontre que 100% des reviews actuel ne montre pas le vrai FPS obtenue puisque FRAPS et autres capte le FPS au départ de la chaine, la ou le game engine envoie la demande. Si le frame est droppé ( runt dans leurs therme ) Fraps calcul quand même ce frame la donc Fraps nous affiche peut-être 80-100fps mais nos yeux n'en verrons que disont 60 puisque plein de frame sont droppé au passage ....

TK ... amd sont mieux de travailler fort sur leur drivers.

Quand je vous parlais que HardOCP nous indique depuis un bon moment que le "feeling" du CFX vs SLI n'est pas très bon malgré le FPS plus élevé.... je crois que tous ceci le prouve.

Edited March 31, 2013 by Boulard83

Je crois qu'il vont réellement fixer leur problème sur leur prochain GPU car avec les drivers, ils peuvent seulement jouer avec la latence sur certain jeux surtout GPU limited pour rendre le gameplay plus fluide sur la souris/clavier. Si on regarde, sous skyrim/dirt3 c'est beaucoup moins pire vu qu'il y à une limitation CPU et + qu'on augmente la résolution, pire que c'est. Farcry3 semble un mauvais port mal optimiser pour PC

Nvidia à un frame metering "hardware" sur leur carte depuis le G80 (je crois) et ça leur permet de gérer quel image est bonne ou mauvaise. (de la aussi qu'ils ont la vsync adatative) Par exemple un image qui arrive trop tard dans une scène qui est très chargé (explosion) sera "dropper" automatiquement. Sur le CF de AMD, ils affichent TOUTES les FPS mais le problème est qu'il en à beaucoup qui sont inutiles, des minuscule FPS qui dure des micro seconde, ce qui cause des lag (stutter). FRAPS affiche tout les FPS, peut importe le temps qu'il dure mais ne dit en aucun cas si c'est fluide ou pas.

Pour voir les FPS inutile du CF, quand on voit les 2 bar de couleur (ex: bleu et gris) et une petite bar vert entre les 2, c'est calculer comme 1 FPS par FRAPS. S'il en à 15 de ces micro FPS dans 1 seconde, en réalité le chiffre est affiché par FRAPS est 15FPS trop élevé.

J'ai toujours remarqué ce problème la sous Nvidia lorsque tu roules un jeu physX en SLI, il faudrait bien qu'il test ça aussi. Si quelqu'un veux essayer, allez downloader Cryostasis demo, j'avais beaucoup de problème de fluidité avec mon ancien 3ways SLI GTX280 à l'époque.

AMD fond des cartes plus performante théoriquement qui coute plus cher à produire que Nvidia. Un GPU qui demande plus de jus va avoir + de couche de PCB, plus complexe à concevoir pour la disposition des vrm. Ils offre plus de performance "rough" que Nvidia, on parle de 3gb vs 2gb, + de bande passante et un GPU avec + de stock. Ça coute + cher à AMD faire des HD7970 que Nvidia faire des GTX680, et pourtant si on regarde les prix, AMD est moins cher et bien meilleur performance/prix single GPU. Nvidia ont plus travailler sur l'aspect techno de leur GPU pour sauvé du $ et rester compétitif, c'est comme ça qui fond leur $. Je suis pas mal certain que des articles comme celui ci fond pas tord à Nvidia, mais j'espère qu'il vont pas dormir sur leur laurier et utilisé cette nouvelle technique de test pour leur marketing... Pour AMD, et bien ça leur montre qu'il ont encore du chemin à faire, au moins ils sont positif en disant qu'ils vont régler le problème en été.

Bref, j'ai hâte de voir leur prochain test, GTX690 vs GTX Titan vs HD7990. On va pouvoir voir si une carte dual GPU est mieux que 2 cartes en terme de fluidité.

Un des articles les plus intéressant que j'ai vu depuis fort longtemps!

Edited April 2, 2013 by RicMX3

Yep, tu as bien raison. À mon avis aussi les GPU de ATI sont plus puissant on général mais leur difficulté est sur les drivers. Ils se sont beaucoup amélioré depuis quelques années mais on voit qu'en multi gpu ils ont encore un bout de chemin à faire. Selon AMD, il devrait nous proposer un outils dans le genre du metering de Nvidia d'ici quelques mois. Espérons que ça va régler ce genre de buzz.

Pour les articles, tu as bien raison aussi, j'ai lue sans passé en diagonal sur certains paragraphes la totalité de l'article... ce qui est rare !

Guru3D aussi vont utiliser la bebelles et pense l'intégrer à leur futurs reviews.

http://www.guru3d.com/articles_pages/fcat_benchmarking_review,1.html

Très intéressant :friends:

Non mais sérieux, c'est ben beau des reviews de x, y z mais ça reste quand même un programme créer par Nvidia pour des cartes de Nvidia. AMD and Intel aurait pu créer un programme du même genre et avantager leurs produits. Du marketing de Nvidia, c'est tout! J'y trouve vraiment rien de spécial à ce logiciel! Si ça aurait été un programme créer par une compagnie tierce qui n'a aucun lien entre Nividia, AMD et Intel, j'y croirait mais il a un sérieux manque de transparence dans ces tests!

il ny a aucune facon pour la machine qui analyse de voir si c'est du Nvidia dans la machine en test. La machine en test a un mini prog qui ajouter les wtermark sur chaque frame. Guru3d on meme dit quils ferais un test avec un prog de watermark autre juste our en etre sur mais selon eux c'est deja correct.

Je me suis gourer je crois! A moins que j'ai manqué quelque chose, j'ai comparé FRAC à FCAT. C'est bien deux programme bien distinct?

Dans ces test c'est un tool qui provient bel et bien de Nvidia, le FCAT. Je crois que ça veut dire Frame Capture Analysis Tool, dequoi du genre.

Le problème viens d'un logiciel qui calcule les performances entre NV & AMD. C'est seulement des spéculations Finalement, c'est du marketing qui a la plus grosse carte !

Ca finiras jamais la techno. Pour la qualité d'image entre (''''') que presque personne qui vois la différence !