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...
Journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux...
22
août
2010
# c'est bien non ?
Posté par BAud (site web personnel) . Évalué à 2.
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 Pinaraf . Évalué à 10.
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 BAud (site web personnel) . Évalué à 0.
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 BAud (site web personnel) . Évalué à 3.
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 Pinaraf . Évalué à 6.
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 BAud (site web personnel) . Évalué à 4.
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 imr . Évalué à 4.
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 Pinaraf . Évalué à 4.
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 Axel . Évalué à 4.
# Ce n'est pas X.Org le problème?
Posté par sanao . Évalué à 9.
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 BAud (site web personnel) . Évalué à 1.
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 imr . Évalué à 7.
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 Pinaraf . Évalué à 3.
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 imr . Évalué à 4.
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 Pinaraf . Évalué à 2.
[^] # Re: Ce n'est pas X.Org le problème?
Posté par imr . Évalué à 2.
[^] # Re: Ce n'est pas X.Org le problème?
Posté par jeffcom . Évalué à 4.
ç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 Olivier Esver (site web personnel) . Évalué à 10.
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 jeffcom . Évalué à 2.
[^] # Re: Ce n'est pas X.Org le problème?
Posté par imr . Évalué à 7.
[^] # Re: Ce n'est pas X.Org le problème?
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ce n'est pas X.Org le problème?
Posté par jeffcom . Évalué à 3.
[^] # Re: Ce n'est pas X.Org le problème?
Posté par IsNotGood . Évalué à -4.
Sont fort NVidia pour des branleurs.
# Décodage vidéo
Posté par patrick_g (site web personnel) . Évalué à 10.
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 _PhiX_ . Évalué à 8.
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. »
[^] # Re: Comment qu'y parle, lui !
Posté par plic . Évalué à 0.
Avec le verbe "implémenter", qui n'existe pas en français ?
:-)
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: Comment qu'y parle, lui !
Posté par 2PetitsVerres . Évalué à 10.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# ...
Posté par M . Évalué à 10.
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 Zarmakuizz (site web personnel) . Évalué à 5.
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 M . Évalué à 4.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
C'est le Flattened Device Tree, et ça avance pas mal. Il y a aussi beaucoup d'infos intéressantes sur la page [http://wiki.freebsd.org/FlattenedDeviceTree].
[^] # Re: ...
Posté par Pinaraf . Évalué à 3.
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 Guillaume Knispel . Évalué à 5.
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 joedu12 . Évalué à 3.
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 ?
[^] # Re: et ATI c'est pire ?
Posté par Olivier Esver (site web personnel) . Évalué à 5.
cf http://linuxfr.org/2010/05/17/26852.html#switcheroo
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: et ATI c'est pire ?
Posté par joedu12 . Évalué à 2.
[^] # Re: et ATI c'est pire ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# ARM.... Android .... Copains.
Posté par Ph Husson (site web personnel) . Évalué à 10.
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 Pinaraf . Évalué à 6.
"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 Ph Husson (site web personnel) . Évalué à 2.
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 cortex62 . Évalué à 2.
http://linuxfr.org/~Zezinho/29476.html
peut être pas avec les pilotes nvidia, mais nouveau.....
[^] # Re: faudrait chercher ce ce coté....
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: faudrait chercher ce ce coté....
Posté par cortex62 . Évalué à 1.
# Remplir les besoins des utilisateurs != Hostile a Linux
Posté par reno . Évalué à 7.
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 Pinaraf . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à 5.
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 Pinaraf . Évalué à 5.
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 BAud (site web personnel) . Évalué à 3.
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 pasScott pasForstall . Évalué à 5.
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 Pinaraf . Évalué à 4.
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 auve . Évalué à 1.
Question : les GPU des MBP récents fonctionnent-ils avec Linux ?
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par Maclag . Évalué à 6.
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 auve . Évalué à 4.
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 Maclag . Évalué à 2.
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 Frank-N-Furter . Évalué à 2.
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 Maxime Buffa . Évalué à 2.
J'ai pas testé grand chose mais si tu veux plus d'infos...
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par pasScott pasForstall . Évalué à 1.
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 Frank-N-Furter . Évalué à 3.
Depending on the time of day, the French go either way.
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par imr . Évalué à 3.
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 Zenitram (site web personnel) . Évalué à 4.
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 imr . Évalué à 3.
"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 Zenitram (site web personnel) . Évalué à 0.
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 Mildred (site web personnel) . Évalué à 1.
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 allcolor (site web personnel) . Évalué à 3.
http://en.wikipedia.org/wiki/X_terminal
Enfin je doute que tu puisse avoir 1000 clients simultanés ceci-dit...
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par reno . Évalué à 2.
- 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 M . Évalué à 3.
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 reno . Évalué à 2.
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 Pinaraf . Évalué à 8.
"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 auve . Évalué à 3.
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 briaeros007 . Évalué à 5.
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 zebra3 . Évalué à -6.
À 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 barmic . Évalué à 5.
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 lasher . Évalué à 4.
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 barmic . Évalué à 2.
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 auve . Évalué à 2.
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 briaeros007 . Évalué à 2.
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 auve . Évalué à 3.
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 briaeros007 . Évalué à 4.
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 campagnard . Évalué à 3.
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 briaeros007 . Évalué à 2.
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 Pinaraf . Évalué à 2.
Sinon l'i7 le plus cher est à 1000€ : http://www.materiel.net/ctl/Socket_1366/55896-Core_i7_980X_E(...)
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par briaeros007 . Évalué à 1.
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par campagnard . Évalué à 1.
PS : ton comparatif est faut, les i7 9xx n'y apparaissent meme pas (intel i7 le plus cher : i7 880).
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par briaeros007 . Évalué à 2.
Pour faire les choses bien il aurait fallu classé les cm par fonctionnalité et faire des stats dessus (donc min,max, moyenne, 90 percentile etc...)
et faire des stats sur l'ensemble des gammes, pas juste min/max sur un seul site ;)
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par tiot (site web personnel) . Évalué à 2.
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 pasBill pasGates . Évalué à 3.
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par imr . Évalué à 3.
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 auve . Évalué à -1.
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 reno . Évalué à 1.
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 cedric . Évalué à 2.
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.