Reprise du message précédent :
Tetedeiench> 2 bug avec la dernière beta, test 3D en DX10 :
1) quand je déplace la fenêtre, sans détection d'erreur j'ai un "Crysis2.exe a cessé de fonctionner", avec détection d'erreur l'image passe au noir mais pas de plantage.
2) difficilement reproductible mais j'ai eu une exception du module ZedGraph au moment de quitter OCCT à la fin d'un test 3D. Je pense que j'ai quitté au moment où les graphes étaient générés.

Shaders à 1
Win7 64bit
ATI Radeon 5k
Catalyst 11.12 beta8

Alors :
 

• SmartScreen n'est pas le fautif, puisque j'ai les mêmes résultats quand il est désactivé
• J'ai remarqué que la description de l'option des shaders repasse parfois en anglais quand on déplace la souris dans l'interface. C'est de toute façon pas important
• En DirectX 9, les modes fenêtré et plein écran fonctionnent, y compris la détection d'erreur. Au passage, j'avais oublié qu'avec cette dernière le donut avait une gueule bizarre et ne bougeait pas. Ou alors il y a un souci là aussi ?

Il semblerait que seul le mode DirectX 10 pose souci chez moi.
 
Pour rappel : Windows 8 Pro x64 (MCE mais sans importance), GeForce GTX 670 de référence avec pilotes 310.70. La VSync adaptative n'est pas fautive, tout comme le SmartScreen à priori. OCCT est toujours lancé en administrateur. J'ai essayé avec "moonly.exe" comme variable sans amélioration de résultat.

chez xbitslab on utilise OCCT
 
"After that we tested our overclocked system stability by running OCCT 4.3.2 utility (30-minute test in Large Data Set mode).Our Core i7-3970X remained stable at the maximum frequency of 4.6 GHz"
 
http://www.xbitlabs.com/articles/c [...] html#sect0

 
Ce qui m'énerve, c'est qu'on a fait le tour de ce qui pouvait foirer. J'ai eu moi aussi un comportement étrange, résultant en l'impossibilité de lancer le test, SAUF qu'au bout d'un moment, c'est tombé en marche tout seul, sans rien faire.
 
J'ai un Windows 8 Pro x64 (developer edition), Une GTX670 asus (DirectCUII classique, pas la version TOP), j'ai pas vérifié les pilotes. Bref, des configs bien similaires.
 
J'en perds mon latin. Quand tu lances le test, peux-tu vérifier si le process tourne (pas OCCT.exe, mais moonly.exe ou ce que tu as configuré) ? Je risque de devoir te filer en MP une version avec debug activé histoire de checker.

 

 
J'ai toujours adoré xbitlabs, je suis fier

faut leur demander de raquer ouais
comme à matos.net

Putain, j'étais parti pour te dire si le processus se lançait ou non quand il me mettait l'erreur et stupeur : écran noir. J'attends quelques secondes et... le test a marché.

1920*1200, plein écran, détection d'erreur, shaders réglés sur 3.

Ça ne t'aidera pas beaucoup du coup. Si tu as besoin de moi pour des tests spécifiques que tu tenteras aussi de faire sur ta bécane, hésite pas à demander.

EDIT : je précise au cas où, je n'ai rien changé à ma config, aucun pilote, aucun matériel.

Bonjour,
 
Est ce qu'en monitoring, la valeur du bus corresponds bien au blck en temps réel?
 
J'ai lancé openhardwaremonitor et je n'ai pas la même valeur.
 
Je soupçonne l'instabilité du BLCK qui provoque des freezes du pc..  
 

 
A mon avis, c'est bien ça. C'est la même valeur que celle de CPU-Z.

Avec tout ça, vous m'avez pas dit si CPU:OCCT en mode "je spécifie le nombre de threads" marchait bien
 
Moonly : je vais mettre un gros coup de collier sur DX11, on verra si ca améliore les choses, je suis absolument pas content de la béta actuelle sur 8.

OK 'iench, je reste dispo pour les tests (sauf début de semaine prochaine). Pour OCCT:CPU, dès que j'ai le temps je teste.

 
Alors le nombre de thread choisie fonctionne bien.
Mais maintenant c'est le mode auto qui m'en trouve 12 au lieu de 6.
Du coups, je ne peux plus lancer le test, manque de mémoire    
 

D'ailleurs, comme pour Linpack, on ne pourrai pas choisir la capacité de ram par core (ou au total)

un truc bizarre iench : si je lance un small 1h avec 3 minute de repos à la fin, le test s'arrête à 57 minutes tout pile, sans erreur. Il ne fais pas les 3 minutes d'idle.
Par contre si je fais un large il va bien jusqu'à 59min 59s

edit : là je pige plus rien, sur mon fx-8350 je passe hier mon NB à 2400, le large passe mais le small plante à 35 minutes.
Je remet un poil de jus au NB, ce matin le small passe mais le large plante en 20 sec
c'est étonnant, pour tester le NB c'est plutôt le large en principe, je vois pas pourquoi c'est le small qui plantait hier soir...

edit 2 : bon après reboot, ça semble tenir

 
En fait, ton phenom est détecté avec hyperthreading, d'où le 12 threads.

 
Ptêt un problème de scheduler, faudrait que je vérifie tiens.

J"'avance sur le test DX11, le background est OK, la génération des textures dynamiques OK, le rendu du donut OK (sans fourrure), bref, ca avance bien.
 
Par contre, dans l'esprit, le switch DX10 => DX11 est comme passer du C++ au C : tu abandonnes tout mode objet pour revenir à du procédural.
 
Rien que pour les paramètres de shader :

• Tu groupes tes paramètres par fréquence de mise à jour (par objet, par frame...)
• Tu fais attention à ce que la taille soit un multiple de 16 octets
• Tu assignes un id ("register" ) à ta structure
• Tu recodes ta struct en C
• Tu lui attaches un numéro de registre identique à ton shader
• Tu balances à peu près 40 lignes de code pour créer le shader, pour créer les buffer, etc
• Tu charges ton shader
• Tu mappes ton cbuffer pour écrire dedans
• Tu assignes son n° de registre à ton cbuffer
• Tu fais le rendu

C'est une vue extrêmement prodécurale du rendu, c'est franchement déconcertant en 2012 (2013) je trouve. Personnellement, ça me semble tout sauf pratique en tout cas.

 
C'est p'tet les dev. qui forcent ça pour avoir le plus de contrôle en étant au plus bas niveua possible.

 
Oui, mais tu n'as pas d'autres solution.
 
Ca se voit dans l'évolution de DirectX : DX9 => DX10 tu perdais les rendus "précablés" génériques, tout devenait Shader.
 
DX10 => DX11 tu perds toute aide coté objet.
 
Le framework gérant les effets (.fx) en DX11 est buggué jusqu'à la moelle, je l'ai rangé dans le "quasi inutilisable en l'état".
 
Ils auraient voulu faire un langage de programmation 3d plus obscur qu'ils auraient pas réussi. A coté, OpenGL ressemble à du VB.
 
La philosophie colle bien à la mienne, mais les docs sont tellement peu nombreuses et tellement mal foutues (à mon sens), que c'est une vraie plaie à comprendre et intégrer tous les concepts, augmentant en plus le nombre de fois où ca peut foirer.

 
Mais c'est pareil en D3D10, je comprends pas là...
Je crois que tu confonds l'interface d'effets, qui est un toolkit, et qui fait du boulot à ta place, et l'API réelle.
En D3D11 l'interface d'effets à juste été sortie, parceque c'est un toolkit.

 
Sauf que les effets sont intégrés à DX10, c'est bien plus simple à utiliser, et pas buggué au point de limite pas être utilisable en DX11 Je t'assure

 
Non mais c'est du détail....
Et y'a pas spécialement plus de bugs dans la version shared source que dans la version D3DX.
Par contre il y a des choses qui ont été dépréciées oui.

 
Bah écoute, j'ai pas réussi à la faire marcher du tout Mais bon, je suis rentré dans le systèmeDX11, ca m'a pris un peu plus de temps que prévu, donc tout va bien. J'avance bien, il me reste des problèmes d'alpha blending pour avoir la version DX11 OK en mode burn, pas en mode error check.

Bonjour Messieurs,
 
Je m'excuse par avance de ma question qui vous semblera sans doute un peu simplette par rapport à votre discussion!
 
J'ai utilisé OCCT pour vérifier la stabilité de mon système (acheté il y a quelques jours, déja 2 écrans bleus). J'ai aléatoirement un message d'erreur "error detectée sur le core #n" (c'est jamais le même), en mode occt large data. Ça arrive parfois dès le début en quelques secondes, parfois ça tiens plusieurs heures, c'est très aléatoire.
Est-ce que ce message incrimine forcément le processeur? Ou bien est-ce que je dois vérifier l'ensemble du système?
 
J'ai des suspicions sur la RAM (plus d'erreur avec d'autre barettes, et l'occurence des erreurs OCCT semble lié au voltage de la RAM => moins d'erreur ou moins rapidement si j'augmente le voltage, l'inverse si je diminue). Pourtant je ne trouve pas de soucis avec MEMTEST, et j'ai un doute sur la manière d’interpréter ce message d'erreur sous OCCT.
 
Bref, si vous pouvez m'éclaircir.
 
Merci d'avance pour votre aide,
 
Guillaume

Marque de l'alim ?

 
Une corsair HX620W que j'avais déja sur ma précédente config (pas de soucis particulier).
Désolé si ma question précédente n'était pas très claire : lorsque OCCT détecte une erreur de calcul, sait-il l'attribuer à un module (genre "erreur sur le coeur #" ou "erreur sur le module mémoire #" ), ou est-ce que toutes les erreurs auront le même message "erreur sur le coeur #" (au n° du coeur près)?

En mode large data la mémoire est plus utilisée qu'en small data, donc plus de chances d'avoir une erreur due à la mémoire.
As-tu les mêmes erreurs en mode small data ?
Le plus simple/sur pour tester ta mémoire c'est de faire tourner memtest.

justement est-ce que memtest est 100% fiable ?
parce que après une nuit (6 passes) sur mes barettes tout est ok, mais j'ai des reboot sous OCCT large que je n'avais pas avec mes barettes précédentes...
Je sens que le NB doit jouer dans l'instabilité mais j'arrive pas à faire la part des choses...

 
Memtest est un testeur bit à bit de mémoire, mais ne stresse pas les composants.
 
Pour prendre une image, memtest va regarder chacun des gravillons un par un pour voir si tout va bien, OCCT va rouler à 200km/h sur la route pour voir si elle tient le choc.
 
Large data set détecte des erreurs mémoire que memtest ne verra jamais, liées au stress des composants, ou à des erreurs de transfert.
 
memtest détecte des erreurs de bit défectueux qu'OCCT ne verra pas à chaque coup, car son espace mémoire se "balade", n'est pas total, et il ne peut accéder à l'espace de l'OS.

ok merci
donc bon faut que j'arrive à voir qui de ma ram ou de mon NB provoque des reboot intempestif en large data set...

 
Tripatouille les tensions, tu verras bien Augmente les timings de la ram aussi.

en fait la ram est donnée pour 2133 et je tourne à 100mhz de moins avec les timings donné pour 2133, en gros elle est large
ce qui est bizarre c'est qu'avec mon NB à 2400 sur mon fx j'avais aucun prob de stabilité, là en changeant la ram ça plantouille
je vais monter la tension CPU/NB et je trouverai bien d'où ça vient, mais ça saoule de perdre du temps là-dessus

Ca peut aussi être le contrôleur mémoire qui en chie...  

Bonjour,
Merci pour vos réponses,
Malheureusement je suis toujours un peu perdu dans mon analyse    :
 
- MEMTEST86+ ne donne aucunes erreurs (15h de bench, 10 pass)
- Windows Memory Diag en mode étendu ne donne aucunes erreurs MAIS le test freeze complètement en max 3 passes, toujours à 21% de la passe en cours (donc un test bien spécifique j'imagine?)
- OCCT donne une erreur dans le coeur N en max quelques heure. Parfois j'ai à peine le temps d'appuyer sur ON et ça faute en 5 secondes (on voit a peine les températures du CPU qui commence à grimper)
- OCCT a l'air d’être plus stable en augmentant la tension de la RAM de 1.5 à 1.6V (le profil XMP par défaut est normalement du 1.5V/1600/CL9)
- OCCT marche bien avec des autres barettes de RAM, mais c'est de la 1333/CL9 et non 1600
 
Ces tests me donne de gros doutes sur la mémoire mais le fait que MEMTEST86+ ne voit rien m’embête  (et je suis pas convaincu que corsair accepte la garantie si MEMTEST ne voit rien?). Je précise que ni le CPU ni la RAM ne sont OC, ça plante avec les fréquences par défauts.
Qu'en pensez-vous?
 
Ce soir je ferais tourner OCCT en mode small data, on verra ce que ça donne.
 
Merci pour votre aide

tiens iench, utilisation d'OCCT pour le test d'un boitier chez hitech Legion
 
http://www.hitechlegion.com/review [...] l=&start=5
 
Sinon je m'arrache toujours les cheveux avec mon O/C, OCCT tourne bien mais dès que je sors le pc de l'écran de veille ça reboot (genre ça fait 2h qu'OCCT tourne, l'écran s'est mis en veille au bout de 30 minutes, donc je bouge la souris pour rallumer l'écran, l'image apparait et au bout de 5 secondes le pc reboot )
idem si je lance occt et que je prends la main à distance du taf pour voir ce qui se passe, j'ai l'affichage d'occt qui tourne puis 5 secondes après reboot...
j'arrive pas à savoir si ça vient de mon O/C ou de ma CG (je l'ai changé en même temps que ma ram, donc peut-être un pilote qui merde)
T'en pense quoi
 
ou un controlleur sata vu que mon DD se met aussi en veille au bout de 30 minutes ?

GPU:3D : Tous les shaders de burn sont implémentés en semblent fonctionner. Je travaille sur la rotation (un petit bug) et je passerai ensuite à la détection d'erreurs.
 
Matthiman : Alors là, bonne question. Le reboot est pas un problème logiciel d'une manière générale...

je continue à essayer de comprendre, hier prime95 tient 8h sans soucis, je lance OCCT en large et pouf en 20 minutes reboot...
j'ai baisser le HT de 2600 à 2400 idem, la ram de 1866 à 1600 idem... faut que je baisse le NB pour voir quand j'aurai le temps.
le truc louche c'est qu'en cas de reboot, l'écran devient noir pendant facile 10 secondes, puis l'ordi redémarre.

Bonjour,
je venais de faire un teste OCCT le 1er teste avec OCCT CPU tous avait l'air stable, par contre le 2ème sur GPU3D il m'affichait des erreurs qui variait de 1500 à 40000 voir + mais changeait toutes les secondes pour redescendre plus bas.
AU niveau de la tension et température sa restai stable sinon les FPS sa restai symétrique mais a 16 de valeur.
 Sachant que j'ai une Saphir HD 7850 et que je suis branché sur ma tv HD vous en pensé quoi ?? ma carte graphique a telle un soucie ou c'est le fait d'être sur une TV HD ???

c'est normal qu'occt gpu ne me trouve pas d'erreur alors qu'il affiche ça ?

avec une Geforce turbocache et un P4.

 
Ali

Tu m'as tué Ali !!