Journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux...

Posté par  .
Étiquettes :
29
22
août
2010
Cher journal

Pendant des années, quand une personne me demandait une machine pour faire de la 3D sous Linux, j'ai conseillé du nVidia. Les pilotes libres ATI ne sont pas au niveau pour la 3D dans la plupart des cas, idem pour l'accélération du décodage de vidéos HD... Et ne parlons pas des pilotes propriétaires ATI qui ne proposent pas l'ensemble des fonctionnalités du pilote nVidia, ou qui ont encore des soucis de stabilité ou de compatibilité variable avec le noyau et le serveur X...
Le pote dont j'ai parlé dans mes deux journaux précédents a besoin d'une machine (portable, ou plutôt transportable) avec de la 3D, et a donc acheté une machine avec une carte nVidia. Sauf que cette machine est dotée de la technologie "nVidia Optimus".
C'est une technologie assez "intéressante". Elle repose sur l'utilisation de deux GPUs : le GPU nVidia et l'IGP intel, intégré aux processeurs i3/i5. L'IGP est bien moins gourmand en énergie que le GPU nVidia, mais n'est pas capable de faire du décodage performant de vidéo HD, de faire de la 3D "fluide"... Bref, il est bien pour le desktop pur, mais dès qu'on monte en demande, PAF. D'où l'idée de plus en plus courante d'avoir deux GPUs. Sauf que cette solution n'est pas optimale : l'utilisateur doit intervenir manuellement pour basculer d'un GPU à l'autre...
nVidia a donc eu l'idée suivante : faire de l'IGP le "contrôleur" graphique principal, en rendant le GPU "co-processeur". Ainsi, lorsque l'utilisateur est sur son tableur, son traitement de textes... Seul l'IGP est utilisé, et dès qu'il va sur un site en flash, qu'il lance le dernier jeu 3D (petit jeu : qu'est-ce-qui est le plus lourd pour la machine ?)... hop, le GPU se met en route et se charge de l'intégralité des opérations de cette application.
Passons à un petit peu plus technique : l'IGP est donc maître à bord, mais le pilote nVidia se glisse entre les applications et ce pilote. Lorsqu'une application 3D est lancée par exemple, un espace mémoire est alloué dans la mémoire de l'IGP, destiné à recevoir "l'image" visible de l'application, le résultat du rendu. Le GPU est alors allumé, et un DMA est mis en place : tout le rendu est réalisé dans un espace de mémoire du GPU, et est automatiquement copié dans la mémoire de l'IGP (à l'aide d'une fonctionnalité de la norme PCI Express a priori, à voir), qui se chargera donc ensuite de l'afficher sur l'écran.
Maintenant, la partie fun : comment faire marcher ça sous Linux. La réponse est simple : ce n'est actuellement pas possible, les développeurs de nVidia n'ont pas d'idée sur comment implémenter ça, et cela ne fait pas partie de leurs priorités. De plus, les développeurs des pilotes libres ont déclaré que le serveur X allait nécessiter des changements majeurs avant de pouvoir supporter un tel traîtement. Seules deux choses sont a priori possibles avec votre GPU nVidia si vous avez de l'Optimus :
- l'utiliser pour du calcul à l'aide de CUDA,
- l'éteindre pour économiser du courant (oui c'est même pas éteint par défaut sur toutes les machines).

Je n'ai pas testé CUDA directement, a priori ça marche assez facilement, d'une manière classique (et encore, c'est à confirmer). Par contre, pour l'extinction du GPU, cela n'est pas a priori générique. Un module a été développé, acpi_call, permettant d'appeler une méthode ACPI arbitraire, sans compiler de module noyau spécifique. Il est livré directement avec un script qui essaye différentes méthodes pour éteindre le GPU.
http://linux-hybrid-graphics.blogspot.com/2010/07/using-acpi(...)

Si je puis me permettre, ces dernières années, la plateforme x86 est devenue de plus en plus hostile à Linux, de plus en plus compliquée... ACPI, EFI... Et pourtant, Linux continue de marcher à peu près, aussi étonnant que ça puisse paraître. Mais là, on arrive quand même à des seuils de complexité difficiles à imaginer. Le salut viendra-t-il des netbooks ? Optimus est conçu pour permettre à nVidia de survivre aux sales coups d'Intel sur les Atom notamment, donc j'en doute. Le salut viendra-t-il des machines en ARM ? Peu probable étant donné que Windows n'est pas compatible avec elles...

Bon, je vous laisse, je vais aller me suicider je crois...
  • # c'est bien non ?

    Posté par  (site web personnel) . Évalué à 2.

    Il va pouvoir utiliser les pilotes libres Intel si j'ai bien tout compris :D

    En plus il va pouvoir contribuer :
    - rapidement, en remontant sa configuration matérielle sur http://hardware4linux.info ou http://smolts.org
    cf. http://faq.tuxfamily.org/CommunicationLibreHardware/Fr
    - sur le (plus) long terme en testant ce qui sera mis en oeuvre dans les pilotes/Xorg, cf. le PoC de David Airlie évoqué sur
    http://linuxfr.org/~Zezinho/29476.html
    • [^] # Re: c'est bien non ?

      Posté par  . Évalué à 10.

      Sur le très long terme tu veux dire ?
      To make this as good as Windows we need to seriously re-architect the X server + drivers.

      Et perso je ne considère pas qu'utiliser les pilotes libres intel, sur un GPU aussi minable que celui là, ça soit une bonne chose. C'est tellement lent que des trucs basiques vont ramer : même un jeu 3D minimal comme ksudoku (en mode roxdoku) rame... Si ça donne une bonne image du libre, je pige plus...
      • [^] # Re: c'est bien non ?

        Posté par  (site web personnel) . Évalué à 0.

        Sur le court terme aussi (cf. ma première proposition).

        Si ça donne une bonne image du libre, je ne pige plus...

        Et ne me fais pas dire ce que je n'ai pas dit. Si tu as recommandé le modèle sans vérifier auparavant son bon fonctionnement complet, ce n'est tout de même pas ma faute ? :D (tu as omis d'indiquer lequel de modèle au passage, d'où ma 1ère suggestion).
        Ensuite, avec le GPU Intel, j'ose espérer que ça fonctionnera autant que mon eeepc 901, sinon il est peut-être possible d'éteindre le GPU Intel et de ne garder que le nvidia (au détriment de la conso peut-être...).

        Si ça se trouve, cela avancera-t-il peut-être plus vite que tu l'escomptes aussi (de l'intérêt de primo-adoptant^Wtesteurs) ? Autant aussi en profiter pour demander du support à ceux qui peuvent y faire quelque chose (donc nvidia, un peu à toi d'assumer tes choix aussi :D).
      • [^] # Re: c'est bien non ?

        Posté par  (site web personnel) . Évalué à 3.

        et pour le moyen terme, il y a le kernel 2.6.34 avec switcheroo
        cf. http://linuxfr.org/2010/05/17/26852.html#switcheroo (un peu ce que je suggère, d'éteindre une carte au profit de l'autre, même si cela semble rester - pour l'instant - sous-optimal, de ton point de vue).

        àmha, avec une Fedora ou un kernel récent, il y aurait peut-être moyen d'avoir des (bonnes) surprises pour le fonctionnement (ou les versions de développement d'autres distros de ta préférence...).
        • [^] # Re: c'est bien non ?

          Posté par  . Évalué à 6.

          Non, justement, il est catégoriquement impossible de faire marcher la carte nvidia, il n'est pas possible d'allumer la carte nvidia et d'éteindre la carte intel, ni avec switcheroo, ni avec aucune bidouille connue, ni avec les appels liés à Optimus dans la DSDT. Il n'y a pas de réglage dans le bios, pas de réglage dans windows... Rien, nada.
          Le GPU Intel, avec les pilotes libres, marche pour la 2D uniquement, pour la 3D, ça rame sérieusement.

          Je n'ai peut être pas été clair dans l'explication : nVidia Optimus, ce n'est pas du tout la même chose que les systèmes hybrides à base de deux cartes. Certains fabricants vont laisser un mécanisme "simulant" le système hybride, qui permet donc de faire marcher le tout sous Linux. Mais ce n'est pas le cas de l'Asus N61Jv...
          • [^] # Re: c'est bien non ?

            Posté par  (site web personnel) . Évalué à 4.

            Certains fabricants vont laisser un mécanisme "simulant" le système hybride, qui permet donc de faire marcher le tout sous Linux. Mais ce n'est pas le cas de l'Asus N61Jv

            un google rapide linux Asus N61Jv me donne
            http://ubuntuforums.org/showthread.php?t=1416269 [en] une ML pour le N61 (un peu vide :/)
            http://ubuntuforums.org/showthread.php?t=1420377 [en] des questions pour le faire fonctionner
            http://forum.ubuntu-fr.org/viewtopic.php?pid=3570432 [fr] les mêmes soucis en français
            http://www.linlap.com/wiki/asus+n61jv [en] qui indiquerait qu'opensuse le fait fonctionner (d'après les commentaires)
            Rien sur http://tuxmobil.org/asus.html ni http://www.linux-on-laptops.com/asus.html ce pourquoi je recommande toujours hwreport, histoire d'avoir des infos factuelles sur le matériel inclus. Sur smolts.org, il y a bien http://smolts.org/reports/view_profile/N61Jv%201.0 (mais quasi personne n'a indiqué à quel niveau cela fonctionne :/ hormis http://smolts.org/client/show/pub_50e5b722-8bf7-4126-9cf7-66(...) dont le bilan global est "doesn't work", pas très encourageant :/).

            donc bon, ça nous fait un nouveau testeur en devenir pour le nouveau matériel sous GNU/Linux :/ (à moins - ou en plus - de se contenter du pilote graphique Intel quand même).

            Au passage, j'ai cru voir que ce portable coûte de l'ordre de 900 euros pour une autonomie de 1h30... rien que ça me l'aurait fait le rejeter (mais c'est parce que pour moi la notion de portable va avec l'autonomie - au début au moins - de 4h minimum avec les restrictions acceptables de performance, wifi coupé toussa).
            • [^] # Re: c'est bien non ?

              Posté par  . Évalué à 4.

              http://www.linlap.com/wiki/asus+n61jv [en] qui indiquerait qu'opensuse le fait fonctionner (d'après les commentaires)

              Save the nVidia Optimus gfx card, everything else works perfectly
              Except the aforementioned nVidia Optimus card, it works great!
              Problem as described above, is with the video-card, Nvidia Optimus
              puis
              GF and LCD works fine with 195.xx drivers


              a mon avis, le kéké du bas a les drivers nvidia installés, le pc marche sur la intel et il s'en est pas rendu compte parce qu'il fait pas de 3D intensive.
            • [^] # Re: c'est bien non ?

              Posté par  . Évalué à 4.

              J'ai trouvé tous tes liens, j'avais fait mes recherches hein...

              Sinon, l'autonomie est ridicule quand t'as la carte nvidia allumée en permanence, typiquement quand t'es sous linux et que t'as pas utilisé acpi_call ou une autre méthode pour éteindre la carte graphique.

              Une mailing list sur launchpad est prévue explicitement pour ces problèmes : hybrid-graphics-linux@lists.launchpad.net.
              Et pour info, l'avis de Dave Airlie sur Optimus : http://www.mail-archive.com/hybrid-graphics-linux@lists.laun(...)
      • [^] # Re: c'est bien non ?

        Posté par  . Évalué à 4.

        C'est pas un problème, ça fait 12 fois qu'il est réécrit ce machin. A la prochaine ça devrait fonctionner.
  • # Ce n'est pas X.Org le problème?

    Posté par  . Évalué à 9.

    Je n'y connais rien, mais d'après ce que tu viens d'écrire, c'est l'architecture actuelle de X.Org qui est un problème ("les développeurs des pilotes libres ont déclaré que le serveur X allait nécessiter des changements majeurs avant de pouvoir supporter un tel traîtement").

    Même si je n'ai aucun doute que X.Org évolue dans la bonne direction (il n'y a qu'à voir le chemin parcouru depuis le fork d'avec XFree86 (est-ce qu'il est d'ailleurs toujours vivant ce projet? Car il n'y a plus d'activité depuis décembre 2008)), c'est juste un mauvais moment à passer.

    Est-ce que je me trompe?
    • [^] # Re: Ce n'est pas X.Org le problème?

      Posté par  (site web personnel) . Évalué à 1.

      Est-ce que je me trompe?

      oui, il indique bien dans son journal que c'est nvidia et sa techno "Optimus" le problème ('fin c'est une question de point de vue quand même, j'ai le mien aussi :p).
    • [^] # Re: Ce n'est pas X.Org le problème?

      Posté par  . Évalué à 7.

      Est-ce que je me trompe?

      Bien sur que non.
      Xorg ne permet pas de faire fonctionner les cartes de cette manière, il faudrait le modifier en profondeur.
      Donc les devs nvidia doivent contourner xorg mais ils ne savent pas encore comment.
      Or, contourner xorg c'est déjà ce qu'ils avaient fait quand il n'y avait pas d'accés direct au matériel dans xorg, et ils se sont fait pourrir depuis pour l'avoir fait. Ca m'étonne pas qu'ils ne sont pas pressés pour faire du travail qui va leur revenir dans la gueule comme un boomerang.

      Ca va être comme d'hab', sauf miracle, ils vont attendre d'avoir un client qui le demande et qui paye pour l'avoir. Qui va payer pour avoir ça qui marche sur linux?

      Sinon, par ailleurs, quel est l'intérêt de cette solution par rapport à ION? Faire du low energy qui puisse avoir de meilleures perfs? Il y a un marché pour ça?
      Parce que le concurrent à Intel sur ce segment c'est ION, non? Et puis inclure du Intel pour contrecarrer Intel, ça me semble pas super efficace comme stratégie.
      Est ce qu'on parle pas plutôt d'un device pour un marché de niche, limite expérimental? Ou est ce qu'il y a beaucoup de portables qui l'utilisent?
      Ca me semble un truc fumeux comme le SLI cette affaire.
      • [^] # Re: Ce n'est pas X.Org le problème?

        Posté par  . Évalué à 3.

        Intel a pété sa gueule à ION en incluant dans l'Atom un IGP (et en refusant je ne sais quelle licence à nVidia).
        nVidia a donc préparé ION2, avec la technologie Optimus, pour contrer ce coup bas d'Intel.
        • [^] # Re: Ce n'est pas X.Org le problème?

          Posté par  . Évalué à 4.

          Merde, je ne savais pas.
          Ca me fait toujours rire quand je vois des pro intels qui ne semblent pas savoir de qui ils parlent. nvidia, c'est de la gnognotte à coté, question machiavélisme et controle.

          Et il n'y a plus de design sans cet optimus si on veut de la 3D et un petit machin? Genre les revo, ça ne se fait plus en ion simple?
          • [^] # Re: Ce n'est pas X.Org le problème?

            Posté par  . Évalué à 2.

            La plateforme "ION1" est vouée à disparaître. Seul ION2 reste. À moins qu'AMD ne sorte un concurrent de l'Atom bien sûr...
            • [^] # Re: Ce n'est pas X.Org le problème?

              Posté par  . Évalué à 2.

              Je viens de regarder, pas mal de design prévus en ion2 ont été finalement en ion1. Mais on commence à voir les ion2 arriver. De toutes façon, si le blocage est en amont avec intel et son nouveau chipset, il ne pourra plus y avoir de ion1 même si les constructeurs prennent pas du ion2. Intel et le monopole, une vieille histoire sans cesse répétée.
      • [^] # Re: Ce n'est pas X.Org le problème?

        Posté par  . Évalué à 4.

        Qui va payer pour avoir ça qui marche sur linux?

        ça serait bien qu'un milliardaire sud-afrcain s'en mêle un peu...
        • [^] # Re: Ce n'est pas X.Org le problème?

          Posté par  (site web personnel) . Évalué à 10.

          Quitte à payer, je préférerai qu'il paye un dev pour contribuer aux pilotes libres plutôt que de mettre cet argent dans du proprio ;)

          S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

          • [^] # Re: Ce n'est pas X.Org le problème?

            Posté par  . Évalué à 2.

            oui moi aussi m'enfin nVidia a bien expliqué qu'ils ne contribueraient pas au libre et entre temps ça permettrait d'avoir quelque chose de fonctionnel
        • [^] # Re: Ce n'est pas X.Org le problème?

          Posté par  . Évalué à 7.

          Pourquoi le ferait il? Pour se faire flamer à mort pendant des années?
    • [^] # Re: Ce n'est pas X.Org le problème?

      Posté par  . Évalué à -4.

      NVidia qui ne fout rien de rien pour le libre et en plus renvoit la faute sur le libre.
      Sont fort NVidia pour des branleurs.
  • # Décodage vidéo

    Posté par  (site web personnel) . Évalué à 10.

    >>> 'IGP intel, intégré aux processeurs i3/i5. L'IGP est bien moins gourmand en énergie que le GPU nVidia, mais n'est pas capable de faire du décodage performant de vidéo HD

    Ah si depuis le noyau 2.6.35, l'IGP Intel des i3/i5/i7 peut assurer le décodage matériel des formats H.264 et VC1 : http://linuxfr.org/2010/08/02/27164.html#bref6
  • # Comment qu'y parle, lui !

    Posté par  . Évalué à 8.

    « ce n'est actuellement pas possible, les développeurs de nVidia n'ont pas d'idée sur comment implémenter ça »

    Attention, « sur comment » n'est pas français, c'est de l'anglais mal traduit (on how). L'erreur est très courante dans les médias qui ont malheureusement contaminé l'ensemble de la société. L'adverbe s'associe en effet très mal avec une préposition.
    Renaud Camus l'a identifié comme un des points centraux de l'effondrement syntaxique de la langue française dans son Répertoire des délicatesses du français contemporain.
    « de comment », « sur comment », mais aussi « de pourquoi », « sur pourquoi », procèdent du même relâchement linguistique.

    Il est plus correct d'écrire : « les développeurs de nVidia n'ont pas d'idée sur la façon d'implémenter ça. »
  • # ...

    Posté par  . Évalué à 10.

    Si je puis me permettre, ces dernières années, la plateforme x86 est devenue de plus en plus hostile à Linux, de plus en plus compliquée... ACPI, EFI... Et pourtant, Linux continue de marcher à peu près, aussi étonnant que ça puisse paraître. Mais là, on arrive quand même à des seuils de complexité difficiles à imaginer. Le salut viendra-t-il des netbooks ? Optimus est conçu pour permettre à nVidia de survivre aux sales coups d'Intel sur les Atom notamment, donc j'en doute. Le salut viendra-t-il des machines en ARM ?

    Arm en tant que tel,ne simplifie pas grand chose : l'acpi, efi et pas mal de truc tordu sur x86 sont la pour abstraire le matériel et permettre d'avoir un noyau générique et "compatible" avec les tous les hards.

    Pour le moment sur arm, tout les informations sont codé dans le noyau, et ça ne passera pas à l'échelle si chacun implémente sa propre plateforme arm. Surtout qu'il faut pour le moment au moins un noyau par famille (omap, marvell, ...)


    Optimus est conçu pour permettre à nVidia de survivre aux sales coups d'Intel sur les Atom notamment, donc j'en doute.
    Au passage la platforme ion2 de nvidia en est réduite à un gpu sur bus pci-e alors que le ion était un vrai chipset (contrôleur usb, ddr) : http://www.tbreak.com/tech/files/ion2_block.gif
    D'ailleurs je vois que la techno optimus est associé a ion2. Quel beau bordel...
    • [^] # Re: ...

      Posté par  (site web personnel) . Évalué à 5.

      Pour le moment sur arm, tout les informations sont codé dans le noyau, et ça ne passera pas à l'échelle si chacun implémente sa propre plateforme arm.
      Tonton Linus a été pas content et a dit qu'il faut factoriser cet énorme amas de code.
      https://linuxfr.org/2010/08/02/27164.html#bref9

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

      • [^] # Re: ...

        Posté par  . Évalué à 4.

        oui, mais c'est diffèrent : la c'était le coup d'un fichier de config par carte (mais même soc).

        C'est pas magique il faut bien que quelque chose dise à linux : ici il y a un controlleur usb de tel type, a tel adresse mémoire, ...
        Certaines personnes sont en train de proposer un arbre de periph http://lwn.net/Articles/367752/ , mais c'est pas gagné.

        De plus sur x86 il y a des bocks bas niveau commun (contrôleur d'irq, timer, mapping ram physique, ...) sous arm c'est pas le cas.
    • [^] # Re: ...

      Posté par  . Évalué à 3.

      Au passage la platforme ion2 de nvidia en est réduite à un gpu sur bus pci-e alors que le ion était un vrai chipset (contrôleur usb, ddr)
      En effet, le contrôleur mémoire est intégré au CPU. Et comme intel force sûrement encore la vente du chipset avec le CPU, ben nVidia a décidé de se simplifier la vie et de ne faire plus qu'un GPU à l'aide d'Optimus. Je ne vois pas comment leur reprocher ça...
    • [^] # Re: ...

      Posté par  . Évalué à 5.

      L'idée d'abstraire le matos pour les "OS" dans une couche magique intermédiaire ACPI (qui inclut une VM suffisamment puissante pour faire à peu prêt tout et n'importe quoi y compris des spywares pas mal furtifs) est de la merde en boite de toutes façons. Le seul effet est de déplacer le code dans quelque chose de plus difficile à débugguer / modifier, et le bousin a été volontairement mal conçu à des fins machiavéliques. Tout ceci serait sans conséquence si les fabricants de CM faisaient correctement leur boulot. Vu la teneur de la norme, et vu que c'est impossible d'y comprendre quoique ce soit sans être sous LSD, ça n'est évidemment pas le cas. Au final beaucoup de fabricants ne testent que sous Windows, et les "détails d'implémentation" d'une des couche compensent les bugs de l'autre.

      Pas tout n'est à jeter des idées d'ACPI. Des descripteurs simples sont par exemple indispensables pour indiquer les connexions des interruptions ou autres trucs similaires. (Mais pour la plupart des descripteurs, le format de la spec ACPI nécessite généralement d'aller au delà du LSD et de passer au crack pour qu'il paraisse avoir un semblant de sens.) Quand à la programmation du matos, l'histoire à continuellement prouvée que hors des spec, point de salut; le code de l'ACPI de la CM écrit par un singe sous amphétamines est trop souvent complètement buggé pour être d'une quelconque utilité sous un vrai OS.
  • # et ATI c'est pire ?

    Posté par  . Évalué à 3.

    Avec ce MSI : [http://www.ldlc.com/fiche/PB00099567.html]
    On peut aussi changer de carte graphique mais avec une ATI pour la partie dédié et l'iGP du core i5.

    Je suppose que c'est le même bazar avec ATI mais en pire, non ?
  • # ARM.... Android .... Copains.

    Posté par  (site web personnel) . Évalué à 10.

    Maintenant que j'y repense, ce problème pourrait très bien être le même sur les Android, qui fait qu'ils utilisent le framebuffer (avec une API étendue), plutôt qu'X. L'architecture sur les téléphones au moment de la création d'android, c'est grosso modo, un moteur 2D extrèmement simple (il ne gère que la fonction blit ! (ie copie de mémoire d'un buffer quelconque vers l'affichage, avec quand même des options d'opacité, rotation (multiple de 90° quand même), redimensionnement, coupe), et différents moteurs qui vont se greffer dessus. C'est à dire que aussi bien le GPU 3D, que le décodage vidéo, vont écrire dans leur propre mémoire, et derrière demander au framebuffer de recopier cette zone.
    Au final, c'est bien la même problématique, sauf que les puces graphiques intel, sont plus puissantes qu'une pauvre gestion de blit, et donc non des "machines en ARM" n'aideraient pas forcément :D
    Comme dit plus haut, il y a un répertoire dans le noyau par série de chipsets (omap/omap3,msm, samsung fait particulièrement fort aussi dans mes souvenirs), et même pire ! À part certaines personnes qui font des efforts particuliers pour (j'en fait partie avec le projet htc-linux, mais bon ça risque pas d'aller en amont de toutes façons), il n'est pas possible de faire un noyau binaire compatible avec plusieurs cartes à la foi ! Typiquement, les beagle boards ont un noyau RevA/RevB, et un noyau RevC, certains téléphones ont des noyaux différents, juste parce qu'ils ont une version du logiciel radio différent !
    Bon donc voilà, en ARM c'est pas forcément mieux qu'en x86. (Enfin qualcomm a décidé de faire un driver Xorg qui gère 3D et accélération vidéo, faudrait voir comment.)

    Pour en revenir au problème, je pense que des solutions (de contournement ? peut être, mais elles me paraissent assez naturelles) existent. Y avait la méthode barbare des DXR3, mais à l'heure du compositage c'est peut être plus trop d'actualité :D
    Plus sérieusement, quand on utilise du Xv, c'est un peu ce que l'on fait, si ce n'est que le décodage est fait en soft et non en hard, mais le problème reste le même: le décodage est fait par une entitée annexe au driver vidéo, écrit dans une zone mémoire à lui, et la carte graphique va le recopier derrière (comme sur ARM, avec des options simples derriere comme du redimensionnement ou du changement de format :D).
    Après on va me dire que c'est sale, que le Xv c'est fait pour la vidéo, mais bon, ce Xv c'est bien l'équivalent d'un blit, à part le nom, et le protocole. Donc à côté de ça, il "suffit" que la lib OpenGL écrive dans son propre buffer, au lieu de vouloir l'écrire directement sur l'affichage, et de faire un lien entre les deux. Je me demande même si ce n'est pas possible même en étant en dehors du driver nVidia, étant donné que CUDA marche.
    "Au pire", il doit être possible de lancer un serveur X sur la carte nVidia (sauf si le driver refuse parce qu'il ne trouve aucune sortie... ce qui est probable en fait.), d'avoir un genre de VNC qui affiche le contenu du serveur X de la nVidia, sur le serveur X de l'intel. Après, pour avoir des fonctionnalités équivalentes à Windows, il manquera juste deux étapes: pouvoir exporter des fenêtres, et non tout un écran, et automatiser le processus de choisir sur quel serveur X afficher le bousin.
    PS: Bon après, vu que je me renseigne avant d'acheter un ordinateur, je n'ai pas de portable avec ce genre de blagues, donc comptez pas sur moi pour essayer de faire ça (et non je ne me mouille pas.)
    • [^] # Re: ARM.... Android .... Copains.

      Posté par  . Évalué à 6.

      Donc à côté de ça, il "suffit" que la lib OpenGL écrive dans son propre buffer, au lieu de vouloir l'écrire directement sur l'affichage, et de faire un lien entre les deux. Je me demande même si ce n'est pas possible même en étant en dehors du driver nVidia, étant donné que CUDA marche.
      "Au pire", il doit être possible de lancer un serveur X sur la carte nVidia (sauf si le driver refuse parce qu'il ne trouve aucune sortie... ce qui est probable en fait.), d'avoir un genre de VNC qui affiche le contenu du serveur X de la nVidia, sur le serveur X de l'intel.

      Hum, raté...

      Tout d'abord, en effet, le pilote nvidia ne trouve pas de sortie, et donc il refuse de lancer un serveur X.

      Sinon, pour la partie OpenGL, c'est assez complexe. OpenGL seul ne peut pas marcher, quel que soit l'OS. Il faut systématiquement un complément qui fournisse le contexte sur lequel le rendu se fera. Dans le cas de Windows, il s'agit de WGL. Dans le cas du serveur X, il s'agit de GLX.
      Pour faire fonctionner Optimus en cassant le moins de choses possible sur l'architecture de X, il faudrait détourner la libGL et être capable de créer un contexte dans le pilote nVidia qui serve à faire le rendu dans un buffer qui soit dans le framebuffer de l'IGP Intel. Ce qui bloque sérieusement actuellement, c'est la création de ce contexte il me semble.
      • [^] # Re: ARM.... Android .... Copains.

        Posté par  (site web personnel) . Évalué à 2.

        Mon "Au pire" marche encore, quelque soit les coups tordus de l'OpenGL, c'est juste un Xnvidia :1 & DISPLAY=:1 glxgears & x2vnc & DISPLAY=:0 vncviewer -display :1
        Sauf que vnc est un protocole on ne peut plus inaproprié ici, mais bon voilà l'idée.
        Après, c'est effectivement une solution extrèmement moche, mais elle ne requiert pas de changements majeurs où que ce soit, et permet d'utiliser quand même d'utiliser sa carte nVidia.

        D'autre part, il faudrait peut être demander aux gens de Qualcomm, ils ont un driver qui fait ce genre de choses, j'essayerais de voir comment ils s'en sortent.
  • # faudrait chercher ce ce coté....

    Posté par  . Évalué à 2.

    regardez ce lien .....
    http://linuxfr.org/~Zezinho/29476.html

    peut être pas avec les pilotes nvidia, mais nouveau.....
  • # Remplir les besoins des utilisateurs != Hostile a Linux

    Posté par  . Évalué à 7.

    Je trouve que ta phrase "la plateforme x86 est devenue de plus en plus hostile à Linux" est plutôt mal fichue, c'est plutôt:
    1) les PC offrent des fonctionnalités toujours plus poussées (GPU programmable, mix de GPU basse et haute performance pour les portables..)
    2) plus de fonctionnalité implique plus de complexité

    --> comme on a toujours 98% d'utilisateurs desktop sous Windows, personne n'investit sur les fonctionnalités avancée avec Linux..

    Et comme personne a part Microsoft et Apple n'arrivent a faire de l'argent sur le desktop (ni le propriétaire cf la déroute de BeOS) ni Linux, cette situation va perdurer..

    • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

      Posté par  . Évalué à 2.

      Dans mes exemples, j'ai mis l'ACPI. Si ça c'est pas de l'hostile à Linux franchement, que te faut-il de plus ? Un système où le BIOS filtre sur l'OS, un système où un bytecode les trois quarts du temps non conforme est indispensable au fonctionnement de la machine...
      Quand linux ne boote plus parce qu'on a augmenté la quantité de RAM et que la DSDT fait mal le mapping mémoire pour Linux, franchement, t'as de quoi chialer (et c'est du vécu)
      • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

        Posté par  (site web personnel) . Évalué à 5.

        Tu n'as pas répondu à la question : en quoi est-ce hostile à Linux?
        Dans l'exemple de ton commentaire, je vois du matos qui évolue, du code qui est fait pour Windows pour s'adapter, et ce code pas fait pour Linux. Ce n'est pas de l'hostilité, juste personne pour payer un dév pour faire pour Linux.

        C'est la même chose dans ton journal : "bonne idée fondamentalement incompatible avec Linux..." j'aurai plutôt mis "Linux incompatible avec une bonne idée", tu attaque nVidoa, qui a simplement fait du matos pour répondre au besoin, et a programmé pour répondre au besoin de 99% des gens qui ont un PC, et n'ont pas éprouvé l'intérêt de développer la chose pour un OS peu utilisé sur le desktop, cible du produit.
        Tu accuses nVidia, pourquoi? Ils n'ont rien attaqué, ils ne voient juste pas l'intérêt de faire le boulot, si tu veux que ça marche pour Linux tu peux payer nVidia pour qu'ils adaptent, trouver d'autres personnes pour montrer qu'il y a un retour sur investissement etc...

        Tu vois des hostilité à des endroits où c'est beaucoup moins machiavélique : ça ne vaut juste financièrement pas le coût, et on te laisse le soin d'investir si tu le penses toi de ton côté. Aucune hostilité, juste une question de rentabilité.
        • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

          Posté par  . Évalué à 5.

          Tu n'as pas répondu à la question : en quoi est-ce hostile à Linux?
          Dans l'exemple de ton commentaire, je vois du matos qui évolue, du code qui est fait pour Windows pour s'adapter, et ce code pas fait pour Linux. Ce n'est pas de l'hostilité, juste personne pour payer un dév pour faire pour Linux.

          Je résume le code de la DSDT vu que c'est pas clair apparemment :
          if (OS == windows) {
          trucQuiMarche();
          } else if (OS == linux) {
          trucQuiPlanteLamentablement();
          }
          La correction, c'est d'enlever le test et de ne faire que trucQuiMarche, qu'il s'agisse de windows ou linux.
          Quand le compilateur AML de Microsoft introduit du bytecode invalide (qui plantait à une époque l'interpréteur de Linux), c'est pas hostile, c'est "l'évolution" ?
          C'est "l'évolution" qui dit qu'il faut que ce qui est simple ne doit plus l'être et que seul ce qui est compliqué mérite d'exister ?
        • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

          Posté par  (site web personnel) . Évalué à 3.

          tu y réponds toi-même, c'est hostile avec les standards et mal développé^W^Wtesté uniquement avec 7 par exemple.

          C'est en fait hostile avec XP et Vista, pour ceux qui ont acheté une version boîte, et accessoirement avec Linux, OpenBSD (*BSD) et Haiku, un peu dommage pour un ordinateur... alors qu'il suffirait de respecter des standards (ou contribuer à les faire évoluer pour prendre en compte le nouveau matériel grâce à des spécifications fournies). Si nVidia avait fourni les specs de leur matériel, ils auraient déjà fait leur minimum possible, sinon bin ça demande plus de boulot.

          Pour le titre, je l'ai pris au second degré (comme mon premier commentaire d'ailleurs, mal comprite visiblement :/).
          • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

            Posté par  . Évalué à 5.

            D'un autre cote, c'est pas trop la faute de nvidia si Linux utilise un serveur graphique aussi rigide que rms.
            Je doute que ms et apple ait du fondamentalement reachitecturer leurs serveurs graphique pour avoir des pilotes pour ces cartes graphiques, donc c'est que quelque part, le probleme est pas la ou certain le voudraient. Ou plutot, il est la ou certains ne le voudraient pas.

            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

            • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

              Posté par  . Évalué à 4.

              Microsoft, avec Vista, a entièrement refait son architecture graphique.
              MacOS X ne peut pas supporter la technologie Optimus pour l'instant, idem pour Windows XP (mais bon vu son âge...)
              • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                Posté par  . Évalué à 1.

                OS X supporte une technologie alternative conçue par Apple en partenariat avec Nvidia qui apporte les mêmes fonctionnalités d'un point de vue utilisateur. Si je me souviens bien, OS X active le GPU lorsqu'une application utilise directement ou indirectement OpenGL, tandis qu'Optimus fonctionne (au niveau logiciel) avec une liste d'applications pré-établie. Je ne sais pas comment cela fonctionne au niveau matériel.

                Question : les GPU des MBP récents fonctionnent-ils avec Linux ?
                • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                  Posté par  . Évalué à 6.

                  Optimus ne marche que si les applications le demandent explicitement??

                  Et ben ça va pas être le foutoir du tout d'utiliser tous les bons vieux logiciels de tout bord déjà acquis par le passé, et pas forcément mieux pour ceux à venir!

                  C'est rigolo, je croyais qu'on allait finir par s'éloigner de cette manie qu'ont les constructeurs à vouloir que les logiciels soient faits pour LEUR matériel, et pas pour tout matériel répondant à des normes établies.
                  Je lui prédis un bien funeste destin, à cet Optimus...

                  ("Allo, le support? Je voudrais comprendre pourquoi mon ordi à 1000€ avec une grosse carte graphique n'arrive pas à faire tourner mes jeux? (...) Hein? Faut attendre la nouvelle version du jeu et ça marchera peut-être???")
                  • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                    Posté par  . Évalué à 4.

                    Optimus ne marche que si les applications le demandent explicitement??

                    Non, ce n'est pas ce que j'ai dit. La dernière fois que j'en ai entendu parler, il y avait dans le pilote une grosse liste d'applications pour lesquelles activer le GPU. Ce ne sont pas ces dernières qui décident qui doivent signaler directement au système leurs besoins.

                    Enfin, ça reste tout de même assez moche à mon avis :-o
                    • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                      Posté par  . Évalué à 2.

                      Ah, effectivement.
                      Dans ce cas, c'est pas après la nouvelle version du logiciel qu'il faut attendre, mais juste que nVidia finisse de recenser toutes les applications 3D qui existent dans le monde, et mette à jour le pilote en même temps que de nouveaux logiciels sortent.
                      Je ne suis pas sûr que ce soit mieux en fait!

                      Je vais peut-être poser une question bête, vu que je ne suis pas versé dans l'affichage graphique et le reste, mais ça ne serait pas plus simple de définir des "circonstances" dans lesquelles la 3D est sollicitée un peu plus comme déclencheur?
                      Je ne sais pas moi, mais il doit bien y avoir des fonctions appelées vraiment caractéristiques d'un rendu 3D un peu lourd, ou une fréquence d'appel de ces fonctions. On éteint le GPU ensuite quand le processus qui a appelé ces fonctions se termine.
                      • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                        Posté par  . Évalué à 2.

                        La liste est sur internet, et le pilote la télécharge régulièrement, tu peux en plus te faire ta propre liste.
                        De toute façon, il me semble que les pilotes contiennent déjà une liste d’applications (jeux) avec les paramètres recommandés, mais je peux me tromper.

                        Je vais peut-être poser une question bête, vu que je ne suis pas versé dans l'affichage graphique et le reste, mais ça ne serait pas plus simple de définir des "circonstances" dans lesquelles la 3D est sollicitée un peu plus comme déclencheur?
                        C’est ce que fait Mac OS, il détecte quand une appli utilise OpenGl et alors active la GForce.

                        Depending on the time of day, the French go either way.

                • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                  Posté par  . Évalué à 2.

                  J'ai pu tester le pilote proprio nvidia sur un MBP 6.2 commandé fin juin et ça fonctionne plutôt bien.

                  J'ai pas testé grand chose mais si tu veux plus d'infos...
              • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                Posté par  . Évalué à 1.

                peut etre pas exactement optimus, vu qu'apple ne la distribue probablement pas, mais un truc similaire.
                Mais faut croire qu'ils ont une techno tres similaire, je bosse presentement sur un macbook pro avec un i7 et une GeForce GT 330M, et je doute que la geforce tourne la majorite du temps vu la duree de vie de la batterie.

                If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

        • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

          Posté par  . Évalué à 3.

          tu attaque nVidoa, qui a simplement fait du matos pour répondre au besoin, et a programmé pour répondre au besoin de 99% des gens qui ont un PC

          C'est la partie de ton raisonnement que je ne suis pas trop. Je ne vois pas trop en quoi ce système répond à un besoin. Il me semble plus, comme l'a dit pinataf, répondre à un barrage en amont fait par Intel.
          Une carte graphique normale avec une bonne gestion de l'énergie serait aussi efficace et plus simple à mettre en oeuvre, c'était d'ailleurs ce que faisait la plateforme ION avant le blocage par intel.
          • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

            Posté par  (site web personnel) . Évalué à 4.

            Il me semble plus, comme l'a dit pinataf, répondre à un barrage en amont fait par Intel.

            Tu pose la question et y répond.
            "répondre à un barrage en amont fait par Intel" est le besoin.

            Une carte graphique normale avec une bonne gestion de l'énergie serait aussi efficace et plus simple à mettre en oeuvre,

            Je n'ai pas dit le contraire : nVidia répond au besoin, après ce serait mieux de ne pas avoir besoin de cette bidouille, mais c'est la vie, quand on ne maitrise pas l'autre (=Intel), ben on fait avec les choix de l'autre.

            Ici, nVidia répond au besoin et Windows a un design le permettant, Linux (X en fait) a un design rigide qui ne le permet pas pour le moment sans compter que l'investissement à un retour financier quasi nul (pour les quelques utilisateurs Linux qui vont acheter cette carte... Financièrement plus rentable qu'ils achètent Windows)

            Intel fout la merde, nVidia vit sa vie (et sa vie ne dépend absolument pas des utilisateurs Linux), le problème concernant Optimus est Linux, pas les autres. Ils ne libèrent pas les specs, c'est leur choix aussi, c'est la faute à Linux si Linux n'arrive pas à démontrer qu'il serait rentable qu'ils les libèrent (mais ça ne changerai pas le fait que X est rigide...)

            Le problème vient, de mon point de vue, que X est techniquement en retard sur Windows (ou Mac) au niveau des fonctionnalités possibles. Alors c'est super que X fasse un supe-méga truc qui fait qu'on peut avoir 1000 terminaux, c'est bien, mais ce n'est pas le besoin de nVidia pour le moment, alors que Windows ne permet certes pas les 1000 terminaux, mais répond au besoin de nVidia.
            • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

              Posté par  . Évalué à 3.

              Tu pose la question et y répond.
              "répondre à un barrage en amont fait par Intel" est le besoin.

              ok, on est d'accord alors, c'est juste la notion de besoin où on diverge, c'est pas énorme, pour moi un besoin provoqué artificiellement par une entreprise en situation dominante n'est pas un besoin des utilisateurs ni un problème techniquemais un problème de la société.

              X est techniquement en retard
              Oui, je suis d'accord, je t'ai dit que j'étais d'accord avec le reste de ton raisonnement.
              • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                Posté par  (site web personnel) . Évalué à 0.

                pour moi un besoin provoqué artificiellement par une entreprise en situation dominante n'est pas un besoin des utilisateurs ni un problème techniquemais un problème de la société.

                Je n'ai pas dit le contraire.
                Mais si tu t'arrêtes au moindre problème "on ne peut pas faire changer l'autre, donc on ne fait rien", ni ne va jamais aller bien loin, car le monde des bisounours prêts à aider son prochain n'est pas celui dans lequel moi je vis en tous cas.

                Il n'en reste donc pas moins que c'est un besoin, et que nVidia répond au besoin pour Windows et n'a pas besoin de répondre au besoin de répondre au besoin pour Linux, ça ne lui rapporte quasi-rien (la, c'est ton besoin, donc libre à toi d'y mettre l'argent/les moyens si tu veux y répondre, ce qui est sûr c'est que dire que Intel est le méchant ne changera rien au problème : Intel ne compte pas changer de position, et nVidia ne compte pas dépenser de l'argent juste pour tes beaux yeux)
            • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

              Posté par  (site web personnel) . Évalué à 1.

              Alors c'est super que X fasse un supe-méga truc qui fait qu'on peut avoir 1000 terminaux, c'est bien, mais ce n'est pas le besoin de nVidia pour le moment, alors que Windows ne permet certes pas les 1000 terminaux, mais répond au besoin de nVidia.

              Si tu parles de terminaux virtuels (xterm) alors j'ai le devoir de t'annoncer que c'est impossible de lancer autant de fenêtres dans un serveur X. 256 maximum selon le wiki de Xorg, et j'ai pu il me semble expérimenter une limite à 512 sur une Fedora:

              http://www.x.org/wiki/Development/X12#XIDsaretoosmall
      • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

        Posté par  . Évalué à 2.

        Bah, l'ACPI c'est juste une preuve de plus qu'Intel est souvent très mauvais coté définition d'interfaces, comme autre preuve j'ai:
        - se louper totalement sur le MMX: le partage des registres MMX avec les registres FP étant une c... sans nom
        - loupage partiel avec le SSE première version, SSE2 étant bien plus régulier
        - ne pas être capable de faire évoluer le x86 correctement, en final c'est AMD qui a du le faire..

        Je ne pense pas que tout ces ratages soient anti-Linux, c'est juste qu'Intel a d'un coté des super-ingénieurs qui gérent les meilleurs fonderies aux monde, de l'autre des dirigeants qui prennent des décisions très, très 'surprenantes':
        - pousser le Pentium4 a plusieurs GHz: un responsable de la conception de CPU a démissioné pour protester!
        - la derniere en date étant l'achat d'un éditeur d'antivirus!



        • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

          Posté par  . Évalué à 3.

          - se louper totalement sur le MMX: le partage des registres MMX avec les registres FP étant une c... sans nom
          Pourtant arm a fait la même chose pour les cortex-A8/A9 avec neon...
          • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

            Posté par  . Évalué à 2.

            Oui, eh?
            Intel n'est pas le seul a faire des bidouilles pas très belle:
            ARM vient d'annoncer une extension 40-bit mais chaque processus restant limité à 32 bit.. Bref, comme PAE quoi, c'est aussi une bidouille moche pour résoudre les limitations en mémoire..

            MIPS, PowerPC eux ont une vrai extension 64-bit..

        • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

          Posté par  . Évalué à 8.

          Pour l'ACPI, c'est pas que du Intel... Y'a ce point également à ne pas oublier : http://antitrust.slated.org/www.iowaconsumercase.org/011607/(...)
          "It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work", Bill Gates
          Traduction approximative :
          "Cela serait dommage que nous et nos partenaires fassions le travail et qu'au final Linux fonctionne bien sans devoir faire ce travail."
        • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

          Posté par  . Évalué à 3.

          Rappelons nous tout de même que tous ces problèmes datent d'une époque ou Intel essayait de pousser à fond IA64 plutôt qu'x86, depuis ils ont redressé la barre, produit plusieurs CPU de folie et fait largement mordre la poussière à AMD.

          Pour le rachat de McAffee, cf. http://www.semiaccurate.com/2010/08/20/why-intel-bought-mcaf(...)
          • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

            Posté par  . Évalué à 5.

            produit plusieurs CPU de folie et fait largement mordre la poussière à AMD.
            ca sent bien le fanboy.

            Intel a presque toujours eu des procs "plus performant" qu'amd, et même quand ce n'était pas le cas, les fanboy trouvait que si, ou que l'on pouvait les o/c plus facilement ou autres.
            Bref.

            Ce qui compte ce n'est pas tant la puissance brute, mais bien le rapport qualité prix, et du cpu, et de l'ensemble CM/RAM/CPU.

            Bref, ce qui compte c'est si tu veux acheter un pc pas cher, ou une bête de course sans restriction sur le budget.


            Et sur le rapport qualité prix, ne t'en déplaise, intel a presque jamais fait mordre la poussière à AMD. Le seul moment où ils l'ont fait c'est avec leur avance sur le quadcore et les bugs du phenom.

            Depuis le rapport qualité prix est souvent en faveur d'amd sur l'entré de gamme (niveau perfs), ou alors est suffisament faible pour que l'une ou l'autre des plateformes soit choisies sur le "mid".

            Certes les derniers phenom ne valent pas un i7 de_la_mort_ki_tue, mais leur prix non plus, ni le prix des CM compatibles.
            • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

              Posté par  . Évalué à -6.

              La seule fois où AMD a dépassé Intel en terme de ventes, c'était à l'époque des Athlon XP, sachant que ces derniers ne tenaient pas la route et fondaient assez facilement (ben oui, plus performants à fréquence moindre, fallait bien que ça se ressente ailleurs). Et les Durons c'était pareil. C'est pas pour rien que cette avance n'a pas duré, vu la qualité des produits...

              À côté de ça, Intel proposait un P4 certes moins performant mais tenant mieux la charge et plus évolutif. J'ai déjà vu des cartes mères cramées où le P4 était comme neuf (et c'était déjà comme ça pour les P3, d'ailleurs).

              Alors j'ai des doutes sur le rapport qualité-prix. Si le produit est moins cher mais crâme facilement, je ne sais pas s'il est réellement meilleur chez AMD...

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                Posté par  . Évalué à 5.

                Le P4 était une architecture tellement évolutive qu'elle n'a jamais tenues ces engagements (10GHz) et qu'Intel est reparti de l'architecture P3 pour les pentium M puis les Core Duo.

                A oui les P4 se prenaient des mandales dans les jeux vidéo à fréquence inférieur par les Athlon 64 (en encodage c'est les P4 qui avaient l'avantage car ils avaient des fréquences plus hautes).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                  Posté par  . Évalué à 4.

                  En fait, la raison pour laquelle les Athlon XP explosaient le P4 à l'époque est la même qui explique pourquoi un P4 se débrouillait mieux pour ce qui était du « multimédia » : il s'agit de la longueur du pipeline d'instructions. Il y avait entre 22 et 31 étages pour le pipeline dans le P4, ce qui signifie que pour du calcul très régulier comme celui de l'encodage (pas de « if/else », des boucles très longues, etc.), alors le P4 pouvait mouliner à fond (car l'allongement du pipeline permettait entre autre d'avoir des fréquences élevées).

                  Ce mếme pipeline, en présence de code extrêmement irrégulier au niveau du contrôle (boucles courtes, if/else, tout ça imbriqué, etc), devait être vidé en cas de mauvaise prédiction de branchement. Si par exemple il n'y a pas de régularité dans la prise d'une branche (disons 50% de chance d'être prise, etc), alors du coup le pipeline doit être régulièrement vidé, ce qui peut donc représenter jusqu'à 31 cycles de perdus. Dans une boucle while qui imbriquerait plusieurs if, par exemple, c'est plutôt gênant... Et du coup, un athlon qui ne propose que (au pif, j'en sais rien pour l'athlon) 12 ou 14 étages, forcément, la perte de temps est divisée par deux.
                  • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                    Posté par  . Évalué à 2.

                    Je sais bien tout ça. Le P3 et toutes les architectures actuelles ont un pipeline court comparé au P4.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

              Posté par  . Évalué à 2.

              [...] Ce qui compte ce n'est pas tant la puissance brute, mais bien le rapport qualité prix, et du cpu, et de l'ensemble CM/RAM/CPU.

              Disons que je suis un peu biaisé par mes centres d'intérêt et mes lectures : le rapport qualité/prix c'est bien, mais il y a aussi dans un certain nombre de domaines des performances minimales attendues, et passée une certaine barre AMD existe difficilement. Mais c'est rarement le cas pour les besoins du grand public, je te l'accorde.

              Plus globalement : j'ai rien contre AMD, je préférerais qu'ils aillent un peu mieux qu'actuellement, et j'espère que Bobcat / Bulldozer vont bien marcher.
              • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                Posté par  . Évalué à 2.

                et passée une certaine barre AMD existe difficilement. Mais c'est rarement le cas pour les besoins du grand public, je te l'accorde.


                Ca doit être certainement pour ça que quand je vais sur un site bien connu, et que je demande amd x86_64 je tombe sur ça :

                Rank Site System Cores Rmax Rpeak
                1 Oak Ridge National Laboratory
                United States Cray XT5-HE Opteron Six Core 2.6 GHz
                Cray Inc. 224162 1759 2331
                4 National Institute for Computational Sciences/University of Tennessee
                United States Cray XT5-HE Opteron Six Core 2.6 GHz
                Cray Inc. 98928 831.7 1028.85
                11 Texas Advanced Computing Center/Univ. of Texas
                United States SunBlade x6420, Opteron QC 2.3 Ghz, Infiniband
                Sun Microsystems 62976 433.2 579.38
                16 University of Edinburgh
                United Kingdom Cray XT6m 12-Core 2.1 GHz
                Cray Inc. 43660 274.7 366.74
                </quote.

                J'ai 49 lignes comme ça.
                Dis moi, "opteron" c'est bien amd qui le fait non ?


                Alors certes, c'est pas les 80% d'intel, mais vu leur place, je pense pas que l'on puisse dire que "dans des domaines où la performance est requise, amd on les utilisent pas"
                http://www.top500.org/stats/list/35/procfam
                • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                  Posté par  . Évalué à 3.

                  T'as une idée de la latence entre l'état du marché et le top500 ?

                  Je ne suis pas en train de te dire qu'AMD est inutile, mais sur certains marchés vraiment importants en terme de revenues (i.e. les serveurs, pas les super-ordinateurs) ils se font tailler des croupières par Intel. Exemple : http://arstechnica.com/business/news/2010/08/bad-news-for-am(...)
                  • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                    Posté par  . Évalué à 4.

                    mais sur certains marchés vraiment importants en terme de revenues (i.e. les serveurs, pas les super-ordinateurs)
                    Ben désolé, mais quand je lis mais il y a aussi dans un certain nombre de domaines des performances minimales attendues, et passée une certaine barre AMD existe difficilement.
                    je pense plutôt aux HPC et grids qu'au marché du serveur.

                    Enfin, en ce qui concerne le marché du serveur ou même du desktop, on peut aussi se rappeller que intel c'est un poil pris des plaintes pour comportement anti concurentiel et abus de position (comme un autre grand nom du logiciel), et que d'ailleurs ils ont filés 1 milliards à amd pour qu'ils se couchent (mais de tête les plaintes continuent d'exister).

                    Pour avoir vu plusieurs fois comment sont choisis les serveurs dans les entreprises, c'est rarement les perfs du cpu qui font tout, ou le fait que le tout dernier xeon de la mort qui tue il est achement mieux que l'opteron 6 coeurs.


                    Attention je dis pas qu'amd n'a pas loupé des trucs ou que intel "c'est pas bien". Je dis just qu'une demande d'appro en entreprise, on prend ce qui est dispo avec les marchés de l'entreprise.
                    On s'amuse pas à choisir pour chaque demande si on prend de l'amd, de l'intel, chez quel fabricant.

                    une info aussi "vaste" que le reporte arstechnica, c'est plus du politique que du technique amha.
            • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

              Posté par  . Évalué à 3.

              "Certes les derniers phenom ne valent pas un i7 de_la_mort_ki_tue, mais leur prix non plus, ni le prix des CM compatibles. "

              Sur ce niveau là, Intel a frappé un grand coup avec les i7 8xx : le proc est legerement moins cher, mais surtout il ne nécessite pas une carte mère trop chere (socket 1156), par contre on perd le triple-channel.
              • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

                Posté par  . Évalué à 2.

                enfin, tu compares les prix des cm intel et des cm amd, et, après 10 ans de comparaison, ca m'étonnerais que les cm intels soit au même prix que celle de l'amd, sans vérifier :P

                Tu en trouveras toujours une ou deux qui proposera les mêmes choses au même prix, voir moins cher, mais globalement tu t'en tireras toujours un poil plus cher en intel qu'en amd.

                Exemple bete, tout les prix sont ceux de materiel.net

                premier prix d'une cm amd am3 : 55€
                premier prix d'une cm intel 1156 : 78€.

                Pour les quad cores :

                premier prix d'n athlon X4 : 104€
                premier prix d'un phenom : 125€
                premier prix d'un i5 : 190€
                premier prix d'un i7 : 290€


                Au niveu des hexa core, intel n'existe pas.
                premier prix d'un phenom x6 : 199€.
                à peine plus cher qu'un i5 entrée de gamme.

                Le plus cher :
                (amd) phenom le plus cher : 289€ (Phenom™ II X6 1090T Black Edition)
                (intel) i7 le plus cher : 540€ (Core™ i7 880 - OEM)
                (intel) i5 le plus cher : 290€ (Core™ i5 680)
    • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

      Posté par  (site web personnel) . Évalué à 2.

      Et comme personne a part Microsoft et Apple n'arrivent a faire de l'argent sur le desktop

      Tu sembles oublier que google a la volonté de mettre son OS sur les netbooks.
      • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

        Posté par  . Évalué à 3.

        Le jour ou ils feront de l'argent tu pourras les inclure, au jour d'aujourd'hui ils font toujours partie du groupe qui ne fait pas d'argent sur le desktop
        • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

          Posté par  . Évalué à 3.

          C'est une attaque à l'épouvantail, leur but n'est pas de faire de l'argent sur le desktop mais de l'argent sur le réseau. Le desktop n'est qu'une commodité, et même un anachronisme dans le monde des petits écrans mobiles.

          Faire de l'argent sur le réseau, par contre, c'est le truc que microsoft n'arrive pas à faire. Ils rachètent yahoo bientôt, ou bien?
          • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

            Posté par  . Évalué à -1.

            C'est une attaque à l'épouvantail, leur but n'est pas de faire de l'argent sur le desktop mais de l'argent sur le réseau. Le desktop n'est qu'une commodité, et même un anachronisme dans le monde des petits écrans mobiles.

            Hum, donc Google développe ChromeOS par pure philantropie ? Mon œil.

            Leur but c'est d'instaurer un point d'entrée supplémentaire vers leur moteur de recherche, applications, etc. dans le but de, je te cite, « faire de l'argent sur le réseau ». Que l'argent rapporté par ChromeOS le soit directement sous formes de licences ou bien sous cette forme diffuse ne change rien à l'affaire et n'invalide pas le commentaire de pBpG. Le succès n'est pas assuré et il va falloir attendre un peu avant d'affirmer que Google fait, d'une façon ou d'une autre, de l'argent sur, ou plutôt avec le Desktop (même indirectement).
          • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

            Posté par  . Évalué à 1.

            > Le desktop n'est qu'une commodité, et même un anachronisme dans le monde des petits écrans mobiles

            N'importe quoi..
            Differents besoins --> differents outils pour les satisfaire..
            On n'utilise pas un téléphone (même un smartphone) comme on utilise un ordinateur de bureau et vice-versa.
            Certains besoins sont communs, ok, et l'un peut remplacer l'autre mais ce n'est pas une majorité loin de la.

  • # gallium3D ou un rendu facon 3dfx?

    Posté par  . Évalué à 2.

    l'architecture gallium 3D ne pernetrait pas deja ou bientot d'utiliser deux GPU?
    le module TGSI permet d'avoir une abstraction des unites de shader.
    ceci couplé a un acces direct d'un GPU a la memoire d'une autre carte video devrait permettre d'utiliser les unites de shaders plus performants que ceux de la carte video integrée.
    si un acces direct n'est pas possible certaines cartes d'acelleration 3dfx, au moins la vodoo rush je crois, utilisaient sous XFree86 un module de copie de tampon video, apres un rendu opengl sur la carte acelerée, technique certes moins performante mais envisageable...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.