Reprise du message précédent :
J'ai commencé le refactoring, ca avance pas mal. Y a du taff, mais bon, vous avez l'habitude
 
J'ai pas encore touché à GPU:3D car je sais que ca sera un vaste chantier... à voir.
 
OCCT dépendra désormais du framework 4. Faudra l'installer si ce n'est pas déjà fait sur les 7. Windows 8 et 10 l'ont par défaut.

proposes le framework  si pas present pour eviter les soucis

Comme j'ai fait pour le framework précédent oui

Je ne sais pas si je suis le seul, mais lorsque mon lecteur de cartes mémoires est connecté, la dernière version officielle d'OCCT se plaint que certains lecteurs sont vides, ce qui n'est pas faux en soit mais l'ancienne version ne le faisait pas, et surtout, il insiste toutes les quelques secondes. Résultat, je dois débrancher mon lecteur de cartes... balot, quoi !

Ce ne serait pas le monitoring par hasard ? Tente de le désactiver pour voir.

Est-ce que la 4.4.2 est plus récente que la 4.4.2 b02 ?
Je demande car quand je lance la beta il me demande de charger la non beta.

C'est probablement le monitoring oui... je remonte le problème.
 
La build stable est toujours considérée comme plus récente que la dernière beta de la même branche La build beta est la 4.4.2.2, la stable est la 4.4.2.99 (marquant la fin de la branche 4.4.2).

Je viens d'avoir une idée lumineuse pour GPU:3D... Ca pourrait le faire, et rendrait le test bien plus utile que maintenant

calculs de belles fractales ? ^^

Le teasing c'est mal.
 
Fait péter les infos.  

Je veux voir si ca marche d'abord

comparaison calculs cpu et gpu comme test d'erreurs ?

Il y en a qui s'y connaissent en CPU/SOC AMD dans le coin ?
J'ai fait un test sur un SOC gx-424cc (un truc pas très connu ) et ce qui est bizarre c'est que la fréquence oscille dès le début, que j'ai pas de véritable throttle et que j'ai une erreur au bout d'un moment...
 

c'est dû à quoi à votre avis ? problème de tension ? (bios limité, impossible d'y toucher...)
AMD annonce 90°C max, normalement il devrait pas y avoir du throttle plus important comme sur les CPU intel pour maintenir à 90°C, non ? je connais pas le fonctionnement des cpu amd, toujours eu des intel...
(pour la température, sur le graph ci-dessus c'est environ 90°C mais j'ai refait d'autres tests après où ça monte à 95°C (pas les tests sur moi actu, je posterai plus tard)

edit 2 : je viens de faire un test extreme : sans ventirad... Du coup la température est vraiment monté et le maxi c'est 98°C pour que ça throttle... bon après même avec un throttle au maxi (donc fréquence en dessous de 1000MHz, la température continuait d'augmenter pour dépasser les 100°C j'ai pas osé continuer par peur de faire claquer quelque chose même si à priori, maintenant, il y a des sécurité qui empeche cela (surement 105°C ?)
Bref, amd qui annonce que le maxi c'est 90°C... ça fait pas très sérieux d'annoncer quelque chose de faux au moins avec intel on sait exactement la température optimal, de throttle, et de sécurité...
reste donc ce soucis de "throttle" au début même quand le SOC est froid...  
edit 3 : le test de la mort :
 
110°C et toujours pas de coupure  

1er période à 98°C où sa throttle vraiment et ensuite une 2eme à 100°C pendant quelques secondes c'est stable... puis ça remonte mais on retrouve encore ce zigzag entre 2.4 et 2.2GHz au début et à la fin même quand c'est froid...

normal les chips sont fait pour tourner  a 125c

125°C ?  
si tu le dis... je m'y risquerai pas en tout cas, déjà qu'à 110°C ça commençait à sentir le brûlé quand j'ai reposé le rad...
 
Sinon j'ai fait encore plein de test, avec une ou deux barrette, sans carte wifi, en changeant l'alim, en trifouillant le bios et toujours pareil...  
Du coup je crois qu'il faut se résigner au fait que c'est le comportement normal de cette puce (ou qu'il y a un soucis avec la carte mère mais comme c'est du soudé, on le saura peut être jamais )

le brûlé vient ptet des trucs en plastique/vernis  autour ^^

Occt sans rad, le bourin

Les rad sont tellement performants, j'arrivais pas à voir la température max avant throttle, fallait bien faire quelque chose
et puis bon maintenant il y a des sécurités, pas comme à l'époque, pour pas griller les puces...

+1  

Grosse update du test CPU:OCCT pour la prochaine béta

Une fois CPU:OCCT fait, je travaillerais sur GPU:3D. Probablement avec une release DirectX11 du coup.

Je suis assez surpris du nombre de posts sur la cat'. L'overclocking est vraiment passé de mode, vache

Cad que le %tage d'o/c est de moins en moins grand (genre un 4790K t'as un Turbo de 4,4GHz, tu peux espérer 4,8GHz easy, 5GHz en en chiant et 5,2GHz le vends dans le dos avec 2x le TDP et jamais vraiment stable ) et en plus moins utile vu la marge des CPU sur les softs.

Et c'est surtout que les cpu sont bloqués si ce ne sont pas des K....
Du coup oui c'est passé de mode.
 
Tout a bien changé, ça c'est complexifié, et de toute façon tout à bougé...  
A une époque tu posais une question t'avais une réponse dans la journée, maintenant nombreuses sont mes questions sans réponse et je me suis démerdé seul.
 
Idem sur les topics uniques à une époque il y en avait des tonnes, maintenant...
Et tous les topics uniques que je créais tournent à vide.
 
Clairement HFR a quand même bien changé.

Les temps ont changés, les gens aussi. A une époque je passais beaucoup de temps sur HFR, je répondais un max quand je savais répondre... aujourd'hui, j'ai "passé la main" à la nouvelle génération si on peut dire.
 
Pourtant, OCCT a toujours son intérêt, même sans OC. Il m'a plus dépanné sur du matos stock que sur de l'OC (où là, si ça tenait pas, c'était ma faute).

Disons qu'arrivé à un age, tu prefères la machine qui tourne point barre, et voilà donc tu te fait pas chier.
 
Et comme les gens sont des assistés quasi incompétent en informatique (ils sont plus axé mobile/tablette). Du coup oui y'a quand même pas forcement de jeune pour reprendre la relève.
 
Puis c'est quand même moins fun que de manipulé des cavalier pour changer le multi.

pareil  
 
et puis je trouve que la segmentation a changé aussi :  
de tout temps les question/réponses se sont organisé de facto selon un schéma que j’appelle "les cercles des enfers" => chacun répond aux questions qu'il maitrise, mais d'un niveau a peine en dessous du sien,  
. les gens prennent pas le temps de répondre aux problèmes qui sont trop basique pour eux.  
 
bilan "la science" se diffuse de proche en proche, d'une poignées de gourous ultra pointu jusqu’à la masse de noob a travers les diverses strates de compétences
 
le problème c'est qu'avant le nombre de gens dans chaque strate formais une belle pyramide  
aujourdhui ca forme plus une "bulle" de bon/très bon qui se gèrent entre eux et une masse de noob qui se regardent le nombril en échangeant des contres vérité , j'ai l'impression que l'amateur éclairé, le mec qui connais bien sans etre un pro existe plus pour moi, t'as plus que des "kissikinnais" ( noob plus plus quoi )

 
En fait c'est une opportunité pour OCCT de supporter les nouveaux modes de variations de tension et fréquences des cpu récents.
Ca serait vraiment sympa que tu implémentes ce que je t'avais proposé, à savoir un test qui change le nombre de cores chargé dans le temps.
Ca permet de bien tester ces variations des modes basses consommations (offset, states C6 tout ça tout ca).
Idem pour directx 11: Fais des charges viariables, ça permet de tester les états P states différents et trouver potetiellement plus de bug que si tu charges à fond les manivelles.
 
Donc ça serait bien x secondes 1 core (medium data), puis x secondes test cache (small data), puis x secondes test mémoire (large data) ainsi de suite avec + ou - de cores et +/- de mémoire.

À mon sens c'est surtout qu'on peut plus du tout se faire un cpu à 1000€ en partant d'une bouse à 75€, vu qu'ils ont tous un nombre de core et un cache différent... Du coup on peut plus faire son riche en étant pauvre

lol
Mais dans le fond, assez juste ^^

 
Le problème de ça, c'est que je me retaperais une phase d'initialisation, qui consomme du temps CPU, et qui donc fausserait le test.
 
Il faudrait alors que je lance plusieurs tests en //, et que je les débloque/rebloque, ce qui est pas si facile à faire
 
Mais y a de l'idée effectivement.
 
Pour le GPU par contre, c'est ce que je souhaite faire, même si cela ne sera pas facile du tout : réussir à permettre à l'utilisateur de charger le CPU et le GPU comme il le souhaite. En gros, pouvoir jauger de manière simple le temps passé sur le CPU entre deux frames. Le problème est le buffering inhérent à Direct3d, et c'est bien ce qui m'empêchera d'être très précis.

pour le gpu ça n'ira pas à mon avis sur les r9 290. Quand le cpu est chargé le gpu est à la ramasse car il ne reçoit pas les commandes à temps directx depuis el cpu.

Le CPU ne sera pas chargé dans un premier temps, il limitera en FPS.
 
L'idée est de définir un truc genre "je veux 30 fps", que tu peux modifier. Le CPU fera des pauses entre chaque frame, te permettant de limiter de manière software l'utilisation de ton GPU.
 
Après, je vais me heurter au système de buffering D3D pour être précis, mais ca...
 
La seconde étape sera de charger le CPU pendant ces intervalles. Mais c'est une seconde étape

Je veux rien dire hein. Mais au lieu de te faire braire avec des API pas fait pour ça (et pour lesquels les pilotes graphiques se permettent toutes sortes de choses), t'irai sans doute plus vite à fait du DX12/Vulkan pour ça
 
Après même en OpenGL t'as des extensions proprio pour faire du pseudo Vsync. Et en DX11 au pire un Vsync @ x Hz devrais le faire

 
Le VSync te permet de te bloquer au taux de rafraichissement de ton moniteur. Moi, c'est pas ce que je veux faire. Je peux pas 60 fps, je peux 22, ou 28 , ou 121...
 
Ensuite, comme d'hab, tu proposes des technologies récentes, mais qui, en dehors de l'amour de l'art, ne sont ni répandues, ni éprouvées, et donc ciblent trop peu de personnes.

pq pas lire les infos power de la sonde gpu et faire varier le framerate pour charger a x % ?

Parce que je n'ai pas cette infos sur toutes les cartes, qu'elle n'est pas très fiable ni très synchro avec ce que j'en fais
 
Le mieux est d'estimer les fps max que la carte est capable de cracher, et ensuite d'introduire un sleep avec une bonne vieille règle de 3.
 
Je veux essayer d'estimer le temps de calcul GPU d'une frame (ce qui va me faire me heurter aux optimisations), et baser mon calcul dessus.
 
Genre sur une seconde, je veux un GPU à 100%. Si une frame mets 0.1s à être calculée, je fais du 10 FPS max, donc pour un GPU à 50%, faut que je fasse 0.1s CPU entre chaque frame. Bref, ce genre de calcul.

et si tu as acces a la vitesse du ventilo sur toute les cartes, tu seras si tu es en espagne ou en norvege ;-)

Et pour les CG sous eau
 

Bien le bonjour,
 
Je tente d'oc mon i5 4690k, et je ne sais pas si c'est normal mais deux choses :
 
D'une j'ai remarqué que les tensions données par OCCT pour le 5v, 12v, etc ... sont fantaisistes, le 3v est à 2, le 12v a ... 0.05  , il n'y a que le vcore qui est normal.
 
Surtout un petit test de 10 min donne ça, sur les 4 cores c'est pareil, ca fait des paliers :
 

 
Et ça suit la RAM usage
 

 
C'est OCCT qui fonctionne comme prévu ou pas