Reprise du message précédent :

 
En gros, tu le sais en regardant la fréquence via un autre outil qu'occt (histoire d'être sur) et de la voir être inférieure à la normale en mode 3d.

D'ailleurs, GPU-Z est bien capable de détecter cette baisse de fréquence ? Quelqu'un l'a déjà vu de ses propres yeux ?

Le throttle sur les CPU c'est pas une baisse de frequence, c'est la puce qui se met en "veille" pendant certain cycle, ça peu être pareil sur les GPU. Et là je crois que sur les CPU c'est calculer avec les compteur de perf. Mais là en GPU si y'a pas d'info bas niveau de remonté, c'est pas possible je pense.

C'était p'tet le genre de questions à se poser avant de se lancer à faire tous nos tests : si l'on est pas capable de voir que notre GPU a dépassé la "limite" et throttle, tout ce qu'on fait ne sert à rien

edit:

Article complet : http://www.geeks3d.com/20120425/ge [...] -tdp-apps/

edit2: avec une HD6950 sous Furmark

Mwarf
Simpliste au possible !

Ouai, donc dans GPU-Z on voit quand même le throttle sous AMD...
 
Quelqu'un peut confirmer ?

Bon, je vais prendre une GTX670, je vais investir les dons, j'espère qu'elle va throttler comme une grande Le blem, c'est que je suis un ayatollah du silence, donc je vais prendre l'asus DirectCUII (pas version top, ca me permettra de la bidouiller seul), et c'est pas le design de référence, qui lui throttle bien.

On va voir.

Il est temps de renouveler mes GTX285...

Sur GPU-Z, je ne voit pas le GPU throttler, comme je l'ai dit, la fréquence reste au max    
Pourtant, il throttle bien comme il faut sous OCCT:GPU3D

 
Et comment tu sais qu'il throttle comme un grand ? C'est bien ça la question
 
Enfin, avec des mesures, si il throttle, je m'en apercevrais.

J'ai deux indicateurs les fps affichés et le courant envoyé par l'étage d'alim.
En gros quand je met +20% au PowerTune j'ai plus de fps et de courant envoyé au GPU.
Et inversement si je baisse PowerTune.
 
Donc j'en déduis que le GPU throttle.
 
Je ferai un petit screen de tout ça ce soir.

 
Avec grand plaisir

Pour illustrer le problème que je rencontre actuellement, et que j'aimerai résoudre avant d'arriver à un algorithme "adaptatif".

Voici un graphique montrant les fps (axe des ordonnées) en fonction de la charge CPU à chaque frame (axe des abscisses) :

Je m'attendais à un truc linéaire, c'est tout sauf linéaire.

que signifie la valeur CPU en ms en abscisse ?

C'est simple : je décompose chaque frame en deux parties : TAFF CPU, TAFF GPU. la valeur en ms est le temps passé, à chaque frame, sur le CPU.

Si chaque frame comporte 100ms de taff CPU, j'ai 9 frame calculées et affichées par le GPU en une seconde. En gros, 9fps quoi. C'est absolument normal. Car le GPU prends un peu de temps (4ms), donc j'arrive à 9*100ms (CPU) + 9*4ms (GPU) = 936ms. Sit 9 frame en une seconde. Donc 9 FPS.

Si chaque frame comporte 25ms de taff CPU, j'ai 36fps. Et ainsi de suite.

Voici les données brutes :
CPU / FPS
0ms/160fps
5ms/134fps
10ms/80fps
15ms/57fps
25ms/40fps
40ms/23fps
50ms/19fps
75ms/12fps
100ms/9fps

Ce que je ne comprends pas (je vais vous faire un peu de maths).

Prenons le cas taff CPU = 5ms a chaque frame. J'ai 134 fps. Si je reprends mon équation d'avant : 134*5 (CPU) + 134 * GPU = 1000. Ici, chaque frame prends 2,4ms de GPU.

Prenons le cas taff CPU = 10ms à chaque frame. 80 fps. Equation idem : 80*10 + 80*GPU = 1000. On arrive ici à 2,5ms GPU. C'est cohérent.

Prenons maintenant 40ms, j'ai 23 fps. Même calcul, j'arrive à 3,4ms GPU. la marge d'erreur étant plus grande, ca ne me choque pas.

Ce qui m'ennuie, c'est ça : Si une frame prends 2,5ms GPU, en théorie, je devrais avoir 400 fps à fond les ballons. Hé ben non, j'en ai 160 à fond les ballons.

Du coup, je ne peux pas déduire la valeur maximale à partir d'une valeur "bridée".

DOnc je ne peux pas dire "10% CPU" ou "80% CPU", car je ne sais pas comment répartir le tout.

En soi, 10 % CPU, c'est 100ms sur le CPU chaque seconde. C'est assez facile. Le blem est de "répartir" ça à chaque frame, ce manière égale.

Comme je sais pas combien de frame je vais avoir, je ne peux pas répartir les 100ms.

Du coup, je cherche un moyen. Je peux partir sur 10ms de taff CPU par frame au début, et m'adapter à la volée, mais j'aurai aimé éviter ça.

Vous avez une idée ?

Prenons le cas "target : 25% CPU", aka 250ms CPU / seconde.

Le truc que je me dis, c'est de toujours partir à 10ms de taff CPU. Je tourne 1 seconde. Ca permet de tourner à la moitié de la puissance. Pas de throttle à ce point. J'ai 80 fps. Ca me fait 800ms sur le CPU, bien trop.

Je descend donc à 5msec ensuite. J'ai 134fps. Ca me fait 134*5 = 670ms sur le CPU.

Et voilà un autre problème : je passe 67% du temps à faire taffer le CPU, et j'ai perdu 17% des frame par rapport à un run "à fond".

C'est quand même con.

Si je mets ça tel quel, le mec va simuler un taff CPU à 66%, et va voir une baisse des frames de 17%. C'est pas linéaire, il va se dire "c'est de la couille" !

Et mon algorithme ne peut pas se baser sur les 180fps, car il ne sait pas trouver cette valeur ! Tourner 1s à fond va faire throttler.

Je crois que je vais devoir me résoudre à mettre un % d'utilisation CPU, non linéaire, et ca m'ennuie.

Ajoute à ça les optimisations MT des driver en DX10/11 + le nombre de core variable (avec ou sans HT) de nos CPU qui encaisseront +/- bien l'augmentation de la charge CPU, ça devient un véritable casse-tête
Au fait, ça c'est ton nouveau système ou celui de la beta2 ? Tu sais d'où venait l'activation de la synchro verticale lorsqu'on activait le limiteur de fps ?

Dans l'équation ne faudrait-il pas le temps CPU utilisé par le pilote et/ou le temps de transfert PCIe...
 
I.e. p'tet qu'à un moment on est limité par le PCIe
 

 
C'est le nouveau système.
 
En b02, je pense que ce sont plus mes timers qui ne sont pas assez précis pour permettre une gestion grain fin, plutôt qu'un vsync.
 
En b02, je fais très simple : Si tu mets 100 fps, ca veut dire une frame toutes les 10ms, donc je bloque au début jusqu'à 10ms, et j'envoie la frame.
 
Je me demande si ca ne revient pas au même que tout mon casse tête précédent, pour finir. Et si ce serait pas plus intelligent de rester sur ce système. Amélioré bien sur.

 
J'estime ça comment ?
 
Faut rester simple pour que ca marche. Je mesure le temps de "faux taff CPU" que je rajoute, et le reste est considéré comme GPU (algo "normal" ).

Exact certains timer ont une résolution de 16ms (donc 60Hz maxi) d'où nos framerates qui étaient des fractions de 60fps

En utilisant un timer précis à la ms (timeGetTime+timeBeginPeriod ou un timer haute-résolution, en tout cas autre chose que ceux dispo dans le Framework .Net) ça devrait suffire pour le souci de la b02.

La b02 utilise déjà timegettime... même si j'ai pas forcé via le timebeginperiod). Je viens d'implémenter un timer à base de QueryPerformanceCounter, qui pose souci sur certains vieux athlons X2, mais est bien plus précis (en dessous de la ms).

Je risque de faire une nouvelle release avec le queryperformancecounter et le truc amélioré.

Le problème du frame limiter est le suivant :

Vous avez un GPU X, capable de délivrer 300 fps si il ne throttle pas. Si il throttle, il délivre 150 fps.

Le throttle arrive à partir de 250 fps.

L'utilisateur va lancer le test à fond, va voir 150 fps. Il va donc limiter à 150fps, et moins. Il va pas limiter à 250 fps (par exemple).

C'est con, hein ?

D'ailleurs, si il met le limiter à 150fps, il verra bien 150fps, et son GPU ne partira pas en throttle. C'est con

Pour le timeGetTime, la résolution par défaut n'est justement pas d'1ms mais de 16 (en théorie, entre 10 et 16 selon les machines) d'où la nécessité du timeBeginPeriod pour le fixer à 1ms.
Mais effectivement le QueryPerformanceCounter est encore plus précis

Yep. Le souci du limiteur de fps, c'est qu'il va falloir avoir l'intelligence de limiter les GPU throttler à un taux de fps supérieur à celui quand c'est débridé. C'est pas intuitif du tout, ca m'énerve.

En plus la vrai question est de savoir si le test est encore efficace à la limite du throttle

Etant donné que le framerate est assez stable, tu pourrais presque automatiser la chose A terme il faudra bien je pense.
Au fait c'était quoi le problème du queryPerformanceCounter sur les AX2. De souvenir dans CSMT, j'avais eu quelques soucis mais résolu en faisant appel toujours sur le même core, sinon les résultats étaient incohérents.

C'est là qu'il devrait l'être le plus, non ? En tout cas, plus que si le GPU throttle

Oh punaise je connais bien ce bug!!!!! Les coeurs qui n'ont pas d'horloge synchronisés!!!
(du coup l'enchainement des éléments ne se fait pas dans l'ordre...)
 
Y a un moyen de contourner ça (mais ça demande à l'utilisateur de modifier le boot.ini )! Et normalement ce n'était valable que pour xp/2003. Par la suite ce fut normalement corrigé.

Bah au final, que le GPU throttle ou qu'on ne lui envoi pas de boulot le résultat est le même, l'ALU n'est pas en fonctionnement 100% du temps, du coup pour moi on ne fait rien à pas consommer du courant, car la stabilité de l'ALU elle est tout faut testée efficacement en fait ...
 
Et je passe outre le fait qu'on ne valide essentiellement que les ALU.

 
Tu forces l'affinité du thread sur 1 coeur. Sinon, suivant le bon vouloir du scheduler, tu auras le counter du core 0 ou du core 1, qui n'était pas synchronisé sur les X2.
 
En gros, tu avait deux horloges séparées et tu savais pas sur laquelle tu pouvais tomber
 

 
C'est exactement ce que je veux vérifier. Ce serait drôle que si tu throttles tu sois à 150fps, et si tu limites à 220 fps, tu ne sois pas en throttle
 
C'est quasi -impossible à présenter de manière intuitive, par contre

C'était pas a corrigé ce bug que servais l'AMD Dual-Core Optimizer ?

Si. Mais il y a aussi la soluce de forcer le thread sur un seul core.

Vu ce que fait le CPU dans GPU:3D, ca devrait pas avoir d'impact.

La nouvelle version de GPU:3D qui devrait sortir bientôt a un limiteur BIEN plus efficace.
 
Je viens de tester, j'ai demandé 11 fps, je suis à 10.9997 fps
 
Ca devrait le faire.

ça commence à être pas mal  

A noter que la HD3000 de mon portable envoie 20fps sous GPU:3D

Le début des emmerdes  

Meuh non

Ce logiciel justement faisait la manip du boot.init en rajoutant l'option "/use pmtimer"!
 
 
J'ai pu profiter de ce super bug récemment. Je fus grandement ravi!
J'ai passé un temps fou à comprendre d'où provenait le pb sur mes vm!  

Pas de release avant ce soir pour que je puisse vérifier sur mes GTX285 ce que ca donne en pratique sur une vrai carte 3d

Le limiteur permet d'envoyer des frames à intervalles très réguliers (en pratique, une frame tous les X ms, la précision descend sous la ms bien entendu), et ca m'a l'air super précis.

Oui enfin il y a une grosse différence entre 90% sous OCCT et un throttling à 50%. Ca restera supérieur aux jeux, donc testé de manière relativement efficace. Ou alors il faut faire sauter la protection mais est-ce raisonnable ?

Va pas le cramer ton portable, c'est fragile ces bêtes là

 
Ca permettra aussi qu'on arrête de m'appeler power virus, vu que tu peux régler la violence du test. Les gens qui veulent e^tre stable "in game" castreront GPU:3D, et voilà.
 
Ca m'ennuie d'en arriver là.
 

 
C'est bien pour ça que je viens d'arrêter

J'ai pas tout suivi le débat sur le FPS Limiter, grosso modo ça va servir à quoi ? Ah ne pas trop pousser le test ?

A deux choses :

• Controler le test en termes de charge
• Identifier si ta carte throttle ou pas, et essayer d'aller à la limite

Donc va faloir allez petit à petit vers des FPS de plus en plus haut jusqu'à ce que ça throttle ?
 
Je pensais que tu trouverais un truc auto
 
Genre ca fait un test tout seul à 5fps pendant 10min, si ça thottle pas à 10fps 10min, etc etc... jusqu'à voir à quel fps ça throttle, puis redescendre un crant en dessous, et monter 1 par 1, jusqu'à throttle, puis -1
 
Tu check toute les 5sec si la fréquence T est égale à Freq. Constructeur / 2, à +/- 5%, si oui ça throttle, sinon non.