Reprise du message précédent :

   
 
merci    

Rien que le temps qu'il faut 'investir et la motivation sont déjà important.
 
Bah de toute façon, si j'ai toujours ces configurations c'est un choix perso car elles me suffisent emplement.
Je ne joue plus donc mes gf6 me suffisent pour faire tourner compiz fluide et profiter de l'accélération sur les dvd etc, et mes procos me suffisent pour mes compilations de tous les jours avec compiz qu'allège tout ça.  

Pour info, le test utilise actuellement 16 threads simultanés qui écrivent la ram par paquets de 64 bits.

Voici le déroulement des tests :
"PATTERN" : calcul d'un nombre aléatoire sur 64 bits. Je l'écris partout dans la mémoire (16 threads qui se partagent le boulot), je vérifie, j'écris le complément (pour les gens qui aiment le C, ~pattern), je revérifie : tous les bits sont passés à 1, théoriquement. Donc j'écris et lis 2 fois chaque bit mémoire.

"OWN ADDRESS" : j'écris à chaque emplacement le n° de l'adresse mémoire (i.e. j'écris la valeur 12 à l'adresse mémoire 12). Je vérifie, puis j'écris le complément (~12 dans l'exemple), et je revérifie.

Test qui reste à réaliser :
Idem au dessus, mais avec uniquement des nombres aléatoires à chaque fois. Il faut que j'implémente une routine de nombre pseudo-aléatoires aussi, et ca prends un peu plus de temps Ca devrait aussi faire chauffer le GPU un peu plus

PS : Lancez CUDAMemTest SANS AVOIR LANCE AU PREALABLE de jeu 3d... il semblerait que cela fasse perdre de la mémoire... Sur ma config, avant de lancer Mass Effect : 460Mo de mémoire dispo. Après : 370... Ne me demandez pas pourquoi. Vous le voyez au lancement ("lost X bytes" );

Test effectué sur une 8800GT 512Mo non OC et stable, le tout sous WinXP et les 174.74 :

Le message au début est normal ?

Ouip
 
Pour info (toi tu capteras facilement), le driver CUDA me dit avoir "463.732.224 octets" de libres pour faire du malloc, mais quand tu testes, tu vois qu'en fait, tu n'en as que "464.121.344". je suis donc obligé de faire des mallocs successifs décrémentés pour avoir la valeur finale.
 
Donc j'affiche, histoire de
 
Bref, ca tourne, reste à vérifier la détection d'erreur Merci fouge

Ah l'époque du maloc et du free. C powered inside.    
 
EDIT: toi qui a programmé un peu en CUDA, c'est facile à utiliser??? est ce que ça se mari bien avec le C++?? ça s'utilise comme un framework ou une lib?

'tain c'est moi où y'a aucun pilote CUDA pour Vista 64 si on a pas une GF9/GTX200 ???
 
Vraiment super, j'ai un G92 qui sert a rien en fait... Pas de CUDA, pas de PhysX, VP2 utilisé comme un VP1... NVIDIA c'est quand même des gros blaireaux, ils est loin d'Unified Driver Architecture...

C'est facile vi, à condition d'être fort en maths (comme pour la 3d), d'appréhender certaines limites "surprenantes" (style "c'est fait pour les gros calculs", mais tu fais tourner un truc plus de 5~7s sur la CG principale : erreur), et d'avoir de l'imagination. J'ai apprécié la pléthore (40 environ) de projets d'exemples fournis avec le SDK.

Ca se marie bien avec le C plus que le C++ j'ai l'impression (bref, c'est pas franchement orienté objet, enfin moi je le vois comme cela). Ca s'utilise comme une lib, avec une syntaxe particulière ( fonction<<...>>(paramètres)).

Y a de très bonnes docs sur www.nvidia.com/cuda

 
Erf
 
Ils ont encore du boulot
 
Clair que l'UDA est loin, et c'est très dommage...

Je remets le post de download ici : (pouu qu'il soit vu)

CUDAMEMTEST v0.1 OUT !

• Qu'est ce que c'est ?

Il s'agit d'une version standalone "temporaire" d'un test qui sera intégré dans OCCT. Il lance un algorithme similaire à Memtest86, mais sur la carte graphique.

• Y a des prérequis en termes de matériel ?

Ce test ne marche que sur les GeForce 8XXX et supérieures et il faut mettre les drivers à jour (testé avec les 175.19) : www.nvidia.com

• Il n'y a que deux tests pour le moment ?

Oui, en fait, ces deux tests recouvrent 4 tests de memtest86. Je travaille sur un troisième. Bref, stay tuned

• Comment le faire tourner ?

Décompresser le fichier zip, et lancer "CUDAMemTest.exe". Par défaut, il lance 10 passes, chaque passe durant une vingtaine de secondes. Vous pouvez customiser le nombre de passes en le lancant depuis une ligne de commande (CMD). Par exemple, pour lancer 5 passes : "CudaMemTest 5"

• Il faut tester quoi ?

Il faut overclocker votre carte graphique, mais uniquement la mémoire. Lancez CUDAMemTest, et vérifiez si il trouve des erreurs alors que vous voyez des artefacts dans vos jeux...
L'idée est de vérifier que CudaMemtest détecte bien des erreurs quand vous en voyez dans vos jeux...

Enjoy !

http://www.ocbase.com/OpenBeta/CUDAMemTestv0.1.zip

PS : Lancez CUDAMemTest SANS AVOIR LANCE AU PREALABLE de jeu 3d... il semblerait que cela fasse perdre de la mémoire... Sur ma config, avant de lancer Mass Effect : 460Mo de mémoire dispo. Après : 370... Ne me demandez pas pourquoi. Vous le voyez au lancement ("lost X bytes" )

PS2 : Je ne supporte pas encore le SLI (le test ne tournera que sur la première carte), mais ca va venir très bientôt

PS3 : encore trop chère, mon fils.

MEI> T'as quelle version des driver ?
 
Tetedeiench> Qu'est-ce que ça rame ton test J'ai regardé la conso CPU (20 à 40% sur un quad), j'en déduis donc que cette lenteur apparente est uniquement dû a des pb de refresh d'affichage.
Je monte progressivement la fréquence de la RAM jusqu'à avoir une erreur. Je ne connais pas la limite stable de ma CG (uniquement en maxbench, et je joue @ stock).

Bon sur le site CUDA j'ai trouvé un 177.35 beta qui est censé tourner sur toutes les NVIDIA. Donc non seulement je pense que le pilote est testé que pour CUDA et pas trop pour la 3D, mais en plus ton programme arrive a alloué 0 octets de RAM... Super... (en plus il essai de faire le test et du coup crash)

 
Ben c'est un memtest, et les fonctions CUDA se baladent dans la mémoire...
 
Actuellement je divise le range à tester en 16 puis je lance les threads qui chacun s'occupent d'un 16ème de mémoire.
 
Faudrait que je morcelle plus en avant (style morceler en 1000 toujours avec 16 threads).
 
En fait, quand tu as du CUDA qui tourne, ton affichage ne se mets plus à jour... marrant, mais scomme ça.
 
Bref, je vais aussi essayer d'améliorer ça ;=

 
TODO : corriger ce bug. merci
 
Je vous cache absolument pas que c'est une préversion de chez préversion, juste pour voir si je vais dans le bon sens

A la base j'avais les 174.74 et ça marchais pas, pas de nvcuda32.dll

1080MHz ça passe.
1095MHz ça ne passe plus :

Je vais comparer avec FurMark...

edit: à 1095MHz, FurMark n'a rien détecté (et j'ai rien vu non plus) pendant 2 min alors que CUDA Memtest met 5s à détecter une erreur.
Par contre, FurMark fait chauffer bien plus.

MEI > le 177.73 est dispo => http://forums.guru3d.com/showthrea [...] 1&t=268631

Oki faudrait vraiment que je m'y penche dessus mais bon sans GF9 difficile de tester. Une autres question et j'arrète le HS, t'as pu tester pour voir ce que ça donnait sous nux? Et c'est quoi cette histoire de pas pouvoir faire tourner plus de 5 7s max sur la carte graphique??  

Test en cours, ça fonctionne sur une bonne "vieille" 8800 GTX des familles  
Driver 175.16 ok également, pas la peine d'installer les 175.19 qui sont globalement moins performants.
Je poste le résultat dans quelques minutes

Merci fouge

Ce test n'est pas là pour la chauffe, loin de là, c'est que de l'écriture/lecture mémoire

 
*nux : non, pas testé du tout.
 
Yep, tu as un "watcher" (appelé watchdog) qui vérifie grosso merdo toutes les 5s que ta CG est bien dispo. Or, la CG, quand elle est occupée à faire du CUDA, ne lui répond pas. Il la considère donc comme plantée et la réinitialise. Ca n'arrive pas sous Linux.
 
Donc t'as des erreurs louches (que j'ai eues quand, pour débugguer, je n'avais qu'un thread qui vérifiait tout), mais en fait, ben... suffit de réduire/diviser le travail

Ah ok merci. Donc déjà sous nux j'éviterais ce genre de problème. Merci pour toutes ces infos et pardon pour le HS.

A ton service

Ah sinon j'y pense watch machin truc tu peux pas lui dire de plus tester? Genre quand t'es en jeux ou autre, la 3D elle doit plus beaucoup répondre quand elle est utilisée à 100% donc y a bien quelque chose qui lui dit ne réinitialise plus je suis occupé sur une appli non?

Tu parles que j'ai regardé La réponse est non, pour le moment. Nvidia taffe dessus.
 
http://forums.nvidia.com/lofiversi [...] 71855.html

Oki.
 
A croire que tout est fait pour qu'on trôlle sur windows.  
 
EDIT:  

Pas pour être méchant gratuitement mais CUDA c'est que nVidia non ? Si c'est le cas ca sert pas à grand chose grand chose, autant prendre un outil qui stresse tout les types de cartes graphiques
 
Enfin bon boulot quand même cela dit

Y a pas d'outil qui permette ça sur toutes les cartes Il est obligé de gérer marque par marque, puisque chaque marque fait sa propre sauce sur le GPGPU.

Y'a pas possibilité de faire un truc type 3DMark ou ATiTool ?

Le plus efficace pour tester la ram ou le core, c'est de faire des calculs implémentables et surtout contrôlables. A moins de s'y connaitre en 3D sur une api normalisée du genre de directx 9 ou OpenGL et de lancer des calculs 3D ce n'est pas possible... Et pour différencier ce qui est en cause entre la ram et le GPU ce n'est pas possible sur un Calcul 3D. Là avec le GPGPU il peut tester ram puis GPU séparément.

8800 GTX à 621/1458/1008 (Core/Shaders/Gmem) dans le bios.
Ce sont les fréquences stables flashées dans le bios suite à différents tests d'o/c ingame (crysis, GROW 1 et 2, GRID, WIC etc...).
Certains jeux montrent des artéfacts dès 1026 MHz sur la mémoire vidéo merci Hynix.
Pour comparaison le "Scan for Artifacts" d'ATItool montre des artéfacts dès 1044 MHz.

Les tests avec cudamemtest

1008 MHz          1026 MHz           1044 MHz          1053 MHz          1080 MHz

Aucunes erreurs détectées même à 1080 MHz
Mais que se passe t-il ... oh mais qu'est ce qu'il se passe http://www.youtube.com/watch?v=AmBbuSDxPb8

Question : faut-il absolument installer les drivers 175.19 ?
Si cudamemtest se lance correctement, ça devrait être bon avec les 175.16, non ?!

Bah c'est là qu'on risque d'en apprendre plus sur les carte video. Si on essai d'appliquer ce que l'on connais sur la stabilité RAM centrale. Je dirais que souvent la RAM peut tenir sous memtest car intrasequement elle ne fait pas d'erreur, mais que le controleur DDR lui peut etre etre limite et provoquer de lui meme les erreurs en cas de forte charge.
 
Or je pense que les grosses charges 3D lstress bien plus le controleur GDDR...

Tu veux dire par là qu'il faudrait "stresser" le GPU en parallèle ?
 
Edit : euh tu répondais à Burn ?

 
Essaie d'aller au delà de 1080, même temporairement. L'idée est de valider que les erreurs sont bien détectées...
 
Pour les drivers, je t'avouerai que je ne sais absolument pas, je n'ai que les 175.19 sous la main

 
Heu non, pas de furmark en parrallèle Juste CudaMemTest
 
Mei > Justement, c'est l'expérience, faut voir ce que ca donne en pratique... si le controleur mémoire est intégré au GPU et que ce dernier chauffe,  il se peut que ca soit lui qui lâche en premier vi.
 
Je suis en train de taffer pour optimiser la répartition de charge pour que ca soit plus efficace.

Ok, j'vais faire ça, mais mon affichage risque de déconner passé une certaine limite.

 
Le mien avait des points rouges qui s'affichaient, l'idée étant de valider en étant sur qu'il y aie une tonne d'erreurs

Bon, allez, dodo, il est temps, je tombe de sommeil

Dites moi ce que vous trouvez, demain, il y aura surement une nouvelle version

 
Vista SP1, 8800GT et 177.72
 
edit: debug visual

Mauvaise nouvelle, ATI Tool détecte des erreurs dès 1058MHz.

edit: contre 1095MHZ pour CUDA Memtest