Reprise du message précédent :

Ben je suis pas expert non plus, mais t'as le rendement qui rentre en compte.

Sur une alim à 80%, si tu as 1000W mesurés à la prise, ca signifie que ta config consomme 800W ( 1000W * 80% = 800W ). J'imagine que les specs de l'alim concernent la puissance en sortie (sous-entendu : la puissance demandée par la config), donc il doit te rester encore de la marge (tu devrais pouvoir encore mettre une troisième carte graphique - si c'était possible bien entendu ).

Maintenant, je suis pas une sommité sur le sujet, d'autres confirmeront / infirmeront les probables conneries que je viens de débiter

Non, non, c'est bien ça.

Oki doki merci bien , j'ai matté , elles sont entre 85% et 88% de rendement (donné constructeur) donc ouais je calculerai en fonction de cela alors
 
Déja c'est pas mal vu la config , je sais pas un Tri SLI 285GTX consommera plus qu'un CF de HD4870x2
 
J'esssayerai de tester le week end prochain

+1 je confirme, tres bon rendement...

ca consomme plus un tri-sli de gtx285...

280GTX

280 ou 285 GTX c'est du kif kif de toute facon
 
A voir mais bon vais rester sur ce protocole de test deja il est pas mal (vers la fin du test j'étais entre 1120w et 1150w a la prise) donc bon avec le rendement constructeur , c'est deja pas mal je trouve pour exploiter bien ces grosses betes

Sinon tu rajoutes des HDD... Meme sans les brancher au SATA, a 10W l'HDD ca commence a faire au bout d'une dizaine
 
De meme si t'as de la place pour de la RAM et des cartes PCI/PCIe et truc USB

Erm, les gars, je viens de recevoir le processeur en don, de la part d'intel, via materiel.net... (encore que je me demande si c'est pas materiel.net directement).

Je savais que c'était un i7, ce que je savais pas, c'est que c'était un i7 965 Extreme Edition

Et ils m'ont eu une carte mère SLI en don (!) de la part de gigabyte aussi

    alors là je dis "chapeau"

Le proco viens bien d'Intel J'avais un furieux doute

Merci Intel Merci Materiel.net

waw c'et géant ça !
Mais c'est largement mérité avec tout le travail que tu as fait sur occt ^^

Ben en l'occurence, ils dépensent quand même énormément d'énergie, et franchement, ca motive son homme.

Je ferai une grosse communication là dessus, surement lors de la sortie de la 3.0.1, ils le méritent bien... c'est rare de rencontrer des gens sympathique, déintéressés (car là, c'est le cas), et qui s'impliquent dans un projet comme le mien

Avec tout ça, j'avais peur de pas avoir de matos de test, je me retrouve :

• Avec une GTX260 prêtée par LDLC qui me permet de vérifier les GT200
• Avec une GTX285 prêtée par Nvidia via Matériel.net qui me permettra de vérifier les GT200b
• Avec un i7 donné (!) par Intel qui me permettra de tripatouiller l'HT comme il se doit (je me demande si linpack est plus efficace en 2 instances avec HT ou en une seule...)

Franchement merci les gars, LDLC, materiel.net, Intel, Nvidia

Comme quoi OCCT est loin d'être inutile.

 
Ben carrément
 
Ca fait plaisir, en fait, après une longue traversée du désert, de te retrouver dans ce genre de cas

bonne nouvelle ça, un travail bien recompensé

Clairement Et ca va bien me servir pour OCCT, j'aurai la nouvelle archi Intel dés le début de sa vie, ce qui m'évitera tous les ennuis que j'ai eu, comme avec la sortie du C2D... Avec ca, je devrais être paré pour quelques années... une fois que ca sera supporté, roulez jeunesse !
 
Restera à faire avec toutes les générations de cartes graphiques

Stapel aux dons caché    !
 
 

Pas besoin de dons pour les cartes, des prêts suffiront

Et pour le moment, honnêtement, il suffirait que Nvidia (dans un monde parfait) lance CudaMemTest sur chaque nouvelle génération de driver/Cuda et co.

Ou un test d'allocation similaire.

Mais là, à mon avis, CudaMemTest n'est pas assez robuste, mature pour y prétendre.

On va voir comment ca évolue Je reproduis mon environnement de test pour débusquer le bug GT200, je vous dirai aussi si il se reproduit avec des GT200b.

Le 965 est débloqué coté multiplicateur
 

C'est l'avantage des Extreme Edition .

GG le iench !!

La petite config qui tue tout

La config de dev OCCT ressemblera donc à :
core i7 965
CM Gigabyte X58 SLI
2x 9800GTX SLI

je sais pas encore pour la ram

6Go de DDR3
Pas mal ta nouvelle config

La vache, j'ai un crash du pilote sous GPU:Memtest sous Vista32, carrément

Tu va pouvoir faire le geek avec ça !

Il semblerait que sous Vista, on soit limité à un nombre de malloc sur la carte graphique en fait...
 
Ca foire sur 512MB avec une talle de bloc à 128KB, ca marche avec une taille de bloc à 256KB... marrant.

Rectification : impossible de faire plus de 4096 mallocs sous Cuda sous Vista.

Cette limite n'est documentée nulle part.

Toutes les cartes ayant plus de 512Mo de RAM et supportant CUDA sont donc touchées (je fais des mallocs avec des blocs de 128Ko, donc fatalement, ca tape dans les 524Mo).

Je sais pas trop trop comment faire, là

je vais voir sous XP.

Sous XP, pas de souci.
 
Bon ben rapport de bug, le workaround doit être trouvable, faut que je le murisse cependant

Bon, me vla avec pas mal de soucis :

• Si j'ai un trop gros espace mémoire, le malloc se passe mal (failed). Donc un seul et unique malloc passera pas (style un bloc de 700Mo)
• Si j'ai que des blocs de petite taille (128KB), ca passe pas sous Vista (ils sont trop nombreux, je tape la limite des 4096)
• Si j'ai des blocs de trop gros que j'écris en une fois (sous vista, je sais que le trigger se lance aux environs de 1Mo, peut être en dessous), le système considère que le pilote a crashé (si, si...)

==> Il faut que je fasse des mallocs de blocs importants (plusieurs Mo), de taille variable (sigh), et que j'écrive dedans par partie (i.e. que je ne remplis pas entièrement d'un coup). Evidemment, ca complexifie énormément le bordel (surtout avec les algos en place).  
 

 
Bon, je fais le rapport de bug quand même, car le gars qui a une liste chainée en CUDA va vite faire la gueule avec ses 4096 éléments...

Et ce bug ça change quelque chose en jeu?

En jeu on utilise pas CUDA donc là n'est pas le pb.

Si le jeu exploite CUDA (donc ceux utilisant PhysX je suppose) il doit être confronté aux mêmes limitations...

ok

J'ose espérer que les mecs qui dev. le PhysX, on accès a une doc ultra précise (voir meme au sources) de CUDA et du pilotes graphique.
 
Du coup ils ont p'tet reussi a limiter au maximum les allocations mémoire.

 
Cuda en jeu, c'est des micro-kernels, qui font plus du calcul que du taff sur la mémoire intensif comme je le fais, donc il ne devrait pas y avoir de problème.
 
Maintenant, c'est clairement quelque chose à fixer d'urgence pour eux, à mon avis. Personne l'a vu avant moi car on est au tout début, mais c'est quand même un bug franchement critique...

Tu parles de ceux qui dev le driver PhysX (des dev de chez nVidia donc) ou des dev de jeux qui utilisent PhysX ? Parce que ces derniers n'en n'ont rien à carrer de CUDA, et ils ont bien raison. Par contre j'espère qu'ils ont toutes les doc de PhysX ainsi que leur limitations exactes (limitations qui héritent en partie de celles de CUDA, si nVidia a bien fait son boulot concernant PhyX et le driver).

C'est bon, je crois avoir le workaround, qui ne peut fonctionner que parce que j'ai obtenu le fix du bug précédent.
 
Par contre, Cuda 2.1 obligatoire (et donc, 181.22 ou + obligatoire).

Ouai enfin spa gagné.
 
Pilote crashé, watchdog qui se déclenche, tout ça...

courage .. on est tous derriere toi