Martin Peres (alias mupuf) n’est pas exactement un inconnu sur LinuxFr.org, puisque son nom a déjà été mentionné lors de la sortie des versions 2.6.37 et 3.3 du noyau, pour son travail sur le projet Nouveau, dont il est l’un des développeurs, ou encore très récemment dans un journal sur la conception sécurisée des serveurs graphiques (X, Wayland).
En creusant un peu, je me suis aperçu que Martin était même actif sur LinuxFr.org, où il a déjà rédigé des dépêches.
Alors que le travail de Martin sur Nouveau sera à nouveau mentionné dans la dépêche à venir sur la prochaine version 3.7 du noyau Linux, le moment me semblait adéquat pour une demande d’entretien qu’il a gentiment acceptée.
Précisons que vous pouvez également suivre Martin via son blogue, sa page recherche ou son compte Google+.
Martin, pourrais‐tu te présenter rapidement ?
J’ai 24 ans, je suis actuellement doctorant au LaBRI sur les problématiques de la gestion d’énergie et de la sécurité dans les réseaux sans fil. Je viens de l’ENSI de Bourges où j’ai reçu le diplôme d’ingénieur Sécurité des systèmes ubiquitaires.
LinuxFr.org a plusieurs fois cité ton nom dans les commits de Nouveau. Pourrais‐tu expliquer comment tu t’es retrouvé à travailler sur Nouveau et ce que tu y fais ?
Comme beaucoup de développeurs X.Org, j’ai commencé à m’intéresser à la pile graphique parce qu’elle ne fonctionnait pas pour moi. Dans mon cas, mon problème venait de Fglrx qui ne gérait pas mon ATI Radeon Xpress 200M, en 2007.
C’est à ce moment que j’ai commencé à m’intéresser aux pilotes graphiques et que j’ai commencé à tester les pilotes libres (radeon).
À mon entrée à l’ENSI de Bourges, la région Centre a offert des ordinateurs ThinkPad à tous les étudiants. Ne voulant pas revivre l’enfer que j’avais connu avec Fglrx, j’ai été déçu de voir qu’ils contenaient une carte graphique NVIDIA. Heureusement, j’ai été soulagé de voir que le pilote propriétaire marchait correctement. Cependant, je m’étais pris de passion pour les pilotes libres, et je suis passé sur Nouveau assez rapidement pour avoir le KMS et tester son niveau de prise en charge.
Après quelques mois, j’ai commencé à me plaindre de corruptions graphiques dans KDE, ce qui m’a poussé à contacter la communauté de développeurs et à essayer de résoudre le problème par moi‐même. Je n’ai pas réussi, mais le CTO de PathScale m’a repéré et m’a proposé de travailler sur PSCNV, un fork de Nouveau visant à proposer le support d’un GPGPU (comme CUDA ou OpenCL) particulier appelé ENZO. Mon travail était de rajouter la prise en charge du pilote dans libdrm de façon à fournir une accélération 2D et 3D. J’ai réussi à avoir glxgears, mais certaines corruptions inexpliquées ont contraint un autre développeur à prendre le relais et ré‐écrire totalement mon code. Deuxième échec, mais faut pas se décourager. :)
On m’a ensuite proposé d’implémenter la gestion d’énergie qui avait un peu de documentation disponible. C’est à ce moment que j’ai décidé de travailler directement sur Nouveau, puis de rétro‐porter mes changements dans PSCNV quand ils seraient prêts. Une première version suffisante pour analyser le VBIOS, lire la température et changer les fréquences de ma nv86 était prête en 15 jours. C’était en septembre 2010, quelques heures avant mon départ pour l’XDS 2010 à Toulouse. Premier succès !
Cependant, ce travail était instable et très dépendant de mon matériel. Depuis cette date, je passe mon temps libre à étudier le matériel (ingénierie inverse), à faire des tests de stabilité durant les changements de fréquence et à implémenter mes découvertes.
Ce travail est de longue haleine. Par exemple, j’ai programmé la première version de la gestion automatique du ventilateur du processeur graphique durant l’été 2011, et ce n’est que maintenant, après que ce travail a été ré‐écrit plusieurs fois, qu’il est enfin prêt à entrer dans le noyau [N. D. L. R. : c’est prévu pour la version 3.7 du noyau Linux].
Cela dit, mon travail ne se limite pas à l’ingénierie inverse et à l’écriture de code. J’essaye de tenir à jour la communauté en participant à des conférences ou par l’écriture d’articles. Je travaille également à attirer plus de développeurs sur le projet Nouveau. Par exemple, cet été, j’ai été le mentor de 2 étudiants pour le X.org Endless Vacation of Code — ou EVoC – (équivalent du Google Summer of Code – ou GSoC). Seulement un des deux étudiants à réussi à aller jusqu’à la fin de son projet. Cet étudiant a travaillé sur l’amélioration de PDAEMON (sorte de RTOS dans les cartes récentes) de façon à pouvoir demander à la carte d’exécuter un script simple. L’application naturelle pour cette fonctionnalité est le changement de fréquence — reclocking — de la mémoire qui doit respecter des contraintes temporelles fortes pour ne pas gêner l’utilisateur. Pour plus d’informations, vous pouvez lire son blogue.
Si je comprends bien, il ne faut pas avoir peur de l’échec et persévérer ?
Exactement ! Une fonctionnalité est terminée quand elle n’a plus de possibilité de ne pas marcher. Il ne faut pas se laisser décourager et persister, jusqu’à ce que tout marche.
À propos de Linux 3.7, tu as proposé des patches relatifs à la gestion du ventilateur. Peux‐tu nous en dire plus ?
La gestion de la température a toujours été un problème dans Nouveau. Sur l’ensemble des cartes gérées par Nouveau, il y a 4 façons de lire la température et 5 façons de changer la vitesse du ventilateur.
Jusqu’à Linux 3.7, seule la lecture de la température sur certaines nv50+ était implémentée correctement. Avec Linux 3.7, la lecture de la température devrait être correcte sur toutes les cartes à l’exception de celles qui utilisent une sonde de température externe. La gestion de ces sondes a aussi été améliorée dans Linux 3.7, et Nouveau devrait charger le pilote hwmon associé à cette sonde.
Cependant, en raison d’une limitation de l’interface de hwmon qui expose la température des sondes externes, Nouveau ne peut pas accéder à la température. Seul l’utilisateur le peut. Nous avons discuté et proposé plusieurs correctifs aux mainteneurs de hwmon pour standardiser l’interface et la rendre accessible depuis le noyau. La dernière tentative faite par Lucas Stach n’ayant pas eu de réponse, nous avons perdu espoir et nous étudions la possibilité de reprogrammer les pilotes nous‐même, pour toutes les sondes utilisées par les constructeurs de carte Nvidia. Il semblerait cependant que nous ne soyons pas les seuls à demander cette interface. Peut‐être viendra‐t‐elle dans une version future de Linux ? Ce n’est pas étonnant car, sans cette interface, il est impossible pour les pilotes de réagir à des évènements tels que la sur‐température.
La gestion du ventilateur est encore plus kafkaïenne. En premier, la gestion automatique peut être prise en charge par le noyau, la carte elle‐même ou par une sonde externe. Dans tous les cas, la vitesse du ventilateur est contrôlée par modulation de largeur d’impulsion (PWM). Cette modulation peut être générée par le noyau en basculant périodiquement une GPIO de la carte définie par le VBIOS (mode TOGGLE), par un contrôleur PWM interne à la carte (mode PWM) ou par la sonde externe.
Avec Linux 3.7, la gestion du mode PWM devrait être terminée pour les familles nv40 et nv50. Les familles nvc0+ gérant la vitesse du ventilateur automatiquement, vous ne pourrez la changer sur ces cartes pour l’instant. La gestion automatique du ventilateur sur les cartes plus vieilles a été écrite, mais a été finalisée trop tard pour rentrer dans Linux 3.7. Je travaille donc à l’améliorer ainsi qu’à ajouter le gestion de la sur‐température. Je finaliserai ensuite mon implémentation de la gestion automatique de la température pour les cartes nvc0+. Le travail initial est déjà disponible.
Avec un peu de chance, tout ça finira dans Linux 3.8, et je n’aurai plus à faire chauffer mes cartes jusqu’à 130 °C avec un sèche‐cheveux pour travailler. :)
Qui sont les développeurs à l’œuvre sur Nouveau, et comment décidez‐vous de ce qui entre dans les branches officielles et ce qui reste dans vos arbres personnels ?
Nouveau est majoritairement composé d’étudiants, à l’exception de Ben Skeggs de chez Red Hat et de Maarten Lankhorst.
Ben Skeggs (alias darktama) est le mainteneur du pilote DDX xf86-video-nouveau et de la partie DRM (pilote nouveau dans le noyau). Il est aussi le principal contributeur de Nouveau et opère majoritairement dans le noyau.
On trouve ensuite Christoph Bumiller (alias calim), étudiant, en tant que mainteneur et unique développeur des pilotes Mesa nv50 et c0. Il est aussi un des principaux rétro‐ingénieur de la partie 3D. Il a aussi passé une bonne partie de son temps à maintenir et améliorer le support de Direct3D dans Nouveau. Cependant, cette fonctionnalité lui a finalement juste permis de déboguer les extensions OpenGL non gérées par Gallium, lorsque celui‐ci était bloqué à OpenGL 2.1. Il était en effet bien plus facile de gérer Direct3D 10/11 qu’OpenGL 3.0. À ma connaissance, seule la version Windows du banc d’essai Heaven de Unigine fonctionne en conjonction avec une version modifiée de Wine. La gestion de Direct3D a récemment été désactivée par défaut, car elle n’est plus maintenue et boguée. Christoph considère que ce state tracker est une occasion manquée, car il aurait démontré la flexibilité de Gallium3D. Espérons que la gestion de Direct3D deviendra plus prioritaire lorsque la prise en charge d’OpenGL sera plus complète et mieux éprouvée.
La majorité de l’ingénierie inverse est effectuée par Marcin Kościelnicki (alias mwk), étudiant, qui s’est d’ailleurs interdit d’écrire le moindre bout de code dans Nouveau depuis quelques années. Sa contribution étant l’écriture d’outils annexes à Nouveau et l’écriture de documentation. Il a par exemple rétro‐ingénieré la plupart des jeux d’instructions des processeurs développés par NVIDIA (Falcon/FµC, VµC et ctxprogs), puis écrit un (dés)assembleur pour faciliter la rétro‐ingénierie des codes existants ou l’écriture de nos propres versions. Pour un petit aperçu, vous pouvez consulter son (hautement addictif) blogue [NDLR : chacun se fera son opinion en fonction de son niveau ;-)]. Le fruit de son travail est disponible sur GitHub, projet envytools. Il n’est cependant pas seul à travailler sur ce dépôt, j’essaye d’aider autant que possible en créant de nouveaux outils suivant mes besoins, ou en complétant les documentations au fur et à mesure que je découvre des fonctionnalités dans le matériel. Il est généralement le dépôt le plus ouvert de Nouveau.
Maarten Lankhorst (alias mlankhorst) vient de se faire embaucher par Canonical pour maintenir les pilotes graphiques pour les versions LTS. Il s’est d’abord fait connaître par son travail sur Wine avant de contribuer sur le décodage vidéo matériel dans Nouveau. Il travaille actuellement à améliorer la prise en charge d’Optimus entre Intel et Nouveau, dans le cadre de son nouvel emploi. Pour en savoir plus, vous pouvez visionner la vidéo de sa présentation au XDC 2012. Vous pouvez le suivre sur Google+.
Concernant la gestion d’énergie, je travaille en partie avec Roy Spliet (alias RSpliet), étudiant, qui a majoritairement rétro‐ingénieré la gestion des timings et qui m’a inspiré un outil pour nous aider dans cette tache (nvamemtimings). La majorité de notre travail est disponible sur Gitorious, Linux Nouveau PM.
Francisco Jerez (alias curro) est un contributeur de longue date. Il a notamment écrit le code pour la gestion des modes d’affichage — modesetting — sur les nv40, mais aussi l’implémentation initiale d’OpenCL dans Nouveau, dans le cadre d’un EVoC. Un travail de nettoyage de code est encore nécessaire, mais la prise en charge est en bonne voie.
Marcin Slusarz (alias joi) est un contributeur qui se limite généralement à la correction de bogues, et qui le fait très bien.
Lucas Stach (alias lynxeye) est majoritairement connu dans Nouveau pour ses patches dans le défunt driver Mesa nv40, qui a été remplacé par Ben Skeggs lors de la ré‐écriture de libdrm. Il travaille maintenant majoritairement sur le portage de Tegra sur l’architecture DRM. Ce travail est fait de concert avec l’équipe de développeurs de chez NVIDIA et d’autres contributeurs externes. Vous pouvez suivre son travail sur Google+.
Il y a bien sûr plusieurs autres développeurs, mais je pense que la majorité des gens qui ont contribué du code récemment sont là.
Quant au choix de ce qui rentre dans les branches officielles ou pas, ça dépend énormément de quelle partie on touche. Pour le noyau, il faut soumettre ses patches à Ben Skeggs, qui doit les accepter. Le niveau de qualité de code demandé est très élevé, et l’on doit généralement prouver que ce qu’on fait est bon. C’est pour cette raison que mes patches sur la gestion d’énergie sont majoritairement dans mon arbre. Ils ne sont acceptés qu’après avoir fait l’objet d’une étude exhaustive du matériel, ainsi que lorsque l’architecture logicielle proposée est totalement cohérente. En moyenne, je produis entre 5 et 10 versions d’une fonctionnalité avant de la voir acceptée.
Durant toute la phase de développement, nous parlons de notre travail sur le canal IRC, de façon à avoir des retours d’autres développeurs. Ben Skeggs propose ensuite ses patches à Dave Airlie, le mainteneur de DRM, qui envoie à son tour les patches DRM à Linus Torvalds.
Je ne peux pas trop parler de Mesa, mais il semblerait qu’il faille simplement envoyer les patches à la liste de diffusion dri-devel, et le mainteneur du code modifié donne son avis et récupère le code assez rapidement. Cependant, pour toute fonctionnalité un peu grosse, il semblerait bon d’en discuter en premier avec Christoph Bumiller.
Tu mentionnes OpenCL, Optimus et la gestion d’énergie, faut‐il s’attendre à d’autres surprises ?
Dur à dire. On travaille sur plusieurs choses en parallèle, et nul ne sait quand une fonctionnalité sera prête. Ben a mentionné la gestion du SLI, mais je n’ai aucune information là‐dessus et je doute que ce soit une priorité.
As‐tu d’autres projets relatifs à Linux ou au Libre en général ?
Oui, j’essaye d’être actif autant que possible sur deux autres sujets : la sécurité et le développement embarqué.
Concernant la sécurité, j’ai commencé à étudier ce domaine à l’ENSI de Bourges. J’ai très tôt contribué à la recherche effectuée par l’équipe SDS (Sécurité des systèmes distribués) en participant au projet de l’ANR (Agence Nationale pour la Recherche) Système d’Exploitation Cloisonné & Sécurisé pour l’Internaute (SEC & SI). La solution proposée était à base de Gentoo Hardened, PIGA et PIGA-SYSTRANS pour contrôler les interactions venant de l’utilisateur. J’étais en charge du développement de cette dernière couche. J’ai par la suite continué à me soucier de la sécurité des données utilisateur, ce qui a abouti à une présentation au XDC 2012 à propos de la sécurité dans la pile graphique. Dans le cadre de mon doctorat, je donne également des cours de sécurité des systèmes d’information et de sécurité matérielle à l’ENSEIRB, dans la filière Télécom, option Systèmes et Réseaux Communiquants (RSC).
Concernant l’embarqué et l’électronique, je suis membre du hackerspace de Bordeaux, appelé LaBX. Je suis aussi mainteneur et développeur d’un EDI libre alternatif pour les Arduinos. Cet EDI se différencie de l’EDI officiel par le fait qu’il est totalement écrit en C++/Qt, contrairement à l’EDI officiel qui est en Java. Vous pouvez avoir plus d’informations sur le site officiel.
Les deux dernières questions ont essentiellement pour but de mettre de l’animation dans les commentaires : quels distribution et environnement graphique utilises‐tu ?
Je suis un Archer (Arch Linux) depuis 2008, grâce à un ami de DUT. J’aime particulièrement l’aspect communautaire, la facilité d’écriture de paquets et la politique de publication continue (rolling release).
Pour le bureau graphique, je suis sous KDE depuis la version 4.3. J’aime beaucoup Plasma, KWin, Kile, Kate, Kcalc et Okteta. J’espère juste que la communauté KDE va arrêter d’ajouter des fonctionnalités et testera mieux ses composants principaux avant chaque publication. Il semblerait que ce soit la direction prise actuellement par KDE. Wait and see! ;)
Arch Linux étant récemment passé sous systemd par défaut, que penses‐tu de systemd ? Et Wayland ? Ce sont deux sujets bouillants auprès de nos lecteurs…
Je n’ai personnellement aucun problème avec systemd. Celui‐ci est encore jeune, mais il fait bien son travail. J’aime le concept du chargement dynamique des daemons nécessaires, et j’adore le fait qu’il soit devenu facile d’utiliser de nouvelles fonctionnalités de Linux, telles que le file system namespace ! L’amélioration du temps de démarrage, ainsi que la facilité d’audit de celui‐ci sont les cerises sur le gâteau. :)
Quant à Wayland, je suis extrêmement enthousiaste. Celui‐ci va permettre de résoudre les problèmes de sécurité de X, mais aussi des problèmes de performance. Un autre avantage de Wayland est qu’il est beaucoup plus facile à comprendre que l’architecture de X. Cette simplification devrait rendre possible l’arrivée de nouveaux types de compositeurs aussi innovant que l’était Compiz en son temps. Voici un petit aperçu de ce qui est à venir.
Merci pour cet entretien et tes contributions.
De rien ! Merci de m’avoir donné la parole.
Aller plus loin
- Description de la pile graphique de Linux, sur Wikipédia (304 clics)
- Le projet Nouveau, sur Wikipédia (360 clics)
- Le site officiel du projet Nouveau (125 clics)
- L’avancement de Nouveau pour chacune des cartes NVIDIA, sur le wiki officiel (156 clics)
- PSCNV, ou Nouveau par PathScale (56 clics)
# Félicitations
Posté par Loïc Blot (site web personnel) . Évalué à 0.
Bonsoir Martin, je tiens à te féliciter, il est rare de voir de jeunes étudiants Français aussi motivés. J'espère que tu sauras amener avec toi d'autres étudiants pour les développements dans le monde du logiciel libre, surtout avec ce qui se prépare sur Bordeaux en ce moment ! Merci pour tes contributions, qui serviront sur le moyen terme à tous.
Veepee & UNIX-Experience
[^] # Re: Félicitations
Posté par coïn . Évalué à 9.
c'est quoi ce cliché de merde ? il y a beaucoup d'étudiant Français qui participent à des projets libres.
[^] # Re: Félicitations
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
Mais ce qui est dommage est le manque de visibilité ; non pas dû à leur inexistence, ou à leur manque de talent et d'acharnement, mais à l'accaparement de l'espace médiatique par d'autres sujets infiniment plus intéressants, tels que — en vrac — les tenues des stars, les crises, les nouveaux produits top super-cool, le refrain à la mode, et cætera. Donc merci aussi à l'initiateur de l'entrevue.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Félicitations
Posté par jihele . Évalué à 10.
Tu as oublié systemd, Unity et Gnome Shell.
[^] # Re: Félicitations
Posté par jyes . Évalué à 4.
Non, c’est bien dans son commentaire:
ou à la limite
comme ça je m’épargne les foudres de Zenitram.
[^] # Re: Félicitations
Posté par Martin Peres (site web personnel) . Évalué à 4.
Merci Loïc. J'avoue ne pas te suivre sur "ce qui se prépare sur Bordeaux". J'ai raté quelque chose ?
[^] # Re: Félicitations
Posté par gnumdk (site web personnel) . Évalué à 3.
C'est pas à Toulouse plutôt ?
http://www.capitoledulibre.org/2012/
# respect
Posté par coïn . Évalué à 7. Dernière modification le 26 octobre 2012 à 06:57.
Respect et bravo.
une petite dizaine d'étudiant face aux mille ingé nvida, le combat est inégal mais c'est beau quand même :)
[^] # Re: respect
Posté par Martin Peres (site web personnel) . Évalué à 10.
Merci, on s'amuse comme on peut ;)
[^] # Re: respect
Posté par gnumdk (site web personnel) . Évalué à 4.
Petit anecdote…
Un collègue était sous Ubuntu avec une carte Intel, j'ai du récupérer sa machine et du coup il a récupéré une machine de chercheur avec carte Quadro de chez Nvidia.
Je prend les disques de l'ancien PC, je les mets en place sur la nouvelle machine et je boot (Ubuntu 12.04). Par réflexe (configuration bi écran, je connais mal nouveau, sur mon pc à la maison, quelques bugs graphiques), j'installe le driver NVIDIA.
Les jours passent et j'apprends que le gars a des freezes sur sa machine plusieurs fois par semaine voir parfois elle plante en lançant X. Je vire le driver NVIDIA histoire de voir si par hasard ca fait la même chose avec Nouveau, je configure le double écran, ca fonctionne… Depuis, la machine ne plante plus!
Bon, faudrait que je me décide à retester nouveau à la maison :)
[^] # Re: respect
Posté par gnumdk (site web personnel) . Évalué à 6. Dernière modification le 26 octobre 2012 à 10:28.
Allez pour le coup, je viens de virer les drivers Nvidia sur mon pc au taf (bi écran avec NVIDIA Corporation G84 [Quadro FX 570].
J'ai un peu flippé d'avoir perdu ma conf KDE quand ca a démarrer en mode clone mais une fois configuré, plasma m'a remis mon bureau de droite en état :)
Ca fonctionne au poil et j'ai même pu réactiver le module kwin pour le curseur qui saute (faut connaitre KDE pour comprendre) qui avait de gros bug d'affichage avec le dernier driver Nvidia ;)
Je regarde ce soir si ca corrige aussi les bugs d'affichage que j'ai à la maison avec les vidéos et xv (parfois, pendant 1 seconde, j'ai une image qui s'affiche à l'écran et qui n'a rien à voir avec la vidéo au temps t… Souvent, c'est une scène de y'a 10 minutes dans la vidéo)…
MERCI!
[^] # Re: respect
Posté par Martin Peres (site web personnel) . Évalué à 6.
Bonnes nouvelles! Tiens nous au courant!
[^] # Re: respect
Posté par Olivier (site web personnel) . Évalué à 4.
Bravo pour le boulot que vous faites sur Nouveau
Le travail de retro-engineering sur des drivers proprio doit être quelque chose de très complexe, et cela m'épate que l'on puisse y arriver !
[^] # Re: respect
Posté par Martin Peres (site web personnel) . Évalué à 8.
C'est pas complexe du tout quand on a les bons outils. Par contre c'est lent et très ennuyeux si on aime pas les challenges ;)
[^] # Re: respect
Posté par djibb (site web personnel) . Évalué à 3.
et c'est quoi tes outils ?
[^] # Re: respect
Posté par Martin Peres (site web personnel) . Évalué à 10.
Ils sont ouverts. Il y a tout d'abord les mmiotraces qui permettent d'espionner ce qui passe par le port PCIE puis il y a valgrind-mmt qui permet de tracer tous les appels systèmes fait pour une application puis de tracer l'utilisation des buffers graphiques. On a aussi nvafakebios qui permet d'envoyer un bios modifié sur la carte sans flasher la ROM. Pour le reste, je te conseille d'aller voir la liste des programmes que l'on a dans le dépôt envytools.
[^] # Re: respect
Posté par djibb (site web personnel) . Évalué à 2.
merci :)
[^] # Re: respect
Posté par antistress (site web personnel) . Évalué à 1. Dernière modification le 27 octobre 2012 à 12:33.
cf, je pense, la partie de l'entretien sur Marcin Kościelnicki
edit : grillé
# Sécurité dans la pile graphique
Posté par tuxicoman (site web personnel) . Évalué à 10.
J'ai lu ton article il y a quelque temps déjà et c'est vrai que savoir qu'aujourd'hui, fier de notre OS "plus sécurisé que la fenêtre", n'importe quelle appli graphique peut écouter le clavier, y compris lorsque l'on tape son mdp root dans un terminal graphique ou la popup Gnome est traumatisant !
[^] # Re: Sécurité dans la pile graphique
Posté par Martin Peres (site web personnel) . Évalué à 10.
Oui, vivement Wayland pour corriger tout ça!
[^] # Re: Sécurité dans la pile graphique
Posté par Olivier Jeannet . Évalué à 1.
J'ai un camarade qui m'avait parlé de ce bug sur SunOS (avant Solaris donc) en 1992 à l'ENST où on avait des Sparc, ce qui lui avait permis d'obtenir la plupart des mots de passe des autres étudiants. Du coup, quand il tapait son mot de passe, il activait je ne sais plus quoi pour éviter que les frappes clavier puissent être écoutées par autre chose que le terminal où il tapait.
[^] # Re: Sécurité dans la pile graphique
Posté par gnumdk (site web personnel) . Évalué à 2. Dernière modification le 26 octobre 2012 à 17:56.
Cela ne concerne que les programmes d'un même utilisateur donc si il avait trouvé un truc, ce n'était pas celui là…
[^] # Re: Sécurité dans la pile graphique
Posté par cedric . Évalué à 4.
Si par defaut la politique de securite de X ressemblait a un xhost +, alors c'etait le meme truc.
[^] # Re: Sécurité dans la pile graphique
Posté par Xaapyks . Évalué à 3.
J'ai d'ailleurs été choqué de voir que sur une linux mint que j'ai installé un peu à la va-vite pour tester, il y a un script au lancement de session qui lance un xhost +….
[^] # Re: Sécurité dans la pile graphique
Posté par Anonyme . Évalué à 3.
Ouch. Tu as l'url d'un git ou d'un fichier quelquepars qui contient ca ?
[^] # Re: Sécurité dans la pile graphique
Posté par jihele . Évalué à 2.
Ça veut dire que n'importe quelle application malicieuse (y compris une saloperie en flash ?) peut avoir accès à toutes les entrées clavier et les sorties écran n'importe quand ?
[^] # Re: Sécurité dans la pile graphique
Posté par Martin Peres (site web personnel) . Évalué à 4.
Rien ne l'empêche dans X et dans le kernel en tout cas. Le seul contrôle existant est trop large.
[^] # Re: Sécurité dans la pile graphique
Posté par ckyl . Évalué à 2. Dernière modification le 26 octobre 2012 à 14:38.
Non c'es sandboxé. Par contre le jour ou la sandbox se fait trouer… Mais de toute facon à partir du moment ou on peut executer du code sous l'uid de l'utilisateur c'est game over, juste plus ou moins facile .
Bref utilisez une VM pour browser l'interweb et autre;)
[^] # Re: Sécurité dans la pile graphique
Posté par Martin Peres (site web personnel) . Évalué à 3.
Par qui? Pas par chromium/firefox car Flash peut accéder à VDPAU pour faire de l'accélération vidéo ;)
[^] # Re: Sécurité dans la pile graphique
Posté par ckyl . Évalué à 4.
C'est Flash qui a accès à X, pas les applis Flash. Elles, elles ne peuvent accéder qu'à ce qu'expose Flash/ActionScript. Les problèmes arrivent quand Flash est troué. C'est le même problème que pour les VM JS des browser.
Pour que les applis Flash puissent chopper les événements X, elles auraient besoin d'avoir fait tourner un bout de code natif sous l'UID de l'utilisateur pour aller chercher lesdits événement. À partir de la le problème de sécu à déjà eu lieu. Si tu enlèves ça elles feront autrement, elles peuvent faire exactement ce que l'utilisateur peut faire.
Après il est aussi intéressant de s'intéresser à comment on limite les dégats quand on se fait trouer. Adobe à bossé à sandboxer le processus Flash pour que quand il se fait trouer, l'attaquant ne puisse pas faire grand chose. Ca repose sur un design de type séparation de privilège. La VM tourne avec les droits les plus minimaux possibles, et quand il y a une interaction à faire avec le système elle doit demander à un autre processus qui à gardé les droits de l'utilisateur. Ca c'est dispo que sous Windows AFAIK. Si c'était dispo sous Linux alors là oui, pouvoir écouter les événements clavier serait un problème. Mais sans ca, ca ne sert pas à grand chose.
[^] # Re: Sécurité dans la pile graphique
Posté par Martin Peres (site web personnel) . Évalué à 5.
J'avoue qu'avec le nombre de failles dans ce genre d'applis (Flash, Java), j'ai du mal à faire la différence ;)
Demander au userspace de faire de la sécurité, c'est se tirer une balle dans le pied. Je préfère l'approche du sandboxing de chrome. Demander au kernel de dropper des privilèges pour toujours!
[^] # Re: Sécurité dans la pile graphique
Posté par ckyl . Évalué à 5.
Le problème c'est qu'on ne comprend plus du tout de quoi on parle si on va part là. Vu la question posée à la base ainsi que son domaine il me semble très important de bien expliquer chaque partie, comment elles interagissent et l'état de l'art actuel.
Soit dit au passage il est très difficile à trouver pour Linux soit dit en passant. Pour Windows on peut se faire une idée là: https://media.blackhat.com/bh-us-12/Briefings/Sabanal/BH_US_12_Sabanal_Digging_Deep_Slides.pdf
[^] # Re: Sécurité dans la pile graphique
Posté par antistress (site web personnel) . Évalué à 1. Dernière modification le 26 octobre 2012 à 14:44.
J'ai trouvé ceci :
http://lists.freedesktop.org/archives/wayland-devel/2012-June/004078.html
Par contre j'avais lu qu'avec Wayland on pouvait ouvrir une fenêtre(*) transparente faisant tout l'écran qui permettrait d'écouter le clavier ?
(*) je ne suis pas sûr du terme, désolé je ne maîtrise pas le sujet
[^] # Re: Sécurité dans la pile graphique
Posté par reno . Évalué à 4.
Pas vraiment: avec Wayland (Weston en fait) tu peux effectivement ouvrir une fenêtre transparente qui couvrirait l'écran sans que l'utilisateur sans aperçoive puisque les décorations sont affichées par le programme donc tu n'aurais pas de fenêtre "bizarre" affichées a l'écran, après ça ne sert à rien car il ne suffit pas de recevoir les évènements souris/clavier il faut aussi les rediriger vers les applications "en dessous" autrement tes applications arrêtent de recevoir des évènements et donc de fonctionner, ce qui n'est pas très discret!
Et il me semble que Wayland/Weston n'a pas la fonctionnalité de redirection des évènements..
Maintenant comment ça va fonctionner pour les clavier "virtuels" avec Wayland, des applications qui doivent légitimement envoyer des évènements, là j'avoue que je ne sais pas..
Je vois 2 possibilités: Wayland vérifie que le programme qui envoient des évenements a des privilèges particulier (comment il peut faire ça??) ou bien les claviers virtuels font partie de Weston, mais ça n'est pas souple du tout..
[^] # Re: Sécurité dans la pile graphique
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 26 octobre 2012 à 17:17.
Ah ben ça c'est abordé dans la présentation de Martin Peres & Timothe Ravier à XDC2012 dont les slides sont ici (p 20-21) :
Proposal: a MAC framework
Mandatory Access Control
Suggestions
# 3D
Posté par Phibrizo (site web personnel) . Évalué à 4.
La vidéo de démo de Wayland est très impressionnante, je l'admet… le compositeur pourrait même devenir un jeu vidéo à lui tout seul (je vois bien un mini FPS où l'on pourrait "killer" les programmes au propre comme au figuré, mais je m'égare)
Concernant nouveau, j'ai bien conscience que la critique est facile et que l'art est difficile, mais quelle sont les raisons qui font que la prise en charge de la 3D progresse si lentement par rapport à celle de la 2D ? Est-ce que nvidia a délibérément compliqué l'électronique pour compliquer le travail de ceux qui voudraient faire de la rétro-ingénierie ?
Peut-on espérer un support de la 3D dans un futur relativement proche ou doit-on se résoudre à conserver les pilotes propriétaires pour les années à venir ?
[^] # Re: 3D
Posté par Renault (site web personnel) . Évalué à 6.
Ça semble pourtant évident, la 2D est quelque chose de bien plus facile à gérer par une carte graphique et du coup par les pilotes (moins d'instructions, de difficultés, moins besoin de puces pour calculer la 2D facilement par rapport à la 3D, etc.).
Je ne pense pas que nVidia fasse volontairement de la 3D plus difficile que la 2D à implémenter, naturellement ça l'est.
[^] # Re: 3D
Posté par antistress (site web personnel) . Évalué à 0. Dernière modification le 26 octobre 2012 à 01:44.
D'après ce qu'on peut lire les GPU NVidia sont inutilement complexes (sans doute comme les CPUs x86, obligés de se coltiner l'antériorité)
comparer :
https://plus.google.com/108010086967233476835/posts/iy21rLJfeCk
et :
http://www.phoronix.com/scan.php?page=article&item=arm_mali_reverse&num=2
[^] # Re: 3D
Posté par Renault (site web personnel) . Évalué à 6.
Comme tu le dis, le problème de nVidia vient sans doute du poids historique de ses composants et qu'il ne peut pas permettre de tous remettre à 0 comme le x86 qui est aujourd'hui un truc assez immonde, énergivore et peu efficace par rapport à sa réelle fonctionnalité. Cela explique le succès grandissant de ARM sur mobile, ARM ayant une architecture profitant des innovations techniques pour faire quelque chose de sobre mais puissant ce qui donne un meilleur rendement et une simplification des pilotes derrière.
[^] # Re: 3D
Posté par Martin Peres (site web personnel) . Évalué à 10.
Quand je disais ça, c'était pour la gestion d'énergie qui est compliquée pour pas grand chose. Je travaillais sur la gestion du ventilateur et voir que piloter
un moteur d'exécution est plus facile qu'un ventilateur, c'était surréaliste.
À contrario, 95% du design hardware d'NVidia est purement génial. On pousse quelques coups de gueules parfois car on a besoin de souffler un coup mais c'est en général justifié quelques années plus tard quand on comprend mieux les contraintes sur les ingénieurs NVidia. Pour les 5% restant, on a de grosses surprises et on se demande sous quelles drogues étaient les ingénieurs quand ils ont conçu ce matériel!
Cela dit, la 3D et les contrôleurs mémoire sont la spécialité d'NVidia et je peux vous assurer que ça se ressent dans le matériel! La 3D est relativement simple à implémenter du coté Nouveau maintenant qu'on a les briques de base. Comme je l'ai dit plus haut, ce qui manque maintenant, c'est le support dans Gallium des nouvelles extensions.
Non, Nvidia ne se coltine pas l'antériorité. Ils ont tout changé pour les Geforce 8 et, à ma connaissance, il n'y a plus rien à changer. Il faut juste rajouter le support des nouvelles instructions. Fermi a changé pas mal de choses, mais pas sur la 3D.
[^] # Re: 3D
Posté par ckyl . Évalué à 10.
C'est clairement la citation de la semaine. On voit souvent les gens tirer à boulet rouge sur des choses qu'ils ont juste survolées en méprisant les gens et leur travail, alors qu'avec un peu de recul et d'information supplémentaire on comprend le pourquoi. Quand c'est pas beau ou qu'on s'écarte du chemin de moindre résistance, il y a souvent une raison.
[^] # Re: 3D
Posté par reno . Évalué à 2.
Ca peut être un problème de performance?
Quand tu rajoutes des choses pour amméliorer la perf (par ex les RISC qui sont passés d'instruction 32bit uniquement au 16/32bit), ça complique la programmation..
[^] # Re: 3D
Posté par ahuillet (site web personnel) . Évalué à 2.
Ça semble évident mais ça ne l'est absolument pas !
Dans le temps il y avait dans les GPU du silicium dédié à un "moteur 2D", qui effectuait certaines opérations 2D. Aujourd'hui, la 2D se fait en général en utilisant le moteur 3D… donc au niveau driver on est pas vraiment sur quelque chose de plus simple.
[^] # Re: 3D
Posté par Laurent Carlier . Évalué à 0.
D'où l'intérêt du projet glamor
[^] # Re: 3D
Posté par Martin Peres (site web personnel) . Évalué à 5.
Oui et non. Glamor est plus là pour abstraire le driver et utiliser la seule API de programmation commune : OpenGL.
Luca Stach est plus intéressé par l'écriture d'un State Tracker Gallium pour permettre l'exposition de primitives plus adaptées à l'accélération 2D. Il a présenté son approche à l'XDC2012.
[^] # Re: 3D
Posté par antistress (site web personnel) . Évalué à 1.
Il y aussi Cairo-gl que Lucas n'aborde pas ?
[^] # Re: 3D
Posté par ahuillet (site web personnel) . Évalué à 3.
Réexprimer les primitives 2D en commandes 3D au niveau de l'API 3D, ce n'est pas optimal du tout. OpenGL n'a pas été conçu pour la 2D et tu vas forcément perdre pas mal en performance.
Les primitives 2D sont exprimées en commandes 3D au niveau du GPU, ce qui n'est d'ailleurs pas optimal non plus (mais ça économise du silicium, le nerf de la guerre quand on fabrique des GPU). L'idéal c'est d'adapter l'API 2D à la réalité du backend, pas de la transcrire bêtement en OpenGL.
C'est pour ca que des projets comme Glamor sont peu intéressants, c'est juste un processus de "migration", mais pas une bonne solution.
[^] # Re: 3D
Posté par antistress (site web personnel) . Évalué à 2. Dernière modification le 26 octobre 2012 à 16:24.
Tiens un développeur Nouveau ("inactif" ?) grenoblois :-)
Merci pour ce point, tu viens de me faire comprendre en quelques lignes ce que j'avais du mal à réaliser depuis un bout de temps, en assimilant un peu vite OpenGL avec les fonctions 3D des puces graphiques
[^] # Re: 3D
Posté par antistress (site web personnel) . Évalué à 1.
Un truc comme Direct-rendering with cairo (cairo-drm)
?
cf http://cworth.org/~cworth/papers/2009-LCA_Carl-Worth_Click-to-Pixel_Graphics-Stack-Tour.pdf (p11)
[^] # Re: 3D
Posté par Martin Peres (site web personnel) . Évalué à 8.
Hey hey, oui. Ça pourrait être marrant. Et pour une fois, les films seraient dépassés par la réalité!
À vrai dire, je ne comprend pas la question. Le support de la 3D est complet (à l'exception du support d'OpenGL 3.1+) du point de vue Nouveau. Ce qui traîne, c'est l'interface Gallium et l'implémentation de l'architecture nécessaire pour supporter les prochaines versions d'OpenGL. Du coté de Nouveau, on a des problèmes de performance à cause du code non optimal que l'on génère pour les shaders (si quelqu'un veut aider là dessus, il est le bienvenue!) mais surtout à cause du fait qu'on ne gère pas encore bien le changement de fréquence. Du coup, on est bloqué à des fréquences ridiculement basses ce qui limite énormément les performances.
J'y travaille mais c'est énormément de boulot!
Pour les cartes un peu vieilles (geforce 8/9), on devrait pouvoir se passer du blob assez rapidement si l'on a pas besoin énorme en performance. Pour les suivantes, le reclocking est une grosse inconnue.
[^] # Re: 3D
Posté par barmic . Évalué à 2.
Tu n'a jamais vu Tron ? Je te le conseil :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: 3D
Posté par Martin Peres (site web personnel) . Évalué à 2.
Si si, j'ai vu les deux :) Mais Tron, ça fait une analogie du monde électronique et système dans le monde "physique". Ça montre pas vraiment une interface faite pour l'utilisateur.
Je pensais plutôt à des trucs à la con comme dans Hackers :D
[^] # Re: 3D
Posté par med . Évalué à 2.
Est-ce que ce sont les seules limitations (les shaders et la fréquence) ou bien est-ce qu'il y a des optimisations non triviales en plus de ça ? J'ai une carte radeon (pas nouveau donc mais j'imagine que les problématiques sont similaires) plutôt bien supportée et les performances avec le pilote libre sont faibles par rapport à ce que je peux obtenir sous windows. J'ai aussi lu que les développeurs d'Intel ne veulent pas passer à Gallium entre autres parce qu'ils pensent que ça engendre une perte de performance trop importante (et ils ne veulent pas réécrire leur pilote).
[^] # Re: 3D
Posté par Xaapyks . Évalué à 7.
http://www.cs.unm.edu/~dlchao/flake/doom/chi/chi.html
[^] # Re: 3D
Posté par BAud (site web personnel) . Évalué à 4.
ou wolfotrack http://linuxfr.org/news/sortie-de-wolfotrack-10 (ainsi que psdoom et http://caia.swin.edu.au/urp/l3dge/tools/l3dgeworld_2.3/ cités dans la dépêche).
# Kafkaïenne
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Dans une des réponses, je lis « Kafakaesque ». Il me semble qu'on dit plutôt « kafkaïenne », en français…
[^] # Re: Kafkaïenne
Posté par Martin Peres (site web personnel) . Évalué à 2.
Désolé pour l'anglicisme. Je note.
[^] # Re: Kafkaïenne
Posté par Thomas Douillard . Évalué à 10.
Pas mal de dénoncer une faute d'orthographe sur un mot invoqué pour dénoncer une complexité énorme et parfois surréaliste de la bureaucratie tatillonnesque :)
[^] # Re: Kafkaïenne
Posté par BAud (site web personnel) . Évalué à 2.
Corrigé, merci.
# Nouveau : vraiment opérationnel
Posté par Pierre Jarillon (site web personnel) . Évalué à 8.
Sur ma machine principale, toujours en Mageia_1, j'utilise le pilote nvidia mais sur deuxième machine utilisée pour le traitement du son et de la video, j'ai laissé nouveau qui a été automatiquement installé par Mageia_2.
Vu que tout fonctionne bien, je n'ai pas envie de m'embêter à installer le pilote propriétaire qui le plus souvent refuse de fonctionner après une mise à jour.
Je viens de tester Mageia_3 version alpha_2 : Nouveau est impeccable, que ce soit pour la vidéo ou pour les effets de bureau de KDE.
En fin de compte, je suis ravi de réduire le nombre de programmes propriétaires sur ma machine. Maintenant que j'ai pu remplacer Acrobat Reader par Okular et le pilote Nvidia par Nouveau, il ne me reste plus que Flash à éradiquer. Je vais être patient et attendre que HTML5 fasse son œuvre. Mais il faudra vivre encore quelques années avec ce module indispensable si on veut avoir une machine pleinement fonctionnelle.
Un grand bravo et un grand merci à tous ceux qui on travaillé sur Nouveau.
[^] # Re: Nouveau : vraiment opérationnel
Posté par Martin Peres (site web personnel) . Évalué à 6.
Merci de la part de l'équipe de Nouveau. C'est bon d'entendre parler des gens chez qui c'est fonctionnel même si clairement pas grâce à moi (je bosse que sur la gestion d'énergie).
[^] # Re: Nouveau : vraiment opérationnel
Posté par Yth (Mastodon) . Évalué à 2.
Comme si la gestion de l'énergie ça ne servait à rien, tsss…
Bravo !
Yth.
[^] # Re: Nouveau : vraiment opérationnel
Posté par Martin Peres (site web personnel) . Évalué à 2.
J'ai pas dit ça, c'est juste que c'est pas encore vraiment automatique ni utilisé ;)
[^] # Re: Nouveau : vraiment opérationnel
Posté par cosmocat . Évalué à 3.
Tu veux entendre des remerciements!!! Ben en voilà!! ;)
Nouveau marche chez moi sans problème depuis plusieurs années.
Merci BEAUCOUP!
[^] # Re: Nouveau : vraiment opérationnel
Posté par Mali (site web personnel) . Évalué à 2.
idem, la GeForce 7300 de mon laptop ne me pose plus aucun problème depuis que j'ai basculé sur nouveau lors de son entrée officielle dans le kernel. Mais je n'ai aucun besoin particulier en 3D.
[^] # Re: Nouveau : vraiment opérationnel
Posté par Kioob (site web personnel) . Évalué à 4.
Un collègue n'utilise pas Nouveau, car il est impossible de rester dans la pièce tellement la ventilation de sa carte graphique est bruyante. Donc tes avancées devraient au contraire lui être plus qu'utiles !
alf.life
[^] # Re: Nouveau : vraiment opérationnel
Posté par Martin Peres (site web personnel) . Évalué à 2.
Comme tu dis, dans le futur ça sera utile! On y arrive ;)
[^] # Re: Nouveau : vraiment opérationnel
Posté par nud . Évalué à 2.
J'utilise pour ma part nouveau depuis au moins deux ans sur mon (vieux) T61 et sa NVS 140M. Avec gnome-shell ça fonctionne relativement bien, y'a juste des corruptions de textures de temps en temps qui forcent à réinitialiser X.
[^] # Re: Nouveau : vraiment opérationnel
Posté par Zylabon . Évalué à 4.
J'ai adopté nouveau avec fedora 15 si je me souviens bien.
C'était la première version qui me permettait de jouer à urban terror correctement (et je me suis du coup débarrassé du dernier blob de mon système).
Je suis tout à fait stupéfait par le fait que les performances du driver nvidia et nouveau soient comparable. Je me souviens d'une époque où il y avait deux ordre de grandeurs d'écart.
Chapeau ! Il ne manque qu'OpenCL du coup ?
Please do not feed the trolls
[^] # Re: Nouveau : vraiment opérationnel
Posté par Thomas Debesse (site web personnel) . Évalué à 4. Dernière modification le 28 octobre 2012 à 16:12.
Sauf qu'aujourd'hui c'est UrbanTerror le blob, depuis qu'ils ont migré d'ioQuake3 vers le SDK propriétaire. /o\
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Nouveau : vraiment opérationnel
Posté par Zylabon . Évalué à 1.
D'ailleurs il me semble que si le moteur
estétait libre, le mod lui ne l'était pas. Donc c'était effectivement pas le dernier.Please do not feed the trolls
# Nouveau sur une nvidia 9300MGS (Asus X71SL)
Posté par xcomcmdr . Évalué à 2. Dernière modification le 26 octobre 2012 à 12:25.
En regardant la Feature Matrix, je savais que c'était risqué, mais la curiosité l'a emporté.
(Linux 3.6.3-1 sous Archlinux 64 bits).
J'ai donc installé nouveau, nouveau-dri, et activé [Option "GLXVBlank" "true"] dans la config de Xorg, ainsi que [options nouveau msi=1] dans /etc/modprobe.d/nouveau.conf, viré le pilote proprio, activé nouveau dans /etc/mkinitcpio.conf et refait mon image initrd, et redémarré en priant. :p
Résultat :
- VDPAU ne fonctionne plus (c'était plus ou moins attendu)
- Une 2D qui plante moins (en tout cas j'ai bien les jeux en 320x200 de DOSBox qui prennent toute la largeur de l'écran en 1440x900 en mode plein écran, alors que le pilote nvidia a décidé de foutre le plein écran de DOSBox en 4:3 dernièrement. Et de ne même plus maximiser le plein-écran si j'utilise output=opengl au lieu de output=surface (une surface SDL) dans la config de dosbox. Juste WTF nvidia ? 1440x900 et 320x200 c'est le même rapport hauteur/largeur!)
- warsow qui tourne à 1 FPS - même pas le jeu en fait, juste l'écran de présentation de la dernière version qui a un arrière-plan en 3D (là aussi c'était plus ou moins attendu)
- Pas eu de plantage, si ce n'est un redémarrage qui a bloqué (en même temps j'utilise systemd en plus, j'suis un peu fou)
Finalement, ça s'est beaucoup mieux passé.
Rien que pour la 2D qui fonctionne mieux, je suis très tenté le garder (la 3D n'est pas le point fort de cette carte de toute façon). Par contre, VDPAU me sert beaucoup pour les films en HD (qui passent souvent mal sur le Core2Duo T5800…)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Nouveau sur une nvidia 9300MGS (Asus X71SL)
Posté par xcomcmdr . Évalué à 2.
j'oubliais dans les paquets installés : libgl, et xf86-video-nouveau
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Nouveau sur une nvidia 9300MGS (Asus X71SL)
Posté par Martin Peres (site web personnel) . Évalué à 2.
Hey hey, il te manque nouveau-dri pour avoir l'accel 3D. Actuellement, tu utilises ton CPU (swrast ou llvmpipe), donc ça ira pas vite :)
Pour vérifier, tu peux faire: glxinfo | grep "OpenGL vendor string".
[^] # Re: Nouveau sur une nvidia 9300MGS (Asus X71SL)
Posté par xcomcmdr . Évalué à 2.
Si si il était bien installé lors de mon test. :)
De nouveau sous nouveau (heu…) :
En fait, warsow tourne entre 10 et 16 FPS (entre 30 FPS - beaucoup d'action - et 60 FPS - on regarde le sol - pour le pilote nvidia), avec le son qui est très très haché et lent. M'enfin pour un pilote qui est tout nouveau (heu…), c'est très impressionnant ! J'avais aussi absolument aucun bug graphique.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Nouveau sur une nvidia 9300MGS (Asus X71SL)
Posté par gnumdk (site web personnel) . Évalué à 1. Dernière modification le 26 octobre 2012 à 18:10.
Pareil pour moi: Archlinux, et openarena se lance bien mais j'ai un écran noir… Pourtant derrière, les menus fonctionnent vu que j'arrive à trouver la sortie du jeu :)
NVIDIA Corporation G94 [GeForce 9600 GT]
[^] # Re: Nouveau sur une nvidia 9300MGS (Asus X71SL)
Posté par Martin Peres (site web personnel) . Évalué à 2.
je serai bien intéressé par ton install. Ça me semble étonnant quand même. Tu peux mettre sur pastebin la sortie de "$ LIBGL_DEBUG=verbose glxinfo"? Je doute que nouveau-dri soit installé/utilisé.
[^] # Re: Nouveau sur une nvidia 9300MGS (Asus X71SL)
Posté par gnumdk (site web personnel) . Évalué à 1.
http://paste.kde.org/582674/
[^] # Re: Nouveau sur une nvidia 9300MGS (Asus X71SL)
Posté par Okki (site web personnel, Mastodon) . Évalué à 2.
Du temps d'Ubuntu 12.04, j'utilisais les drivers propriétaires nVidia. Tout était fluide, rien à redire. Lors du passage à la version 12.10, que ce soit sous Unity ou Gnome Shell, tout était lent, hyper poussif, avec X qui se mettait à consommer énormément de CPU. Ça semble correspondre au bug suivant
https://bugs.launchpad.net/ubuntu/+bug/1067432
J'ai dégagé les drivers propriétaires pour mettre Nouveau 1.0.2 et, oh joie, j'ai enfin retrouvé ma fluidité d'antan. Et ce, y compris sur les vidéos HD, aussi bien 720p que 1080p, alors que je ne possède pourtant pas du matos dernier cri
VGA compatible controller: NVIDIA Corporation GT216 (GeForce GT 220) (rev a2)
Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz
Un grand merci à l'équipe de Nouveau
# Contribuer
Posté par jihele . Évalué à 10.
Bon, comme tout le monde, merci de fournir un truc libre et qui marche bien !
Histoire de renvoyer l'ascenseur, on est tenté de regarder comment contribuer.
Tâches à accomplir
Pour ceux que ça intéresse, il y a une page TODO for newcomers, avec des tâches en documentation / communication, développement et reverse engineering.
En cherchant dans un vieux message, j'ai retrouvé les liens suivants :
https://github.com/pathscale/pscnv/wiki/TestingTimings
http://nouveau.freedesktop.org/wiki/PowerManagementDumps
https://github.com/pathscale/pscnv/wiki/PM_memory_timings
https://github.com/pathscale/pscnv/wiki/TestingTimings
Il n'y a pas de lien direct depuis la page TODO. Parce que les données en question ne sont plus utiles ?
C'est bien fait, ces pages, parce que ça permet d'essayer seul de voir ce qu'on peut produire, et de contacter l'équipe uniquement si on pense que c'est pertinent.
Maintenant, si je prends par exemple en reverse dans la page TODO :
- Improve the current temperature vbios parsing. Possible mentor: mupuf.
- Find where is the max brightness in the vbios. Possible mentor: mupuf
Martin, si on veut participer, on doit nécessairement te contacter ? Avec le risque de te faire perdre ton temps si ça se révèle trop compliqué ? (Et donc le risque inverse de ne pas oser déranger de peur de pas suivre derrière.)
Existe-t-il une page qui explique comment faire ces choses-là ?
Avancement par famille de cartes
Un autre truc bien serait d'avoir un état actuel de la connaissance, pour savoir sur quelles cartes les infos sont utiles. Peut-être que ça existe déjà et qu'il manque plus que le lien en page TODO.
On en a parlé la semaine dernière au L@BX et tu me disais que par exemple, sur la famille nv92, vous aviez (à peu près ?) tout donc je pouvais pas faire grand chose de bien utile.
Et si ça plante ?
Par ailleurs, que faire en cas de plantage ? Il m'arrive, bien que très rarement, d'avoir un freeze. A ce moment, là, j'aimerais faire quelque chose pour que ça ne se reproduise pas, ici ou ailleurs. Je ne suis pas certain que ce soit nécessairement lié à X ou à nouveau. Comment savoir si ça peut être le cas (quels indices ?). Quelles sont les infos utiles à remonter quand ça arrive (quels logs ?). Même si c'est plutôt à remonter au bugtracker de la distro, autant donner toutes les bonnes infos.
En bref, quelque outils pour donner des pistes très simple à celui ou celle qui veut modestement et ponctuellement aider sans nécessairement appartenir à la communauté de contributeurs (et qui sait, une fois qu'on a mis le pied dedans…).
A plus.
# Merci !
Posté par kursus_hc . Évalué à 3.
J'en profite pour remercier chaudement Martin et tous les contributeurs de Nouveau. Habitué des cartes nvidia, j'utilisais les pilotes proprio depuis des années quand un bug m'a forcé à passer temporairement sous Nouveau. C'était il y a deux mois, et je pense que je ne repasserai plus jamais aux pilotes proprio.
Ma carte chauffe carrément moins, le ventilo est bien mieux géré (j'ai ENFIN un pc silencieux) et la 3d, pour le peu que je m'en sert, fonctionne très bien. Bref que du bonheur.
Alors bravo et merci !!
[^] # Re: Merci !
Posté par gnumdk (site web personnel) . Évalué à 2.
Oui, effectivement, sur l'ancien pc de mes parents avec le driver nvidia, le ventilo était toujours à fond… Mais bon, c'est la seul machine ou j'ai vu cela…
[^] # Re: Merci !
Posté par Martin Peres (site web personnel) . Évalué à 10.
Hmm, on a pas encore de gestion du ventilateur. Je te conseille de regarder la température de ta carte ($ sensors) avant qu'elle ne fasse une combustion spontanée.
[^] # Re: Merci !
Posté par R. Danell Olivaw . Évalué à 1.
Question bête : sur une carte (une 8800 gt en occurrence) où le ventilo d'origine à été remplacé par un système passif, est-ce-qu'utiliser le pilote nouveau peut être risqué ?
[^] # Re: Merci !
Posté par Martin Peres (site web personnel) . Évalué à 2.
Non, pas du tout risqué ;)
[^] # Re: Merci !
Posté par R. Danell Olivaw . Évalué à 4.
Je vient de tester, nouveau a fait beaucoup de progrès depuis la dernière fois où j'ai essayé.
De ce que j'ai testé, le compositing Kwin marche très bien, Doom3, en natif, fonctionne bien ; les perfs sont plus que correctes.
Par contre, Diablo3, via wine, ne se lance pas (problème de carte qui n'a pas les capacités nécessaire) ; je n'ai pas eu le temps de chercher plus avant, je ferais d'autres essais ce week-end.
Voila pour mon retour.
[^] # Re: Merci !
Posté par kursus_hc . Évalué à 2.
Ok je suis à 70° avec nouveau, soit la même chose que via les drivers proprio + ventilo à fond (au passage nvidiasettings classe cette température dans "attention c'est bientôt limite" mais je n'ai jamais réussi à descendre en dessous, même en dépoussiérant la carte).
Que faut-il en conclure exactement ?
[^] # Re: Merci !
Posté par antistress (site web personnel) . Évalué à 2. Dernière modification le 29 octobre 2012 à 14:18.
que dans Linux 3.7 tu auras la gestion manuelle du ventilo (à l'utilisateur de définir la vitesse de rotation), et plus tard la gestion auto si tout va bien
[^] # Re: Merci !
Posté par kursus_hc . Évalué à 4.
Je parlais d'une conclusion opérationnelle et pas d'un enfonçage de porte ouverte, si on me dit "attention avec nouveau tu vas cramer ta carte" j'aimerais bien connaître les cas où il fait bon l'utiliser.
[^] # Re: Merci !
Posté par freem . Évalué à 4.
"les cas où il fait bon l'utiliser. "
En hiver?
Perso, le pilote nouveau me va bien:
_ support de randr
_ pas de config Xorg à faire (en tout cas sous debian)
Seul "bémol" impossible d'utiliser 2 cartes branchées en même temps (cela dis, c'est précisé sur le site officiel) et il me semble que les jeux 3D soufrent d'une perf moindre, mais pas testé depuis longtemps avec NVidia et/ou windows.
Vu le peu de temps ou je joue à des jeux 3D, je préfère le confort d'un WM qui marche à celui de jeux qui carburent (en attendant les deux en simultané peut-être?).
Et puis tant qu'openMW arrive à fonctionner, donc ça me va.
En tout cas, merci bien à l'équipe de dev.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.