- Catalyst 4.9 Beta : le bilan
- Catalyst 4.9 Beta disponibles
- ATI vs Nvidia : 1 - 1
- ATI Catalyst 4.9 dopés pour Doom 3 ?
- Longhorn rendra le bureau Windows en 3D
- Pilotes Catalyst 4.7 pour Windows 98/Me
- GeForce 6800 FanLess
- Un comparatif entre GeForce 6800 GT/Ultra/5950 Ultra
- Radeon 9250
- ForceWare 61.77 avec support DirectX 9c
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
Riva Tuner : réactiver les 16 pipes des GeForce 6800

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
- Baisse du prix de la mémoire
- Premier retard pour Counter-Strike : Source
- Riva Tuner : réactiver les 16 pipes des GeForce 6800
- [Edito] Asus et les cartes mères dopées
- Nouveaux radiateurs Thermalright
- Premier virus s'attaquant aux PDA
- 1 / 3
- Suivante
-
http://www.lesprix.net/prix/fichev [...] 169&list=1
Asus 9999 Gamer Ed (6800) 449€
Et la Leadtek est probablement overclockable (vu le system de refroidissement)
| DML777 a écrit : Ca va faire comme pour les radeon 9800SE cette histoire : un coup de poker... |
+1
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
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
| 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). |
:sarcastic: a peine sortie, nvidia suicide le haut de gamme du NV40 ? j'y crois pas trop moi
| 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... |
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).
| casimir59 a écrit : Un CPU et un GPU (ou VPU) restent trés différents |
Il est gentil lui
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
?
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 !
| 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. |
Respire fort : ça va aller
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
| wivern a écrit : Respire fort : ça vas aller |
L'argument tient la route
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
!! (même question pour le cache des durons)H.S. : Il parrait que je suis succeptible sur les sujets traitant des CPU/GPU
| cgsyanick a écrit : L'argument tient la route |
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
Ou ils sont idiots et ils foirent toujours la même partie exprès pour fabriquer des gpu bas de gamme
| 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 |
Cela fonctionnerait pour les bridages hard, mais pas soft justement
| 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
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
| 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
De toute façon ça ne résoud pas le problème des pipelines de notre chère (
| 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 |
Sinon le plus probable est le marquage physique des pipeline a désactivé et par le bios on procede a leur désactivation logiciel
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
- 1 / 3
- Suivante
-


![[:nedurb] [:nedurb]](http://img.infos-du-net.com/forum/images/perso/nedurb.gif)





impossible n'est pas humaine.