Malgré l'opposition de certains envers ces pilotes propriétaires, cela permettra à ceux qui veulent jouer à Doom3 sur leur OS favori de profiter de performances proches de celles sous Microsoft Windows. ATI
ATI a annoncé la sortie de la version 3.11.1 de ses pilotes x86 pour Linux. Au menu, surtout des correctifs :
- Les modules fglrx sont maintenant corrects pour les noyaux 2.6.6 et suivants.
- Les RPMS des modules fglrx rentrent en conflits avec les anciens packages pour fglrx-glc22 (ce qui n'était pas le cas avant !!)
- La palette de couleur est correctement restaurée lors des switchs VT.
- L'utilisation du Quad-Buffer stéréo avec les FireGL X1/Z1 ne provoque plus de corruption de bureau.
- Ajout des supports pour les Radeon X800 AGP et FireGL X3-256.
NVIDIA
Nvidia propose la version 1.0-6111 de ses pilotes pour GNU/Linux IA 32 et AMD 64. Beaucoup de correctifs bien que la version précédente date d'à peine 1 mois :
- Support des processeurs Intel EMT-64, AMD Opteron, AMD Athlon64 et AMD AthlonFX 64 .
- Correction de la validation de la certification de SoftImage.
- La validation pour quitter devient optionnel.
- Correction du problème sur les multiples instances de serveurs X avec les TNT/TNT2.
- Correction du problème de la sortie TV qui empêchait d'autres résolutions que 640X480 et 800X600.
- Correction du problème de placement/corruption du curseur avec certaines configurations Twin.
- Correction du problème d'options ignorées avec certains module AGP.
- Correction du problème GLSL avec shadow2DProj.
- Correction des problèmes de console avec les GeForce4 Ti.
# Complèments
Posté par un_brice (site web personnel) . Évalué à 6.
A part ça, la news dit que Il s'agit de la confirmation pour quitter nvidia-settings, l'utilitaire de configuration graphique de nvidia.
[^] # Re: Complèments
Posté par Gawan . Évalué à 2.
D'autres ont eu le même problème ?
[^] # Re: Complèments
Posté par SF . Évalué à 1.
Juste à configurer à la mano le support du Fast Writes et de SBA.
[^] # Fast write ?
Posté par Beurt . Évalué à 2.
Parce que ma GeForce en est capable, mon BIOS en est capable (et c'est activé) mais le driver (comme indiqué dans la doc) le désactive tout seul.
Je voudrais essayer de lui forcer la main pour voir... Mais je n'ai pas trouvé.
[^] # Re: Fast write ?
Posté par Damien . Évalué à 4.
Option "AGPFastWrite" "1"
Je pense que c'est ça que tu cherches
[^] # Re: Fast write ?
Posté par Beurt . Évalué à 2.
J'avais parcouru trop rapidement la doc (en abusant du Ctrl-F/F3 sur l'expression "Fast Write" et non "AGPFastWrite"...) La prochaine fois je RTFMerais plus proprement.
[^] # Re: Fast write ?
Posté par Beurt . Évalué à 2.
Non, en fait, ce n'était pas si simple. Malgré l'option AGPFastWrite à "1" ou à "true", le pilote le désactive...
[^] # Re: Fast write ?
Posté par Stephen Amar . Évalué à 0.
[^] # Re: Fast write ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 3.
option nvidia NVreg_EnableAGPFW=1 NVreg_EnableAGPSB=1 NVreg_EnableVia4x=1
(Respectivement fast write, side banding, et agp4x pour via, comme les noms l'indiquent :)
[^] # Re: Fast write ?
Posté par Raphaël G. (site web personnel) . Évalué à 0.
Donc faire très gaffe quand on joue avec ce genre de choses!!!
ne pas oublier un petit Alt+Impr Scr+s pour syncroniser les dur en cas de plantage!!!
[^] # Re: Fast write ?
Posté par gnujsa . Évalué à 6.
J'ai une carte ATI Radeon 7000 VE. J'utilise le pilote libre (xlibmesa-dri 4.3.0.dfsg.1-4 Debian sarge) et en rajoutant ces quelques options dans /etc/X11/XF86Config-4 la différence de perfs en 3D est ENORME !
+20% dans glxgears, mais c'est surtout avec les jeux, qui passent de saccadés à super fluide. Il faut vérifier ensuite dans /var/log/XFree86.0.log que ces options sont bien «passées»
(**) RADEON(0): Using AGP 4x mode
(**) RADEON(0): Enabling AGP Fast Write
etc ...
[^] # Re: Fast write ?
Posté par GhZaaark3 . Évalué à 1.
[^] # Re: Fast write ?
Posté par tgl . Évalué à 2.
[^] # Re: Fast write ?
Posté par William Steve Applegate (site web personnel) . Évalué à 1.
[+] je confirme. En revanche, si je connaissais bien les trois premières, je ne trouve rien sur l'option BackingStore en faisant un man radeon. Ça sert à quoi, ce truc ?
Envoyé depuis mon PDP 11/70
[^] # Re: Fast write ?
Posté par gnujsa . Évalué à 2.
# Prevents some artifact
Mais comme c'est pas dans la page man, c'est peut être une erreur (ou une fonction cachée ?)
En tout cas X ne s'en plaint pas dans XFree86.0.log
[^] # Re: Complèments
Posté par Philippe MAES (site web personnel) . Évalué à 1.
# Utilité des pilotes proprios
Posté par tzeentch00 . Évalué à 10.
Certaines personnes (moi en l'occurence) sont obligées d'avoir recours à ces pilotes proprio pour le boulot (visualisation en chimie théorique). Pour le moment, les pilotes libres ne font largement pas l'affaire, donc pas moyen de se passer des pilotes proprio.
Contrairement à ce qu'on entend toujours, il n'y a pas que pour les jeux qu'on a besoin des dernières cartes graphiques hi-tech (et des drivers qui vont avec :)
(Voilà pour mon mini coup de gueule)
[^] # Re: Utilité des pilotes proprios
Posté par tuiu pol . Évalué à 3.
[^] # Re: Utilité des pilotes proprios
Posté par tgl . Évalué à 7.
[^] # Re: Utilité des pilotes proprios
Posté par SF . Évalué à 2.
Quand à la différence de prix entre les cartes pour les pro de la CAO et les cartes pour les GAMERS était principalement liée au support OPENGL. Cablé dans un cas et émulé par du soft dans l'autre cas.
[^] # Re: Utilité des pilotes proprios
Posté par Prosper . Évalué à 2.
[^] # Re: Utilité des pilotes proprios
Posté par SF . Évalué à 1.
-> "avant l'avènement des jeux 3D accélérés"
[^] # Re: Utilité des pilotes proprios
Posté par SF . Évalué à 6.
Pour info Linux et un OS tout à fait intéressant pour faire tourner
des soft comme MAYA ou encore PRO-ENGINEER.
http://www.alias.com/eng/support/maya/qualified_hardware/QUAL/maya_(...)
http://www.ptc.com/partners/hardware/current/proe.htm(...)
En effet il n'y a pas que les jeux qui ont besoin d'un bon support OPENGL !!!
[^] # Re: Utilité des pilotes proprios
Posté par GhZaaark3 . Évalué à 1.
Exactement... et puis ça me ferait mal de devoir utiliser Blender sous Windows!
[^] # Re: Utilité des pilotes proprios
Posté par GhZaaark3 . Évalué à 1.
j'ajouterai que c'est avant tout grâce à ce marcher qu'on dispose de pilotes complets.
# doom3?
Posté par Sébastien Cismondo . Évalué à 1.
Je vais peut-être avoir l'air idiot mais, par pure curiosité... je n'ai pas entendu parler d'une version de doom 3 pour linux? Ce serait trop beau. Ou alors est-il question d'un utilisation via Wine?
Ceci dit, pour ce qui est des pilotes eux-mêmes, on peut en dire ce qu'on veut, ils ont au moins le mérite d'exister!
Seb.
[^] # Re: doom3?
Posté par Alexandre . Évalué à 2.
[^] # Re: doom3?
Posté par Gonéri Le Bouder (Mastodon) . Évalué à 3.
[^] # Re: doom3?
Posté par Sébastien Cismondo . Évalué à 1.
Seb.
[^] # Re: doom3?
Posté par Serge Rossi (site web personnel) . Évalué à 10.
C'est le fait que tous les jeux Id Software et leurs dérivé utilisent OpenGL et non l'abominable DirectX qui a fait que les jeux soient facilement portables sur Linux et MacOS X.
Sans eux, on n'aurait pas eu Quake 3, Return to Castle Wolfenstein, Ennemy Territory et surtout Doom 3.
Pour la petite histoire, avant l'arrivée de XFree 4 et de DRI, un projet Open Source réalisé un driver OpenGL avec accélération matérielle pour XFree 3. C'était le projet Utah-GLX.
Les cartes supportées étaient essentiellement les Matrox G200 et G400 ainsi que les ATI Mach 64.
Le projet a longtemps végété jusqu'au moment ou John Carmack est arrivé et a mis toute son énergie à en faire un driver stable et performant. C'était d'ailleurs très impressionnant de suivre la mailing list du projet.
C'est depuis ce temps là que je suis beaucoup plus réservé sur les drivers OpenGL open source car je sais que c'est loin d'être à la portée du premier programmeur venu. Il faut être à la fois très compétent en développement, en architecture noyau et en 3D/OpenGL et très rares sont les gens à avoir les 3 compétences à la fois au niveau nécessaire pour faire vraiment avancer le sujet.
A ma grande surprise, le projet existe toujours et fonctionne pour XFree 4.
Ils ont même une implémentation Open Source de drivers pour les NVidia TNT et GeForce !!!
http://utah-glx.sourceforge.net/(...)
Il reste encore des traces de la participation de John Carmarck dans les docs d'enfer qu'il avait écrit pour le projet à l'époque :
http://utah-glx.sourceforge.net/docs/overview.txt(...)
http://utah-glx.sourceforge.net/memory-usage.html(...)
http://utah-glx.sourceforge.net/docs/X_dma_hack.txt(...)
[^] # Re: doom3?
Posté par Sébastien Cismondo . Évalué à 1.
Seb.
[^] # Re: doom3?
Posté par isydor . Évalué à 2.
[^] # Re: doom3?
Posté par spongurex . Évalué à 1.
Question :
Pourquoi ne pas en faire des pilotes framebuffer / directfb / Y / etc... ?
# une occasion manquée?
Posté par Jean CHEMINADE . Évalué à 2.
Car personnellement j'utilise les drivers proprio d'ATI car je ne connais pas le moyen de faire du DUAL HEAD avec ma seul carte radeon 9500 et ses drivers opensources.
# y'a t-il du mieux chez ATI ?
Posté par sekoia . Évalué à 1.
Et ce qui me chagrine le plus je pense c'est que ATI ne sort que des RPM, et une fois "aliénisés" en .deb ou autres ca marche de traviole.
Cette nouvelle release de drivers est-elle réellement prometteuse ? ca reste à voir ....
[^] # Re: y'a t-il du mieux chez ATI ?
Posté par TuxMips . Évalué à 1.
Je ne suis pas le seul.
A chaque nouvelle vesrion des pilotes ATI. Sans jamais avoir la 3D.
Que ce soit avec la Mandrake 9.2 ou la 10..
Ma carte est une Sapphire 9200 Atlantis - 128 mo.
Il semblerait qu'avant l'installation du pilote, il soit necessaire d'installer le source du noyau qui va bien..
Alors je vais à nouveau tenter ma chance.
[^] # Re: y'a t-il du mieux chez ATI ?
Posté par tuiu pol . Évalué à 2.
[^] # Re: y'a t-il du mieux chez ATI ?
Posté par Raphaël G. (site web personnel) . Évalué à 3.
conseil :
Installe les source qui correspondent a la dernière version de kernel et le dernier kernel aussi (tant qu'a faire ça corrigera quelque bugs...)
urpmi kernel (choisi le plus récent)
urpmi kernel-source (choisi le plus récent identique à au dessus)
reboot sur le dernier kernel
loggue toi en root et fait ceci :
cd /usr/src/linux
make mrproper
cp -f /boot/config ./.config
édite le fichier Makefile avec : kwrite Makefile
et change le champ où il y a = -xmdk custom en = -xmdk
si tu utilise le noyau normal
make oldconfig
make prepare-all
et installe ton rpm normalement, tu sera peut-être obligé d'aler dans /lib/je sais plsuquoi pour aller compiler le module, mais normalement cette maip suffit...
[^] # Re: y'a t-il du mieux chez ATI ?
Posté par Raphaël G. (site web personnel) . Évalué à -2.
[^] # Re: y'a t-il du mieux chez ATI ?
Posté par BAud (site web personnel) . Évalué à 2.
perso :
telinit 3 # tue X proprement
urpmi kernel # si nécessaire
urpmi kernel-source # obligatoire si étape précédente faite (sinon ne pas le faire) => vérifier qu'il y a concordance des versions : uname -a ; rpm -q kernel-source
# ici la compil' du driver récupéré chez nVidia (chez moi) / ATI pour les autres
telinit 5 # revient à X (et pour les démarrages suivants)
si changement de kernel : boom reboot (pas trop souvent : c'est pour prendre en compte le nouveau kernel
bon une fois sur deux au changement de kernel j'oublie de recompiler le driver nvidia donc ça donne plutôt :
urpmi kernel
urpmi kernel-source # quand je ne l'oublie pas non plus
boom reboot (pour aller sur le nouveau kernel)
arg démarrage avec le driver nv au lieu de nvidia (avant c'était arg je suis en console...) enfin bon au fil du temps ça devient gérable et un peu moins destabilisant ;-)
[^] # Re: y'a t-il du mieux chez ATI ?
Posté par Colin Leroy (site web personnel) . Évalué à -2.
ça marche avec les drivers libres ça...
[^] # ATI for Debian
Posté par Schwarzy . Évalué à 2.
pas a jour avec les derniers drivers venant d'ATI mais bien utile pour comprendre comment installer les drivers binaires avec une debian.
# Monitorer une carte nVidia...
Posté par Beurt . Évalué à 6.
Cependant j'aimerai bien suivre l'augmentation de température du core et de la mémoire de ma carte graphique. La sonde existe, je l'ai vu.
Je n'ai pas trouvé comment utiliser lm_sensors avec des cartes nVidia (je ne suis d'ailleurs pas sûr que ce soit possible). J'espérais en installant ces nouveaux drivers trouver avec nvidia-settings un outil de monitoring: que-nenni.
Quelqu'un connaît-il un outil qui me permette de surveiller la température de ma GeForce (que je vérifie si mon bricolage a du succès)...
[^] # Re: Monitorer une carte nVidia...
Posté par Geo Vah . Évalué à -1.
[^] # Re: Monitorer une carte nVidia...
Posté par Beurt . Évalué à 2.
Donc ma carte graphique (en plus d'avoir un ventilateur pourri à un format propriétaire) a aussi une sonde propriétaire... (pour info c'est une Leadtek)
Dommage...
Cela dit, lm-sensors prétend supporter les nVidia grâce au kernel-module rivatv, mais je cherchais quelque chose de plus simple que de compiler un module (qui du reste, n'est pas réellement destiné à fonctionner avec ma carte graphique)
[^] # Re: Monitorer une carte nVidia...
Posté par Raphaël G. (site web personnel) . Évalué à 1.
Je ne sais pas en revanche si il tourne sur ta carte.
En tout cas il l'est sur la mienne : ASUS GeForce 5700FX 256DDR
J'ai changé la pâte thermique à la silicône infâme (y avais même pas une goute de silicône, ASUS me déçois...) en pâte a l'argent je suis passé dans nvidia-settings de 56°C à 44°C!!!
Avec le même dissipateur et le même ventillo!!!
[^] # Re: Monitorer une carte nVidia...
Posté par Beurt . Évalué à 2.
Je ne pensais pas qu'elle avait une telle importance.
J'ai préféré fixer un nouveau ventilateur sur l'ancien radiateur de ma carte avec trois bouts de ficelle (non... ce n'est pas une façon de parler ! :o) J'avais bien dit que c'était un bricolage immonde !). Et puis j'ai rajouté des petits radiateurs sur les chips de mémoire (des deux cotés du PCB :o)).
Et cela semble suffire... Si j'ai à nouveau des plantages j'irai jeter un il du coté de la pâte thermique.
[^] # Re: Monitorer une carte nVidia...
Posté par benoar . Évalué à 1.
"Content" de savoir que je ne suis pas le seul à avoir ce problème avec cette carte dont le ventilo est d'une solidité et d'une fiabilité .... désastreuse. Pareil que toi, montage d'un autre ventilo avec 2 bouts de ficelles ...
[^] # Re: Monitorer une carte nVidia...
Posté par Mark Havel . Évalué à 1.
[^] # Re: Monitorer une carte nVidia...
Posté par Benoît Déchamps (site web personnel) . Évalué à 1.
Sinon pour remplacer ton bricolage, je te conseille le Zalman ZM-80. Cela m'a permis de remplacer le ventilrad d'origne hyper-bruyant par du refroidissment passif avec quelques degrés de gagnés au passage.
# Ça commence par les pilotes de cartes graphiques...
Posté par Arthur Accroc . Évalué à -1.
Non, parce que non contents d'être des pilotes propriétaires pour X11, ceux-ci se croient obligés de s'imposer dans le noyau, alors que bien d'autres pilotes X11 s'en passent très bien...
Évidemment, il y a de bonnes raisons de les accepter (bénéficier sous Linux des performances 3D des dernières cartes sorties), mais il n'y aura pas de retour en arrière (pourquoi fournir les spécs pour des pilotes libres quand 99 % des utilisateurs de Linux se contentent de pilotes propriétaires), et puis bientôt, il y aura de bonnes raisons d'accepter un autre truc non libre, puis un autre... et quand on se réveillera, on s'apercevra qu'on est en train d'utiliser l'équivalent exact de Windows !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par lebowski . Évalué à 1.
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par zerbro . Évalué à 3.
En effet, si ces derniers sont fournit pour linux, avec les memes performances que sous windows, ou est le probleme ?
Les constructeurs investissent enormement pour creer des processeurs graphiques performants, et ils devraient rendre publique les speficites comme ca ? Juste parce que "c'est mieux si c libre ?". Je ne pense pas.
Il ne faut pas etre integriste, et le proprietaire peut parfaitement cohabite avec le libre !
Autant sur les logiciels, en particulier le systeme d'exploitation, le proprio peut entrainer les pb de dependances etc... comme on peut le voir avec microsoft. Mais la il sagit d'un carte graphique ! il n'y pas de compatibilite comme sur un pc "vide", on est dependant des le materiel. Donc le probleme n'est plus du tout le meme, et le proprio ne me derange pas quand il sagit de drivers, et que ceux-ci sont fournit avec la carte bien evidement.
Voila, j'en ai assez de cet integrisme "il faut que ce soit libre a tout prix, sinon c'est nul". En plus j'ai l'impression en lisant ton message que tu me prends de haut (cf : Ça y est, tout le monde se réjouit de la sortie de nouveaux pilotes propriétaires ? Tout le monde est content ? Tout le monde est bien dressé à accepter du code propriétaire dans son noyau ?), et desole, mais ton point de vu n'est pas forcement le bon.
Oui je me rejouit, de la sortie de pilotes proprio, vu que ma carte vient d'un fabriquant particulier, et ne doit pas repondre a une norme particuliere. Oui je suis tres content. Et non je n'ai pas ete dresse, etant donne que le probleme est tout a fait different que pour le systeme d'exploitation.
Ce n'est pas parce qu'on accepte qqchs de non libre qu'on tombe dans le systeme "a la windows". Au risque de me repeter : il faut savoir remettre les choses dans leurs contextes !
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par M . Évalué à 7.
En effet, si ces derniers sont fournit pour linux, avec les memes performances que sous windows, ou est le probleme ?
Autant sur les logiciels, en particulier le systeme d'exploitation, le proprio peut entrainer les pb de dependances etc... comme on peut le voir avec microsoft. Mais la il sagit d'un carte graphique ! il n'y pas de compatibilite comme sur un pc "vide", on est dependant des le materiel. Donc le probleme n'est plus du tout le meme, et le proprio ne me derange pas quand il sagit de drivers, et que ceux-ci sont fournit avec la carte bien evidement.
C'est sur c'est mieux d'avoir des pilotes foireux et mal teste (y a qu'a voir le changelog) dans le noyau qui font te pourrir le systeme de basse, que d'avoir une pauvre appli proprio qui ne touchera a rien au systeme de base. Pour moi le pb de dependance ce trouve dans l'autre sens etant donné que GNU/linux, X, ... depande de ta carte...
Et puis c'est bien avec des drivers proprio si on veut se faire une divx box, ou quelque chose du meme genre qui utilise directfb (oui X n'est pas si leger que ca), ou meme faire des drivers a vidix ben tu peux toujours courrir pour avoir un truc 100% fonctionnel...
Idem si tu veut utiliser un autre OS non supporte (hurd,...)
Ce n'est pas parce qu'on accepte qqchs de non libre qu'on tombe dans le systeme "a la windows". Au risque de me repeter : il faut savoir remettre les choses dans leurs contextes !
oui, mais tu perd tout l'aspet libre, personellement je trouve deja que certains drivers sans spec (par exemple driver wifi intel, pilote eagle) ou encore ceux qui depande d'un firmware proprio (par exemple carte dvb-s ) c'est tres limite. Dans les deux cas tu n'est pas libre de faire evoluer ton driver pour pouvoir profiter au maximun du materiel comme tu l'entend (par exemple pour les carte dvb-s tu prefere avoir un osd avec 256 couleurs dispo sur toute l'image, plutot que d'utiliser la memoire interne pour la bufferisation,...). Y a un bug dans le firmware ou dans la partie d'acces au materiel, sans les spec t'iras pas loin...
Par exemple routeurs wifi comme le linksys qui grace au fait qu'il utilise linux comme OS, on les sources du systeme disponible (enfin y a certaines partie propio) ce qui te permets de rajouter sur ton routeur du vpn, un ssh,...(bref tu est libre d'en faire ce que tu veux et non pas etre depandant du constructeur, t'as bien acheter le materiel, t'es bien senser pouvoir en faire ce que t'en veux)
[mode reve]
Finalement ce qui serait bien c'est qu'une companie (ou des) ce fasse a faire du materie compatible avec le libre : ie du bon materiel avec de vrai spec et un driver/systeme initial libre...
[/mode reve]
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par William Steve Applegate (site web personnel) . Évalué à 3.
Le problème, il est dans le fait que tu ne sais pas ce qu'ils font, que tu ne peux pas les déboguer, les améliorer, etc.
> Les constructeurs investissent enormement pour creer des processeurs graphiques performants, et ils devraient rendre publique les speficites comme ca ? Juste parce que "c'est mieux si c libre ?". Je ne pense pas.
Laisse-moi juste réécrire ta phrase, pour voir si ça passe : « les éditeurs investissent énormement pour créer des logiciels applicatifs performants, et ils devraient rendre publiques les sources comme ça ? Juste parce que “ c'est mieux si c'est Libre ” ? Je ne pense pas ». Ah bah oui, ça passe bien. Sauf qu'il y en a qui les rendent libres quand même. Pour ce qui est des adaptateurs graphiques, la question est même encore plus simple, vu qu'ils ne font pas leur pognon sur les pilotes, mais sur le matos. Donc oui, ils devraient (nVIDIA l'a même fait à l'époque de GLX et des TNT. Désormais, ils affirment avoir du code tierce partie qu'ils ne peuvent révéler. Bah moi, je peux pas acheter leur matos tant qu'ils l'enlèvent pas. Point final).
> Il ne faut pas etre integriste, et le proprietaire peut parfaitement cohabite avec le libre !
Oui, bien sûr. Tant que c'est un choix. Là, faute de spécifications publiques, il n'y a guère de choix possible pour les possesseurs de ces cartes. C'est soit des pilotes ne faisant pas de 3D, soit du proprio. Merci bien…
> Mais la il sagit d'un carte graphique ! il n'y pas de compatibilite comme sur un pc "vide", on est dependant des le materiel.
Je comprends pas bien, là. En quoi le pilote de ta carte graphique est-il moins important que, mettons, ton kernel, ton shell ou ton traitement de texte ? Perso, je me fiche un peu d'installer (par exemple) le plugin proprio pour Flash (après tout, je peux m'en débarrasser sans réduire horriblement les fonctionnalités de mon système), en revanche je suis dépendant de ma carte graphique pour beaucoup de choses, je ne veux donc pas dépendre d'un morceau de code opaque que je ne contrôle pas.
> Oui je me rejouit, de la sortie de pilotes proprio, vu que ma carte vient d'un fabriquant particulier, et ne doit pas repondre a une norme particuliere.
<sarcasme mode="gentil">Ah ? Toutes les normes édictées jusque-là ont disparu ? VESA, OpenGL, tout ça, ça n'existe plus ? On en apprend tous les jours, dites donc !</sarcasme>
> Ce n'est pas parce qu'on accepte qqchs de non libre qu'on tombe dans le systeme "a la windows".
Aujourd'hui, tu vas accepter un pilote non libre. Demain, tu accepteras une bibliothèque non libre (c'est déjà arrivé, le cas le plus célèbre est KDE avec Qt), puis des outils de développement non libres (*couf* BitKeeper *couf*), puis petit à petit, tu te retrouveras avec plein de soft proprios dont tu ne pourras pas te passer, et tout sera à refaire. Mieux vaut dire stop dès maintenant, et faire avancer les softs libres plutôt que d'aller chercher un soft proprio pour remplir une tâche (et d'autant plus que la tâche est critique, puisque ça rendra ledit soft plus indispensable). Ce n'est pas de l'intégrisme, là (on ne peut guère m'accuser d'être un fan de RMS), c'est tout bonnement de l'instinct de conservation !
Envoyé depuis mon PDP 11/70
[^] # Pourquoi il faut des piotes libres
Posté par Arthur Accroc . Évalué à 1.
Voyons, par où commencer ?
- Il n'y a pas de raison d'avoir beaucoup plus confiance en un système dont une partie du noyau est fermée que dans système entièrement fermé.
- En cas de bug sévère compromettant le fonctionnement du système, tu es totalement dépendant du constructeur pour sa correction.
- Les constructeurs de matériel ont un grand passé de programmation avec les pieds : à l'époque de Windows 95, il y a des machines, comme ça, qui plantaient très souvent et qui, comme par miracle, pouvaient devenir beaucoup plus stables en changeant un pilote, ou carrément un composant. Quand Microsoft en a eu marre que les plantages dûs à la médiocrité des drivers soient attribués (aussi) à Windows, ils ont mis en place un programme de certification. Sous Linux, il n'y en a pas, les constructeurs peuvent donc à nouveau "se lâcher". Et pour avoir eu le cas d'une machine sur laquelle le driver nVidia propriétaire cause un gel du système en cas de mise en veille de l'écran, je n'ai aucun doute sur le fait qu'ils aient tout de suite retrouvé les bonnes vieilles habitudes...
- Tu es totalement dépendant du contructeur quant au support du matériel pour d'autres systèmes (BSD, Hurd...), d'autres architectures (IA64...), ou même des versions ultérieures de ton système. S'il décide qu'il n'y a pas de raison que les gens qui ont acheté leur matériel il y a trois ans puissent l'utiliser avec des sytèmes récents plutôt que de leur en racheter du neuf, il leur suffit d'arrêter de fournir de nouveaux pilotes pour ce matériel.
Qu'il existe des pilotes propriétaires pour ceux qui préfèrent que leur système tourne vite (dans le domaine des cartes graphiques en particulier, le but des constructeurs est de faire un pilote qui donne l'impression que leur matériel est plus performant que celui de leurs concurrents, au détriment de toute autre considération) et mal, ça ne me dérange pas, mais que ce soit prétexte à ne pas diffuser les spécifications du matériel pour permettre le développement éventuel de pilotes libres, c'est extrêmement génant...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par Laurent Mouillart . Évalué à 3.
NVIDIA pilotes propriétaires 20%
Intel pilotes propriétaires 40%
VIA visiblement libre
Matrox visiblement mort (dernières modifs y a un an)
Donc a part VIA je vois pas trops chez qui te fournir (via ne fait que du matos embarqué il me semble).
Pour les spec tu peux te battre, te fouetter, implorer la justice des hommes, de dieu, de qui tu veux jamais ils te les filerons.
(Les pilotes DRI ont une partie DRM qui s'incruste dans le noyau).
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par DiZ . Évalué à 0.
>NVIDIA pilotes propriétaires 20%
>Intel pilotes propriétaires 40%
>VIA visiblement libre
>Matrox visiblement mort (dernières modifs y a un an)
Bonjour,
Pourrais-tu me donner un lien sur ces statistiques ?
Pourrais-tu me donner un lien sur les pilotes Intel proprio ?
Merci d'avance
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par Laurent Mouillart . Évalué à 4.
Pour les pilotes : intel http://zdnet.com.com/2100-1103_2-5299219.html(...)
[^] # Erreur de lien
Posté par Laurent Mouillart . Évalué à 2.
http://support.intel.com/support/graphics/sb/CS-010512.htm(...)
(je n'y ai pas trouvé de licence)
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par Croconux . Évalué à 2.
NVIDIA pilotes propriétaires 20%
Intel pilotes propriétaires 40%
VIA visiblement libre
Matrox visiblement mort (dernières modifs y a un an)
Il faut relativiser quand même. Tous ceux qui utilisent des cartes ATI ou Nvidia n'utilisent pas forcément les drivers proprio. Personellement je n'en n'ai jamais installé un seul.
Sur mes machines j'ai actuellement des Radeon 9200 avec le driver dri et sur mon portable c'est un chipset i855GM dont le driver libre me suffit amplement.
Pour les driver proprio Intel tu as vu ça où? A ma connaissance Intel fourni tout ce qu'il faut aux développeurs (noyau et X). Il n'y a que pour le composant Pro Wireless qu'ils emmerdent le monde.
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par Homer . Évalué à 2.
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par Guillaume Knispel . Évalué à 1.
Je ne vois pas pourquoi le souhait que les drivers soient libres entrainerait forcement des drivers non développés par les constructeurs. Après c'est bien entendu une question de choix pour eux (et de sombres histoire de "c'est pas nous qui l'avons codé, on a pas le droit de vous le filer" ce qui ne me rassure guère quand à la qualité des drivers (et m'empeche d'en acheter jusqu'à présent ; je ne peux pas me permettre de pourrir mon noyeau)).
Il y aurait des repercussions quasi "immédiates" à ce que les drivers soient libres : support de Linux sur architecture PPC par exemple (pas besoin d'être un expert dans 30 domaines différents pour faire un port correct) ! Support d'autre OS aussi. Débuggage des trucs triviaux par des gens exterieurs au constructeurs aussi surrement (regler un problème de palette lors de commutation de VT doit prendre 1H à tout casser, ou alors l'architecture de la carte est désastreuse si c'est plus compliqué)
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par GhZaaark3 . Évalué à 2.
ce genre de comportement intégriste nuit gravement à la santé :)
Je suis content que des pilotes sortent, que ma carte pour laquelle j'ai déboursée des biftons, marche impec, si il y a l'équivalent en libre, alors je passe aux pilotes libres.
Mais faut arrêter un moment.
Utiliser les pilotes fermés, n'est pas un mal, mais il ne faut pas baisser les bras quant à la demande incessante (j'éspère) des specs.
Car je ne comprend tjrs pas pourquoi ils ne les filent pas ces specs, tout ce que ça peut faire, c'est encourager l'achat de ce genre de cartes.
Le problème c'est qu'Nvidia tiens bon le monopole, qu'il a enterré 3Dfx qui -sans nul doute - nous aurrait fait eviter à tous cette situation de m****.
parlons pas des bleus d'Ati...
+
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par Fred Albrecht . Évalué à 3.
Et ton BIOS ?
Et le code du contrôleur de ton disque dur ?
Et celui de ton CDROM ?
Et celui de ton graveur ?
Du code il y en a une floppée dans une machine, il n'y a pas que ce qu'on charge quand on l'allume, il y a beaucoup de trucs embarqués aussi. Là curieusement personne ne râle. "Ouin, le BIOS de ma carte SCSI il est pas libre, je peux pas le patcher, elle envoie peut-être les photos de ma copine à Bill Gates dans mon dos".
Le matériel actuel est devenu complexe, le temps de l'AppleII livré avec un schéma de montage complet est passé. Il n'y a probablement plus personne qui puisse prétendre maîtriser l'ensemble des aspects d'un ordinateur, logiciel et matériel.
Les cartes graphiques sont des petits systèmes embarqués particulièrement pointus, qui représentent des investissements d'autant plus lourds que leur durée de vie n'est pas très longue. Les fabricants ont beau essayer de déporter les coûts en ne vendant que les chips et en laissant des revendeurs genre Hercules faire les incvestissements de packaging, de comm, d'assemblage, etc, il reste la R&D, le développement, le suivi des gammes, la rémunération des fondeurs (je ne pense pas que nVidia ou ATI soient fondeurs, etc.), tout ça coûte quand même très très chèr (voir le taux de mortalité élevé dans le secteur).
Bref c'est bien joli de couiner du "ouin c'est pas libre" mais il faut être un minimum cohérent. Soit tu râles pour tout le code qui n'est pas libre sur ton système et tu fais tourner un R3000 (je crois que le design a été libéré) avec du matos d'il y a 20 ans qui est parfaitement connu, documenté et libéré en collant un VT100 au cul du bouzin, soit tu fais comme tout le monde, tu regrettes qu'on ne puisse pas faire mieux, tu espères que des progrès seront faits et tu profites des jolies images.
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par step . Évalué à 6.
Il y a un argument en faveur des drivers libres que j'aimerais avancer.
Le fait, pour un périphérique, de posseder un driver libre permet à l'utilisateur
d'avoir la liberté de déterminer la fin de vie de son matériel sans dépendre de son fabriquant pour disposer d'un driver sur le système sous lequel il veut tourner.
Cette mésaventure m'est déja arrivé avec une carte tuner radio (type guillemot). Passage sous windows XP impossible ( pas de driver à l'époque prévue pour ce système chez le fabriquant et visiblement pas envie d'en faire un).
A titre de référence, se driver existait du temps du 2.2, du 2.4 et existe pour le 2.6 sous linux.
Les drivers libres plus que par leur valeur technique valent par la pérénité qu'ils donnent au matériel que l'on achète. C'est cette liberté que nous perdons en partie si nous considérons le driver propriétaire comme une fin en soit.
Cependant, je pense qu'un drivers propriétaire n'est pas une mauvaise idée dans un premier temps. Elle permet en effet de garantir une mise à disposition et une qualité technique minimale ( en général :-)). Cependant, il devrait être acquis dans une société ou le développement durable va devenir une obligation pour notre survie à tous, que la fin de vie d'un matériel vienne de son épuisement, pas du caprice d'une société commerciale quelconque qui veut faire renouveler son matériel. Dans cette optique, un driver, lorsque la société signe l'arret de commercialisation de son matériel, devrait automatiquement devenir ouvert dans un but d'interopérabilité pour le futur. La loi est dans ce sens et cette première phase en tant que driver fermé permettrait aussi de protéger la R&D de la société commerciale en lui permettant de garder 3-5 ans (durée de commercialisation d'un matos) d'avance sur des copieurs potentiels.
Voila mon avis... il n'engage que moi mais à le mérite de tenter de concilier les deux positions.
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par Fred Albrecht . Évalué à 1.
Un pilote avec un code fermé oblige à maintenir une API compatible ou une couche d'émulation. Ou comme le fait XP à abandonner le matériel...
Pour l'instant dans le cas des adaptateurs graphiques ça semble se libérer au fur et à mesure que les cartes deviennent obsolètes. Mais il n'est pas du tout certain que la tendance va se poursuivre avec les modèles actuels qui sont autrement plus complexes que ceux d'il y a cinq ou dix ans...
Forcer la divulgation lorsqu'un produit est abandonné serait une bonne solution mais la législation actuelle me semble plutôt aller en sens inverse avec des lois de plus en plus contraignantes sur la protection intelectuelle et notamment les données numériques et le reverse engineering.
On verra.
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par wismerhill . Évalué à 2.
Note que la situation n'est pas aussi mauvaise que ça dans le cas de NVidia et ATI, puisqu'ils utilisent une couche de compatibilité qui, elle, est open-source (je sais pas sous quelle license).
C'est ce qui avait permis d'avoir le driver NVidia dispo pour le 2.6 alors qu'ils ne le supportaient pas encore officiellement, et j'utilise toujours cette ancienne version car les nouvelles me posent problème dans les consoles texte (même cette dernière version).
Si d'autres constructeurs faisaient déjà ça ce serait un bon début. Je pense au cas d'un modem ADSL USB dont le constructeur fournit une archive avec un modile pré-compilé pour le noyau standard de la mdk9.1, et rien d'autre. Inutilisable.
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par Thierry Vignaud . Évalué à 1.
il n'y a aucune couche de compatibilité: ils ont simplement ecrit un peu de glue pour avoir accces aux fonctions du noyau.
cette glue est regulierement cassee par les changements upstream du noyau
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par Guillaume Knispel . Évalué à 3.
Et ton BIOS ?
Et le code du contrôleur de ton disque dur ?
Et celui de ton CDROM ?
Et celui de ton graveur ?
Du code il y en a une floppée dans une machine, il n'y a pas que ce qu'on charge quand on l'allume, il y a beaucoup de trucs embarqués aussi. Là curieusement personne ne râle. "Ouin, le BIOS de ma carte SCSI il est pas libre, je peux pas le patcher, elle envoie peut-être les photos de ma copine à Bill Gates dans mon dos".
Tes exemples sont dérisoires : tu ne parles que de code soit ne tournant pas sur le processeur central, soit ne tournant pas en meme temps que linux sur le processeur central. Aucun de tes exemples ne pourri le noyeau...
Beaucoup de personne accepterait que le code embarqué de la carte graphique soit fournis sans les sources, tant qu'on ait avec ce code les spécifications pour utiliser ainsi la carte (et des drivers proprio uniquement pour Linux sur x86 pour te faire plaisir)
tu profites des jolies images.
Le gas qui a un Mac sous linux il va avoir du mal (il doit emuler le proc ?)
[^] # Re: Ça commence par les pilotes de cartes graphiques...
Posté par Fred Albrecht . Évalué à 1.
Le noyau n'a rien à voir là dedans. Le jour où le BIOS refusera de démarrer un OS qui ne sera pas signé, tu seras quand même bien avancé avec ton noyau "pur".
Quand au problème du peu de plateformes supportées par les pilotes propriétaires, c'est un autre problème auquel je suis parfaitement sensibilisé, n'utilisant pas que du x86 (et même là, voir le bordel des qu'on sort des sentiers battus, sur AMD64 par exemple).
C'est aussi un problème pour les petites applications gratuites un peu incontournables comme acroread, flash, la jvm, etc. Dans ces cas là, pour beaucoup il ne reste malheureusement souvent que l'émulation. C'est l'inconvénient de sortir du lot...
# Effet Siggraph
Posté par photon . Évalué à 1.
http://www.siggraph.org/s2004(...)
# Problème de stabilité : quelque un a le même ?
Posté par Samuel Pajilewski . Évalué à 1.
j'avais téléchargé de driver juste avant cette version. J'utilise un noyau 2.4.24 sur une distribution SuSE 9.0 avec Xfree 4.2.99-XXXX
En installant les drivers Nvidia, tout va bien. Au niveau performance c'est le top (d'ailleurs Nvidia sont trres fort sur Linux à ce jeu là)
Cependant j'ai des freezes systèmes mais dans des conditions particulieres :
- Quand j'utilise Netscape 7.1
- Quand j'utilise amsn
Sinon pas de freeze ! Je me dis que ces applications doivent faire appels à des routines particulieres sur Xfree pour provoquer ces plantages.
Quelqu'un a t-il eu le même problème ?
[^] # Re: Problème de stabilité : quelque un a le même ?
Posté par un_brice (site web personnel) . Évalué à 0.
Sinon, je rapelle juste qu'il ne faut pas utiliser le framebuffer nvidia avec le driver propriètaire.
Ce que tu peut faire, c'est essayer avec le driver libre par aquis de conscience et si ça plante qu'avec le driver propriétaire, faire un rapport de bugs chez nvidia.
# support chez ATI.COM
Posté par warmup031 . Évalué à 0.
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]INSERT statement conflicted with COLUMN FOREIGN KEY constraint 'FK_Customer_Processor'. The conflict occurred in database 'linuxDriver', table 'Processor', column 'kprocessor'.
/linuxDfeedback/datasource.asp, line 75
Surtout après avoir gentiment rempli tout leur formulaire....
# Pas que pour la 3D
Posté par tux_tux . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.