Reprise du message précédent :
A bon bah OpenCL
 

C'est pas super simple non plus hein.
D'autre part, il faudra bien vérifier que c'est aussi efficace qu'avant sur les nVidia et tester si c'est efficace sur les ATI.
Sur cartes nVidia, OpenCL n'est pas aussi complet et parfois moins performant qu'avec CUDA.

Ben je sais pas comment c'est pas trop comment c'est dev. Mais je suppose qu'il faut juste reprendre l'algo cuda, et le pondre en OpenCl en espérant que les fonctions permettant la vérif de la mémoire avec Cuda soit réalisable / existante sur opencl...
 
Mais comme je dit, je n'y connais rien.. et c'est surement bien plus compliqué que çà...

Et un Freeze Check plus visible ?

Du genre une petite diode en bas qui clignote toute les 0.5 Secondes ou plus pour voir si cela Freeze ou autre ?

Vivement la RC !

 

 
J'ai décidé de regrouper les graphes de tension, températures et ventilos, chacun son graphe. Ca se présentera comme suit :
1ère ligne : 3 graphes : CPU, Mémoire, FPS
2ème ligne : 1 graphe : température (avec plusieurs lignes qui apparaissent)
3ème ligne : 1 Graphe : tensions (avec plusieurs lignes aussi)
4ème ligne : 1 graphe : ventilos (plusieurs lignes)
 
Si aucun ventilo n'est sélectionné (par exemple), le graphe n'apparaîtra pas. Et ceux au dessus auront donc une taille plus importante.
 
Je ne sais pas encore trop comment je vais gérer la légende du graphe du coup
 
 
Pour la sélection de prio, oui, j'hésite encore. Je réserve ma décision sur ce point là, on verra
 
Je vois pas trop de quoi tu parles avec l'ascenseur, mais l'idée, c'est de virer les modes "auto, custom, infinite", par "custom, infinite" avec la durée du custom à 1h (=test auto) par défaut. Et de sélectionner infinite par défaut aussi, car j'en ai marre de voir les gens se plaindre de la durée de monitoring
 
Faudrait essayer pour la 7600GT, mais ca devrait passer. Je t'avouerai ne plus avoir les specs en tête là tout de suite (ca fait un an, mine de rien), mais ca devrait tourner sans trop de souci. La chauffe était plus évidente sur la série 8, ca, je m'en souviens
 
Je taffe dessus sans relâche, mais y a encore des travaux en cours dans la baraque, donc je suis limité par les durées de TGV... mais ca avance. Je refonds les graphes suite à la baffe que je me suis prise, je vais pas me laisser faire

 
Dans la v4, le test GPU:Memtest sera désactivé. Pas assez bien foutu pour y figurer AMHA.
 
L'idée c'est de se replonger dedans pour l'améliorer, probablement changer de techno, et le stabiliser.
 
Je t'avouerai ne pas m'être trop penché sur le sujet du choix de techno, mais si il faut refondre, on refondra entièrement.
 
J'ai déjà fait la bascule OCCT GPU OpenGL => Direct3d en 2 semaines, je suis pas à ça près

 
Les boutons qui clignotent en test c'est pas suffisant ?

Coucou, ça faisait longtemps !
 
Occt v3.1.0 ne détecte pas tous les coeurs, il n'en voit que 16 sur les 24.
 
 
 
 
Et inutile de dire que le test CPU de Occt ne va pas tester grand chose de la mémoire. Il y a une version 64 bits de ce test de prévu pour la v4 ?

Voilà la réponse du sav asus quand je leur demande sil ils ont un test fiable pour leur carte graphique vu que occt ne leur plait pas.
 
 

Ascenseur = menu déroulant (déformation support, les lusers me poluent avec leurs expressions )
 
Quant à Bilbo, cherche pas, OCCT à une réputation catastrophique auprès des constructeurs ; il n'y a qu'à voir l'affaire des étages d'alim faiblard d'ATI, ça avait été franchement tangent jusqu'a ce qu'ATI admette sous forme de oui... mais...
Donc malheureusement, OCCT n'est pas une reference chez les constructeurs, par contre en maintenance, c'est pour moi une phase obligatoire, meme pour une machine neuve.

On est bien d'accord, mais çà sert a quoi si tu détecte des choses et que le sav te dit : " Nan occt, c'est  pas un test, c'est un power virus "...
 
Le pire c'est qu'ils ont aucun outil fiable pour tester le matériel.

 
 
 
Pas tout à fait je trouve, toute les secondes...
 
 
Parfois, chez moi lors d'un OC moyen Stable, cela freeze un quart de seconde
 
 
Après, cela peut être une option à activer seulement.
 
 
 
Sinon, encore merci et bon courage !

   Vraiment abusé. Forcément que pour eux ce n'est pas un test fiable...
 
Je pense que la iench la sortie du code permettant de faire tourner le gpu s'impose vraiment!
 
Mais même comme ça ils continueront à dire que non blabla...    Forcément ça ne va pas dans leur sens...  
 

Heu ça ça n'a rien avoir. LEs freezes dont tu parles c'est juste une question de ressources indisponibles, parce qu'un vrais freeze de plantage c'est système out figé. Un pc ne peut pas planter "temporairement" et repartir comme si de rien été...

je suis plus vicieux : je dit que c'est pas stable sans preciser que c'est OCCT qui fait planter / je dit "en jeux" et si on demande lequel tu sort les 4~5 derniers hit a la mode et hop

Ils doivent bien faire des tests par derrière ?
 

sans doute oui // mais dans l'interval ils ont filé une autre carte ( chat perché ... je suis caché )  
et le sample instable sera envoyé en cadeau pourri au prochain qui donera ca carte en SAV

Quoi qu'il en soit, LDLC a accepté de me la reprendre.. le technicien a pas ralé.. je suis lui ai parlé d'occt et de atitool.. il avait l'air de connaitre un peu qu'il a pas dit non...
Vous savez comment çà se passe chez ldlc le sav ? La carte de remplacement est envoyé dès réception de la carte hs ?

99% des tests se font avant qu'une décision ne soit prise sur le dossier  
 
Mais ca ne veut pas dire qu'on ne change pas une carte qui mérite de l'être.
 
OCCT est par ailleurs une référence pour nous, il fait partie des softs très utilisés pour éprouver le fonctionnement des machines clients (avant/après vente).
 

 
Encore heureux, non mais    

pour ca que je prend pas de matos chez vous      

   
 
Ceci étant, ce n'est (bien sur) pas fait pour embêter les gens, au contraire : dans la plupart des cas, il s'agit de vérifier effectivement qu'il y est bien un problème... Et donc qu'il ne soit pas ailleurs.  
 
Trop de cas ou l'on nous assure "X rade !" par ex, tu échanges et.. Bah ac alors, même problème à réception (et bien sur, c'est de notre faute quand même, mais c'est annexe   ).
 
Pleins de gens, pas forcement informaticiens, sont très près à faire des tests ceci dit, OCCT inclus (à part le souci de DX bien connu, il est facile à utiliser, et ça c'est pratique )
 

je sais oui .; verifier que c'est pas le user qui est trop con pour faire marcher le matos ( oui oui le user de base est un gland .. on est entre nous pas la peine de se cacher pour le dire )
 
vous avez eux les retours de RAM "capacité incorrect, y a pas les 4Go sous windows "

C'est clair qu'un protocole de test clair, efficace, et simple a mettre en oeuvre, çà cours pas les rues. Clair que nous on se débrouille comme on peux, mais heureusement qu'il y a des outils tel qu'occt pour détecter les problèmes... et quand une marque me sors, "quoi occt ? nan c'est un power virus", ma première réaction c'est, "qu'elle bande d'amateur", la seconde c'est de leur demander qu'elle test ils utilisent, et on me sors, "regarde avec tes yeux peut être que tu verra quelque chose..." mais boulet je suis aveugle et je ne fait que du gpgpu sur boinc !
 

Comme quoi, je suis pas tout seul à l'utiliser en milieu pro

Bonne année à tous !

Bonne année.

Bonne année à vous aussi

Et en 2011, ma bonne résolution : sortir la v4 rapidement avec des graphes comme vous les voulez (ca fait 10 jours que je suis dessus )

Bonne année

bonne année à tous

Bon, par acquis de conscience, j'ai posé la question à ma protection juridique, et selon eux, "Nvidia ne fait que protéger leur création contre la votre", donc, on ne peut rien faire

La seule chose que tu peux faire c'est diffusé le code de la partie 3D comme tu avais dit, faire diffuser l'information de blocage de nvidia vers tous les magasines d'informations....  
 
ça en général ça peut faire assez mal...

Mon but c'est pas de faire mal hein, c'est de faire en sorte que ce blocage saute, ou que l'étage d'alim des cartes soit correctement dimensionné plutôt

Donc go pour diffuser l'info.

L'étage d'alim. est correctement dimensionné, pour un usage typique c'est tout.
 
Si NVIDIA ou ATI dimensionne leurs étages d'alimentation pour le cas qui arrive jamais où 100% du GPU est utilisé à son maximum - là une 5870, par exemple, aurai un TDP de 300W sans soucis et peut-être même qu'elle n'aurait même pas pu être cadencé à 850MHz.
 
Il faut bien voir qu'il est impossible d'imaginer un cas où les ROP et les TMU et les SP sont utilisés à 100%, pourtant si on te suit faudrait que l'étage d'alimentation puisse supporter ça si on veut être tranquille. C'est d'autant plus pinailler, que dans 99,9% des cas les limitations imposées par NVIDIA ou ATI sont inutiles.
 
Quand tu fait un shaders qui tiens en cache L1 avec une texture en cache L2, faut bien voir que c'est un cas plus que particulier qui n'arrive jamais dans un jeu (le but premier d'une carte 3D). Et après, il faut savoir ce que l'on veut : avoir 100% des perfs et cramer la carte, où accepter un bridage partiel qui en plus reste dans les limites du PCI-SIG.
 
Car de toutes façons NVIDIA et ATI sont limités à 300W en peak par les spécifications du PCI-SIG. Sachant que les carte mères ne sont pas toutes dans les normes, franchement passé 250W de TDP ça devient dangereux et on risque de flamber le slot de la carte mère (surtout en SLI ).
 
Bref, je préfère encore l'état actuel au cas des 4870/4890...

Bha perso je préférai le cas 4870/4890 dans le sens où au moins, tu savais que tu ne pouvais pas aller plus haut sans déclencher l'OCP qui lui ne causait pas une baisse artificielle des perfs.

Ce n'est pas parce qu'aujourd'hui ce n'est pas le cas (et encore personnellement je ne serais pas catégorique dessus, je ne suis clairement pas assez pointu pour être catégorique) qu'il faut laisser passer ça, rien ne dit que dans le futur ça ne posera pas problème!
 
Soit on est capable de faire un gpu sortant tel puissance réellement, soit on limite sa consommation et on ne ment pas, et donc on le bride. Les chiffres de performances donnés sont bien des valeurs brutes correspondant aux meilleurs calculs possibles...
 
Donc s'ils ne sont pas capable de faire un gpu qui tien à 100% de charge, on le bride jusqu'à ce que cela soit possible, courir à celui qui a la plus grosse dans les cas ou ça passe en le vendant comme le cas général, personnellement ce n'est pas pour moi... Libre à toi d'accepter ce choix, choix que tu aurais toujours via l'overclocking en fait, mais personnellement je ne le cautionne pas du tout!
 
Quand on vend un composant stable, on le vend pour tenir une charge de 100% point final, il en a toujours été ainsi et c'est totalement honteux de gruger l'acheteur et les infos en disant si si ça peut développer telle puissance mais en fait non parce qu'à 100% elle se bridera pour ne pas dépasser sa conso maximale....
 
Surtout que là c'est encore pire, on parle d'une bride propre à occt, histoire de masquer que le problème existe. Donc pour occt ça paraitra stable, mais tu peux tout cramer en jeu en cas d'overclocking et tu n'as aucun moyen de valider un overclocking...
 
Vraiment super pratique! Accepter ça c'est donc dire adieux à l'overclocking....

Burn2 > L'info a circulé sur tous les sites de news récemment hein. Ce qui m'ennuie, c'est que ca tue un peu dans l'oeuf le test OCCT GPU, et furmark aussi d'ailleurs.

Non c'est juste au dev. de torture test de faire des tests qui sont plus représentatifs c'est tout.
 
La plus value c'est pas de faire chauffer le GPU, mais de certifié le rendu 100% sans artefacts.
 
D'autant que Furmark/OCCT:GPU c'est bien mais par ex. ça ne valide pas le tesselateur.

Une charge de 100% est représentatif du maximum de chaleur à dissiper. Point final, c'était le but de ce test....
 
Surtout qu'encore une fois si j'ai bien compris la chose et l'histoire, nvidia limitera occt gpu maintenant qu'il fasse (sauf changement), donc même si ça restait un simple test graphique, il en serait de même.
 
Et ça reste quand même la meilleur c'est au développeur de s'adapter au matériel pour ne pas le faire chauffer, c'est la meilleur... Analogie: c'est à l'utilisateur de s'adapter au programme, je pense que l'utilisateur serait vachement content...
 
Qu'on s'adapte à une archi parce que différente ok, mais qu'on s'adapte à une archi parce qu'elle ne peut tenir une charge de 100% c'est quand même la meilleure, bref j'arrête de tergiverser sur le sujet... Personnellement je trouve ça honteux un tel comportement...
 
 
 
Iench, tu dis que tout le monde en a parlé? je n'ai vue aucune info perso, je n'ai plus trop reparcourue les news récemment, mais aucun gros titre en tout cas, peut-être inclus parmi certains titres mais aucune grosse information...  

J'imagine que si OCCT GPU devient un test moins violent, nvdia enlèvera la bride (je les vois pas en train de me tuer sciemment, surtout qu'ils m'ont bien aidé à pondre OCCT GPU, ce qui est assez surprenant, j'avoue Mais les gens des US et de france sont surement pas les mêmes ).

Pour l'info, suffit de voir sur google Par exemple sur pcinpact : http://www.pcinpact.com/actu/news/ [...] cement.htm

Mei > Ce que tu proposes est pas réaliste. Transpose cela aux CPU. 90% de l'utilisation des gens est du web/office. Tu me vois coder un test pour valider la stabilité d'un overclock en simulant la charge d'une firefox + word ? Ca n'aurait pas de sens. Pourtant, c'est l'utilisation "classique" d'un CPU. De plus, TOUS les tests de stabilité CPU ne font chauffer quasiment qu'une unité : FPU/SSE/SSE2. Tu ne testes pas l'ALU par exemple. Pourquoi ? Car c'est le meilleur moyen pragmatique de vérifier que ca tourne. C'est un peu pareil pour les GPUs

En gros, tu pousses à fond les unités les plus fragiles même si l'utilisation n'est pas réaliste pour voir ce que ca donne.

De plus, et malheureusement, je ne suis pas 3dmark et ne pourrait absolument pas coder seul un test "réaliste" au delà de la petite scène pondue avec OCCT GPU.