Processeur graphique : NVIDIA est mal parti pour les années à venir

Posté par (page perso) . Modéré par baud123.
Tags : aucun
24
8
sept.
2009
Technologie
Les processeurs graphiques sont d'une puissance inégalée par rapport aux cœurs de calcul disponibles sur les processeurs x86. Malgré tout, leur coût d'accès mémoire reste trop important. Plus encore, les processeurs graphiques sont très spécialisés dans le calcul pur rendant difficile leur programmation.

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) ;
    AMD est en mauvaise posture mais possède ATI ;
  • ATI est légèrement derrière NVIDIA en terme de performances, mais de peu ;
  • AMD peut coller un traitement graphique dans ces processeurs.

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 (page perso) . Évalué à 8.

    Perso je n'aime pas trop NVIDIA, mais là ça sent le troll.
    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 . Évalué à 8.

      Nvidia est leader pour les parts de marché actuelles et, indéniablement, l'outillage logiciel (CUDA, OpenGL, OpenCL...), pas pour la qualité du matériel où ATI lui tient la dragée haute. On parle quand même d'une entreprise qui renomme de façon mensongère ses cartes pour portables depuis trois générations pour coller avec les gammes desktop !

      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 . Évalué à 6.

        Nvidia est leader pour les parts de marché actuelles et, indéniablement, l'outillage logiciel (CUDA, OpenGL, OpenCL...), pas pour la qualité du matériel où ATI lui tient la dragée haute. On parle quand même d'une entreprise qui renomme de façon mensongère ses cartes pour portables depuis trois générations pour coller avec les gammes desktop !

        C'est quoi le rapport entre la qualité du hardware et un marketing pourri ?
        • [^] # Re: Sympa le troll !

          Posté par . Évalué à 6.

          Des choix de conception judicieux permettent d'avoir une gamme mobile équivalente à la gamme desktop, comme ce que fait ATI. L'inflation en taille des cartes Nvidia de dernières générations s'accommode mal des contraintes du marché mobile...

          À 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 . Évalué à 6.

            En tout cas, chez le marchand du coin, les choses ont radicalement changé :
            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 . É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 . Évalué à 3.

              Et enfin tout le marché des consoles de jeux ! il est où ati ? sur la wii, ok...

              Aux dernières nouvelles, la xbox 360 embarque toujours un GPU ati ( Xenos )...
              • [^] # Re: Sympa le troll !

                Posté par . Évalué à 1.

                Ha ?? j'étais persuadé que la xbox embarquait elle aussi de l'Nvidia.
                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 . Évalué à 4.

              Gasp!

              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 (page perso) . É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 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 . Évalué à 1.

                Oui, merci !
                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 . Évalué à 1.

                  et certainement me coltiner la taxe illégale de microsoft !! argg c'est ça en fait qui me fait hésiter
                  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 . Évalué à 9.

                  je suis obligé de passer par des facilités de paiement (genre 4 ou 10 fois sans frais)

                  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 (page perso) . Évalué à 4.

                    Et en plus, si tu mets l’argent économisé sur un Livret, ben les intérêts travaillent pour toi au lieu de travailler pour le prêteur !

                    L’épargne forcée, une vertu à redécouvrir.
  • # Tournures de phrase

    Posté par (page perso) . Évalué à 9.

    NVidia est seul, mais leader

    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 . Évalué à 10.

    Ça fait plusieurs années que Tim Sweeny dit que le GPU est mort, et à SIGGRAPH cette année (où j'étais), ça n'a pas semblé être très relayé. Au contraire, le nombre de papiers s'appuyant sur le GPGPU semblait encore avoir augmenté (si c'est possible).

    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 . Évalué à 5.

      T'as l'air de connaître beaucoup de choses, alors je pose des questions :)

      * 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 . Évalué à 4.

        pour répondre a ta dernière question, le calcul sur GPU se prette très bien aux calculs matriciels, vectoriels....
        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 . Évalué à 5.

          Des calculs ou t'as le même traitement à faire sur des très grosses quantitées de données, donc massivement parralélisable quoi si je me trompe pas ...
      • [^] # Re: Un peu précipité, non ?

        Posté par . Évalué à 10.

        alors, dans l'ordre, et sous reserve de corrections par des gens plus qualifiés que moi* :

        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 . Évalué à 8.

          Tres bon post, mais tu n'as pas mentionné ce qui est pour moi l'inconvennient numero un du GPGCU à l'heure actuelle : l'absence quasi totale de registre mathématique et de FPU des familles.
          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 . Évalué à 3.

        t'as des exemples de problèmes tu utiliserait un GPGPU ou un Larabee

        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 . Évalué à 4.

      Tim Sweeny dit :
      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 . Évalué à 3.

        à perfs égales, un moteur de lancer de rayons temps réel c'est 10 fois moins embêtant à coder sur GPU que sur CPU (et je parle d'expérience). Il suffit de voir les forums pro parlant de lancer de rayon temps réel [1], le nombre de gens qui se sont fait un petit raytracer avec CUDA qui tourne à 30 fps pour une scène simple est très important comparés à ceux qui l'ont fait sur CPU, et ce ne sont pas forcément des gourous du domaine (moi le premier). On parle bien d'implementations à *performances égales* ici, pas de dire qu'on a codé son algo sur une plate-forme, parce que dans le genre "comparaison qui veut rien dire", c'est difficile de faire mieux....Donc encore une fois, pour un certain nombre (et même un nombre certain) de problèmes, arriver à des performances données est bien plus simple sur GPU que sur CPU. Et pour d'autres, ca sera l'enfer, je suis tout aussi conscient de ça.


        [1] http://ompf.org/forum/
        • [^] # Re: Un peu précipité, non ?

          Posté par (page perso) . Évalué à 1.

          Et puisque tu expliquais que OpenCL est adapté à des problèmes consistant à appliquer un calcul n fois sur n paramètres différent (si j'ai bien compris), que penses-tu de la possibilité d'utiliser des compilateurs de haut niveau pour générer ce genre de code.

          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 . Évalué à 1.

            En d'autres termes, crois-tu possible de mettre une couche d'abstraction au dessus d'un tel framework ?
            C'est en cours de part chez moi ;-)
            • [^] # Re: Un peu précipité, non ?

              Posté par . Évalué à 1.

              C'a-d ?

              "La première sécurité est la liberté"

              • [^] # Re: Un peu précipité, non ?

                Posté par . Évalué à 6.

                Je travaille sur la realisation d'un compilateur dont le but est de simplifier un peu la vie du programmeur pour ecrire des algos pour GPU. Le language dans l'esprit n'est pas eloigne de CUDA et de C. Cependant, un certain nombre d'elements du languages disparaissent. Ce sont ces memes elements qui influencent en partie la performance de l'algo sur ces GPUs. Sans rentrer dans les details et pour rester comprehensible pour ceux qui ne sont pas famillier avec CUDA, je vais faire une petite analogie avec le language C.

                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 . Évalué à 2.

                  Tu fais ça pour un compilo proprio j'imagine ?

                  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 . Évalué à 3.

                    A long terme c'est sous une license approuvee par l'OSI.
                    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 . Évalué à 1.

                      concernant le temps de latence, sous reserve de mémoire suffisante on peut faire des streams asynchrones (copie(s) host<->GPU en parallèle de calculs), ca fait que la latence host/GPU est à peu près inexistante pour tout calcul valant le coup d'etre fait sur GPU (qui prennent un minimum de temps donc, pas 3 additions max à faire par stream).

                      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 . Évalué à 1.

                        Oui on peut effectivement. Il existe pas mal de solutions, encore faut-il que le programmeur ne soit pas epuise trop tot!

                        Pour les publications, on est attente de reponses des conferences.
                        • [^] # Re: Un peu précipité, non ?

                          Posté par (page perso) . Évalué à 2.

                          Ce serait sympa de nous en faire part une fois que tes papiers seront passés.
                          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 (page perso) . Évalué à 1.

    vu ce monstre de puissance dans les attaques de type GPU bruteforcing (dictionnay attack) tant mieux pour les scripts kiddies.

    envoyé depuis mon clavier bépo

    • [^] # Re: gta200b

      Posté par . Évalué à 3.

      "C'est trop puissant, retournons à des technologies préhistoriques" ?
  • # Chipset CPU

    Posté par (page perso) . Évalué à 2.

    Un des autres problèmes des cartes graphiques et que le changement de contexte est lent car il faut vider leur mémoire pour mettre celui d'un autre processus. D'ou une carte = un écran.

    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 . Évalué à 5.

      Mettre l'itanium dans la même phrase que l'avenir, ca ne fait pas très sérieux...
      • [^] # Re: Chipset CPU

        Posté par (page perso) . Évalué à 2.

        Avec un socket pour mettre un compilateur en hardware ça pourrait peut-être marcher ...
      • [^] # Re: Chipset CPU

        Posté par . Évalué à 1.

        C'est pour préparer la mort de l'Itanium ..... A mon avis, IA64 et X86_64 sont amenés à converger. D'ailleurs, historiquement, il me sembke que larchi X86 était censée mourrir avec l'arrivée de l'Itanium non ?
        • [^] # Re: Chipset CPU

          Posté par . Évalué à 4.

          Je ne vois pas comment deux ISA aussi différentes que ia64 et x86_64 pourraient converger.

          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 . Évalué à 2.

            Ils ont déjà commencé à faire des sockets compatibles. Je pense qu'il peuvent rendre interchangeable les 2 types de cpu, en rendant compatible les carte mères, ce qui donne du boulot au niveau bios, socket, chipset,etc...

            "La première sécurité est la liberté"

    • [^] # Re: Chipset CPU

      Posté par . Évalué à 3.

      Si tu t'intéresses aux affichages accélérés déportés, j'avais aperçu un jour qu'IBM se lançait là-dedans pour remplacer ses workstations haut de gamme (c'est dire qu'ils y croient ...). Ya des gros gros serveurs derrière et des tout petits terminaux pour les utilisateurs, qui permettent de faire de la grosse 3D sans problème (bon, j'ai lu que les infos marketing, mais ça avait l'air pas mal, vu qu'ils ne font plus de workstations POWER aujourd'hui). Ça s'appelle BladeCenter HC10 pour les serveurs, mais là je tombe que sur des 404 donc j'ai pas de lien à te donner.
      • [^] # Re: Chipset CPU

        Posté par (page perso) . Évalué à 3.

        SGI a aussi une solution de type blade avec n cartes graphiques dedans... Je ne connais pas la solution d'IBM mais tout ce que j'ai vu avait la contrainte, une carte = un utilisateur. Pour cacher cela, ils mettent n cartes 3D dans le système central comme n jetons d'un programme propriétaire et cela devient une ressource limité à partager.

        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 . Évalué à 2.

        ça avait l'air pas mal, vu qu'ils ne font plus de workstations POWER aujourd'hui

        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 (page perso) . Évalué à 3.

          Le marché des stations marchait encore sur la fin parce que pleins de logiciels n'étaient pas porté sur Linux et donc les clients étaient coincés par les solutions propriétaires.

          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 . Évalué à 4.

    "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.

    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 . Évalué à 3.

      "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."

      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 . Évalué à 4.

      "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"

      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 . É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.
  • # Et si les processeurs ARM suffisaient ?

    Posté par . Évalué à 3.

    Personnellement, je n'aime pas trop Nvidia non plus mais ils distribuent néanmoins des drivers qui marchent à peu près bien sous Linux même s'ils sont propriétaires.
    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.
  • # futurs bus mémoire+I/O

    Posté par . Évalué à 7.

    "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 ;"

    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 . Évalué à 1.

      >>"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 ;"
      > 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 . Évalué à 4.

    Deux remarques,

    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 . Évalué à 1.

      "Or avec la mode des grilles de calcul"

      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 (page perso) . Évalué à 1.

      En théorie, le rapport GFLOPS/prix est bien meilleur avec des GPU. Si on a une application comportant beaucoup de gros calculs parallélisables, il devient intéressant d'attaquer les machines hybrides.
      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 . Évalué à 4.

    Il n'y a pas si longtemps le co-processeur mathématique était externe au cpu, il est maintenant intégré.

    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 (page perso) . Évalué à 3.

      >> Le Gpu et le Cpu dans une seule puce sur le même support.

      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 (page perso) . Évalué à 3.

    C'est un article desinformé comme rarement on en vois sur LinuxFR ..

    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 . Évalué à 7.

      Tegra est une puce tout-en-un, mais pas Ion. Ion c'est avant tout un chipset comportant un GPU (9400GM), c'est également le nom d'une plateforme structurée autour de ce chipset et d'un CPU Atom, ainsi tu peux acheter des carte mère Ion.

      > ... 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 (page perso) . Évalué à 1.

      Je suis assez d'accord... J'ai eu la chance de voir marcher certains prototype de leurs nouvelles gammes cet été (Ion, Tegra,...) Ben je peux vous dire que ça poutre pas mal...

      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 . Évalué à 0.

    Je profite de cette news pour poser une question.

    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 . Évalué à 5.

      ATI avait un driver libre utilisable sur des chips un peu ancien (genre <9200). Puis plus rien. Le driver pas libre était (est ?) complètement bugué.

      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 . Évalué à 9.

      Pour répondre à ce type de question, et sans appuyer sur des considérations prenant un peu de temps :

      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 . Évalué à 2.

        J'ai acheté un portable avec une ATI cet été, et il marche très bien avec le pilote non-libre (bonne accélération, veille, hibernation, pas de freeze, elle chauffe pas trop…).
        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 . Évalué à 5.

          D'où le "au mieux : on se retrouve avec une solution comme nvidia".

          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 . É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 (page perso) . Évalué à 7.

      Ça dépend si tu considère le coté technique ou idéologique.

      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 . Évalué à 0.

      Merci à tous pour vos réponses! Toutes ces questions parce que j'ai un portable assez puissant mais sans carte graphique et c'est la misère, même pour de la bureatique à 2 balles, assez pénalisant pour que je ne puisse pas vraiment utiliser linux comme OS principal. (je n'ai pas l'ordinateur sous la main, pour vous dire précisément la conf). Mais sur une autre portable avec une nvidia , on retrouve la fluidité à l'affichage.
  • # Coder avec OpenCL: un vrai foutware?

    Posté par . Évalué à 1.

    Je n'ai pas du tout compris en quoi la présentation suffit à faire... comprendre que le développement avec OpenCL est un vrai foutoir. Quelqu'un peut-il m'expliquer?
  • # Nvidia opencl

    Posté par (page perso) . Évalué à 0.

    On dirait qu'il y a un amalgame, je opencl est difficile entre autre, donc ca va être dur pour nvidia.
    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 . Évalué à 1.

      > On dirait qu'il y a un amalgame, je opencl est difficile entre autre, donc ca va être dur pour nvidia.
      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 . Évalué à 2.

        Au passage, le langage propriétaire de CUDA comme OpenCL se base sur C99

        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 . Évalué à 1.

    C'est dit depuis bien lontemps. C'est une des raisons qui a poussé AMD à acquérir ATI. Mais depuis rien de vraiment concrêt.

    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 . Évalué à 1.

      Oups! Mon commentaire a été publié avec du retard.
      Petit pb de validation.
    • [^] # Re: Pas nouveau

      Posté par . Évalué à 2.

      AMD a permis à ATI d'augmenter ses fréquences de fonctionnement. Cela ne saute pas au yeux mais c'est aussi une raisons de leur succès.

      "La première sécurité est la liberté"

    • [^] # Re: Pas nouveau

      Posté par . Évalué à 2.

      ouaih :)
      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 . Évalué à 3.

      Il y a déjà des alims séparées pour les cartes graphiques.
      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 (page perso) . Évalué à 1.

        C'était quel modèle de 3DFX ? J'ai eu une 3DFX-2 et je pensais que c'était la dernière, mais je ne me souviens pas de la nécessité de l'alimenter de façon séparée. Par contre, je me souviens qu'ils filaient un cable pour relier deux 3DFX-2 dans le même boitier.
        • [^] # Re: Pas nouveau

          Posté par . Évalué à 1.

          je me suis amuse a relire l'historique de 3dfx peu apres avoir poste ce message, c'etait bien la derniere carte qu'ils ont produit avant de se faire racheter par nvidia et finir par faire banqueroute.
          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 à ceux qui les ont postés. Nous n'en sommes pas responsables.