Martin Peres a écrit 413 commentaires

Hey hey, je précise car la dernière fois, j'avais explicitement demandé de ne pas publier mais quelqu'un l'avait quand même fait (conférence toulibre 2012).

Si c'est concernant la gestion de l'énergie, on y travaille encore et toujours. J'y bosse pas trop moi là car je suis en déplacement pour quelques mois, mais j'ai écrit un papier sur ça qui devrait être publié à OSPERT13 la semaine prochaine. Je posterai un journal sur ça :)

Ah, les proceedings viennent juste d'être publiés. Je vais pas tarder à publier ça sur mon site puis faire une annonce.

<!> Personne poste sur lien en journal/dépêche sur LinuxFR, je m'en charge dès que je suis prêt!
http://ertl.jp/~shinpei/conf/ospert13/OSPERT13_proceedings_web.pdf (diapo 36, Reverse engineering power management on an NVIDIA GPUs - Anatomy of an autonomic-ready system).

je reste sur ma fin au niveau des évolutions du pilote nouveau…

Ah ben ouais, elle est pas terriblement excitante cette release. Cependant, y'a des trucs cool qui arrivent dans mesa qui ont besoin de ce kernel (compteurs de performances et OpenCL).

Si c'est concernant la gestion de l'énergie, on y travaille encore et toujours. J'y bosse pas trop moi là car je suis en déplacement pour quelques mois, mais j'ai écrit un papier sur ça qui devrait être publié à OSPERT13 la semaine prochaine. Je posterai un journal sur ça :)

Je suis sur le 3.10-rc7, et en effet, la mise en veille ne passe plus par un tty. C'est assez sympa.

Quand au boot, j'ai pas fait attention si y'avait un autre modeset car kwin prend 3 plombes à se lancer sur ce laptop et commence par un écran noir.

Y'a des fonctions de cryptage dans certains GPUs pour pouvoir décoder des flux vidéos. Je suppose qu'il serait théoriquement possible de faire un truc pour autoriser un fabriquant à lire des vidéos. Mais comment le rendre par personne, je vois pas d'autre moyen que d'avoir un couple de clé privé/publique dans la carte graphique que l'on enverrait au serveur de vidéo pour qu'il nous retourne un fichier crypté avec notre clé publique et donc, seulement décodable par notre carte graphique…

Mais bon, on pourra toujours récupérer toutes les images décodées car c'est impossible de protéger ça, alors ça sert à rien :s

Me semble déconnecté de la réalité. lisp, perl, python, ruby, java, (o)caml, haskel,… ont 15 ans pour les plus jeunes et plus de 50 ans pour le plus vieux. Je n'ai pas mémoire de langage un peu notable qui ai disparu.

Je suis globalement d'accord pour cette liste (qui ne contient aucun langage propriétaire et qui ne contient pas non plus Ada), mais qu'en est il de Delphi, Visual Basic, Action Script ou encore Quick Basic ? Que je sache, ces langages ont été très utilisés et ont (bien heureusement) majoritairement disparus (Action Script est en voie).

Et pour le coup cette manie d'apprendre des langages plutôt qu'apprendre à programmer me semble poser bien plus problème que le mal qu'à pu faire basic ou je ne sais quel langage.

"C'est quoi cette manie de vouloir apprendre une langue avant de savoir bien s'exprimer"? C'est utopique de croire qu'on peut apprendre à programmer sans apprendre plusieurs langages et les étudier. Apprendre à programmer, c'est pas connaitre 3 mots clés, les boucles, les fonctions et basta. Apprendre à programmer, c'est la complexité algorithmique, c'est du génie logiciel et c'est comprendre les choix possibles avant même d'avoir à le faire choix. Ça demande majoritairement de l'expérience et c'est en forgeant qu'on devient forgeront. Par contre, je suis tout à fait d'accord avec toi pour dire que les gens qui apprennent un ou deux langages et qui s'y limite, c'est pas comme ça qu'ils vont s'améliorer et devenir de meilleurs programmeurs.

Mais quoi qu'il en soit c'est à mon avis triste d'imaginer qu'on apprend un langage pour faire carrière avec derrière (que ce soit au bac, en IUT, en Fac ou en école d'ingénieur). Tu utilise le bon langage point (celui qui est adapté à ce que tu fait et aux contraintes du projet). Le reste c'est de queues de cerises. Se focaliser sur le langage c'est un problème de geek dans son garage, c'est rigolo parce que c'est du troll, on se sent mieux parce qu'on se démarque ou on a l'impression d'appartenir ou pas à un groupe, mais très franchement OSEF.

Je trouve cette logique totalement contraire à ce que tu indiques. C'est totalement une idée de geek que se dire qu'il faudrait toujours utiliser le langage le plus adapté pour le projet ou la tâche à faire. Dans la vie, tu changes de langues plusieurs fois par jours? Non, car les autres en face aussi doivent avoir la même aisance que toi dans ces langues. Et puis à baragouiner 10 langues, comment tu peux savoir quel langage est le plus adapté à quelle tâche vu que tu en maîtrise au final aucun? Je caricature à peine d'après certains ingénieurs que j'ai rencontré. Bon, si tu codes h-24 depuis 10 ans, tu as moyen de commencer à avoir une bonne maîtrise de 4-5 langages, ça reste peu. Et, pour finir avec ce point, tu fais quoi si ton projet change de direction? Tu recodes dans un autre langage? Au final, ta logique marche si tu prends en compte que tu es seul et que ton projet est un hack et pas quelque chose que tu vas devoir maintenir et faire évoluer potentiellement dans des directions opposées.

Personnellement, dans mon travail, j'utilise plusieurs langages et c'est rarement mon langage de choix (C++ avec ou sans Qt). Au contraire, je dois m'adapter aux gens en face et utiliser ce qui permettra à tout le monde d'être le plus productif possible tant que ça ne rentre pas en conflit avec les contraintes du projet. Ça me blase souvent car je ne peux pas exprimer pas mal de ce que je pourrai en utiliser le C++, mais je fais avec (en jurant pas mal quand même).

Je suis aussi totalement pour le fait d'apprendre des langages pour apprendre des façons de penser différentes. Mais au final, y'a un coeur de langages communs, qui a généralement son sens suivant le niveau d'abstraction que l'on veut avoir. Et puis, ces langages sont généralement pas trop restricteurs. Pourquoi ne pas mettre l'accent sur eux alors? C'est pas le rôle de l'éducation de donner un socle commun aux gens? C'est pas avec des langages de niche que ça va marcher, il faut des langages généralistes.

Ah ? N'importe qui peut écrire un programme en C qui fasse quelque chose. Pas forcément ce qui était prévu, mais quelque chose.

Si t'apprend pas la rigueur à l'école, tu l'apprendras quand ? Le C doit être un des rare langage qui te permette de comprendre entièrement ce que tu fais. Pour les plus doués, ça va jusqu'à savoir exactement où vont les données en mémoire et le code généré.

Quand on apprend, c'est important de comprendre ce qu'on fait et ce que la machine fait. Ce n'est que mon avis, mais l'objectif de la formation est de redonner le contrôle à l'utilisateur, donc autant choisir un langage qui permet de comprendre tout depuis le début.

Le C est plus simple conceptuellement car il ne cache rien. En ce sens, il est un bon outil pédagogique. Par contre, son problème est qu'on mélange les concepts algorithmiques avec "le détail d'implémentation/gestion de la mémoire". Ça me dérange pas trop cela dit car l'algo peut être étudiée sur papier puis ensuite traduite sur machine.

Il me semble impensable de former des étudiants à des langages haut niveaux car ils ont aucune chance de tenir dans le long terme. Le C est un standard qui est vieux et qui ne va jamais disparaître car il fait exactement ce qu'il est sensé faire, abstraire le langage machine.

Après, je pense qu'il faut se dire que l'objectif ici n'est pas d'apprendre un langage pour aller bosser direct après le bac. Le but c'est de donner une culture et une façon de penser.

Mais est-il envisageable (techniquement du moins) que SELinux soit étendu pour faire ce genre d'analyse ? Ou est-ce que ça n'a rien à voir ?

Linux isole déjà les processus entre eux. On peut ensuite partager la mémoire avec SHM et les droits Unix ou SELinux peuvent choisir qui a le droit d'y accèder.

Pour ensuite faire du contrôle d'accès d'un process à sa propre mémoire et utiliser le contrôle d'accès SELinux, ça a été le sujet de mon mémoire de master. La réponse est oui, c'est possible et non c'est pas trop lent. Mais y'a encore un bon paquet de boulot pour bien comprendre la gestion de la RAM dans Linux pour garantir que ça marche.

elle est très performante mais plus cher, mais je l'ai gagné :p

Oh JMax le crâneur ;)

Cela dit, y'a de quoi être fier, c'est une tuerie cette carte!

*On doit dire GNU/Linux et non pas seulement Linux car Linux désigne le noyau du système complet qui contient également des outils du projet GNU.

Je me demande vraiment combien de pour-cent de logiciels GNU on utilise maintenant sur nos machines. Personnellement, du kernel à kde en passant par systemd, il ne reste guère que grub, gcc et les libs très bas niveau que j'utilise encore.

Du coup, si je devais dire à chaque fois, j'utilise GNU/Linux/KDE/Systemd/X.org/etc…, on s'en sortirait pas!

Une opinion?

D'accord, mais qui est concerné ?

Dur à dire, mais je te conseille d'envoyer cette capture d'écran sur #dri-devel et de demander si ils connaissent le bug. Cela dit, j'en doute car j'ai rien sur la mailing list dri-devel. Ensuite, faudra remplir un bug report.

Pour les versions, je suis sous Arch et ce problème existe depuis que je l'ai essayé (je n'y ai jamais vraiment joué vu que je ne dépasse pas les 20FPS sous Linux).

Très bien, déjà t'es à jour.

Je me demandais, les glitchs graphiques dans un jeu, c'est dû à un bug/quelque chose de non implémenté dans mesa, ou dans les drivers de mon chipset graphique (une ATI Radeon Xpress 1150, avec ati-dri et xf86-video-ati) ?

C'est un bug, oui. Met à jour pour utiliser les dernières versions de tout et si le problème persiste, contacte les devs (bug report ou IRC).

Il n'y a pas de ponts entre les équipes des pilotes Intel, Radeon et nOUVEAU?

Si si, le code est partagé au maximum. Enfin, à part Intel qui refuse de bosser sur Gallium, mais c'est une autre histoire.

Mais quand je dis qu'il n'y a qu'un seul développeur à travailler sur mesa/nouveau, je veux dire qu'il n'y a qu'une personne qui bosse sur le support de la 3D pour les cartes nvidia (et il est étudiant en physique). Il écrit le code des compilateurs qui transforment la représentation intermédiaire gallium en code machine pour les cartes et gère le runtime ((sous-)allocation de buffers, fences, etc…).

Il a fallu attendre tes récentes initiatives et le coup de balais Wayland pour y voir quelque chose.

Je dirai plutôt que c'est la modularisation du serveur X qui a rendu tout ça possible. Ça reste un énorme sac de noeud mais on avance! Quant à mes interventions, elles ne me permettent juste que de voir à quel point j'ai encore rien compris… Pour info, si ça t'intéresse, les présentations faites par les "X-men" à LCA cette année sont vraiment excellentes!

Martin : dommage que ça n'ait pas été documenté !

Je sais… Mais comme presque tout mesa/nouveau est développé par une seule personne, je vais pas trop lui en vouloir si en plus il documente pas tout ce qu'il fait…

Faudrait vraiment que quelqu'un vienne l'aider!

Ce n'est pas terrible si la mise à jour corrige des failles de sécurité (surtout si on est pas disponible le weekend suivant).

Qui a besoin d'un serveur SQL aussi complexe de Postgre sur un desktop user ;) Et puis, si c'est le cas, ça veut probablement dire que le service est pas accessible de l'extérieur alors bon… Je trouve que passer à un système "stable" a bien plus d'inconvénients que ce petit problème surtout que c'est pas tout rose niveau sécu chez eux (tout le monde a les mêmes versions de tous les logiciels).

Bon cela dit, faut qu'on arrête de dériver là, on est loin de mesa ;)

Personnellement, ça doit m'arriver une ou deux fois par semestre de devoir changer la configuration d'un programme à cause d'un changement de version majeure. Et c'est souvent uniquement à cause de Arch.

D'ailleurs, en 2012, y'a eu de gros changements dans Arch et j'ai été étonné de la stabilité! (Grub2, merging de /(bin|lib) et /usr/(bin|lib) et systemd. C'est d'ailleurs la seule année où j'ai dû prévoir des mises à jour sur mes systèmes car elles pouvaient potentiellement mal se passer.

Si un projet est bien fait, il est rétro-compatible avec ses anciens fichiers (ça me semble le minimum). Parfois, on a des petits messages qui nous conseille de mettre à jour telle ou telle chose mais ça s'arrête généralement là et tu peux te permettre de repousser ça au week end.

Cela dit, j'ai un contre exemple, le projet PostgreSQL qui est une usine à gaz pour faire le changement de version. La solution est d'empêcher ses mises à jour (en le marquant dans la liste des paquets à ne pas mettre à jour). Quand une nouvelle version sortira, pacman affichera un joli warning et tu peux attendre le week end pour faire ta mise à jour.

Un autre point qui n'a pas été documenté est le support d'OpenGL 3.0 pour la famille nv50 des cartes nvidia. Cela met le driver mesa nv50 à parité avec le driver nvc0.

Je n'ai pas d'infos sur ce qu'il manque à faire pour supporter OpenGL 3.1 sur Nouveau.

Vous êtes en retard :o

Si je me souviens bien, le ~ indique que le paquet est pour l'instant masqué, c'est ça? Si c'est le cas, l'équivalent dans Arch, ce sont les repos [testing] et [community-testing]. Mesa 9.1 est dans [testing] depuis hier.

Quand y'en a assez d'attendre, y'a les Rolling Release. :)

Ah mais non, tu comprends, c'est "instable" ;)

Franchement, je comprend l'intérêt de debian dans le monde des serveurs ou en entreprise mais pour le desktop personnel, si on a assez de connaissance pour maintenir une debian, on en a assez pour maintenir une Arch. Et Arch, c'est bien assez stable par défaut et c'est surtout à jour.

/me sent qu'il va se faire moinsser par ceux qui ont jamais testé Arch et qui font que répéter la doctrine des distros non-rolling-release.

Diantre! Je comptais utiliser Nouveau à partir de Linux 3.8, mais je pense que je vais attendre la 3.9. :/

Désolé, c'est un peu de ma faute mais c'est aussi dû au fait que j'ai pas réussi à convaincre le mainteneur de la stabilité de mon code. Du coup, il a maturé durant quelques mois sur notre branche perso et a eu quelques corrections de bugs, notamment pour les nv40 :)

J'espère que cela donnera la visibilité et le succès que le projet mérite. Et n'oubliez pas de les aider en utilisant REnouveau.

Pitié, faut oublier REnouveau. On a en plus besoin depuis des années :)

Désolé pour le retard, j'avais totalement zappé de te répondre.

C'est clairement sous optimal avec un GPU discret, donc il faut forcement garde le chemin avec xshm pour ce cas la.

Non, c'est faux. On a uniquement besoin de xshm pour les applications qui n'utilisent pas le GPU ou la pile graphique pour rendre son buffer. Les autres GPUs doivent utiliser GEM pour allouer et partager leurs buffers graphiques.

Et j'economise aussi de la batterie a reste en soft quand je code, car au lieu de redessiner tout l'ecran, il ne met a jour qu'un tout petit coin.

D'après mon expérience, avec un compositeur software, quand je bouge une fenêtre, mon PC consomme 30W contre 9W en hardware. Tu parles de pas faire de copies tout le temps, mais un compositeur sw fait ça en permanence…

Je te conseille vraiment d'étudier xdamage, ça devrait te prouver que tu as une mauvaise vision des flux entre les applications et X.

Parce que la majorite des drivers OpenGL ne sont pas capable de tenir un mois sans cracher en faisant du compositing ?

Je trouve que tu as tendance à inventer des chiffres comme bon te semble, je me trompe? Si ton compositeur plante, met à jour ta distro car ça fait un bon moment que ça n'a arrive plus à part avec Nouveau si la carte est mal supportée.

Sinon de nos jours, c'est les GPU discrets qui sont en "voit" de disparition face au GPU a memoire integre. Comparer le nombre de Linux dans un cas et dans l'autre est d'ailleur assez vite fait ! Plus d'un million sont active par jour avec une memoire partage… Et Wayland ainsi que le futur de Linux se trouve dans ce domaine la, donc il faut que ce cas soit optimisable.

Le développeur principal de Wayland travaille chez Intel, tu crois vraiment qu'il ferait un truc pas utilisable sur leur plateforme? De plus, Wayland a pour cible l'embarqué qui a une mémoire partagée. Je suis désolé, mais Wayland est ce que l'on peut faire de plus optimal sans faire de partage de framebuffer (à la DRI1 où les applications faisaient elles même le rendu sans passer par le compositeur).

Le canvas des applis QT/QML peut utiliser OpenGL, même si les applis ne sont qu'en 2D.

Qt/QML sait aussi faire de la 3D et la mixer avec la 2D. Mais qu'on soit clair, allouer un contexte OpenGL sur la carte graphique pour rendre une appli 2D, c'est une grosse connerie. Le context switching sur une carte graphique, c'est rarement contrôlable (implémentation hardware) + très lent (plusieurs centaines de Ko de contexte à quelques Mo si on veut du vrai préemptif)! Et c'est sans compter la limite hardware sur le nombre de contexte.

Nous sommes en train d'étudier la solution à ce problème dans Nouveau et c'est pas mignon!

Xshm te donne une position et une taille, donc il y a bien une copie a ce moment la.

SHM ne nécessite pas de copie en soit. C'est juste du partage de pages mémoire physiques. Du coup, je suis pas sûr de saisir ce que tu veux dire.

Si tu as un GPU discret (discrete GPU ?), c'est effectivement une bonne chose de ne pas reuploader toute ta fenetre et de t'appuyer sur un DMA pour faire la copie.

On est d'accord.

Par contre, si tu es sur la meme memoire, cas des SoC et de Intel, il vaudrait mieux completement eviter le DMA en accedant directement a la surface video. La plupart des SoC et Intel supporte de faire les operations depuis une surface non tile/compresse avec une faible perte de performance qui dans la pratique devient un gain du fait de l'absence de copie et de cas de rendu direct (pas de compositing, car fenetre au dessus ou plein ecran).

C'est assez étonnant d'entendre parler de SoC Intel car la mémoire est toujours séparée, tout comme le chipset et les deux sont toujours indispensable. Du coup, c'est pas vraiment un System On Chip. Je suppose que tu fais un abus de langage SoC/puce.

Alors, je suppose que tu as dans l'idée d'avoir un compositeur software (pour une raison qui m'échappe). Tu veux donc pouvoir récupérer les données depuis le GPU. Dans le cas d'un GPU discret, tu dois récupérer le buffer depuis la VRAM en programmant la GART (soit en laissant le CPU accéder à la VRAM via la GART, soit en demandant au GPU de copier le buffer dans la RAM ce qui est bien plus performant!) puis tu peux faire ton compositing comme bon te semble mais avec une mémoire lente un processeur pas du tout parallèle. Dans le cas d'un GPU intel, le CPU peut directement bliter le buffer de l'application sur le framebuffer. Si l'application est en plein écran, elle peut directement rendre dans le framebuffer (attention à ne pas faire rendre toutes les applis dans le fb directement car sinon, on retrouve la merde de DRI1).

Cela dit, il faut une collaboration entre le driver GPU et le CPU pour pouvoir faire ça. Mais au fond, tu veux en venir où? Ce que tu proposes est sous optimal dans pratiquement tous les cas, et ne change rien dans d'autres (GPU avec mémoire partagée only).

Par contre, ton point sur Wayland m'ennuie. Je sais que la partie rendu soft n'est pas vraiment au point (quid d'une appli OpenGL avec un compositing software par exemple). Mais bon, dans le pire des cas, tu dois pouvoir utiliser l'api EGL en maintenant le rendu en soft pour obtenir le meme resultat, non ?

C'est parfaitement possible de mixer le rendu logiciel et hardware. Cela dit, avoir une appli accélérée mais un compositeur software, ça me semble stupide. Tu as un cas en tête?

Tu pinailles, à part glamor, personne n'utilise opengl uniquement pour la 2D. Mais oui, tu as raison.