Pour un développeur programmant autre chose qu'un jeu, il est difficile d'évaluer si transférer les calculs sur le processeur graphique est intéressant, d'autant plus si la complexité des calculs peut être variable.
Quelques voix s'élèvent pour pointer ces problèmes qui peuvent laisser penser que le traitement graphique hors du processeur n'a plus que quelques années devant lui.
La victime de cet état de fait pourrait bien être NVidia. Un très intéressant billet sur Macbidouille, nous offrant un retour d'expérience d'un développeur utilisant OpenCL sous Snow Leopard (Mac OS X). Si la technologie Grand Central, qui simplifie le développement multithread est considéré comme une avancée pas trop difficile à absorber, la technologie OpenCL pose de très gros problèmes.
En effet, un processeur graphique se trouve "géographiquement" au loin, au bout d'un port PCI Express. Si le débit de ce sous-système a été largement amélioré depuis les AGP voire PCI, le transfert mémoire des données nécessaire au calcul est long et coûteux. Il faut ensuite évaluer si le processeur graphique sera plus intéressant en terme de coût de calcul eu égard à la possibilité de paralléliser lesdits calculs.
Le problème est assez bien présenté dans ce document : le processeur graphique est une brute en calcul pur, mais est très mauvais pour les tests (peu d'unités y sont consacrés), et donc pour les boucles. Il faut donc user de stratégies savamment tordues pour contourner cet épineux problème. Et même si on a réussi, on n'est même pas sûr que c'est intéressant, sans compter qu'on ne peut pas toujours connaître à l'avance la complexité des calculs… Dans un jeu 3D si, mais dans d'autres domaines…
Pour vous convaincre que coder avec OpenCL est un vrai bordel : http://s08.idav.ucdavis.edu/munshi-opencl.pdf.
La synthèse de tout cela ? Comme l'explique toujours aussi brillamment Tim Sweeny, CEO fondateur de Epics Game (les moteurs Unreal Tournament), le processeur graphique est mal barré. Trop rigide, trop "loin" de la mémoire centrale, trop de contraintes d'exploitation vont rendre difficile son utilisation pour la haute performance, même si de gros efforts sont faits.
Donc, rapide petit tour d'horizon sur l'état du marché et des feuilles de route/contraintes technologiques :
- NVidia est seul, mais leader ;
- Intel ne sait pas faire encore des processeurs graphiques qui tiennent la route face au spécialiste, mais ça vient doucement mais sûrement ;
- Intel produit des processeurs et a l'intention de coller des traitements graphiques dans ces processeurs; dans ce cas fini le problème d'accès mémoire ;
Intel mise sur des architectures superscalaires, où au lieu de devoir donner à manger aux lointains successeurs du MMX en alignant gentiment les scalaires en mémoire, on pourra lui donner un tableau de pointeurs, et donc faire des calculs de manière plus flexible (diapositives 48 à 57 de la présentation de Sweeney) ;
- ATI est légèrement derrière NVIDIA en terme de performances, mais de peu ;
- AMD peut coller un traitement graphique dans ces processeurs.
AMD est en mauvaise posture mais possède ATI ;
Conclusion, NVidia est mal barré, et j'ai du mal à croire qu'ils vont s'en sortir en mettant des processeurs graphiques dans des ARM, quoique vue la taille du marché, cela pourrait peut-être suffire ?
# Sympa le troll !
Posté par Xavier Bestel (site web personnel) . Évalué à 8.
En gros, NVIDIA est leader, mais comme peut-être qu'Intel et AMD feront mieux dans l'avenir, ils est mal barré.
Mouais.
Ça sent le troll.
[^] # Re: Sympa le troll !
Posté par auve . Évalué à 8.
La nouvelle itération de l'architecture ATI sort vendredi, et ça risque d'être une sacrée déconfiture pour la firme au caméléon. Cela a provoqué un sondage plutôt amusant sur le célèbre forum de Beyond3D : http://forum.beyond3d.com/showthread.php?t=54918
[^] # Re: Sympa le troll !
Posté par Prosper . Évalué à 6.
C'est quoi le rapport entre la qualité du hardware et un marketing pourri ?
[^] # Re: Sympa le troll !
Posté par auve . Évalué à 6.
À la relecture de mon commentaire précédent, j'ai été un peu sévère ; je ne pense pas que les cartes Nvidia soient de mauvaise qualité ; je pense juste que celles d'ATI sont plus efficaces et élégantes au niveau de l'approche, ce qui leur permet d'ailleurs d'être très agressifs au niveau prix actuellement.
[^] # Re: Sympa le troll !
Posté par bubar🦥 (Mastodon) . Évalué à 6.
Très difficile de touver un portable puissant avec une nivdia. 9 portables sur 10 "haut de gamme" chez 4 marchands différents possédaient une ATI. (alors qu'il y a encore 2 3 ans, ati c'était l'entrée de gamme)
Bien entendu cela n'a rien de techniques comme arguments. Et si les constructeurs intègrent plus de ATI que e Nvidia dans leur portable, c'est certainement pas par choix technique direct... plutôt au mieux un "pareil pour moins cher"...
Nvidia paye aussi peut être les cartes pourries livrées sur certains modèles il n'y a pas longtemps ?
Ce n'est qu'un reflet partiel du marché français.
/*ma vie*/
En bon linuxien je suis reparti bredouille, devant la complexité de choix d'une ATI, et devant l'absence de portable haut de gamme avec une intel (haut de gamme semble signifier forcément "avec une carte graphique de-la-mort-qui-tue-(c) )"
/*ma vie*/
Enfin la dépêche oublie quant même Apple, qui est passé, lui, assez globalement à Nvidia. Le journal oublie aussi les cartes graphiques professionnelles (auparavant le panache de ATI, d'où certainement l'origine d'un petit soutien à Linux du fait que Ati était très présent sur les Unix) : Nvidia propose la série des FX par exemple, dédiée pour l'affichage 2D -aucune concurence et marché important et cartes hors de prix- ainsi que toute la gamme des cartes de "puissance supérieure" pour la 3D. Et enfin tout le marché des consoles de jeux ! il est où ati ? sur la wii, ok... Bref, l'avenir à long terme est peut être "sombre" selon ces déclarations mais à court terme tout va bien et moyen ils ont le temps d'évoluer eux aussi, au pire.
Merci pour cette dépêche, et pour vos commentaires techniques (un régal à suivre)
[^] # Re: Sympa le troll !
Posté par Alek_Lyon . Évalué à 2.
/*ma vie*/
En bon linuxien je suis reparti bredouille, devant la complexité de choix d'une ATI, et devant l'absence de portable haut de gamme avec une intel (haut de gamme semble signifier forcément "avec une carte graphique de-la-mort-qui-tue-(c) )";
/*ma vie*/
Pour info, les derniers Thinkpad viennent souvent avec deux cartes cartes graphiques : une ATI et une intel...
[^] # Re: Sympa le troll !
Posté par Prosper . Évalué à 3.
Aux dernières nouvelles, la xbox 360 embarque toujours un GPU ati ( Xenos )...
[^] # Re: Sympa le troll !
Posté par bubar🦥 (Mastodon) . Évalué à 1.
A tel point que je visualisais le logo Nvidia dessus !
ça m'apprendra à (pas) vérifier, tiens ! (bon je vis assez loin de toute console à ma décharge \_0 )
merci.
[^] # Re: Sympa le troll !
Posté par Narishma Jahar . Évalué à 2.
[^] # Re: Sympa le troll !
Posté par Maclag . Évalué à 4.
Il faut voir le volume que représente le marché aussi!
Je doute que le marché professionnel soit si rentable. Quand on pense aux frais de développements qui deviennent exponentiels, je crois que le marché grand public reste le plus lucratif (diviser tous ces frais de développements par centaines de milliers de produits sinon par millions, si c'est pas plus commode que sur ces quelques centaines de professionnels...).
Je pense que c'est la même problématique sur les consoles: globalement, ça ne doit pas rapporter tant que ça (ventes en grande quantité, certes, mais donc avec un certains rabais!), mais ça gonfle l'image de marque.
[^] # Re: Sympa le troll !
Posté par Laurent A. . Évalué à 1.
[^] # Re: Sympa le troll !
Posté par Zorro (site web personnel) . Évalué à 2.
En bon linuxien je suis reparti bredouille, devant la complexité de choix d'une ATI, et devant l'absence de portable haut de gamme avec une intel (haut de gamme semble signifier forcément "avec une carte graphique de-la-mort-qui-tue-(c) )"
/*ma vie*/
Pour les portables des magasins grand public, oui, certainement. Mais regarde les catalogues Pro de Toshiba ou Dell, et tu verras que c’est carrément autre chose, et que là, la puce 3D, ils s’en foutent.
[^] # Re: Sympa le troll !
Posté par bubar🦥 (Mastodon) . Évalué à 1.
Malheureusement je ne peux me permettre de débourser une somme pour un pc d'un seul coup : je suis obligé de passer par des facilités de paiement (genre 4 ou 10 fois sans frais) typiquement "magasins grand public" (et certainement me coltiner la taxe illégale de microsoft !! argg c'est ça en fait qui me fait hésiter)
sinon j'aurai acheter directement un super Clevo avec un linux pré-installé ;) :)
bon, désolé pour cette apparté personnelle sur ce topic.
[^] # Re: Sympa le troll !
Posté par Grunt . Évalué à 1.
http://racketiciel.info
Si tu ne te bouges pas, qui le fera à ta place?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Sympa le troll !
Posté par Sylvain Sauvage . Évalué à 9.
Hmm, résumons, au bout de 4 (ou 10) mois, tu as payé ta dette.
Qu’est-ce qui t’empêche d’économiser la même somme sur 4 (ou 10) mois ?
Bon ok, tu ne l’as pas tout de suite, il faut attendre 4 (ou 10) mois. Mais il suffit de s’y prendre 4 (ou 10) mois à l’avance…
[^] # Re: Sympa le troll !
Posté par Zorro (site web personnel) . Évalué à 4.
L’épargne forcée, une vertu à redécouvrir.
# Tournures de phrase
Posté par Dr BG . Évalué à 9.
Ce n'est pas l'inverse ?
ATI est légèrement derrière NVIDIA en terme de performances, mais de peu ;
Pourquoi mais, si c'est légèrement, c'est de peu, pas d'opposition.
Sinon, je n'ai rien à dire de constructif. À part qu'Intel voyait sans doute aussi d'un bon œil les premiers tests de lancé de rayon temps réel devenus envisageables avec les processeurs massivement multicœurs : http://linuxfr.org/~gart/26247.html
# Un peu précipité, non ?
Posté par tarlack . Évalué à 10.
Après, qu'utiliser de manière efficace le GPU soit non trivial, certes (et je peux en parler, je l'utilise, et je trouve ça non trivial). Mais utiliser le SSE (et plus généralement les instructions vectorielles) de manière efficace peut être tout aussi casse-tête, et demande des adaptations majeures des algorithmes (au moins pour ceux que je connais, liés à la synthèse d'images). Utiliser les SPUs (vectoriels et avec gestion de la mémoire code/données explicite) de la PS3 au maximum de leurs perfs est tout aussi difficile (aussi testé). Et rien qu'utiliser un CPU efficacement (donc s'arranger pour ne pas exploser le cache, minimiser le nombre de défauts de pages, etc) demande là aussi des adaptations non négligeables sur les algos, et pas mal de réflexion (au moins pour moi). Bref, toute utilisation orientée performances nécessite une bonne connaissance du matériel et une adaptation des algos plus ou moins importante, il n'y a rien de nouveau ni de spécifique aux GPUs là dedans. Concernant la flexibilité des GPU et leur bonne capacité à traiter des problèmes liés au calcul scientifique, il suffit d'aller sur la CUDA zone [1] pour voir que ce n'est pas que de la 3D temps réel, loin de là.
Donc au final, il y a toujours les mêmes problèmes qu'avant : quelle est la techno la plus adaptée à mon problème ? Sans essayer ou sans forte expérience sur chacune des technos disponibles, il me semble très difficile de le dire... Mais jeter à la poubelle une techno parce qu'on ne peut pas en tirer le maximum en codant avec ses pieds, je trouve ça un peu hâtif. De plus, la somme de travaux faits sur la programmation générique des GPUs est quand même bien moindre que celle faite sur l'utilisation des CPUs. Ça ne fait que quelques années que ca existe, et je trouve que les résultats sont plus que prometteurs quand on sait depuis combien de temps on utilise les CPUs actuels et qu'on compare les résultats pour des problèmes où les GPUs sont adaptés. Et les outils commencent à arriver eux aussi (debugger notamment, cf [2]). Donc voyons ce que ça va donner, je doute qu'on ait assez de recul actuellement pour juger.
[1] http://www.nvidia.com/object/cuda_home.html# (je sais, c'est du flash....)
[2] http://developer.nvidia.com/object/nexus.html (je sais, c'est que pour windows, je suis le premier que ca embête croyez le bien, mais bon, les outils arrivent !)
[^] # Re: Un peu précipité, non ?
Posté par Thomas Douillard . Évalué à 5.
* Concrêtement, on peut faire n'importe quel type de calcul en GPGPU ? C'est quoi les grosses contraintes de programmation ? Si j'ai bien compris l'idée c'est de programmer la séquence d'instruction sur le pipeline de la CG pour paralléliser à mort ... On est limité en instructions, on peut boucler (je connais pas du tout les langages)
* Pour prolonger la question, la grosse difficulté c'est qu'on a des algorithmes pas implémentables, ou qu'on peut implémenter n'importe quoi, mais de manière non triviale ?
* Si j'ai bien compris, des procos types Larabee ou assimilé, c'est générique, mais c'est pas facile à exploiter de manière performantes parce que l'architectsure est un peu spéciale, avec les problèmes de caches, etc. Donc l'avantage de ce type d'archi par rapport au GPGPU ce serait sa généricité, mais difficile à exploiter, en particulier pour des traitements graphiques parce que les architectures sont mal connues.
** 1 - J'ai bon ?
** 2 - Par rapport a du GPGPU c'est carrément moins parrallèle, mais plus souple à programmer ?
Et enfin questions subsidiaires, t'as des exemples de problèmes tu utiliserait un GPGPU ou un Larabee ? Pour avoir une idée du type de problème traitable par les archis ...
[^] # Re: Un peu précipité, non ?
Posté par ecyrbe . Évalué à 4.
il y a une pelleté d'application a ces domaines :
- traitement de l'image
- simulation de problèmes physiques (météo, big bang, aéronotique ...)
- mathématiques vectorielles/matricielles
- analyse spectrale
[^] # Re: Un peu précipité, non ?
Posté par Thomas Douillard . Évalué à 5.
[^] # Re: Un peu précipité, non ?
Posté par tarlack . Évalué à 10.
1/oui, on peut faire n'importe quel type de calcul. Avec CUDA par exemple (openCL j'ai regardé de très très loin, mais de ce que j'ai vu ca devrait etre pareil), tout le côté pipeline graphique est caché, meme si tu peux interagir un peu avec openGL côté CPU (j'ai pas trop regardé ca). Tu vas programmer ce que Le langage ressemble très fortement au C, avec quelques mots clés en plus pour dire ce qui est sur GPU ou sur CPU, et gerer la hierarchie mémoire (que tu gères de manière explicite). Niveau prog effective, c'est comme du C : tu peux boucler, appeler des fonctions, ... . Alors par contre à la réflexion je sais pas si ca gere les pointeurs de fonctions - je n'en ai pas eu besoin -, comme tout est inliné dans le noyau (équivalent du main() d'un prog C). Et après, tu appelles ton noyau depuis un prog (C ou C++) presque comme une fonction normale, tu précises juste comment tu répartis chaque tache sur le GPU (je te laisse te référer au guide de programmation de CUDA - très bien fait, trouvable dans le SDK - pour plus de détails).
2/ Tout peut être calculé, mais d'un autre côté, seuls une partie des problèmes peut être traités efficacement par le GPU. Typiquement, les GPUs ne sont pas du tout adaptés aux algos purement séquentiels avec une seule donnée à traiter à travers de nombreuses étapes. Le mieux, c'est quand tu veux N résultats (N grand) d'une même fonction (ne bossant pas forcément sur les mêmes données, heureusement ^^). Dans ce cas, ton noyau contiendra le code d'une tâche. tu peux aussi faire des opérations où tu ne veux qu'un seul résultat, pour des fonctions de type "rédux". Si les données de base sont très grosses, le gain est vraiment notable aussi. Bon après des fois des algos qui apparemment ne s'y pretaient pas peuvent être adaptés, c'est au cas par cas.
3/Si j'ai bien compris, le Larrabee se programmera comme un GPU, avec du vectoriel en plus. Après, peut-etre qu'ils proposeront plusieurs niveaux : un niveau "facile", ca sera du openCL (threading et SIMD géré automatiquement), et un niveau "bas niveau", où tu te feras ton threading toi-meme et exploitera le SIMD toi-même. N'étant pas devin et ne bossant pas sur le Larrabbee, j'attend de voir ^^. Dans tous les cas, ca sera par du parallélisme massif qu'on en tirera le mieux (plus y a de taches, plus on peut cacher la latence des accès mémoires)
4/ben la CUDA zone donne un bon apercu...je l'utilise pour du rendu par lancer de rayons, mais des gens l'utilisent en dynamique des fluides, en electrodynamique, en rayonnement, ... en gros, dès que c'est intensif et qu'on veut plein de résultats d'un même calcul de base.
les algos qui en tirent le plus parti
*parce qu'il y en a toujours, loi 1 de l'humanité ^^
[^] # Re: Un peu précipité, non ?
Posté par Jerome Herman . Évalué à 8.
Quand un regsitre déborde, c'est un peu au petit bonheur la chance (parfois une erreur, parfois une rotation du registre sans rotation de carry (bien entendu, il y en a pas), parfois 2^x +1 = 2^x). Les arrondis dépendent du sens du vent et les trap à erreur genre "not a number" et "division by zero" sont variables d'une carte à l'autre.
En bref pour faire du GPGCU il faut quand même avoir une bonne maitrise de ses éléments de départ sinon c'est un poil le mur.
[^] # Re: Un peu précipité, non ?
Posté par Grunt . Évalué à 3.
Il y a aussi le test de nombreuses clefs en parallèle afin de casser un chiffrement pas très costaud, non? Ça parait logique de confier ce genre de tâches à des unités de calcul qui travaillent en parallèle.
Si les connaisseurs veulent confirmer ;)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Un peu précipité, non ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
If it costs X (time, money, pain) to develop an efficient single-threaded algorithm, then…
*Multithreaded version costs 2X
*PlayStation 3 Cell version costs 5X
*Current "GPGPU" version is costs: 10Xor more
Over 2Xis uneconomical for most software companies!
Il compare donc la complexité de programmation entre un mono cpu et les autres téchno. Si on "pousse les curseurs", cela veut dire qu'un multi cpu moins puissant qu'un gros GPGPU pourrait donner un moteur de 3d meilleur car plus simple à optimiser, malgré la différence de puissance.
"La première sécurité est la liberté"
[^] # Re: Un peu précipité, non ?
Posté par tarlack . Évalué à 3.
[1] http://ompf.org/forum/
[^] # Re: Un peu précipité, non ?
Posté par Ontologia (site web personnel) . Évalué à 1.
En d'autres termes, crois-tu possible de mettre une couche d'abstraction au dessus d'un tel framework ?
Je te pose cette question car je sais que tu as un peu joué avec ce genre de compilateur ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un peu précipité, non ?
Posté par mdlh . Évalué à 1.
C'est en cours de part chez moi ;-)
[^] # Re: Un peu précipité, non ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Un peu précipité, non ?
Posté par mdlh . Évalué à 6.
Il y a quelques annees, il etait courant d'utiliser le mot-clef "register" afin d'ameliorer les performances d'un algo. La difficulte etant de determiner quelles variables allaient recevoir ce mot-clef. Ensuite, les compilos sont devenus plus performants et, sauf quelques rares cas, sont en meilleur position pour detecter dans quels cas une variable doit rester dans un registre, ou dans quel cas il est plus intelligent de stocker la variable en memoire pour faire de la place.
Le principe ici est le meme: Le compilateur fait le boulot et adapte en fonction de la carte GPU cible.
[^] # Re: Un peu précipité, non ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En gros, tu fais de l'OpenCl sans les informations d'espaces mémoire à utiliser.
"La première sécurité est la liberté"
[^] # Re: Un peu précipité, non ?
Posté par mdlh . Évalué à 3.
On gere d'autres choses que la memoire (taille des blocks par exemple) mais l'idee est la. Il y a plusieurs cibles mais en general la sortie est du source code, qui peut etre de l'OpenCL, mais optimise pour une cible donnee.
Si effectivement OpenCl offre une certaine souplesse au niveau ecriture et permet a partir d'un seul source code d'obtenir quelque chose d'executable sur les cartes AMD, NVidia, Lrb et meme des processeurs multi-coeurs, l'experience montre que si l'auteur veut obtenir quelque chose de performant, il faut malheureusement un source OpenCl ecrit pour chacune des cibles. C'est a ce niveau la que l'on se situe: Un language source en entre simplifiee, plusieurs code OpenCl en sortie.
On aimerait pouvoir se passer de la couche OpenCl, mais a part pour des binaires a executer sur des CPUs, on a aucun moyen de produire des executables pour les gpus, et Larrabee encore moins.
Sinon, pour ce qui est du rapprochement entre le GPU et le processeur, si cela va effectivement reduire les latences qui sont significatives pour des petits calculs, la bande passante entre la memoire et le GPU va etre grandement reduite. Hors beaucoup d'algos avances qui tournent aujourd'hui sur GPU sont malgre tout limite par la bande passante. Autant dire qu'ils vont prendre du plomb dans l'aile et que je ne suis pas certain que ce raprochement sera percu finalement comme le saint graal.
[^] # Re: Un peu précipité, non ?
Posté par tarlack . Évalué à 1.
En tout cas très interessant votre boulot de recherche ! y a de la doc (papiers, ...) dispo et lisible par quelqu'un ayant des connaissances limitées en compil et trucs dans le genre ?
[^] # Re: Un peu précipité, non ?
Posté par mdlh . Évalué à 1.
Pour les publications, on est attente de reponses des conferences.
[^] # Re: Un peu précipité, non ?
Posté par Ontologia (site web personnel) . Évalué à 2.
En tout cas bonne chance avec tes relecteurs, surtout ceux qui ne sont pas spécialistes de la question pour tout comprendre...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# gta200b
Posté par cichlid . Évalué à 1.
envoyé depuis mon clavier bépo
[^] # Re: gta200b
Posté par Octabrain . Évalué à 3.
# Chipset CPU
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
La technologie VirtualGL consiste en gros a tunneliser la sortie écran OpenGL en image jpeg pour l'envoyer sur le poste client via le réseau. Ainsi, on a l'affichage distant.
J'aurais bien voulu grâce à cette technologie pouvoir mettre plusieurs clients derrière mais cela ne marche pas. Le changement de contexte 3D donne des latences de plusieurs secondes... Non tolérable par les utilisateurs. Du coup, il y en a qui ont inventé un système de réservation.
Bref, tout cela pour dire que c'est quand même bien spécialisé et cela ne peut pas tout faire, notamment du multi-utilisateur.
L'avenir : l'itanium et le x86 vont partager normalement en 2010 le même socket. Un des buts est aussi de pouvoir mettre une puce de type reprogrammable afin de pouvoir cabler un calcul. Ainsi, toutes les puces ont un accès direct à la mémoire comme une machine NUMA. C'est un peu la généralisation de la la gamme Altix Itanium de SGI (450 et 4700) qui permet déjà l'intégration de telle carte FPGA. Je ne vois pas alors ce qui empêcherait nvidia de faire une puce graphique qui se greffe sur ce type de socket, les problèmes de latence mémoire seraient alors nettement réduits.
[^] # Re: Chipset CPU
Posté par Brice Goglin . Évalué à 5.
[^] # Re: Chipset CPU
Posté par Cédric Chevalier (site web personnel) . Évalué à 2.
[^] # Re: Chipset CPU
Posté par totof2000 . Évalué à 1.
[^] # Re: Chipset CPU
Posté par lasher . Évalué à 4.
Ia64 est VLIW+superscalaire, in-order (sauf pour certaines opérations mémoire), là où x86 est superscalaire out-of-order. Le seul truc qui se rapproche "un peu" (mais alors juste un peu) de l'Itanium pourrait à la limite être le Larrabee, mais uniquement parce qu'il s'agit d'un proc superscalaire in-order lui aussi.
Après, si par converger tu veux dire qu'un jour l'ISA x86 aura des instructions prédicatées et qu'on retournera à du many core in-order, c'est bien possible, mais on sera toujours loin de l'ia64 ...
[^] # Re: Chipset CPU
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Chipset CPU
Posté par benoar . Évalué à 3.
[^] # Re: Chipset CPU
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Le problème vient de la conception même des cartes 3D, ATI ou nvidia. A ma connaissance, il n'y pas vraiment d'autres cartes 3D sur le marché qui aurait une conception autre. Mais je suis intéressé de savoir si cela existe.
[^] # Re: Chipset CPU
Posté par Antoine . Évalué à 2.
Heu, s'ils ne font plus de stations de travail POWER, c'est certainement que ça ne marchait pas.
Le marché des stations de travail non-x86 a disparu depuis que les processeurs x86 sont suffisamment puissants pour ça.
[^] # Re: Chipset CPU
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je me souviens qu'il y a 10 ans, les PC linux x86 allaient déjà plus vite que bien des stations (et pour bien moins cher).
Mais Catia ne tournait pas sous Linux, mais...
Bref, les stations ont disparus parce que tous ces gens là travaillent maintenant sous Windows ! Linux n'a récupéré qu'une petite partie du gâteau des stations à mon sens.
# Fallais y penser !!!
Posté par Jolidragon . Évalué à 4.
Bah ouais, allez pouf pouf c'est collé, tant qu'à faire autant coller aussi un traitement son et un traitement réseau, et des ports usb au dessus du ventilo.
C'est peut être pas évident d'utiliser le matos à son maximum, mais les dev de jeux vidéos ne se foulent pas non plus (cf GTA IV...)
Après pour les autres utilisations je ne pense pas que l'impact sur le marché soit vraiment important, ce sont les gamers qui achètent les grosses carte graphiques.
[^] # Re: Fallais y penser !!!
Posté par tarlack . Évalué à 3.
déjà les labos en achètent (et pas que dans les équipes de synthèse d'images, mais aussi certains labos de physique), parce que s'ils peuvent faire leurs calculs dessus, ils sont preneurs :) après, si vraiment ça marche bien, les industries concernées vont certainement s'y mettre aussi, il suffit de voir la gamme Tesla de nVidia (4 GPU avec 4Go de RAM par GPU, pas de sortie video) pour voir qu'ils sont près à cela et l'espèrent fortement...
[^] # Re: Fallais y penser !!!
Posté par Quzqo . Évalué à 4.
Comparaison nVidia (avec Processeur de traitement parallèle, i.e. CUDA) :
- Gamme grand public : 8 références* dont haut de gamme GeForce GTX 295 ~480€
- Gamme professionnelle : 12 références dont haut de gamme Quadro FX 5800 ~3500-4000€, Quadro NVS 450 ~450€
Penses-tu toujours qu'il n'y a que les "gamers" pour acheter de grosses cartes graphiques ?
* "véritables" références (caractéristiques GPU) faisant partie de l'offre officielle du constructeur
Et accessoirement, ces traitements, câblés ou programmables, dans le GPU/processeur parallèle constituent une véritable optimisation des performances... dans un contexte donné et précis.
Le souci est qu'aujourd'hui avec CUDA et consorts, les développeurs voudraient faire du GPU/processeur parallèle un processeur générique avec gestionnaire de mémoire intégré et puissance de calcul supérieur au processeur central...
Curieusement, ça exige 1/ des efforts 2/ de diminuer ses prétentions...
Rien de nouveau sous le soleil...
[^] # Re: Fallais y penser !!!
Posté par geb . Évalué à 2.
"AMD peut coller un traitement graphique dans ces processeurs."
Bah ouais, allez pouf pouf c'est collé, tant qu'à faire autant coller aussi un traitement son et un traitement réseau, et des ports usb au dessus du ventilo.
Ou quelquechose de plus generic comme des SPIs, qu'on utiliserait pour de la video ou comme dsp, comme le fait ziilabs.com (creative), ou sony/ibm avec le cell.
[^] # Re: Fallais y penser !!!
Posté par zerkman (site web personnel) . Évalué à 2.
# Et si les processeurs ARM suffisaient ?
Posté par xavier philippon . Évalué à 3.
Bon, pour revenir au dernier point de l'article, je pense que les processeurs de type ARM ont un réel avenir devant eux. Ils ont un meilleurs ration Puissance de calcul/consommation que les X86. Ils disposent d'une pléthore d'environnement de développement, gratuits ou propriétaires, Idem pour les OS.
Les Netbooks ont ouvert une brèche dans le monopole Windows, ils pourraient bien continuer avec celui d'Intel et des X86;
Je pense donc que l'implication de Nvidia dans cette architecture a toutes les chances d'être gagnante.
[^] # Re: Et si les processeurs ARM suffisaient ?
Posté par NickNolte . Évalué à -4.
Parce que c'est proprio ça ne peut que "marché à peu près"?
Ah oui, on va me sortir l'exemple foireux de KDE 4.X qui ne fonctionnait pas bien avec une nVIDIA.
[^] # Re: Et si les processeurs ARM suffisaient ?
Posté par BAud (site web personnel) . Évalué à 5.
c'est aussi et surtout que des cartes qui fonctionnent bien - comme les GeForce 2 - tout d'un coup ne vont plus fonctionner avec le tout dernier pilote o_O (c'est trop vieux ma bonne dame !).
Heureusement, il y a nouveau[1] et après on va encore dire que c'est Linux qui a le plus de pilotes pour faire fonctionner le plus grand nombre de matériels[2].
[1] http://nouveau.freedesktop.org/wiki/FrontPage-fr
[2] http://broadcast.oreilly.com/2008/10/how-linux-supports-more(...)
[^] # Re: Et si les processeurs ARM suffisaient ?
Posté par NickNolte . Évalué à 2.
Sauf que pour ATI non seulement ça ne marche pas bien mais en plus la série avant HD est obsolètes déjà. :)
[^] # Re: Et si les processeurs ARM suffisaient ?
Posté par gpe . Évalué à 3.
Dans ce domaine ARM n'est pas le meilleur, Les ARC par exemple présentent un ratio puissance/conso plus intéressant.
[^] # Re: Et si les processeurs ARM suffisaient ?
Posté par xavier philippon . Évalué à 4.
[^] # Re: Et si les processeurs ARM suffisaient ?
Posté par gpe . Évalué à 3.
C'est un fournisseur de cœurs CPU, DSP, etc.
# futurs bus mémoire+I/O
Posté par Brice Goglin . Évalué à 7.
Il ne faut pas aller trop vite là. Tu as beau être dans le processeur, l'accès à la mémoire n'est pas gratuit, et ca va ne faire qu'empirer dans le futur.
A terme, on devrait avoir une fusion entre bus mémoire (QPI ou hypertransport actuel) et le bus I/O (PCIe actuel). Quand ce sera le cas, les périphériques seront grosso-modo connectés comme les processeurs, et donc l'accès à la mémoire pourrait être similaire.
En pratique, ca existe déjà avec les slots HTX qui permettent de brancher des cartes réseau ou des accélérateurs sur le bus hypertransport des machines opterons. Ca réduit effectivement la latence d'accès à la mémoire centrale. Dans ces machines NUMA, tu as un peu de RAM à coté de chaque processeur, et un peu de RAM dans le périphérique. Chacun à accès rapidement à sa mémoire locale et un peu moins rapidement au reste de la mémoire (de l'ordre de 100ns de différence).
Bref, que le GPU soit un périphérique connecté au futur bus mémoire+I/O fusionné (ce que nVidia pourra faire facilement), ou un core spécialisé dans les futurs processeurs hybrides à la Cell (ce que AMD et Intel feront surement), l'accès à la mémoire sera grosso-modo du même genre à terme.
[^] # Re: futurs bus mémoire+I/O
Posté par reno . Évalué à 1.
> Il ne faut pas aller trop vite là. Tu as beau être dans le processeur, l'accès à la mémoire n'est pas gratuit, et ca va ne faire qu'empirer dans le futur.
J'allais reagir mais tu m'as battu, j'ajouterai cependant que le probleme d'acces memoire avec les futurs CPU d'Intel est different de celui des GPGPU mais n'est definitivement *pas* 'fini':
une des grosses forces des GPU est d'avoir une bande passante memoire 'brute' monstrueuse grace a des bus d'acces memoire large, comment vont-donc faire les CPU pour etre competitif?
En utilisant des caches.
Mais exploiter efficacement des caches, en plus avec plusieurs coeurs en meme temps, c'est loin d'etre evident: il faut decouper les acces memoire en zone qui tienne dans les caches et faire les traitement par zones.
C'est probablement plus simple que d'exploiter efficacement une GPU, mais d'un autre cote je doute que les CPU d'Intel soient aussi efficace que les GPU (au moins au debut) donc je dirais qu'Intel va probablement l'emporter, mais a long terme (5 ans? voire plus), ce qui rend toute prediction tres aleatoire..
# CPU is cheap
Posté par Mais qui suis-je ? :) . Évalué à 4.
Pour du GPU processing, il faut non seulement que les machines aie les mêmes processeurs mais aussi les mêmes carte graphique,
Or avec la mode des grilles de calcul, le but est plutot d'envoyer un machin sur une file d'attente qui va le distribuer sur une machine aléatoire parfois a l'autre bout du monde suivant ou l'on trouve de CPU dispo.
Avoir du GPU processing facilement accessible au end-user risque donc de reduire fortement la capacité des grilles de calculs si les gens en ont besoin d'une carte graphique donnée.
Seconde question vu le prix d'une carte vidéo, est il vraiement rentable de faire du GPU processing, alors qu'il suffit de rajouter un processeur sur le cluster.
A Budget équivalent vaut il mieux 180 processeur ou 100 Processeur + 100 Cartes graphique ? Si on rajoute le temps de formation et d'écriture du code pour utiliser la GPU ?
Est ce vraiement rentable par rapport a
-De la paralelisation mal faite(Je coupe mon Giga de datas en 10 paquet de 100 MO que je traite séparément et re merge a la fin)
-De la paralelisation bien faite donc au niveau du code source (tiens d'ailleurs gcc peux le faire ou il faut utiliser icc ? c'est une vraie question il y a pas de troll cacher)
Vu que de nos jours le CPU ne coute plus rien je me demande vraiement si c'est pas plus simple et efficace d'ajouter des CPU que des GPU ?
[^] # Re: CPU is cheap
Posté par Brice Goglin . Évalué à 1.
Ah ah, très bon ! Sérieusement, la mode c'est le cloud, pas la grille. Ton argument ne s'y applique pas.
"Vu que de nos jours le CPU ne coute plus rien je me demande vraiement si c'est pas plus simple et efficace d'ajouter des CPU que des GPU ?"
Toujours pareil, ca dépend du problème que tu veux résoudre. Y a des cas où les GPU apportent un speedup de 100 donc il vaudra mieux ajouter un GPU par noeud. Et y a des cas où le GPU n'aide pas vraiment. Avant l'introduction des GPUs, on était déjà censés regarder les applis cibles avant d'acheter une machine: vaut-il mieux un cluster, une constellation ou un MPP à la Bluegene? Ben maintenant faut prendre en compte les GPU/accélérateurs avant de décider quoi acheter.
[^] # Re: CPU is cheap
Posté par etham (site web personnel) . Évalué à 1.
Quand on ajoute un noeud dans un cluster de calcul, adjoindre à ce noeud une ou deux carte graphique n'est pas un coup très élevé.
# L'intégration continue.
Posté par Zarck . Évalué à 4.
Amd / Ati l'affiche sur son site que l'avenir est à la fusion. Le Gpu et le Cpu dans une seule puce sur le même support.
Nvidia maintenant seul, racheté par Intel ?
Et Amd / Ati racheté par Apple ? *_*
Pour ARM dans des ordinateurs de bureau, cela à déjà existé, j'ai acheté ce type d'ordi à la société Acorn dans les années 90, la société Acorn est aux oubliettes.
Je participe au programme Folding@home le gain offert par le Gpu est impressionnant, 3 jours pour faire un calcul avec le CPU, 3 heures avec le GPU.
@+
*_*
[^] # Re: L'intégration continue.
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
J'espère juste qu'utiliser l'un ne met pas l'autre en pause, sinon je ne pourrai plus utiliser mon clavier en même temps que mon écran est allumé…
# Ca manque d'information
Posté par Bactisme (site web personnel) . Évalué à 3.
Tiens, ca alors, "le GPU est trop loin du CPU, c'est trop couteux" ..
Il oublis deux technologies de chez Nvidia : Ion et Tegra ....
Ion = Atom + chip nvidia
Tegra = ARM + chip Nvidia
... tout ca sur un même chips ... dédiés a la mobilité ... la ou le "cout" est primordial.
Quand on voit le nombre de prototypes de netbook qui sorte avec des puces Tegra et le nombre de nettop programmé avec Ion....
... Je me dit que la firme Nvidia a encore de beau jours devant elle...
[^] # Re: Ca manque d'information
Posté par GeneralZod . Évalué à 7.
> ... Je me dit que la firme Nvidia a encore de beau jours devant elle...
Mouais, Intel cherche à révoquer la licence accordé à nVidia pour produire des chipsets à destination de ces CPUs. Si Intel gagne sa bataille judiciaire, tu peux dire adieu à Ion & cie.
http://www.zdnet.fr/actualites/it-management/0,3800005311,39(...)
En parrallèle, Intel essaie de s'assurer que nVidia ne puisse jamais obtenir une licence x86.
Quand AMD a "cédé" sa licence x86 à Global Foundries (une société partagée externalisant la partie production), Intel a menacé de faire révoquer la licence en question sous prétexte qu'elle ne respectait pas l'accord liant AMD à Intel. Évidemment, Intel n'aurait jamais révoqué la licence qui entrainerait inévitablement les foudres de l'UE et du département d'Etat US pour pratiques anti-concurrentielles. Le but de la manoeuvre était d'éviter le "partage" de la licence à travers Global Foundries. De plus, la licence AMD est non-transférable depuis longtemps, le cas GF est toléré à cause de la participation d'AMD (environ 30% des actifs et 50% des voix au CA)
http://www.brighthub.com/computing/hardware/articles/29783.a(...)
Reste la licence Cyrix détenu actuellement par Via. C'est plus incertain, Intel a dénoncé la licence, mais Via détient 3 brevets cruciaux qui leur ont permis de négocier un accord il y a quelques années. Un accord qui très probablement rend la licence non transférable.
Si nVidia freine des quatre fers contre la convergence CPU/GPU, ce n'est pas pour des raisons techniques, ils savent le faire mais pour des raisons économiques.
Si la convergence CPU/GPU se confirme, on peut être sûr d'une chose: l'avenir de nVidia est entre les mains d'Intel.
[^] # Re: Ca manque d'information
Posté par pyknite . Évalué à 1.
Encoder un dvd en divx avec leur nouvelle puce, ça prend à tout cassé 10min!
Et je vous parle pas du prototype de téléphone mobile qu'ils nous ont montré qui utilisait leur puce (en plus d'une consommation minimum, la puissance est assez impressionante).
Perso, je pense que Nvidia est entrain de ce diriger vers un nouveau marché très interessant!
++
# A ce propos, meilleure carte graphique pour linux
Posté par Gabriel . Évalué à 0.
J'ai lu qu'avec un Linux, il valait mieux avoir une NVidia car les drivers étaient meilleurs.
Est-ce que vous êtes d'accord avec cela?
Est-ce que cependant les autres cartes graphiques sont aussi de bonne qualité ?
merci d'avance
(trolls excluded)
[^] # Re: A ce propos, meilleure carte graphique pour linux
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
NVIDIA a un bon drivers pas libre mais qui marche. Nouveau avance vite.
Avec la sortie des spec des ATI/AMD, cela devrait bouger aussi de ce coté.
"La première sécurité est la liberté"
[^] # Re: A ce propos, meilleure carte graphique pour linux
Posté par bubar🦥 (Mastodon) . Évalué à 9.
OUI une NVIDIA est préférable, dès lors que tu aimes jouer (avec des jeux natif ou avec wine)
Saches que les Intel d'aujourdhui suffisent largement pour jouer avec son bureau 3D, ert de plus décompresse la vidéo Full HD de manière matérielle, donc une INTEL suffit dans la plupart des cas.
ATI c'est vraiment le foutoir pour choisir, et si le support pour Linux s'est largement amélioré, il n'en reste pas moins que sur une carte neuve on se retrouve au pire avec une carte qui fonctionne très mal, au mieux avec une solution comme nvidia.
(Nvidia assure que la carte fonctionnera très bien pour TOUTES ses cartes dans tout les cas, sous linux.)
Le bon compromis pour un Libriste sont les dernières cartes Intel, donc.
Le meilleur choix pour un utilisateur de Linux c'est Nvidia.
[^] # Re: A ce propos, meilleure carte graphique pour linux
Posté par Adrien . Évalué à 2.
Le seul soucis : Pour avoir l'accélération 3D je ne peux pas utiliser le noyau 2.6.30, mais un plus ancien.
De plus les pilotes libres marchent bien, mais ils n'ont pas encore l'accélération, ça devrait arriver sous peu théoriquement…
[^] # Re: A ce propos, meilleure carte graphique pour linux
Posté par bubar🦥 (Mastodon) . Évalué à 5.
Et encore... : ils ne suivent pas évolutions : ni celle du kernel, ni celle de xorg, ni celles de openGL.
C'est pourquoi prendre du ati, c'est vraiment la roulette russe pour des cartes neuves.
[^] # Re: A ce propos, meilleure carte graphique pour linux
Posté par Prosper . Évalué à 1.
Saches que les Intel d'aujourdhui suffisent largement pour jouer avec son bureau 3D, ert de plus décompresse la vidéo Full HD de manière matérielle, donc une INTEL suffit dans la plupart des cas.
Seul les chipset intel GMA45xx ( et encore pas complètement ) décompressent des codecs comme le VC1 ou le x264 , et ca seulement sous Windows ( je crois même que c'est limité à Vista et Seven )
[^] # Re: A ce propos, meilleure carte graphique pour linux
Posté par case42 (site web personnel) . Évalué à 7.
Techniquement, si tu as besoin d'une grosse carte 3d, nVIDIA et ses drivers propriétaires ont toujours mieux fonctionné / ont toujours étés plus simples à installer que les drivers ATI. Depuis l'ouverture des spec d'ATI, on s'attend un jour ou l'autre à une inversion de tendance, mais pour le moment ce jour n'est pas venu.
Idéologiquement, les meilleurs drivers libres sont probablement ceux d'Intel. Donc si tu n'as pas besoin d'une grosse carte 3d mais si une carte 3d modeste te suffit, un GPU Intel est le meilleur choix.
En ce qui me concerne, je suis un libriste pragmatique et même si je préfèrerais avoir un système 100% libre, j'ai besoin d'une 3d accéléré performante et donc je vivrais avec le driver propriétaire d'nVIDIA, tant que personne n'aura aussi bien et plus libre a proposer.
[^] # Re: A ce propos, meilleure carte graphique pour linux
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
"La première sécurité est la liberté"
[^] # Re: A ce propos, meilleure carte graphique pour linux
Posté par bubar🦥 (Mastodon) . Évalué à 7.
poulsbo ? poubelle !
[^] # Re: A ce propos, meilleure carte graphique pour linux
Posté par Gabriel . Évalué à 0.
# Coder avec OpenCL: un vrai foutware?
Posté par FantastIX . Évalué à 1.
# Nvidia opencl
Posté par peck (site web personnel) . Évalué à 0.
Bien sauf que nvidia n'utilise pas opencl et ses cartes graphiques se codent en C. Donc de leur point de vue c'est déjà une difficulté de balayée.
Ensuite pour ce qui est du transfert mémoire, tout dépend des calculs, la carte graphique dispose déjà d'une grande quantité de mémoire. Seules les données d'entrées et de sorties ont besoin d'être transférées, ce qui n'a de conséquences que si on a une quantité gigantesque de données à traiter et peu de de traitement à faire.
[^] # Re: Nvidia opencl
Posté par GeneralZod . Évalué à 1.
Non, il est dit que le GPGPU c'est difficile et que l'arrivée de nouvelles solutions basés sur la convergence CPU/GPU sensées être plus faciles pourraient lui damer le pion.
Certes ce sera difficile pour nVidia mais il y a d'autres raisons qui n'ont pas été évoqués.
> Bien sauf que nvidia n'utilise pas opencl et ses cartes graphiques se codent en C
Faux, nVidia a participé activement à la conception d'OpenCL (qui s'inspire de CUDA) et compte bien le supporter. Les pilotes et le SDK (basé également sur LLVM/CLang comme celui d'Apple) sont disponibles depuis environ 6 mois via un programme de béta.
Au passage, le langage propriétaire de CUDA comme OpenCL se base sur C99 plus des extensions et un jeu d'API. Si OpenCL est difficile, ben C avec CUDA l'est tout autant
http://www.nvidia.com/object/cuda_opencl.html
[^] # Re: Nvidia opencl
Posté par mdlh . Évalué à 2.
Au passage, Cuda est un sous-ensemble de C++ plus que C99 etendu. Pour preuve la gestion de la memoire texture sous forme de templates et quelque declarations ici et la qui relevent de C++ plutot que de C.
# Pas nouveau
Posté par dstauret . Évalué à 1.
Mais ce qui me dérange, c'est l'intérêt de faire tourner le "grille pain" pour des calculs.
Les processeurs ont un meilleur rendement (puissance nécessaire, dégagement thermique) que les GPU.
Les GPU actuels de + en + gros, consomme de + en + et chauffe autant. Alim PCI-E 6 broches, 8 broches. Il y a déjà des alims séparées pour les cartes graphiques.
Donc il est grand temps que le système de carte actuelle soit revu.
[^] # Re: Pas nouveau
Posté par dstauret . Évalué à 1.
Petit pb de validation.
[^] # Re: Pas nouveau
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pas nouveau
Posté par bubar🦥 (Mastodon) . Évalué à 2.
j' ai encore vue récemment les très grosses toutes dernières Nvidia au boulot, bon ok j'ai pas une habitude personnellede ce type d'negins, mais franchement... on peux se demander comment ce si petit connecteur qu'est le pci-e peut supporter un tel poids !!!
En fait c'est le cable pour l'alimentation dédiée à la carte graphique qui font que ça reste en place lol sinon le pauvre pci-e il tiendrai pas longtemps !
Et autant sur HP-UX que sur Linux, ça poutre sévère ces cartes là, niveau perfs' \o/
ps : je crois m'être gourré : ce sont les type NVS chez Nvidia qui sont dédiées à l'affichage 2D avec latence garantie. Non ?
[^] # Re: Pas nouveau
Posté par thedude . Évalué à 3.
C'est pas forcement nouveau non plus.
Une des dernieres 3dfx necessitait d'etre connecte a l'alim principale (ils fournissaient meme le cable en y au cas ya plus de cable pour).
Et au passage, etait tellement large qu'elle rentrait difficilement dans un boitier atx, en gros si le port (encore pci il me semble a l'epoque) etait au niveau du disque dur, ben fallait bricoler.
De memoire c'etait ya environ 10 ans.
[^] # Re: Pas nouveau
Posté par jseb . Évalué à 1.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Pas nouveau
Posté par thedude . Évalué à 1.
Tres interessant a lire sur les debuts de la 3d acceleree soit dit en passant.
Nostalgie, nostalgie...
http://en.wikipedia.org/wiki/Voodoo_5
Bon apparement, wikipedia dit que c'etait la 6000 et qu'elle etait "unreleased" mais je suis sur et certain d'avoir lu le test dans Joystick a l'epoque.
Et au temps pour moi, c'etait sur de l'agp, pas du pci.
Apres, quand tu regardes http://en.wikipedia.org/wiki/File:KL_3DFX_Voodoo5_5500.jpg j'ai l'impression de voir un connecteur d'alim en haut a droite.
Et apparement http://www.devhardware.com/c/a/Video-Cards/3dfx-Voodoo5-5500(...) a l'air de confirmer que la 5500 necessitait bien une alim externe.
http://www.x86-secret.com/articles/divers/v5-6000/v56kfr-6.h(...) est plus prolixe sur la 6000 que vikipedia.
A leur decharge, on peut noter que nvidia a aussi eu pas mal de problemes avec l'alim, la raison etant que les constructeurs de mobo ne respectait pas les specs du port agp en se disant "pfouuulala, ca sert a rien tout ca, pourquoi qu'ils ont besoin de temps de courant pour afficher trois triangles, allez zou degages moi ca". Et paf, les cartes plantaient, resultant en un windows qui se mettaient au tas.
Le probleme a ete resolu en tapant sur les doigts des constructeurs de cartes meres et un utilisateur tres mecontent de sa carte a 1500 balles..
Relier les 2 cartes ensemble, c'etait different, c'etait une SLI, qui permettait en gros d'appliquer 2 textures au lieu d'une seule a chaque passe.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.