Reprise du message précédent :

 
 
ben c'est comme un moteur de bagnole , fait le tourner  a plein regime , il tiendra  pas longtemps....c'est nimporte quoi ce que tu dit

Non, c'est totalement faux ta comparaison. Un moteur de bagnole comme tu dis, tiendra parfaitement la charge tant que tu restes en dehors de la zone rouge.
Bien sûr qu'au rupteur c'est pas fait pour, mais en dessous de la zone rouge si. (bon y a tout un tas de variables qui rentrent en jeux sur un moteur, etc, bref pas comparable)
Ta comparaison est totalement foireuse de toute manière vu tout ce qui rentre en jeux sur un bloc moteur ou là tu as de la mécanique, ce qui n'est pas le cas d'un gpu.
 
Tu as une machine conçu pour un usage, tu utilises cet usage là en respectant les normes, ça ne tien pas y a un problème point!
Là tu as une carte graphique, tu l'utilises en lui affectant une tâche 3D, si ça surchauffe, c'est que la conception est foireuse Point! L'analogie, comme je te dis, c'est j'ai une carte mère qui supporte un cpu X, mais attention faut pas le charger à 100% ce cpu X sinon l'étage d'alimentation en état surchauffe. Ce n'est pas normal point.

Non ce n'est pas n'importe quoi, ca vient du fait qu'il n'y a pas de comparaison à faire entre l'informatique et une voiture...
 
L'informatique est prévu et testé pour, une voiture tu n'es pas censé dépasser 130...
 
La différence vient de là, le constructeur de voiture connait la limite et prend une marge, le constructeur informatique prend une première marge suivit d'une seconde car il ne connait pas la limite thermique en utilisation que la carte va avoir, il connait son dégagement max, il fera avec (et pour des raisons de coup aura tendance à prévoir un système qui supporte moins que la limite max sachant que personne ne pourra atteindre cette limite), mais il ne connaitra jamais l'utilisation que l'utilisateur en fera.
 
pgase -> t'a déjà passé une carte au SAV ? On dirait pas... Personne te demandera l'origine de la panne, suffit de faire le coup du mec qui pige pas, je sais pas je jouais et pouf plantage et ca passera nickel
 

Et si j'habite en Allemagne ??    

Pour stopper le HS. Un moteur est prévu pour être utilisé sur une plage d'utilisation, qui va jusqu'a la zone rouge. Sur cette plage (en dehors de la zone rouge) le moteur ne risque rien à chaud. Après la la mécanique qui rentre en jeu qui est que plus un moteur est haut dans les tours plus il y a de frottement donc d'usure, même si à la longue ça reste négligeable puisque qu'on ne peut jamais comparer le même moteur sur deux régimes fixes, et que chaque moteur a une durée de vie propre (un minimum garantie mais pas de maximum identique...), un peu comme plus j'utilise un cpu plus ils s'use mais bon voilà quoi... Mais bon voilà je stoppe le hs on est sur un forum info.
 
Et pour en revenir à l'info, j'ai un gpu, conçu, on sait son utilisation de volt en usage intensif de 100%, puisque c'est le constructeur qui le conçoit donc il sait qu'a une fréquence nominale, un voltage nominale et une charge de 100% il y aura telle consommation. En l'état il installe l'étage d'alimentation nécéssaire pour cette charge.
 
Occt, ne fait que s'approcher de l'utilisation de 100% du gpu (il ne change pas le voltage, ni la fréquence, ni l'étage d'allimentation), et si on voit que l'étage d'allim arrive à la limite en version stock, c'est clairement qu'a la base il y a un problème de conception.

Oui la comparaison est totalement farfelu ,cela dit travaillant dans l'électronique je peux t'assurer que bon nombre de composants n'aime pas fonctionner à bloc (trop de puissance à dissiper, donc élévation de la température, qui entraîne une déformation du PCB et des composants durant cette intense activité, cela peut engendrer sur le long (comme sur le court terme suivant la qualité des composants et les vis de fabrication) la détérioration voir la destruction de ce dernier, et croire que le constructeur a prévu cela, car sinon on pourrait pas le faire, je te laisse y croire seul, et le jour (et c'est souvent 1 semaine après la fin de ta garantie) tu auras casser ton matos sans soupçonner ton OC ou tes logiciels de tests, il sera malheureusement trop tard , après il faudrait établir des statistiques pour connaitre l'influence de tout cela (sur la durée, comme sur l'intensité des tests ou OC). Personnellement je change de matos que tout les 2/3 ans, donc je préfère qu'il tourne encore comme au premier jour sans lui infliger de douleur supplémentaire à celles de mon porte-feuille .
 
Voilà pour moi  
 
 

Oui mais normalement ton composant, si tu assures qu'il est fait pour telle fréquence, tu le garantis pour.
Donc à cette fréquence là à bloc ça doit passer.
Bien sûr qu'a bloc bloc, fréquence maximale stable de la puce ça peut poser problème, mais normalement quand tu vends ton composant, tu le sors, avec une marge, et bridé pour qu'en usage de 100% ça passe. Ce n'est pas à l'utilisateur de limiter la charge (car ça il ne peut pas forcément) et que rien ne te dis que dans le futur aucun logiciel ne l'utilisera à 100%.
 
Il faut différencier:
Fréquence stock validé par le constructeur et vendu en l'état. ==> puce bridée pour que ça passe à 100% en continue sur une durée qui est en général justement celle de la garantie comme tu le dis si bien.
Fréquence maximale et voltage max supporté par la puce mais qui pourrait ne pas passer à la longue en usage de 100%
 
Tu vois ce que je veux dire?
 
En plus là on parle de l'étage d'allimentation, donc tu peux toujours la surdimentionner, et surtout prévoir son refroidissement pour que ça passe en usage de 100% pour accompagner le gpu que tu connais et dont tu connais sa conso en full.
C'est tout ce que je veux dire. Je ne parle pas à long terme de plusieurs années etc, mais bien sur un test de base d'une heure ou deux, voir l'étage d'allim atteindre des limites et surchauffer, c'est pas pareil qu'un clacage de ta carte après garantie (car ça on est souvent habitué ) car utilisation de 100%.
 
Surtout que bon c'est connu que sur les HD48XX le gros point faible c'est l'étage d'alim, ou en jeu on voit bien que ça monte trés trés haut, chose pas rassurante. Donc c'est bien tout ce que je veux faire remarquer.
EDIT:

Désolé, mais je vais re-jeter un pavé dans la mare de toute facon

OCCT GPU v0.69 OUT !

Au menu :

• Le mode de détection d'erreur peut être lancé dans des résolution différentes de 512x512, en fenêtré ou en fullscreen. Ca sera moins joli car un zoom est effectué (en interne, ca reste du 512x512), mais les points blancs seront plus visibles. SLI/Crossfire/ATI sous Vista rejoice !
• En mode fenêtré, vous ne pouvez plus basculer directement en FullScreen ni resizer la fenêtre (ca évite pas mal d'ennuis en mode Error check)
• La résolution minimale du mode Error check reste 512x512. Heink. Non, pour les petits malins.

Enjoy !

http://www.ocbase.com/download.php?fileext=gpu

PS : j'adore ce numéro de version

Coquin
 
Ali

 
Attention, ici, on ne fait pas fonctionner les composants "à bloc".
 
Ce n'est pas le problème du programmeur que de se dire "je fais fonctionner la carte à bloc, ou pas". Si tu savais ce que je fais pour faire chauffer autant une carte graphique, tu serais attéré tellement c'est à la fois simple, con, et à la portée de n'importe quel débutant en 3d. Autant pour les CPU, il faut le vouloir, autant pour une carte 3d, c'est simple. Enfin simple... il faut rentrer dans le vocabulaire, dans l'API, dans le merdier infâme Direct3dien/Shaderien/blabla-ien, mais j'ai utilisé le 2% le plus basique des fonctions de ces APIs. Honnêtement. Et franchement.
 
Lors du design de la carte, les constructeurs se doivent de spécifier la zone rouge. La zone de "débrayage", la zone de sécurité, bref, la zone où de toute facon on ira pas, pour être tranquille et être sur que ca tourne. Si il y a un problème de design, c'est pas OCCT le responsable.
 
OCCT te sert à voir, de facto, si ton overclock, qui te fait titiller les specs de ta carte, toi qui ne les connait pas, te fait rentrer dans ladite zone rouge ou pas. Et la seule facon que tu as, toi, de le faire, pauvre béotien (je parle de l'utilisateur lambda, tu te situerai, vu tes connaissances en électronique, coté utilisateur éclairé), c'est le tour de circuit ou tu regardes comment se comporte la carte. Le truc de référence, qui reproduit toujours la même chose, et de manière assez violente.
 
De la même manière que tu ne sauras pas comment se comporte une ferrari sur la route entre Pouru St Rémy et Sachy, dans les ardennes, tu le sauras par contre sur le circuit de Spa francorchamp. Et voilà ce qu'est OCCT. Alors oui, c'est sur, si ta bagnole est limite, tu prends un risque à rouler par temps de pluie avec des pneus slick et à te dire "ca va passer".
 
Le problème, c'est qu'avec les cartes ATI sus-citées (je m'étais promis de placer ce mot aujourd'hui), le constructeur te dit "vous avez un bagnole de course, monsieur", et il te met des pneus "demi-slick", tout en te les vendant comme du tout terrain no problémo. Alors des fois ca passe, des fois ca casse, mais bref, c'est limite. C'est pas de ta faute, c'est le design qui est mal foutu.
 
Donc voilà le souci, et la philosophie d'OCCT GPU

Ben si ça crame sav

@ Burn2 et Tetedeiench
 
Je suis entièrement d'accord avec vous. Cela dit êtes vous sûr que les constructeurs prennent toutes les précautions adéquates pour garantir la pleine fonctionnalité sans anicroche de leur produit ... J'en doute, et même énromément, combien de personne ici on cramé leur Xbox360 (mon cousin en est à sa 3ème ), mais sa PS3 tient le coup , les téléphones portables (il faudrait qu'ils soient portables et potables, sans en avaler une goutte ) ... Combien de personne ont rencontré des problèmes avec les VRM sur les dernières HD48*0 ... Combien de personne change de réfrigérateur ... Ne croyez pas que les certains/beaucoup constructeurs font tout pour vous garantir un matériel sans défaut et exploitable sans soucis pour l'utilisation par laquelle ils sont décrites ... Ce temps est révolu pour bon nombre d'entre eux, seul quelques élitistes s'y accroche encore . Tetedeiench avec tes tests de boucles de débutant tu t'en rend d'ailleurs compte, Ton soft fait endurer un stress qu'aucun jeu n'est capable de faire, pourquoi alors que c'est si simple, est-ce du à la programmation qui est optimiser pour rendre le rendu le meilleur possible avec le moins de gourmandise possible ... Oui éventuellement mais alors pourquoi les jeux comme Crisys couche les cartes graphiques alors que leur potentiel de chauffe n'est pas atteint ??? Serait-ce par ce que certaine fonctionnalité des GPU sont calées et donc entraine la chute de FPS, sans avoir à atteindre les 100°c ??? Ou bien est-ce que tout ceci est pour préserver la carte qui n'est finalement pas aussi endurante que l'aurait laisser penser les constructeurs ??? Et pourquoi les pilotes chez ATI bride la carte graphique suivant les applications lancer (Furmark ...) ???
 
Je vous laisse seul juge car je n'ai pas ces réponses, c'est juste un constat. Mais ne croyez pas que si c'est écrit et que le constructeur l'affirme que c'est vrai, car souvent on se rend bien vite compte des limites .
 
 

 
 
 tu dit nimporte quoi , occt  tire a fonds  sur les composants du moment  ou on flirte les temps "limites" c'est que  tes de longue en zone rouge

Mais comme on t'a dit OCCT ne fait qu'utiliser ce que n'importe quel pc peut produire, donc tu es censé être dans la zone verte, et si t'es dans la zone rouge, ben ya une couille, et pas la tienne
 

Il y a une différence entre ta XBox, ton téléphone portable, et l'informatique, les deux premiers sont des amuses geules, doivent couter le moins cher et être kikoolol.
L'informatique quoi que vous en pensiez sert la grande majorité du temps à faire tourner des applications de sousous pour des boites, de trucs de modélisation de parcours, des tris massifs, les payent/facture des clients (d'ailleurs la TOTALITE des écoles d'ingénieurs en informatique, à quelques rares exceptions prêt, t'apprennent à faire des tris, pas de la 3D...).
Bref c'est deux mondes, deux exigences, d'un côté on cherche le beau et pas cher, de l'autre la sécurité des données, dès lors les contructeurs font plus attention, quitte à ce que ca coute plus cher aussi. Sachant que le monde du serveur = celui de l'utilisateur lambda depuis déjà pas mal d'années tu retombes donc sur une qualité un poil moindre mais dans l'ensemble similaire...
 
Et si les cartes ne chauffent pas assez dans un jeu c'est comme tu l'as dit due à des priorités à respecter, par exemple en 3D il est fréquent d'utiliser des formules de maths...
Prenons un exemple : la modélisation de la déformation de l'eau par une goutte, ben oui mais voila tu peux pas calculer la déformation à x+1 sans connaitre x (exemple non réel parce que en fait pour l'eau si on peut ), c'est le genre de ralentissement que tu as, la différence c'est que OCCT n'a pas vraiment besoin d'attendre le résultat x pour calculer x+1 il peut donc paralléliser (x2 voir plus) son calcul et/ou l'accélérer, donc ca va plus vite, mais donc ca chauffe plus aussi... Le secret est là
 
Et comme tu l'as dit les pilotes des cartes ATI brident pour les raisons que tu penses, ca fait mauvaise pub de voir un SAV énorme à 20%, ca prouve que l'on a complètement rater ses estimations, donc oui ils hésitent pas à brider (tout comme ils hésitent pas non plus à modifier certaines parties du fonctionnement pour par exemple gonfler un score 3DMark un peu faiblard)

Je te conseille de relire tout ce qui c'est dit dans cette page...  

YES !!!! Faut dire qu'il faut bien connaître les Ardennes pour citer c'te route, mais ça faut plaisir, moi qui suit Ardennais et fervant utilisateur / admirateur d'OCCT !!
 
Vive Tetediench !!!  
 
[HORS SUJET OFF]  
 
Sinon concernant le sujet en cours, un constat est évident : les VRMs des ATI sont sous-dimensionnés. Et comme le dit très bien Devil'sTiger, les pilotes appliquent un filtrage de performance en fonction de l'app en cours d'uitlisation, donc les constructeurs sont conscients du problème.
 
Une CG est conçue et testée pour couvrir 99% des cas connus, et parfois d'ailleurs, il faut attendre 15 jours / 3 semaines pour avoir le driver QVB pour jouer correctement avec le dernier jeux qui vient de sortir. Ceci tend à démontrer que le marketing tient une place prédominante sur les décisions de design, il faut :
- Pas cher,
- Efficace (pas trop sinon on se grille la génération suivante),
- Pas cher (bis),
- Vite vite et puis vite aussi.
 
Les concepteurs font plus ou moins ce qu'ils doivent en fonction de ce qu'ils peuvent, on en a pour preuve les Radeon HD4970 qui on des VRMs revus et corrigés.
 
Finalement OCCT couvre le dernier % des 99% cités plus haut, tout comme peuvent le faire Furmark ou encore 3DMark, seulement aujourd'hui les 2 derniers sont suffisamment connu pour être considéré par ATI et NVidia, viendra bientôt le jour d'OCCT je l'espère, (en terme de notoriété j'entends) bien que si c'est le cas, OCCT ne sera plus aussi agressif puisque bridé par les drivers, ce qui serait dommage.
 
Pour finir longue vie à OCCT et moi qui suit également développeur j'imagine la fierté de Tetediench devant tout le travail accompli et la notoriété grandissante.  

Moi je pense  à une chose concernant ces vrm qui sont faiblards, on pourrait intégrer dans occt une température limite au dela de laquelle le test se stop afin de ne pas endommager les vrm ?
 
 
De plus c'est déjà présent dans occt pour la température critique du cpu.
 
 
 
bon après il faudrait connaître la bonne valeur à utiliser (valeur qui doit d'ailleurs être entré par l'utilisateur car je pense que les vrm de toutes les cartes ne tiennent pas la même température)

Avant de peter un VRM faut y aller... Un MOSFET c'est, en general, prevu poru une T° de fonctionnement dans les 100°C voir plus. Donc bon y'a une grosse marge. Au pire la carte peu planter... Mais bon comme tout torture test faut pas lancer ça a l'arache et revenir 2 jours plus tard pleurer que ça a surchauffer.
 
Après si ATI ne calcule pas bien, c'est là le pbs. Est-ce à OCCT de prevoir les conneries des fabricant où au fabricant d'assurer la sureté de leurs carte ? Parce que bon à la rigueur n'importe quel jeu pourrais tirer autant que OCCT...
 
(Deja que la T° limite CPU ne veut plus rien dire vu que chez Intel depuis le P3 Coppermine et chez AMD depuis l'Athlon 64 y'a AUCUN risque de cramer un CPU a cause de la T°... Bref. )
 

Au pire le mosfet peut cramer surtout oui, et empêcher la carte de fonctionner une fois celui-ci cramer (comme mon ancienne 6800)

Oui si ati ne calcul pas bien, on est d'accord que c'est dans la conception qu'il y a un problème.
Cependant occt est surtout utilisé pour tester le fonctionnement des cartes qui sont  overclockées ?
Donc dans ce cas la ça rentre encore moins dans le "calcul" d'ati et la le risque est plus grand, donc afin de rassurer l'utilisateur et pourquoi pas éviter de cramer des cartes, un seuil de température critique des vrm pourrait être implanté.

Et si un jeu peut tirer autant qu'occt, le but d'occt est pour moi de tester ma carte avant le jeu afin de voir si les températures ne sont pas trop limites, si l'overclocking tient bien, si la carte ne fait pas des bugs d'affichage.....

On est d'accord pour les cpu, mais c'est loin d'etre le cas sur les gpus et mosfet aussi
Je me vois mal enlever le rad de ma cg en plein fonctionnement, alors qu'avec les c2d par exemple c'est tout a fait faisable tellement ils sont biens protégés et résistants

Sur les GPU, déjà ma 6600GT avait une sonde interne monitorée par le pilote avec protection thermique. C'est une carte de 2004...
 
Faut arrêter de se pisser dessus dès qu'on fait un torture test. Les risques ont toujours été là, si t'as peur tu fait pas de tests, basta.
 
Le VRM quasi aucune carte a de sonde vraiment viable et surtout on a aucune specs là dessus sur les T° supportée ou non. Je sais même pas si le pilote ATI en fait quelque chose de cette sonde.

Sur le gpu peut-être ça j'en sais vraiment rien, mais sur les vrm c'est quasi-sur qu'il n'y a pas de protection thermique....
 

Belle mentalité.....
Plus haut on dit que les hd48** ont des vrm très faibles et sous dimensionnés et tu nous sort que si on a peur on fait pas le test...
 
Il y a des cartes qui ont des vrm très faibles et qui atteignent leurs limites avec occt c'est tout, moi perso oui ça me fait peur de claquer ma hd4870, je suis étudiant, j'ai très peu de revenus, j'ai pas que ça a faire de me racheter une nouvelle carte, d'autant que celle-ci fonctionne bien.
 
Et une carte graphique claque beaucoup plus vite qu'un cpu, c'est parce que ca ne t'es jamais arriver que tu parle ainsi.
 

 
Je ne sais pas, ma hd4870 affiche la température de ces vrm, après que ce soit viable ou pas j'en sais rien, d'ailleurs je n'est jamais rien vu qui prouvait que les températures des vrm affichés par la carte n'était pas viable.

rien a voir avec le debat en cours .. je revient sur le debat d'il y a qlq jours sur le nombre de cores/thead a gerer  
 
on etais sur la limite de 32 core atteingnable l'an prochain .. ben c'est fait  
AMD l'as depassé avec 4*12 cores presenté hier .. c'est encore du proto mais c'est deja en marche, sortie en masse dans 1 ans,  
le 64 thread est pour demain  
 
tant de puissance conventré en si peut d'espace  

Comme dit, rien ne te force à faire un torture test sur ta carte vidéo. Si t'as peur tu le fait peur. Voir même simplement tu n'o/c pas.
 
Oui j'ai jamais claqué de carte vidéo. Normal j'o/c pas où peu et surtout jamais 24/24. J'ai valide une fois pour le fun pi c'est tout.
 
A moins que j'ai un gain probant. Ce qui ne m'es jamais arrivé depuis les GeForce 2 MX...
 
Mais si ma carte crame pendant un OCCT bah tant pis, je fait un SAV. C'est le jeu c'est tout.
 
o/c et securité c'est juste incompatible. Si on commence a rajouter la T° VRM on va rajouter quoi ? La T° HDD poiur pas les abimer si a cause du test alim la T° interne monte de trop ??? ...
 
A partir du moment où le problème ne touche que les RV770 et est connu je ne vois pas l'interet d'un limite qui ne sera en pratique quasi jamais utilisé. (d'autant plus que le RV770 est plutôt en fin de vie...)

Intel a déjà présenté du 64 (et pas avec n'importe quel version de Windows, ça va de soi) :

il avais ete posté lors du debat justement, mais la date de dispo annoncé est plus lointaine (2011 de memoire )
 
enfin toussa pour dire que 32 en grans public ca va suffire encore qlq temps mais en pro ca va très(trop ) vite etre insufisant
 
solution batarde N°1 proposé .. autoriser le multi instance pour charger plus , un peut comme il faut faire pour prime

Perso je vois pas comment AMD peut faire des 12 coeurs monolithique avec ce qu'ils ont démontré comme savoir faire niveau fabrication. A moins qu'il ne fasse pas de 32nm et vise direct le 28nm. Mais là pour 2010 j'y crois moyen, même pour decembre 2010.

 
Oui oui je suis d'accord cependant l'overclocking et la protection des gpus est très en retard comparé aux cpu (quand je vois mon q6600 qui est overclocké a 3.8ghz au lieu de 2.4ghz en h24 et ceux sans aucuns risques (ca fait du 63% d'overclocking et donc de perf en plus et avec les protections thermique d'intel, et surtout 65° en charge sous occt pour le cpu, c'est pas méchant).
 
Et après le problème des vrm touche, je pense plus de gpus que le rv770, on a trop peu de recul avec des logiciels tels qu'occt gpu (qui sont assez récents), mais ma 6800 a eu un mosfet qui avait cramé, le hasard ou bien une carte avec des mosfets sous dimensionnées ?
 
Cependant pour la limite de température des vrm comme je l'avait proposé, il n'est peut-être pas indispensable, cependant je donne une idée comme ça a tetedeiench, il peut ajouter un petit module qui permettrait à l'utilisateur de sélectionner la(les) température(s) a surveiller ainsi que la limite a ne pas dépasser qui stopperais tout test (ainsi dans mon cas avec ma 4870, je choisirais la température des vrm à je ne sais pas peut-être 100/110°, cela ne peut être qu'une sécurité supplémentaire qui peut rassurer l'utilisateur, et protéger sûrement mieux la carte même si vous en êtes peut-être pas spécialement convaincus).
 
 
C'est juste une idée qui me semble plus que réalisable, d'autant qu'une partie de ce module a déjà été développée avec la limitation de température du cpu (dans les options).

c'est pas du monolithe, c'est 2 die 6 cores couplé  
 
idem chez intel, les xeon EX sont construit avec 2 die nehalem 4core + HT

MEI> C'est pas du monolithique mais du 2*6. Ca n'empêche pas que ça reste du 12 cores / socket

Autant de cores, ainsi qu'une bonne quantité de mémoire vive (on peut même envisager du bi-proc ) avec du ssd pour les pro comme on peut le voir dans certaines news (ssd qui atteignent des debits de 500mb/s ...), ca peut effectivement bien le faire  

A priori chez Intel c'est aussi du monolithique... mais bon c'est encore flou les infos qu'on a sur ça.

je dirait meme plus  
12 core physique /socket  
 
la ou intel ne propose que 8 cores +HT pour le moment

Il ont arreté avec "nous on fait que des multicore natif"... "le multi die c'est le mal"... "le multi die c'est pour les nuls"...
 

8 coeur monolithique aussi. Avec un GROS L3 (de mémoire c'est un truc genre 24Mo )
 
Je pense que y'a eu des débat pour savoir le nécessaire, plus de core ou plus de L3.
 

ben vu que c'est en HT , avoir plus de L3 permet d'avoir plus de donnees a mouliner donc au 8 thread "virtuel" d'etre efficasse  

Ils pourront toujours dire que la "communication" intercore reste à l'intérieur du socket, via un lien HT (pas comme sur les PD et les C2Q).
Pour l'octocore d'Intel, j'avais aussi entendu que c'est était du monodie.

arkrom> Oui mais ça donnerait quoi face à 10 ou 12 cores avec un peu moins de L3 ? Là est la question. Les choix d'Intel (pour les CPU serveur) est le résultat du compromis entre nombre de cœur et quantité de L3.

edit pour MEI> AMD se rattrape avec « Real men use real cores »

je passe en coup de vent ( iphone ) :
 
Arkrom >occt c'est 64 threads par process sous xp32 pour ce que j'ai pu tester. Je vais faire des tests sous vista et co dés que j'ai 5 minutes a moi. Au pire je lance X process de 64 threads...
 
Le debat sur les vrm> le vrai crash test ce serait de mettre la carte dans un four tout en la survoltant... Pas de juste lancer une bete appli 3d maison.
 
Et la v0.69 d'occt gpu alors, ca donne quoi ?

T'as pas fini de faire de la pub pour l'iphone

J'ai vecu 17 ans dans les ardennes, a un jet de pierre de sachy... Donc oui je connais le coin douzy, mouzon, margut, carignan,...

 
Lorsque sur un test auto d'une heure le test rapporte une erreur au delà d'une heure, à quoi cela peut il être du?
 
"Error detected on core #-1
1h 1s"
 
Merci

A une erreur faite par le procal qui n'est donc pas stable...
Un poil plus de VCore, pour commencer, et tu seras fixé.