Publicité
Dernier test
Intel Centrino 2 : la preview

Intel Centrino 2 : la preview Intel a lancé cette semaine sa plateforme Centrino 2. Centrino 2 se présente comme une mise à jour complète de la plateforme : nouveaux CPU, nouveaux chipsets, nouvelles cartes WiFi, Wimax, Ethernet, modules Turbo Memory. Présentation et premiers tests Lire la suite

Voir tous les tests et comparatifs Cartes graphiques

Riva Tuner : réactiver les 16 pipes des GeForce 6800

Vendredi 6 août 2004 à 09:25 par Florian Charpentier
Source: Présence PC
90 commentaires
Alexey Nikolaychuck, la personne à l'origine du très bon Riva Tuner, serait parvenu à activer par voie logicielle les 4 pipelines désactivés des GeForce 6800. Passant de 12 pipelines à 16, cette carte retrouve ainsi les performances de la GeForce 6800 GT, comme ont pu le constater nos confrères Digit-Life. Evidemment, dans le cas où les 4 pipelines seraient effectivement défectueux (cette carte permettant notamment de récupérer des GeForce 6800 GT/Ultra avec des pipelines non fonctionnels), des artefacts apparaîtront, mais il convient de saluer cette trouvaille alors que nVidia avait prévenu initialement que cette manipulation ne serait pas possible.



Riva Tuner beta devrait bientôt être disponible, et il faudra alors observer le nombre de cartes passant sans problème à 16 pipes pour être vraiment fixé concernant les GeForce 6800.

Réagissez ! Retour à la liste des news
Publicité
Commentaires

obi0ne 06/08/2004 09:48
Masquer
-0+
obi0ne
"cette manipulation ne serait pas possible" :

impossible n'est pas humaine. :D
rexet 06/08/2004 10:07
Masquer
-0+
rexet
pas mal cette news moi qui voulait une GT :love:
DML777 06/08/2004 10:21
Masquer
-0+
DML777
Ca va faire comme pour les radeon 9800SE cette histoire : un coup de poker...
FAiRLiGHT 06/08/2004 11:03
Masquer
-0+
FAiRLiGHT
c'est quoi cette histoire de pipes ? :o

[:nedurb]
gg53 06/08/2004 11:09
Masquer
-0+
gg53
Et ce genre d'activation marche t-elle avec les écrans 17" en 19"? :pt1cable:
mopoulpo 06/08/2004 11:34
Masquer
-0+
mopoulpo
WinFast A400 GT TDH 256 Mo (6800 GT) 449€ :)

http://www.lesprix.net/prix/fichev [...] 169&list=1

Asus 9999 Gamer Ed (6800) 449€ :ange:

Et la Leadtek est probablement overclockable (vu le system de refroidissement)
silgit 06/08/2004 11:58
Masquer
-0+
silgit
franchement ils allaient pas dire que c ete possible sinon quel interet de prendre une gt ou une ultra ?

bon ca devient la carte a "presque" bon rapport qualite prix
Bichoco 06/08/2004 12:08
Masquer
-0+
Bichoco
sauf k'apparement on peut pas revenir en arriére :/
si avec les 16 pipes d'activés des artefacts apparaissent ben la crate est bonne pour la poubelle et vu le prix...
casimir59 06/08/2004 12:22
Masquer
-0+
casimir59
DML777 a écrit :

Ca va faire comme pour les radeon 9800SE cette histoire : un coup de poker...





+1 :jap: . Mais généralement, ce sont les premiers modèles sortis qui sont boostables, car: afin de pouvoir livrer une quantité suffisante de chips pour les différentes gammes lors de la sortie des nouveaux modèles, le constructeur fabrique un seul type de GPU (ou VPU chez ATI) 100% fonctionnel en "haut de gamme" (Geforce 6800 GT/Ultra) mais le bride volontairement afin de pouvoir satisfaire à la demande de chips "bas de gamme" (en l'occurence, ici, des Geforce 6800) ;) .

P.ex: le cas de la gamme GF FX 5900 (5900 XT, 5900, 5950 Ultra). Lors de la sortie (vers la fin 2003) de la gamme FX 59**, des acheteurs de FX 5900 XT (bas de gamme) ont pu monter sans pb aux fréquences d'une FX 5950 Ultra (soit: 460 Mhz GPU, 950 Mhz RAM)!!! Pourquoi ??? Parceque Nvidia devait pouvoir satisfaire la demande de GPU's pour toute sa gamme lors du lancement de sa gamme de produits :jap: . 6 mois + tard, les FX 5900 XT sont devenues "seulement" overclockables comme une FX 5900. (450 Mhz GPU, 800 Mhz RAM).

Donc, pour ceux voulant changer de CG (et ayant les moyens), fonçez vous procurer une 6800, c'est le moment!!! (histoire de passer à une 6800 Ultra et ses "16 pipes effectifs" (en les réactivant) avant qu'il ne soit trop tard.

ps: mais ça reste toujours un "coup de poker": simplement, le risque de gagner est toujours plus important pendant le lancement d'un nouveau modèle, plutot que pendant sa "fin" de carrière :jap: .
Del Gro Badeu 06/08/2004 12:24
Masquer
-0+
Del Gro Badeu
ca m'étonnerais, vu que c'est par voie logicielle ....

et c'est pas le style Nikolaychuck de mettre des fonctions iiréversibles dans son logiciels sans rien dire ;)
squall 06/08/2004 12:33
Masquer
-0+
squall
nVidia a fait exprès de laisser une possiblité. CA m'étonnerait meme pas qu'il ait "aidé" le gars de chez RivaTuner pour activer l'option au moment opportun (qq semaines après la sortie massive).

Il vont pas me faire croire qu'ils peuvent pas mettre une protection hardware... :kaola:
lucky luky 06/08/2004 12:51
Masquer
-0+
lucky luky
Ca peut être interessant si ca marche vraiment :jap:
Faudrait voir l'ecart de prix pour la difference de perf pris par le risque...
Del Gro Badeu 06/08/2004 14:28
Masquer
-0+
Del Gro Badeu
squall a écrit :

nVidia a fait exprès de laisser une possiblité. CA m'étonnerait meme pas qu'il ait "aidé" le gars de chez RivaTuner pour activer l'option au moment opportun (qq semaines après la sortie massive).

Il vont pas me faire croire qu'ils peuvent pas mettre une protection hardware... :kaola:




:sarcastic: a peine sortie, nvidia suicide le haut de gamme du NV40 ? j'y crois pas trop moi [:666 ]
cgsyanick 06/08/2004 16:09
Masquer
-0+
cgsyanick
J'ai toujours pas compris comment Intel parvenait à bloquer de façon hardware le coef de ces CPU (depuis certains P133 si mes souvenirs sont exacts), alors que les fabricants de GPU en sont toujours à des bridages logiciels...

A moins que ce soit voulu ?
bidoulou 06/08/2004 17:03
Masquer
-0+
bidoulou
bichoco a écrit :

sauf k'apparement on peut pas revenir en arriére :/
si avec les 16 pipes d'activés des artefacts apparaissent ben la crate est bonne pour la poubelle et vu le prix...




c'est une modif soft, je ne vois pas où est le problème ?
casimir59 06/08/2004 17:42
Masquer
-0+
casimir59
cgsyanick a écrit :

J'ai toujours pas compris comment Intel parvenait à bloquer de façon hardware le coef de ces CPU (depuis certains P133 si mes souvenirs sont exacts), alors que les fabricants de GPU en sont toujours à des bridages logiciels...

A moins que ce soit voulu ?





Un CPU et un GPU (ou VPU) restent trés différents ;) .

Pour un CPU, tu choisis de lui associer un type de RAM, la carte-mère, etc...
Pour un GPU (ou VPU), tu achètes une carte vidéo, laquelle comprend:
le processeur, la carte qui l'héberge, plus la mémoire RAM.

Pour un CPU, il existe différents chipsets (+ ou - performants), la fréquence de bus système correspondant à la RAM employée et au processeur. Par rapport à sa fréquence, tu peux modifier sont coeff multiplicateur (dans le meilleur des cas quand ce dernier est débridé) et/ou son FSB (bus système), et ainsi sa fréquence ;) .
Pour un GPU (ou VPU), tu ne peux modifier que la fréquence du GPU (VPU) et de la RAM. (pas de coeffs multiplicateurs).
cgsyanick 06/08/2004 17:46
Masquer
-0+
cgsyanick
casimir59 a écrit :

Un CPU et un GPU (ou VPU) restent trés différents ;) .

Pour un CPU, tu choisis de lui associer un type de RAM, la carte-mère, etc...
Pour un GPU (ou VPU), tu achètes une carte vidéo, laquelle comprend:
le processeur, la carte qui l'héberge, plus la mémoire RAM.

Pour un CPU, il existe différents chipsets (+ ou - performants), la fréquence de bus système correspondant à la RAM employée et au processeur. Par rapport à sa fréquence, tu peux modifier sont coeff multiplicateur (dans le meilleur des cas quand ce dernier est débridé) et/ou son FSB (bus système), et ainsi sa fréquence ;) .
Pour un GPU (ou VPU), tu ne peux modifier que la fréquence du GPU (VPU) et de la RAM. (pas de coeffs multiplicateurs).




Il est gentil lui :D

je te parle pas de sous système (on n'en a strictement rien à faire dans l'histoire) mais de la puce qui lors de sa conception pour le P4 est identique en ce qui concerne un P4C 2.4 ou un P4C 3.2, le bloquage du coef n'intervenant que plus tard... Alors pourquoi ne pas utiliser le même procédé de modification hardware après avoir réalisé le GPU [:huhu] ?
cgsyanick 06/08/2004 17:57
Masquer
-0+
cgsyanick
Je la refais pour ceux qui ont l'air d'avoir du mal... Sur ta chaîne de production qui sort des 6800, des Athlon XP ou des P4, tous sont identiques au départ. Seulement pour certaines raisons, certains verront des défauts apparaître (pipelines ou cache défectueux par exemple). La politique des fondeurs récemment est de récupérer les puces défectueuses et de sortir des produits bridée en désactivant les parties justement défectueuses des puces.
Un phénomène analogue (mais légèrement différent) fait que tel puce tiendra une fréquence, alors qu'une autre produite de la même façon non. Ainsi sortiront de la même chaîne de production des XP2500+ et des XP3200+ (l'exemple est volontaire, pour montrer que ce qui sort est également influencé par le jeu de l'offre et de la demande).

Et ce QUEL QUE SOIT LE TYPE DE PUCE, CPU OU GPU !

AMD bride ses durons à l'aide de ponts en ce qui concerne le cache. (et également le coef si je ne me trompe pas, mais nous y reviendrons)
Intel bride DEPUIS CERTAINS PENTIUM 133 le coef de façon hardware.
ATI bride le nombre de pipelines utilisables à l'aide d'un pont également il me semble (mais activable AUSSI par voie logicielle - rectifiez moi si je me trompe)
Nvidia bride de façon logicielle apparemment les pipelines utilisables.

Ma question reformulée est :
Pourquoi tel bridage sera réalisé de façon logicielle (dans le bios de la carte qui va accueillir le gpu par exemple), et tel autre de façon hardware (le bios de ta carte mère aura beau faire tout ce qu'il peut, il ne réactivera pas les coefs bloqués de ton P4 sauf s'il d'agit d'un ES qui lui verra CERTAINS de ses coefs débloqués)

On se contrefiche ici du sous système mémoire utilisé, du chipset, de la qualité du pcb de la carte mère/carte vidéo, de la quantité de ram ou de l'age du capitaine !
casimir59 06/08/2004 18:15
Masquer
-0+
casimir59
Ahhh...Bonne question :??: (peut-etre pour "brider mais pas trop", histoire d'acquérir la clientèle bidouilleuse :??: ).
Wivern 06/08/2004 18:25
Masquer
-0+
Wivern
cgsyanick a écrit :

Je la refais pour ceux qui ont l'air d'avoir du mal... Sur ta chaîne de production qui sort des 6800, des Athlon XP ou des P4, tous sont identiques au départ. Seulement pour certaines raisons, certains verront des défauts apparaître (pipelines ou cache défectueux par exemple). La politique des fondeurs récemment est de récupérer les puces défectueuses et de sortir des produits bridée en désactivant les parties justement défectueuses des puces.
Un phénomène analogue (mais légèrement différent) fait que tel puce tiendra une fréquence, alors qu'une autre produite de la même façon non. Ainsi sortiront de la même chaîne de production des XP2500+ et des XP3200+ (l'exemple est volontaire, pour montrer que ce qui sort est également influencé par le jeu de l'offre et de la demande).

Et ce QUEL QUE SOIT LE TYPE DE PUCE, CPU OU GPU !

AMD bride ses durons à l'aide de ponts en ce qui concerne le cache. (et également le coef si je ne me trompe pas, mais nous y reviendrons)
Intel bride DEPUIS CERTAINS PENTIUM 133 le coef de façon hardware.
ATI bride le nombre de pipelines utilisables à l'aide d'un pont également il me semble (mais activable AUSSI par voie logicielle - rectifiez moi si je me trompe)
Nvidia bride de façon logicielle apparemment les pipelines utilisables.

Ma question reformulée est :
Pourquoi tel bridage sera réalisé de façon logicielle (dans le bios de la carte qui va accueillir le gpu par exemple), et tel autre de façon hardware (le bios de ta carte mère aura beau faire tout ce qu'il peut, il ne réactivera pas les coefs bloqués de ton P4 sauf s'il d'agit d'un ES qui lui verra CERTAINS de ses coefs débloqués)

On se contrefiche ici du sous système mémoire utilisé, du chipset, de la qualité du pcb de la carte mère/carte vidéo, de la quantité de ram ou de l'age du capitaine !




Respire fort : ça va aller :lol:

Il est fort possible que le bridage materiel ne soit tout simplement pas possible sur les GPU au vue de leurs structures et que AMD choisisse de brider ses processeurs de façon logiciel eventuellement pour des raisons de cout de production : je suppose toujours que le bridage materiel de masse doit engendrer un cout supplémentaire :jap:
cgsyanick 06/08/2004 18:28
Masquer
-0+
cgsyanick
wivern a écrit :

Respire fort : ça vas aller :lol:

Il est fort possible que le bridage materiel ne soit tout simplement pas possible sur les GPU au vue de leurs structures et que AMD choisisse de brider ses processeurs de façon logicielle eventuellement pour des raisons de cout de production : je suppose toujours que le bridage materiel de masse doit engendrer un cout supplémentaire :jap:




L'argument tient la route :jap:

Enfin ça résoud pas un certain problème : par quel moyen nvidia parvient à l'aide du bios de la carte vidéo à définir QUEL groupe de pipelines sera désactivé car défecteux ? C'est pas toujours le même groupe qui prend tout de même [:dawa] !! (même question pour le cache des durons)

H.S. : Il parrait que je suis succeptible sur les sujets traitant des CPU/GPU :whistle:
Wivern 06/08/2004 18:42
Masquer
-0+
Wivern
cgsyanick a écrit :

L'argument tient la route :jap:

Enfin ça résoud pas un certain problème : par quel moyen nvidia parvient à l'aide du bios de la carte vidéo à définir QUEL groupe de pipelines sera désactivé car défecteux ? C'est pas toujours le même groupe qui prend tout de même [:dawa] !! (même question pour le cache des durons)

H.S. : Il parrait que je suis succeptible sur les sujets traitant des CPU/GPU :whistle:




Sur les chaines de fabrication ils doivent avoir des machines qui testent et diagnostiquent les processeurs et il est facile apres d'y adjoindre une unité de prod qui récupérant les données d'analyse va désactiver les parties hors d'usage :D

Ou ils sont idiots et ils foirent toujours la même partie exprès pour fabriquer des gpu bas de gamme :pt1cable:
cgsyanick 06/08/2004 18:45
Masquer
-0+
cgsyanick
wivern a écrit :

Sur les chaines de fabrication ils doivent avoir des machines qui testent et diagnostiquent les processeurs et il est facile apres d'y adjoindre une unité de prod qui récupérant les données d'analyse va désactiver les parties hors d'usage :D

Ou ils sont idiots et ils foirent toujours la même partie exprès pour fabriquer des gpu bas de gamme :pt1cable:




Cela fonctionnerait pour les bridages hard, mais pas soft justement :pt1cable:
Wivern 06/08/2004 18:49
Masquer
-0+
Wivern
cgsyanick a écrit :

Cela fonctionnerait pour les bridages hard, mais pas soft justement :pt1cable:




Pourquoi le bridage logiciel ne pourrait pas ce faire selon les parties defectueuses localisé par une analyse du GPU ???
Patch 06/08/2004 18:56
Masquer
-0+
Patch
cgsyanick a écrit :

Cela fonctionnerait pour les bridages hard, mais pas soft justement :pt1cable:


et pquoi pas? suffirait de séparer les pipelines par groupes ou à l'unité, et de dire au soft quels pipelines/groupes de pipeline désactiver
cgsyanick 06/08/2004 18:57
Masquer
-0+
cgsyanick
wivern a écrit :

Pourquoi le bridage logiciel ne pourrait pas ce faire selon les parties defectueuses localisé par une analyse du GPU ???




Prend une 6800, elle a 4 de ses pipelines désactivés (mais personne ne sait lesquels, ni vous, ni nous - le chat gnagnagn...) de façon logicielle donc. Quel est la seul partie soft de la carte vidéo qui pourrait brider et désactiver ces pipelines ? le bios de la carte vidéo. Hors ça m'étonnerait qu'il y ait 4 types de bios différents (1 pour chaque groupe de pipelines à désactiver) pour une même carte :pt1cable:
Ou alors le bios SAIT quels sont les pipelines à désactiver, car ceux ci sont "marqués" physiquement dans le gpu (ce qui poserait de nouvelles question : pourquoi nvidia marquerait-il ces pipelines de façon hardware mais les désactiverait de façon soft ? La théorie du petit bidouilleur content ne serait alors pas si bête que ça). Autre possibilité, la carte teste à chaque démarrage quels sont les pipelines defecteux.
Mais cela ne fonctionne pas avec les durons dont le cache est désactivé : il suffit d'un pont pour brider/débrider le cache non ? Hors comment avec UN pont définir lequel des QUATRES groupes possibles de 64k est bon ?

Je sais pas si je suis clair :D
cgsyanick 06/08/2004 18:58
Masquer
-0+
cgsyanick
Patch a écrit :

et pquoi pas? suffirait de séparer les pipelines par groupes ou à l'unité, et de dire au soft quels pipelines/groupes de pipeline désactiver




cf post précédent :D
Patch 06/08/2004 19:01
Masquer
-0+
Patch
poru les duron c simple : utiliser +sieurs ponts différents (on parle DES ponts, pas DU pont), qu'on regroupe sous un même nom, et couper ceux qui activent les parties à désactiver
cgsyanick 06/08/2004 19:06
Masquer
-0+
cgsyanick
Patch a écrit :

poru les duron c simple : utiliser +sieurs ponts différents (on parle DES ponts, pas DU pont), qu'on regroupe sous un même nom, et couper ceux qui activent les parties à désactiver




Si je me trompe pas il suffit de relier LE dernier pont L2 non :heink:

De toute façon ça ne résoud pas le problème des pipelines de notre chère (:D) 6800 ;)
Wivern 06/08/2004 19:27
Masquer
-0+
Wivern
cgsyanick a écrit :

Prend une 6800, elle a 4 de ses pipelines désactivés (mais personne ne sait lesquels, ni vous, ni nous - le chat gnagnagn...) de façon logicielle donc. Quel est la seul partie soft de la carte vidéo qui pourrait brider et désactiver ces pipelines ? le bios de la carte vidéo. Hors ça m'étonnerait qu'il y ait 4 types de bios différents (1 pour chaque groupe de pipelines à désactiver) pour une même carte :pt1cable:

Ou alors le bios SAIT quels sont les pipelines à désactiver, car ceux ci sont "marqués" physiquement dans le gpu (ce qui poserait de nouvelles question : pourquoi nvidia marquerait-il ces pipelines de façon hardware mais les désactiverait de façon soft ? La théorie du petit bidouilleur content ne serait alors pas si bête que ça).

[g]Il me semble que de toute façon la seule partie logicielle embarquée dans une carte graphique est le bios ou le firmware ... c'est improbable que ce soit le driver de la carte qui procede a son analyse et qui fasse la désactivation :pt1cable: [/g]

Autre possibilité, la carte teste à chaque démarrage quels sont les pipelines defecteux.
Mais cela ne fonctionne pas avec les durons dont le cache est désactivé : il suffit d'un pont pour brider/débrider le cache non ? Hors comment avec UN pont définir lequel des QUATRES groupes possibles de 64k est bon ?

Je sais pas si je suis clair :D




Sinon le plus probable est le marquage physique des pipeline a désactivé et par le bios on procede a leur désactivation logiciel :jap:

Quand au pourquoi on peut emettre la possibilité qu'une désactivation materielle soit trop délicate a faire surtout pour fabriquer en definitive des cartes a moindre cout donc la solution retenue serait celle représentant le plus faible surcout de production.

je ne pense pas que le fabricant tienne compte des petits bricoleurs dans ces choix de production :o
Patch 06/08/2004 19:50
Masquer
-0+
Patch
cgsyanick a écrit :

Si je me trompe pas il suffit de relier LE dernier pont L2 non :heink:

De toute façon ça ne résoud pas le problème des pipelines de notre chère (:D) 6800 ;)


non ce sont LES ponts L2 ;)
il y en a 4 ou 5, et l'ensemble s'appelle "L2" (et c pareil pour les autres ponts)

A savoir Vous allez poster en tant qu'utilisateur anonyme.



Publicité