Martin Peres a écrit 413 commentaires

D'où l'intérêt du projet glamor

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.

Tu n'a jamais vu Tron ? Je te le conseil :)

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

Bonnes nouvelles! Tiens nous au courant!

Comme si la gestion de l'énergie ça ne servait à rien, tsss…

J'ai pas dit ça, c'est juste que c'est pas encore vraiment automatique ni utilisé ;)

Un grand bravo et un grand merci à tous ceux qui on travaillé sur Nouveau.

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).

NVIDIA doesn't know how to design simple hardware.

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.

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é)

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.

Désolé pour l'anglicisme. Je note.

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).

Hey hey, oui. Ça pourrait être marrant. Et pour une fois, les films seraient dépassés par la réalité!

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 ?

À 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!

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 ?

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.

Merci Loïc. J'avoue ne pas te suivre sur "ce qui se prépare sur Bordeaux". J'ai raté quelque chose ?

Merci, on s'amuse comme on peut ;)

Oui, vivement Wayland pour corriger tout ça!

Voilà la fameuse démonstration. Tout y est bien expliqué!

Je vous conseille de regarder la vidéo en entier! C'était une des meilleures conférences de l'XDC.

git peut très bien gérer ça ;)

http://bogdan.org.ua/2011/03/28/how-to-truncate-git-history-sample-script-included.html

Je suis un grand fan de git. Ça me permet d'accéder à mes données de partout et de gérer les versions et conflits de versions. Cerise sur le gateau, ça réplique :) C'est parfait!

C'est pas totalement vrai non plus. Tout n'est pas documenté et je suis pas sûr que toutes les générations soient documentées.

Alors, j'en ai discuté avec quelques personnes de la board X.org et la fondation est prête à financer des étudiants via le programme X.org Endless Vacation of Code.

Pour l'instant, seule une personne a profité de ce programme. Si vous êtes intéressés:
- http://www.x.org/wiki/SummerOfCodeIdeas
- http://www.x.org/wiki/XorgEVoC

Comme vous pouvez le voir, je propose de mentorer deux sujets, si vous êtes intéressés par bosser sur Nouveau, vous savez qui contacter ;)

Tu confondrais pas avec la brève sur OpenGL 3.0 ?

Si, maintenant, je comprend mieux, merci :D

Pour plus d'informations sur pourquoi le driver nv50 n'a pas OpenGL 3 dans mesa 8.0, c'est simplement car on est en plein milieu d'une ré-écriture de libdrm-nouveau et que c'est le driver nv50 qui vérifie le bon fonctionnement. Du coup, les patchs pour fixer OpenGL 3 sont mélangés avec le portage du driver vers la nouvelle lib.

Les slides de la fosdem2012.

En tant que dev nouveau, je suis étonné de voir que le support de wayland sur les geforce 8+ n'est pas disponible.

Il me semble bien que ca marche, j'avais teste ça il y a un an. Quelle source dit que Wayland ne tourne pas sur toutes les cartes récentes ?

Sinon, pour le driver Lima, l'impulsion vient de Luc Verhaegen, pas de codethink qui fourni "uniquement" une source de financement si je me souviens bien.

Quoi qu'il en soit, il faut espérer que ARM prenne le support du driver à sa charge.

C'est ce qui m'a poussé à bosser sur Nouveau alors que je refusais d'avoir une carte graphique nVidia.

Quand mon école m'a donné un ordinateur portable, j'ai pas eu le choix, il a fallu coder.

Les infos secrètes sur le contenu de la X.org devroom, shuuuuuut!

Plus sérieusement, la composition date d'il y a 1 semaine, mais ça ressemblera à un truc comme ça. Le numéro correspond à l'ordre d'arrivé des propositions de talks.

01: Martin Peres and Lucas Stach : Nouveau: Recap, on-going and future work
02: Alon Levy : Xspice
03: Chris Wilson : Cairo
04: Kai-Uwe Behrmann : Colour Management in Compositors [DÉPLACÉ]
05: Daniel Vetter : DRM/KMS
06: Jesse Barnes : DRM/KMS Planes
07: Luc Verhaegen : ARM graphics drivers
08: Robert Bragg and Neil Roberts : Adapting Mutter into a Wayland Compositor
09: Daniel Stone : Input Methods
10: Eric Anholt : Intel userland
11: Francisco Jerez : OpenCL
12: Robert Bradford and Kristian Hogsberg : Wayland Q & A for toolkit developers

Le planning devrait être disponible durant le week end. Luc Verhaegen qui s'occupe de l'organisation est très satisfait d'avoir rempli tous ses slots disponibles.

Je pense ne pas trop m'avancer en disant que cette édition accueillera un nombre conséquent de développeurs X et pas les moins connus (Keith Packard, Kristian Høgsberg, Luc Verhaegen, Jesse Barnes, Daniel Stone, Eric Anholt et probablement plus encore).

Le bug de sécu a été fixé dans ArchLinux:
https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xkeyboard-config&id=a1bb8eb3bcdcdcbe79e5efc0f6a631fc83409882

Comme je disais, je ne sais pas trop comment la procédure de mise à jour du noyau.

Cependant, concernant le TPM, la procédure de scellement permet d'empêcher de lire/empêcher les modifications à moins d'être dans le bon état.

Cet état est dérivé de registres de 160 bits. La seule façon d'altérer ces registres, c'est d'effectuer une extension:
- Lire une valeur (opération appelée mesure)
- Étendre le registre avec cette valeur: new_val = SHA1(cur_val + valeur_lue)
Le scellement permet donc d'établir une chaîne de hash, et donc une suite d'état.

Cette procédure ne semble pas trop adaptée pour le boot car aucune information sensible doit être stockée. Il semble donc que chaque composant de la chaîne de boot soit signé avec la clé du TPM.

Dans ce cas, si le BIOS n'est pas signé, il ne sera pas exécuté par la ROM initiale.
Si le kernel n'est pas signé, il ne sera pas exécuté par le trusted-grub.

Concernant la procédure d'ajout de nouveau kernels, ça devrait être un truc du genre:
- Le kernel vérifie ton gestionnaire de paquet
- Le gestionnaire de paquet vérifie que le paquet du kernel a été fait par une personne de confiance
- Le gestionnaire de paquet demande au TPM de signer l'initrd + vmlinuz

Mais encore une fois, je commence à peine à me renseigner sur les TPMs, je pense que tu devrais t'intéresser à trusted grub si tu veux savoir vraiment ce qu'il se passe.

Bah, un bout de code en ROM qui vérifie le code du BIOS avant de lui passer la main, je vois pas ce qui semble fou là dedans.

Tu vois un problème à ça ?

Le dernier misc sur la sécurité hardware devrait t'aider à comprendre comment marche la chaîne de confiance.
Il faut comprendre comment marche le principe de scellement des données ou alors ce que propose l'extension intel txt.

L'idée, c'est que avant de donner la main à un composant, celui ci est obligatoirement vérifié. Dans le cas du noyal, c'est trusted grub qui s'occupe de cette vérification avant d'exécuter le code du kernel.

Pour ce qui est de la mise à jour des noyaux, je n'ai pas de réponse, il faut que je me renseigne sur trusted grub donc je ne pourrai pas te répondre.

Cela dit, tes interrogations sont vraiment légitimes.

C'est usant ces jugements incessants... Qu'est ce que ca peut bien te faire !?!

Au risque de me faire passer pour un gros troll, je dirai aussi que si on respectait ce genre de commentaire, on resterait tous sur kde 1.0.

Autant je suis d'accord qu'on ait pas envie de mettre à jour si fonctionnellement, la nouvelle version rend les même services, autant là, le monsieur pense à faire ses sauvegardes comme il faut mais reste dans un système de fichier vulnérable à la moindre coupure de courant.

Pour info, ext3 est sorti dans Linux 2.4.15 en novembre 2001.
Sachant que la transition ext2->3 est très simple et ne fait perdre quasiment pas de place, il n'y aucune raison évidente de rester en ext2.
Du coup, Tanguy Ortolo avait toutes les raisons d'être étonné par ce choix!

<troll>
Du coup, j'ai envie de dire: C'est usant les gens qui trainent les pieds et poussent à l'augmentation de la taille du code source du kernel sans raisons :D
</troll>

C'est exactement ce que fait GoboLinux: http://www.gobolinux.org/