Reprise du message précédent :
Vu le Vcore je dirais que ça manque un poil de jus.

si le proco est en CPU critique ca voudrait pas dire que ca chauffe de trop et au contraire il faudrait descendre le Vcore

je vais tester a 1.35V voir si cela fait pareil
par contre un E4400 ca peut prendre combien de temp avant de le cramer ?
avec linpack ça chauffe sévère, on m'a dis de faire gaffe a l'étage d'alim de la mobo, ca risque de la cramée a force de bencher

 
Ah merci, il me semblais bien l'avoir déjà fait

Bon, je rassemble des infos sur la technique de bridage des cartes Nvidia, je vais taffer dessus dés que j'ai un peu de temps. Une idée lumineuse m'est venue à l'esprit, ca pourrait être drôle Merci damien

De manière tout à fait perso, je m'interroge de plus sur la légalité de la chose, car :

• On te vends une carte compatible Direct3d
• On t'annonce des performances (capacité de calcul, etc)
• quand tu t'approches de l'optimal de ces capacités de calcul, on te bride, alors que ton programme est Direct3d "standard".

Alors que ton programme est complètement dans la norme supportée par la grande entreprise, on te bride.

Cela signifie pour le consommateur qu'il achète une carte dont il ne pourra jamais utiliser les pleines capacités vantées sur la boiboite.

Publicité mensongère ? je sais pas trop.

Moralement, ca me choque, personnellement. Et vous ?

 
Un nom de processus aléatoire?

C'est exactement ce que j'ai dis plus haut.

Nan, mais je dis pas ce que c'est avant de tester le bazar histoire que ca soit pas bloqué avant même d'être dispo

ça marche. Cela dit le nom de processus aléatoire c'est imparable ça.  
(ou tu inclues une liste de nom de processus de jeux existant ou de benchmark  et tu puises aléatoirement dedans)
 
De toute façon ils seront bien obligé de laisser passer un nom de processus particulier qui ne bride pas sinon ils ne pourront pas valider leur score de celui qui a la plus de grosse archi qui ne fonctionne que sur un seul benchmark et bridé pour les autres tests pour pas que ça sur consomme...    
 

Il utilise déjà le nom d'un jeu très connu, donc j'imagine qu'nVidia a trouvé la parade et ne se base plus sur ça (ou pas que sur ça).

les cartes graphiques c'est quand même l'arnaque depuis toujours
entre les benchs ou les jeux optimisé pour une marque
l'AA ou d'autres fonctionnalités qui ne marchent que sur certaine marque a cause d'accord commercial.
les chiffres pipotrons marqué sur la boite.
les drivers qui font gagné soit disant 50% de perf en plus (alors qu'en fait sur un bench tu passe de 1fps a 2 fps ... et sur un jeu tu ne vois pas de différence)
les noms des cartes qui change pour faire croire que la carte est plus puissante alors que c'est une merde.

 
Moi aussi ça me choque...

 
Pareil, j'ai donné mon avis sur la page précédente  

Il se passerait quoi si je rendais le code open source, je me le demande.
 
Enfin pour ça faut que je le proprifie, car il est VRAIMENT moche
 
Bref, après OCCT V4, c'est la prochaine priorité, mettre à jour le test 3d, proprifier le code, et le faire en DirectX10 aussi sans MAJ nécessaire.

JE ne sais pas trop si ça serait bénéfique pour toi.
C'est tellement technique, je me pose la question de si quelqu'un pourrait réellement t'aider.
 
JE suis pour l'openSource en général c'est sûr. Mais là tu es sur un domaine pointu et bien spécifique. Je doute que du monde puisse t'aider. Et surtout que tant que tu souhaites le maintenir à fond comme tu le fais, tu y apportes déjà tout le support nécessaire.
Et surtout le gros risque, c'est que quelqu'un s'en serve pour faire une application proprio fermée vendue sur ton dos. (ça c'est plus probable que la possibilité que quelqu'un ne t'aide).
 
Donc là j'ai envie de dire je ne sais pas trop, je suis un fervent défenseur du libre et de l'openSource mais ton cas est spécifique. Le jour ou tu en auras marre ou tu n'auras plus vraiment le temps de t'en occuper, là oui je pense qu'ouvrir le code sera la solution. A l'heure actuelle je ne sais pas trop...
Je suppose que les gens qui souhaiteraient t'aider à dév ayant les compétences pourraient déjà te proposer de t'aider tout en laissant le code source fermé. Et il n'y a pas l'air d'avoir foule à avoir les connaissances nécessaires à t'aider à avancer sur ce logiciel.  

+1  
 
Je pense que ce n'est pas une bonne idée l'open source dans le cas de ton appli.

Nan, juste le coté 3d. l'idée est pas de tout passer en open source, mais de faire en sorte qu'on arrête de parler de power virus quand il s'agit de GPU:3D.
 
Histoire que les gens vérifient (enfin, que quelques gusses regardent et disent) que ce n'est effectivement que du Direct3d à la con sans aucun appel chelou

Pour cette partie là oui, pourquoi pas ça peut être une bonne idée oui.

+1
On a même sorti publiquement l'API pour donner la possibilité à chacun de développer un plugin de monitoring et on a eu aucune demande/retour.
On ne s'est pas donné du mal pour rien puisqu'au final CSMT et OCCT ont profité de cette interface commune, mais preuve que ce début d'ouverture n'intéresse pas grand monde.
On pourrait même imaginer un système ouvert de plugin 3D, j'suis sûr que ça marcherait pas mieux

Ceci dit, pas bête l'idée d'ouvrir le source d'OCCT GPU, histoire que certains puissent constater que c'est une application Direct3D valide, et non pas un truc bas niveau et tuné à mort (que seuls ATI et nVidia pourraient sortir).

Faut que je le refonde pour que ca soit présentable, car là c'est VRAIMENT trop moche.

Et si je release le code source, c'est juste pour la chauffe, pas pour la vérif d'erreurs (simple à coder mais bon).

Ca permettrait effectivement de clouer le bec à tous les power viruseux. le truc, c'est que cela ne fera rien, SAUF si des gens calés en 3d le certifient.

On pourrait donc arriver au même point si un gars codant chez MS sur le coté Direct3d validait un code comme étant "Direct3d natif". Car tu dis à un geek que le truc n'est pas louche car le code est dispo, il te répondra "ben tu t'y connais toi en 3d,k tu sais le dire en lisant un code ? pas moi", et voilà...

D'ailleurs, pour être clair, si on isole, pour la partie "burn", le code qui fait chauffer du code d'interface, gestion de l'écran etc, on pourrait dire que c'est une trentaine de lignes de code qui font plier les cartes graphiques.
 
En fait, un shader de 15 lignes (j'ai pas compté), un modèle de donut à la con, deux textures et une boucle.
 
Et derrière, tu te prends l'appellation power virus

si tu ouvre cette partie du code tu vas avoir les fabricants de CG qui vont se jeter dessus pour implémenter une verif dans les drivers pour te contrer  
 
m'enfin m'est avis que si ils voulaient vraiment.. ils trouverai un mec capable de decompiler ton soft et de sortir le shader qui pose problème

ATI a déjà un OCCT like dans les pilotes pour l'overdrive. C'est juste que ça fait moins chauffer, mais ça fait de la verif. d'erreur.

C'est aussi effectivement le risque, mais rien ne dit qu'ils ne soient pas capable déjà en l'état de savoir ce que fait la loop d'occt.  
Ils savent les appels de fonctions utilisées donc...  

A mon avis ils l'ont déjà le shader en question Et nVidia le bloque déjà.

 
Et c'est franchement pas facile de le planquer. Surtout quand t'es fabricant de carte graphique et que tu peux analyser tout ce qui est envoyé à la carte que tu fabriques

Voilà c'est ce que je disais.  
 
Sinon je serais curieux de voir la ligne en question qui est "barbac ready"

Y a pas de ligne réelle. ce qui fait chauffer, c'est une boucle qui dessine le même modèle avec le même shader appliqué.
 
C'est tout. Un modèle, un shader, deux/trois textures (tu peux t'en sortir avec 1 d'ailleurs, y a le logo OCCT derrière que je compte) et basta.

En openGL le problème est le même ou pas d'ailleurs?
 
Sinon ça a l'air vraiment basique d'après ce que tu dis.

C'est le même vi, sauf que OpenGL chauffe moins bien que d3d d'après mes tests (ce qui me permet de devancer furmark en chauffe pure d'ailleurs), mais je suis loin du niveau de JegX en OpenGl

Donc si un jeu utilise à 100% une cg on aurait une chauffe équivalente à OCCT et donc nv ou ati ne pourrait pas cacher la conso de leurs cartes derrières des programmes de bridage...
 
T'as plus qu'a sortir un jeu Tetedeiench

AMD a trouvé la parade, un switch manuel...

Ou alors le Power Containment.

 
OCCT est pas à 100% Mais en théorie, oui.
 
Je peux très bien transformer le programme de burn en "jeu" où il faut appuyer sur les touches qui apparaissent à l'écran assez vite pour augmenter le score Devant un donut poilu qui fait chauffer à mort
 
Ce genre de trucs débiles. mais je serai bridé quand même, ils s'en foutent que ca soit un "jeu" ou pas.

Sinon, ca avance, hein, mais petit à petit Je me bats avec cette saloperie de serialization xml made in .net qui pète dés que tu veux faire des trucs un peu complexes, mais je m'en sors

Petit cadal pour Tetedeiench : http://www.ixbt.com/video3/cayman-part1.shtml

Même en Russie on te reconnait.

EDIT: Ça ressemble à un graphe AMD en plus ça, non...?

J'adore la précision : OCCT Shader Complexity 8

Tetedeiench
 
Pour contrôler le wattage de leur cartes ils doivent  faire appel au pilote qui lit une sonde ou un truc comme ca... Le résultat doit être a un moment ou un autre stoker en mémoire.. donc il est théoriquement possible de réécrire cette valeur a ton avantage... en mettant une valeur proche du max mais sens approcher la valeur max qui déclenche le bridage.
par sécu je ferais mettre une valeur haute au cas ou ils utilisent la valeur de conso comme valeur de test pour le contrôle des ventillos..
du genre : si conso < 70W alors ventillo = 20%trm max  
pouf plus de carte.
 
enfin voila
 

Vu la limite de 200W de conso de toutes facons le Cayman a du Throttler pendant OCCT GPU non ?

C'est très probable. ^^

 
Putain comment je les explose en termes de W

C'est une piste effectivement, et je me demande si ce n'est pas ce que fait GPU-Z

 
Je confirme, c'est un graphe AMD, d'après la traduc google, juste avant : "Résultats AMD dans les applications suivantes à titre d'exemple:"
 

 
Ma suprématie en termes de W confirmée par AMD