Reprise du message précédent :

 
C'est pas juste la température, ca peut être le courant demandé au GPU...
 
Et surtout, je n'ai aucun moyen de connaitre la valeur à ne pas dépasser. Je sais juste quand je la dépasse, parfois, via la fréquence GPU

IWH 800  

OCCT PT 4.2.1.b02 OUT !
 
Changelog :

• Added tabs to system information
• No "non valid" frequency will appear anymore
• Various bugfixes around system information

Enjoy !
http://www.ocbase.com/download.php?fileext=beta

Juste par curiosité, OCCT GPU se situe comment par rapport à Kombustor (en mode eXtrem Burner) ?
 

 
Kombustor est un branding de furmark, et GPU:3D propose moins de feature 3d (test épuré), mais est devant en termes d'efficacité.

D'ailleurs, le "software limiter" de GPU:3D est bien plus complexe qu'il n'y parait. Je sais pas trop comment je vais m'en sortir, algorithmiquement parlant, c'est pas simple, car je ne peux pas me baser sur la durée de calcul d'une frame du tout, vu que cette durée n'est pas une donnée de référence (ca dépend si le GPU est bridé, ou non).
 
Il va donc falloir que je fasse un load CPU que l'on règle. Si 50% du temps de GPU:3D est passé sur le CPU, le GPU sera effectivement à 50% de ses capacités.
 
Reste que pour répartir de manière homogène ce temps CPU, ca va pas être simple DU TOUT. Enfin bon, je vais y réfléchir, comme souvent, en codant je vais avoir une idée

Et par rapport à la fréquence du gpu c'est pas possible?  
 
Normalement d'ailleurs tu dois avoir accès à tous les modes du gpu, donc dès que tu le vois tomber à la fréquence du throttle c'est que c'est trop. non?

 
Ca serait pas plus rapide de demande a NVIDIA si y'a pas une backdoor dans leur pilote pour qu'une appli. contrôle le frame limiter du pilote ?
 
Après je sais pas si ATI a un frame limiter...

La détection de la fréquence GPU n'est pas encore assez bonne pour ça Ce serait la solution oui !

Oh que si. Nvidia et AMD en ont un, et c'est pas dans les pilotes. Quand tu demandes trop au GPU, fréquence /2, et le tout codé en dur, et basta GPU:3D et furmark

C'est ce qui fait que OCCT fait quasi jeu égal avec métro 2033 vu les throttle...

http://www.anandtech.com/show/5818 [...] at-evga/17

La détection de la fréquence du gpu ne marche pas en charge alors?
 
Et par rapport au nombre de FPS? Je suppose qu'ils doivent plonger à moment donné non?

Hier je teste la 4.2 n'ayant pas testé d'OCCT depuis un moment, je lance OCCT GPU, shaders 8 comme conseillé pour les AMD par l'infobulle, start.
3 secondes de burn, driver restart en boucle sans pouvoir rien faire qui fini par un reset.
 
Je tiens parfaitement et longtemps Furmark extreme, 3DM, les jeux, etc...
Avant que je ressaie y'a un problème ? (HD6950)

 
Si, mais pas pour tous.
 
Oui, dans un algorithme automatique, mais cela risque de prendre du temps à trouver la bonne valeur.
 
J'ai demandé à Damien (le gourou carte graphique HFR) si il sait si les protections sont instantanées, ou si j'ai une marge, même de quelques frames, pour travailler.
 
Imagine que j'ai 5 frames qui passent à plein régime avant d'être bridé. Je calcule le temps de la 4ème (pour une raison inhérente à DX10, je ne peux avoir celui des 3 premières). Ca me donne le temps de calcul d'une frame à pleine puissance ( 100 ms, par exemple, si le truc tourne à 10 fps). Si je veux un load GPU à 50%, il me suffit de simuler un load CPU pendant 100ms entre chaque frame.
 
Ca fera une charge en pic certes, mais n'oubliez pas qu'en pratique ca se passe à peu près pareil.
 
Si j'ai pas ce temps, je suis baisé pour calculer la répartition du temps de sleep CPU entre chaque frame, qui sera jamais égale. Car le framerate bouge avec la protection qui s'active, ou pas. Je risque même des scénarios du style "je déclenche la protec, puis je la déclenche plus, etc".

Essaye en Shader 7, sur le site y a une news comme quoi les AMD n'aiment pas les shaders 8, trop long pour elles

Mais sois pas étonné si tu tiens pas OCCT et que tu tiens furmark, GPU:3D est le top de la violence

Change l'infobulles alors ^^

 
Exact, ca fait partie de la TODO

En directx, il n'y a pas moyen d'augmenter progressivement le nombre de FPS? C'est ce que tu cherchais à faire c'est ça?
 
Non parce s'il existait une fonction miracle tu pouvais aussi faire l'inverse, monter progressivement le nombre de fps avant de le plafonner quand t'as passé la limite.  Maintenant je suppose que si c'était aussi simple tu l'aurais déjà fait.

 
je croyais que c'était que pour le cross ?

 
J'en suis pas certain justement

 
Tu controles la durée de ta boucle de rendering. Une boucle de rendering = une frame.
 
Alors oui, dis comme ça, c'est facile, mais tu sais comment que tu as passé la limite ? T'as pas la fréquence, tu ne sais ptêt même pas si tu es limité dés le départ
 
Une solution serait de démarrer effectivement en douceur, style commencer à 10 fps pour ne pas toucher au limiter, avec de belles grosses pauses CPU arbitraires de 150ms par exemple, et d'utiliser ce temps. Enfin, j'en saurais plus après avoir eu la réponse de damien

 
bon perso c'est toujours passé pour du single (5870/6950/7870) mais pas sur mon cross de 6870...
oui oui j'ai pas mal fais d'achat/vente de CG dernièrement
c'était pour aider le iench à dev OCCT

Voilà c'est ce que je voulais dire, commencer tout pourri au début et monter progressivement.

 
Ok j'essaie cet aprem et je feedback, parce que tout de même je sais qu'il est plus violent mais 3 secondes

Je parlais du vrai frame limiter de NVIDIA où l'utilisateur cible au FPS prêt la framerate maximum.

 
Solution spécifique, planquée dans les pilotes... je voudrais l'exposer dans l'interface. Mais l'idée est là, oui.

Pour les 800 pages, je demande un OCCT avec la couleur de son choix !
 
Y'en à "ra la casquette du rouge" !

Malheureusement, cela ne risque pas de changer dans l'immédiat !

C'est mon identité, ce rouge

Je viens de voir la news sur OCBase, petit détail chez moi il ne s'agit pas de fullscreen mais de win 1024x768 !

 
Essaye en fullscreen donc, j'ai déjà eu des emails relatant des problèmes entre aero + GPU:3D windowed sur certaines AMD.

 
J'habite à 30 bornes d'hénin-beaumont, OCCT y aurait attiré mélenchon ?

Azy hack-le
On vendra des cracks couleur à seulement 5.99€
 

 
Je vais te faire une session de tests full/win oc/pas-oc shaders7/shaders8, combien je dois compter de temps minimum pour dire "pas de bug" hors instabilité hardware ?

Ben si tu me dis que tu as le pilote qui reboote en boucle

Pour moi, sans parler d'erreurs mais juste de "ca marche", 1 minute suffit pour voir. Après, si on parle de stabilité matérielle, il y a un souci

Dis-toi que l'algorithme derrière est identique frame après frame, et que si ca plante au bout de 5 ou 6 secondes, il y a surement une cause matérielle derrière. En burn, il n'y a qu'une rotation d'un modèle à chaque frame (i.e. une variable incrémentée). En détection d'erreurs, toutes les 5 secondes j'exécute une routine particulière pour compter les erreurs sur une texture. Si ton pilote tient une petite période puis crashe en burn, soit il a un problème, soit ta carte a un souci.

Mon smiley utilisé

Surtout utile pour le joueur, mais le développeur peut très bien le gérer lui-même sans devoir dépendre d'une obscure fonctionnalité liée à un fabricant et dispo que sur certains driver.

tiens au fait iench, dans la 4.2.0 en test GPU j'ai bien "GPU core" en face de la t°, alors que sur al 4.2.1.b01 ou b02 c'est juste marqué "TMPINO2"

Tetedeiench> J'ai les onglets GPU:3D, Opwer Supply et GPU grisés. Pour ce dernier, j'imagine qu'il n'est pas reconnu par le moteur de détection. Mais pour les 2 autres ? Même raison ? Si oui, c'est p'tet un peu sévère, non ? Ca doit être rarissime les machines sans accélération 3D, et si c'est le cas ça doit pouvoir se détecter à l’exécution (à l'initialisation du device 3D).
J'ai une HD5450, driver récent installé, Win7 64bit SP1

edit: idem avec les versions 4.2.0, 4.1.0 et 4.0.0

edit2: c'est finalement OCCT 3.1 qui m'a donné la réponse :

CPUZ 1.60

edit3: après un coup de dxwebsetup, les 2 onglets sont bien accessibles
Du coup GPU:3D ne fonctionne pas sur un Win7 SP1 out-of-the-box

Whadda fuck

GPU:3D DirectX10
 
 
Vérification d'erreurs activée
Go...
 
Test  1. 960/1440 fullscreen 1792x1344 shaders8 OK 600sec
Test  2. 960/1440 windowed 1024x768  shaders8 FAIL Freeze à 41.9sec puis écran noir; reset
Test  3. 960/1440 fullscreen 1792x1344 shaders7 FAIL Freeze à 61 ou 91sec puis driver restart en boucle; reset
Test  4. 960/1440 windowed 1024x768  shaders7 FAIL Freeze à 88.2sec puis driver restart; reset sans attendre
Test  5. 800/1250 fullscreen 1792x1344 shaders8 OK 600sec
Test  6. 800/1250 windowed 1024x768  shaders8 OK 600sec
Test  7. 800/1250 fullscreen 1792x1344 shaders7 OK 600sec
Test  8. 800/1250 windowed 1024x768  shaders7 OK 600sec
 
Dans tout les cas aucune erreur n'est détectée.
Ah, ça devient bizarre, j'aime ça .
 
Test  9. 960/1440 fullscreen 1024x768  shaders8 FAIL Freeze à 28.5sec puis retour bureau et freeze final; reset
Test 10. 800/1250 fullscreen 1024x768  shaders8 OK 600sec
 
Bon alors là j'me dis, d'une j'ai pas reproduit le bug du driver restart direct, mais mon OC pue malgrés que le test 1 soit passé, donc:
 
Test 11. 960/1440 fullscreen 1024x768 shaders8 FAIL Freeze à 25.4sec puis écran noir avec curseur fixe; reset
 
Je me goure et n'ai pas remis 1792x1344 bon..
 
Test 12. 960/1440 fullscreen 1792x1344 shaders8 FAIL Tout pleins d'erreurs à 630+sec
 
Je crois que je vais m'arrêter là pour le moment
 
 
Infos supp:
HD6950 MSI 2Go 1536 shaders
Windows 7 Ult x64
Catalyst 12.4
Powertune: +20%
800/1250: 1.1V (stock) 960/1440: 1.2V
Temps max: 71°c (GPU), 75°c (Shaders), 73°c (VRM) pour 27/28°c dans la pièce .

pour ma part c'est le "blend" de prime95 qui plante à 20 minutes quand OCCT "large" est stable 3h

fait un OCCT "Small Data Set" d'une heure. Ça revient à faire un Prime95 sur les cache CPU, durant 15 minutes (AMD) à 30 minutes (intel)