Reprise du message précédent :

Ça peut aller TRÈS vite. J'ai vu des waterblocs se faire ronger en moins de 6 mois.
J'ai même vu des systèmes comme celui utilisés par la R9 295X tomber en panne en moins d'un an, car le client a changé le radiateur par un plus gros et performant, mais incompatible. Ca a bouffé le waterblock et attaqué la pompe avant de fuir. Une catastrophe.

Moi je part du principe que si mon G5 avec le système WC catastrophiquement pas fiable à tenu le coup c'est que tout ce qui existe de nos jours est mieux. Bref au départ je parlais de Kit en circuit fermé, kit de base et vous partez tous dans des grand délires aluminium/nickel/cuivre. C'est peut être valable pour les montages maison mais dans le cas d'un kit permanent bah ça porte bien son nom…. Et de toute façon même si ça crève au bout de 5 ans à moins de se faire un ordi très haut de gamme,c'est l'ordo qui est crevé!  
 
J'ai aujourd'hui un mac pro de 2006 (donc 8 ans cette année) , il fait encore un bon job mais comme je l'ai dit c'était du haut de gamme à son époque, les mecs qui avait achetés des HP celeron les ont déjà foutus à la cave.  
 
Ce qui me fait donc dire qu'un kit WC sur des configs grand public ne serait pas si idiot (surtout en été)

Pourquoi lors du protocole de test, l'hyperthreading du i7 est-il désactivé?

C'est juste pour une meilleure stabilité des résultats, dans de rares jeux l'HT ajoute une variabilité non désirée pour nos mesures.

"Mise à jour du 25/04/2104:"
Eh bien j'espere sincerement que pour les possesseurs de 295X, il ne faille pas attendre aussi longtemps
 

J'ai moi même un WC depuis plus de 10ans, et la seule vidange complète a été en 2010 quand j'ai changé de config et donc de waterblock.
Aucun dépôt, aucun soucis, tout était nickel.
Je tourne en full cuivre, embout plastique et eau déminéralisée mélangée avec du liquide de refroidissement auto.

 
T'as une source pour dire que le WC de la r9-295x comporte des incompatibilités métal entre les différents éléments qu'ils le composent ?
Ou c'était juste une mauvaise utilisations de mots, genre de déformation toute sauf professionnelle, induit par ta longue carrière de fanboy/hateboy....  
 
Wait réponds pas quand tu peux pas répondre ( >>> la source ) autrement qu'en éludant la vérité. On a l'habitude avec les mauvais fanboys.

C'est parce que tu n'as pas utilisé de carte NV dans ton système auparavant.

d'ailleur cette nvapi est une belle merde, obligé de la desactiver sinon mon explorateur plante des que je fait un click droit sur un dossier....

Ahhhh, j'suis un chouia déçu tout de même.
 
Dans mon inconscient, je voyais Damien avec 2 HDD (même modèle) dédiés aux tests gpu sur la même mobo => à jour (OS et pilotes), l'un pour AMD et l'autre pour nVidia.
 
Désinstaller, même proprement les pilotes après chaque session, c'est ouvrir la porte à un gros facteur de problème potentiel (exactement comme celui révélé par Grid).
 
PS: ouais, je me doute que c'est relou d'avoir un mettre à jour 2 fois la même chose (OS, jeux, pilotes), mais bon, à la maison je veux bien, mais pas pour un test professionnel.
 

Ce serait beaucoup d'emmerdement pour au final un bug de ce type en 10 ans

Croisons les doigts

la différence entre "quiet" et "oc" sur les cf 290x

C'est donc une erreur de manip et de désinstall, ce n'est pas lié à GRID2. Je comprends mieux, je pensais que GRID2 chargeait une dll de driver NVIDIA comme ça, pour le plaisir ou pour l'honneur.[/quotemsg]
C'est le cas aussi....
Grid2 utilise cette dll pour vérifier quelque chose, es-ce que le jeux a des paramètres dispo uniquement sur NVdia?? Genre... Physx? AA custom?

 
C'est un bug spécifique à GRID2 qui essaye d'accéder à des fonctionnalités Nvidia lorsqu'il détecte nvapi.dll alors qu'il ne devrait le faire que lorsqu'une GeForce est présente.

Certes, mais il m'est arrivé un truc dans le genre lors de la vente d'une HD4870. L'acheteur trouvait que la CG était morte d'après ses stress-tests. Après discussion, il s'agissait d'un cador du "clique sur OK sans lire" qui avait passé toutes sortes de CG sur sa config. Pour avoir expérimenté la chose personnellement, je lui ai fortement conseillé de poser les pilotes CG sur un windows vierge. Si les pilotes sous windows étaient gérés proprement, ça se saurait.  
 
Bref, à la lumière de cette aventure, m'est avis d'avoir des DD ou partitions séparées pour les tests de CG : 1 windows AMD d'un côté, 1 windows nVidia de l'autre.

 
Ce n'est pas utile. Nettoyer les traces d'anciens pilotes, ce n'est pas simple, mais depuis le temps on a l'habitude 99% des problèmes du style que nous rencontrons sont liés au passage d'un pilote AMD vers un autre pilote AMD ou d'une carte AMD vers une autre carte AMD. Pour éviter ces problèmes, la BDR doit être nettoyée manuellement en mode système (un coup de psexec pour lancer l'éditeur).

Je comprends, mais je suis surpris qu'un changement de pilote pour une CG qui bouge pas demande un nettoyage. Pour ma part, j'ai toujours appliqué les catalyst les uns sur les autres en mode "gros boeuf".  
 
Par contre, et parce que l'installation se fait en fonction de la CG détectée par le kit d'installation, j'opère un nettoyage complet de la BdR quand je change de Radeon (via un passage par les pilotes génériques microsoft). M'enfin sous Windows hein, parce que sous Linux, c'est une autre histoire, y'a rien à faire (et en plus on peut installer tout les pilotes imaginables sans qu'ils se marchent sur les pieds, mais bon, ça c'est un autre débat)

 
Avec les Catalyst, et encore plus avec les betas fournis pour les tests, tout est possible Par contre passer par les pilotes génériques ne revient pas à faire un nettoyage complet. Il reste des entrées, surtout s'il y a eu plusieurs Radeon différentes (ou une même carte avec des bios différents) qui sont passées dans le système. Pour que Windows autorise la suppression de ces entrées, il faut lancer l'éditeur de la bdr en mode système.

Selon Sweclockers, en général plutôt au fait concernant nVidia, la Titan Z serait repoussée à plus tard :
 
http://translate.googleusercontent [...] JrFDCq7rcQ
 
Il semble bien que la puissante 295X2 va pousser le caméléon à revoir sa copie.

Bref, il ne reste guère plus qu'une solution à base d'un ghost sans pilote de CG au final
 
Ahhhh les joies des tests

Je me demande bien sur quelle base tu peux déformer les propos ci-dessus pour écrire ça.

Il se pourrait que cette phrase soit issue d'une discussion qui dépasse le bug de GRID2. Il se pourrait également que Singman ait trouvé de la concurrence niveau mauvaise foi

Un peu facile, nan ?

 
Je pense qu'il voulait dire que les catalyst sont sources de problèmes en ce qui concerne l'install/desinstall et que cette partie n'avait rien à voir avec ton débat mais plutôt avec celui qu'avait lancé TNZ.
 
Sinon pour en revenir à ton débat "Grid2" je pense tout simplement que ce jeu en particulier, qui est fait pour exploiter autant des dlls nvidia et dll amd, doit appeler les deux ou au mieux toujours appeler une dll nvidia, que son environnement soit sur AMD ou nvidia.
 
Pas de chance sur le pc de test les deux étaient présentent et seul ce jeu était touché, bon c'est qu'une hypothèse.

Surtout que le chargement de DDL n'est pas forcément automatique. Il s'agit d'un mécanisme de l'activateur d'image (comprendre les .exe) qui est mis à disposition du programmeur pour que celui-ci puisse charger une librairie dynamique (DDL sous Windows, lib*.so sous Unix et .exe sous OpenVMS) au cours de l’exécution du programme principal.
 
Donc le problème vient de Grid2 et non de la présence de DDL d'un pilote de CG.
D'autres questions ?

Je ne pense pas

ilyon » Disons que Grid2 charge TOUTES les DDL qu'il sait gérer, puis après il réfléchit. Hors cette logique a des failles fonctionnelles et surtout celle de la news, c'est à dire le cas d'une machine ayant les 2 pilotes installés à un moment ou un autre et avec des cadavres dans les coins parce que mal nettoyée.
La bonne approche pour Grid2 serait de demander les caractéristiques de la CG à DirectX/Windows (au choix) avant de commencer à charger une liste de DDL spécifique suivant la CG.  
 
Mais bon, là, en tant que développeur depuis depuis, je peux te dire que ce genre de problématique est bien connue et que ce cas de figure est passé au travers des tests d'installation / déploiement. Ce genre d'oubli ne présagent généralement rien de bon.

Nan nan, Codemasters est le seul responsable dans cette affaire.  
Les développeurs aurait dû anticiper ce cas de figure. De plus, ils connaissent tout autant que les dévs AMD ou nVidia l'aspect "cours des miracles" que sont les zones système d'un Windows.

Même chose côté AMD après la désinstallation des pilotes il reste toujours des traces, clé de registre, dossier, fichier AMD etc...
 
Donc ni l'un ni l'autre sont fautif (AMD comme Nvidia)