Reprise du message précédent :

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

edit: contre 1095MHZ pour CUDA Memtest

Tu avais raison le iench, détection d'erreurs à partir de 1107 MHz.

1008 MHz          1026 MHz           1044 MHz          1053 MHz          1080 MHz - aucune erreur

1107 MHz - 4 erreurs       1116 MHz - 88 erreurs
           

Récapitulatif :

in game : artéfacts/plantages à partir de 1026 Mhz (variable suivant les jeux).
ATItool Scan for Artifacts : artéfacts à partir de 1044 MHz.
CUDAMesmTest : Erreurs à partir de 1107 MHz.

Et CUDAMemTest détecte des erreurs à partir de 1095 MHz, soit de l'ordre de 40 MHz plus haut.
Dans mon cas c'est dans les 60 MHz de plus.

On est dans les mêmes eaux mais c'est pour l'instant insuffisant pour tester la stablité de la GDDR.

 
le problème est que le driver configure le contrôleur mémoire pour favoriser les types d'accès les plus courant pour un jeu.
 
une approche générique par cuda peux moins stresser effectivement le sous-système mémoire du gpu qu'un jeu qui aura des stratégies optimales stoquées dans le driver.

Et comment cela fonctionne avec mes deux 8800GTX en sli
Le test se lance bien mais sur une seul des deux cartes ou un peut sur les 2

J'ai pareil, on dirait que les 177.xx sont moisi

Après réflexion, je ne trouve pas ça si énorme que ça. Les débits max théorique sont donnés pour plusieurs dizaines de Go/s. Je me doute bien que dans les faits ce sera bien moins, mais quand même...

Avec un CAS Latency >10 aussi les latences doivent etre de lors de 100ns si ce n'est plus, alors qu'un bon sous system RAM de CPU c'est 50ns...

Il me semble même que c'est 300 à 400ns, mais même ça explique pas pourquoi on a un débit de 100Mo/s (2Go en 20s)

edit: quoique non, il parle d'écriture+lecture, donc faut multiplier par 2. Mais je trouve ces chiffres plutôt faible.

Parce qu'on est jamais Buffered et qu'en plus c'est (en principe) plein de petit access.
 
MemTest sous DOS c'est pareil, tu met 30 plombes a testé 2Go de RAM qui debite quasi 10Go/s...

En tout cas, je vais essayer d'innover par rapport au memtest pour avoir un taux de détection d'erreur suffisant

une petite question sans trop d importance, les FPS indiqué dans furemark lors du bench corresponde a quoi exactement?
 
merci

Bah au nombre d'images par seconde

Min=xx° - Avg=xx° - Max=xx°
la valeur minimale - la moyenne - la valeur maximale

C'était ça ta question ?

oui entre autre, mais surtout si ca correspondait au FPS comme testé lors d un jeu par exemple ou si c est juste du au bench
 
si le nombre de FPS indiqué dans furmark seront les memes lors d un jeu (en générale) je sais que suivant le jeux les FPS peuvent changer ^^
 
merci
 
/fin HS

A ma connaissance, des FPS c'est des FPS c.a.d. le nombre d'images calculées par la/les carte(s) graphique(s).
Donc FPS FurMark ou FPS in game = même combat.
Ça parait logique, non  

Content d'apprendre que j'ai le premier lcd 24" affichant à plus de 200 Hz

Moi je dirais calculées car mon écran n'est pas capable d'afficher plusieurs milliers d'images par secondes, pourtant elles sont toutes calculées (et entièrement, bien entendu).
De même, dans un jeu avec synchro verticale qui tournerait à 30 ou 60fps (écran à 60Hz), la CG ne calcul pas plus que ce qui est affiché.

ok merci pour vos réponses et désolé pour le HS ^^
 
en faite je teste les derniers drivers nvidia et lors de bench OCCT, dans furmark plus la version du driver est récente plus je perds (un chouilla) de FPS.
 
c est pour ca que je me demandai si furmark etai bien pour les FPS
 
merci a vous

Non mais on est d'accord Fouge, ça tombe sous le sens

Pour tester l'optimisation des pilotes je ne pense pas que FurMark soit le meilleur outil.
Rien ne vaut tes tests in game avec tes jeux préférés  
 
Fin du HS également, pas tapaÿ

Au sens stricte c'est affiché, d'où le tearing.

Je considère que dans ce cas là, une image affichée est issue de plusieurs images calculées.
Mais surtout, tu n'as pas prouvé que ce qu'il disait était faux
Le framerate correspond bien aux nombre d'images calculées (et, à la limite, affichées).

En MSAA on en calcul plus qu'on en affiche... (surtout dans le cas de l'implementation de feu 3Dfx)

pour ceux qui avait des problemes avec les drivers, les 177.79 sont sortis, si ils veulent tester ^^

 
Pour en revenir a ma question...
 
Avec un sli, quand on lance le ""memtestcuda"" il se cantonne a la gddr d'une seul des 2 cartes graphiques (la principale) ou un peut des 2.....

 
Juste la principale (pour le moment).

Bon, je vais essayer d'être plus méchant avec la mémoire, ca prendra plus de temps d'exécution, mais je vais faire du shuffle (style je remplis un bloc avec des données, et je les copie partout plusieurs fois).

Je vous cache pas que cela prendra du temps avant d'être au point Mais patience, courage, et merci de m'aider

T'utilises combien de thread ? Parce que je sais pas comment fait Cuda, mais pour un minimum faire mal aux contrôleurs RAM faudrait sans doute avoir un multiple du nombre de ROP...
 
Apres je sais pas comment marche l'algo de memtest (s'il parcoure lineairement de A à Z la RAM ou fait des test aléatoire par zone de taille variable).

Memtest est linéaire dans quasiment tous ses tests, mon memtest aussi.

Actuellement, dans la première version, j'en suis à 16 threads qui écrivent par paquets de 64 bits dans la mémoire.

Augmenter le nombre de threads n'a pas l'air, sur ma 9800GTX, d'améliorer les perfs (en termes de temps d'exécution). Et pour cause, elle a 16 ROP

J'ai fait des modifs récemment (plutot que chaque thread travaille sur 1/16ème de la mémoire, chaque thread travaillera sur 1/16/1000 de la mémoire, et ce, 1000 fois, pour arriver au total, et ainsi augmenter la réactivité de l'affichage.

Je suis en train de me demander si je devrais pas écrire de plus larges paquets que 64 bits, après réflexion.

En plus de la tension, faut baisser la fréquence si tu veux gagner en chaleur, mais bon la c'est clairement un refroidissement sous dimensionné

Tetedeiench> Au cas où tu ne l'aurais pas vu, HFR a (re)testé CUDA il y a 4 jours :
http://www.hardware.fr/articles/72 [...] ation.html

Fouge, tu sais que je t'aime, toi ?

J'adore le paragraphe suivant :

Merci énormément, ca explique pas mal de choses. Ca va optimiser CUDAMemTest grave En fait, cela devrait diviser le nombre d'accès mémoire par 16, carrément... Ca explique peut-être les mauvais résultats de la 1.1...

MERCI FOUGOUNET D'AMOUR 11111!

Allez, j'espère que ca sera lâché demain
 
Prions mes frères

J'ai bon espoir pour demain Stay tuned

Mais y vont nous faire des p'tits ceux-là

Plus sérieusement, ça ne risque pas d'être spécifique aux architecture G8x et G9x  quid des GTxxx ?
En d'autres termes, ne vas-tu pas devoir faire une version différente à chaque changement d'archi ?

On a déjà essayé. Mais depuis que fouge n'arrive plus à s'asseoir et vu la pauvreté des résultats, ben...
 
Insémination artificielle. Y a plus que ça.

Je viens d'éditer

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.