Reprise du message précédent :
Ah
 
Donc non, ca n'est pas spécifique à une archi.
 
Mon nombre de threads est déjà adaptable (pour avancer "normalement", j'y vais par étapes, pour le moment c'est 16, demain, ca sera le nombre adapté à la carte).
 
De plus, l'algo implémenté pour les G8X et G9x est un cas plus restrictif des futures cartes graphiques. Autrement dit : les GT200 fonctionneront pareil + supporteront d'autres cas. Comme je ne peux pas prédire le futur, j'utilise la meilleure approche à un instant T, et je verrai ce que ca donne dans le futur...
 
Le truc qui m'ennuie le plus, c'est qu'ATI n'ait pas développé autant son langage GPGPU.

Pour le cas du memtest faut voir les specif hardware qui sont importante :
- taille des lectures RAM
- nombre de ROP
- taille de pool
- etc.
 
Apres tu fait un system de profil et voilà.

J'ai aussi lu l'article et effectivement ce comportement est spécifiques aux G8x/9x. Mais en fait, Tetedeiench est obligé d'optimiser pour G8x/9x parce qu'ils ne sont que très peu flexible, contrairement aux GT200 qui posent moins de pb à ce niveau. Donc ce qu'il fera marchera également bien sur les GT200, enfin je pense.
Concernant le nombre de thread (là n'était pas le pb), il pourra faire varier en fonction de l'archi, mais cela signifie qu'il va devoir faire des MAJ très régulière des CG, à moins qu'il arrive à trouver une méthode de calcul du nbre de thread +/- "générique".

Tetedeiench> A priori DX11 intègrera du GPGPU, mais tu perdras la compatibilité 2k/XP/2k3. A moins qu'OpenCL vienne y mettre son grain de sel...

Les archi Cuda y'en a eu combien ? 2 (en gros)... Puis les CG ca sort pas comme ça, donc même s'il doit updaté regulierement, ca sera justep our les grosse archi, et pour le moment que NVIDIA. Meme si a terme CUDA tournera sur CPU et ATI/S3/Intel tout ceux qui voudront faire leur implementation.

Je ne pensais pas spécialement aux archis GPU, mais aussi et surtout à toutes leur déclinaisons qui voient leur nombre Multiprocessor/ROP/etc varier.

edit: ne serait qu'entre une 8800GT et une 9800GTX, pourtant tout 2 pourvu du G92, il y a des différences.

 
J'ai vu pour DX11...
 
A l'heure actuelle, tout est "modifiable", i.e. :
Nb de threads
Taille mémoire allouée
patterns
...
 
Y a que l'algo utilisé qui ne l'est pas.
 
Tout est détectable à la volée facilement. le seul souci, c'est que je n'ai pas le nombre de ROP. Donc faudra juste que je pense à avoir un nombre de threads assez conséquent pour tous les occuper, et voilà Si il y a plus de threads que de ROP, ca ne changera pas grand chose, ca restera du 100%.

Ancien CUDAMemTest sur ma bécane : 5425ms pour le fill&check
Nouveau CUDAMemTest : 1845ms pour le fill&check
 
Impressionnant, non ?
 
Je vais stresser plus la mémoire en faisant des shuffles de blocs

yes ....  diviser pat trois    
 
uniquement en reduisant les appel memoires inutiles comme tu disait hier ?  
 
question ... une version "test infini" avec des passes enchainée est prevu ??

 
Je fais le même nombre d'appels mémoire, ils sont juste dans la séquence quivabien pour optimiser les performances.

CudaMemTest v0.2 OUT !

Au menu :

• Algorithme 3 à 4 fois plus rapide
• Ajout du test Shuffle (il initialise une partie de la mémoire de la CG et la copie partout, plusieurs fois)

Enjoy !

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

Plus je travaille dessus, plus je me dis que CUDAMemTest ne peut servir qu'à détecter une mémoire défectueuse "de base" et pas "instable"... ce qui est déjà pas mal en soi, m'enfin.

Je vais voir pour la chauffe de la CG

excellent et toujours aussi réactif, comme d'hab Tetedeiench
 
Vi même si le CUDAMemTest ne fait que vérifier si la mémoire est HS, c déjà très bien, si en plus tu intègre ça à occt, excellent.
 
OCCT va devenir un outil des plus complet

Le SLI arrivera bientôt

Bah memtest de base est pas precis, alors sur un GPU c'est p'tet normal.

 
C'est un peu ce que je me dis en fait

Excellent ! ! !  
 
     

C'est déjà +/- le cas avec MemTest86+.

En gros il n'y a que la recherche d'artefact qui permet de "voir" l'instab du couple GPU+mémoire, si j'ai bien suivi  

En gros on test si la RAM fait ce qu'on lui demande mais bon ce qui fait mal dans l'o/c c'est les refresh moisi aussi. Et ça y'a que le test 7 (de tete) qui ecrit et attend avant de voir si c'est encore comme il faut.

La 0.2 marche enfin et ne crashe plus
 
Par contre, ca trouve pleins d'erreurs    
 

Même syndrome.

Fréquence d'origine : 900MHz
Erreur ATI Tool : 1058MHz
Erreur CUDAMT 0.1 : 1095MHz
PATTERN : no error
OWN ADDRESS : plein d'erreurs (30 ?)
Erreur CUDAMT 0.2 : 1095MHz
PATTERN : no error
OWN ADDRESS : 3 erreurs
SHUFFLE PATTERN : 1 erreur
 
Chez moi les tests durent 2.5 fois moins longtemps que la v0.1. Peut-être les faire durer aussi longtemps qu'avant pour pouvoir juger l'efficacité de manière "équitable" ?

Je me permets de reprendre la mise en forme de fouge, ce sera plus clair  
 
8800 GTX
Artéfacts/plantage "in game" : entre 1026 MHz et 1044 MHz
Erreur ATI Tool : 1044 MHz
 
Erreur CUDAMT 0.1 : 1107 MHz
PATTERN : no error
OWN ADDRESS : 88 erreurs
 
pas d'erreur CUDAMT 0.2 à 1107 MHz
Erreur CUDAMT 0.2 : 1134 MHz    
PATTERN : no error
OWN ADDRESS : 9 erreurs
SHUFFLE PATTERN : 3 erreurs
Remarque : toujours 3 erreurs "own adress" pour une erreur "shuffle pattern" par passe avec la version 0.2
 
durée des passes à fréquence mémoire égale :
 
PATTERN
v0.1 8250 ms
v0.2 3030 ms (2.7x plus rapide)
 
OWN ADDRESS
v0.1 8670 ms
v0.2 3360 ms (2.6x plus rapide)
 
Etrange la durée des passes d'Anthony

Moi ca met 0,2ms mais ça marche quand meme pas

Je vérifie pour le "own address", doit y avoir une bêtise Si les addresses affichées sont 0,0,0,0 ==> bug.
 
Merci pour le feedback

Sun USA utilise maintenant officiellement OCCT (un peu tweaké ) pour les tests de dissipation thermiques de leurs serveurs.
 
Je suis fier et eux sont très content
 
Comme quoi, le mail était absolument pas du spam, et j'aurai fait une belle connerie de pas leur répondre !

J'dois avouer être assez fier et content de ça
 
Ça m'a fait marrer, car j'étais chez un client qui avait un serveur sun qui faisait du bruit à mourir en pleine charge, dans le bureau. J'ai donc pu lui dire "ca, ca va changer, et c'est grâce à moi !" quand il se plaignait du barouf du bordel
 
Ça s'est fini autour de la machine à café

Il y a de quoi être fier BRAVO !  
 
Par contre les serveurs SUN utilisent des plateformes X86  
 
Désolé de la question de noob

 
Ouaip
 
De l'opétron et du xeon. Tu peux le voir sur leur catalogue francais. Style le X4100, et plein d'autres.

J'irais jeter un oeil  
 
Faudra voir à contacter Cray maintenant    
 
Bon jyvas moa...
 
@bientôt et encore merci pour ton boulot

De rien, ca me fait plaisir aussi
 
CUDAMemTest v0.2a OUT !
 
Au menu :

• Les codes d'erreurs ne devraient plus s'enchainer de manière débile
• Le programme affiche la version

Enjoy !
 
http://www.ocbase.com/OpenBeta/CUDAMemTestv0.2a.zip
 
PS : version mineure vi Mais bon

Félicitation!  

Je viens d'avoir une zoulie idée Stay tuned, ca prendra du temps par contre.

Ya moyen que tu rallonges les tests pour que ça dure à peu près aussi longtemps que la v0.1 ?
 
Et toutes mes félicitations pour Sun

et mon bug alors ??      

 
Demande à être engagé par eux
Tu pourra même tester les plateforme CUDA

Tjrs le même pbs, je suis pourtant passé des 177.30 (officiellement fait pour CUDA) au derniers 177.79...
 
Zetes sur que NVIDIA a activé le CUDA sur autre chose que les 9800 et GTX 200 ???

J'ai une 8800GT et les vieux (mais stable&WHQL) 174.74 pour WinXP 32bit.
Ca doit être la version pour ton OS qui doit être +/- bugué.

edit: quand je regarde la version de ma DLL nvcuda, j'ai "NVIDIA Windows XP CUDA 1.1 driver"

Toujours les erreurs debiles (177.72)

Si Vista 64 tourne pas pour CUDA c'est chaud... Enfin je sais pas, quand on a une Tesla 4Go on a pas que 3,25Go de RAM je pense...
 
EDIT : dans system32 et SysWOW64 j'ai nvcuda.dll avec CUDA Driver 2.0 blabla... (les deux ne font pas la meme taille donc en principe ya pas de DLL x86 moisi dans le dossier x64)