Téléchargez l'application
Tom's Hardware sur l'App Store
Toute l'actu informatique de référence sur votre iPhone
Oui Non

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

par - source: Présence PC
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.
Partager:
90
Commentaires
X
Valider

Commentaires
Ajouter un commentaire
obi0ne 06/08/2004 09:48
Masquer
-0+

"cette manipulation ne serait pas possible" :

impossible n'est pas humaine. :D

rexet 06/08/2004 10:07
Masquer
-0+

pas mal cette news moi qui voulait une GT :love:

DML777 06/08/2004 10:21
Masquer
-0+

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

FAiRLiGHT 06/08/2004 11:03
Masquer
-0+

c'est quoi cette histoire de pipes ? :o

[:nedurb]

gg53 06/08/2004 11:09
Masquer
-0+

Et ce genre d'activation marche t-elle avec les écrans 17" en 19"? :pt1cable:

mopoulpo 06/08/2004 11:34
Masquer
-0+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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+

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

Publicité

Les offres du moment

Newsletters


OK