Martin Peres a écrit 413 commentaires

Tu montre bien qu'on utilise pas le même système de fichier en local et en distant, et au final, peut-être que les toolkit implémenteront un système pour Wayland en local et un système pour le distant.

C'est aux compositeurs de faire ce travail. Pour info, Weston a un backend RDP et Kristian Høgsberg a déjà fait une démo de fenêtre distante. L'idée est vraiment de transmettre des images (avec mise à jour partielle, très bien pour le desktop) ou une vidéo compressée pour le support des vidéos ou des jeux (comme le fait NVIDIA avec le streaming de jeu). Alors oui, si tu peux streamer la vidéo sans la ré-encoder c'est mieux, mais c'est pas le plus générique.

Au final, ça marchera mieux que X et sa transparence réseau qui n'existe plus. Je met au défi à quiconque de lancer thunderbird à distance, à travers internet!

Tu as raison, les planes sont généralement utilisés dans l'embarqué. Cependant, toutes les cartes ont au moins un plane pour le curseur. Ensuite, ça dépend des GPUs.

En général, y'a aussi des planes pour les vidéos, mais le format est limité au YUV. Sur les cartes NVIDIA, on a une plane par CRTC. C'est pas énorme mais c'est déjà pas mal ;)

Je précise, "idle" équivaut à un terminal avec l'affichage de la conso qui change, rien de plus. C'est pas entièrement "idle", mais c'est rarement le cas sur une machine.

Par exemple, meme si tu utilises une memoire partage entre CPU et GPU, il n'est pas possible pour le GPU d'utiliser directement la memoire d'une tache utilisateur et reciproquement en fait.

Hmm hmm, bien sûr que c'est possible. Tu peux mmaper des buffers graphiques et y acceder depuis le CPU. Inversement, les GPUs font du DMA depuis la VM de la tâche utilisateur. Tu peux critiquer que ce soit pas fait, pas que ce soit pas faisable.

Je viens de faire des tests sur mon laptop (carte graphique Intel):

Idle

• rendu CPU: 8.9W
• rendu GPU: 8.8W

En faisant bouger une fenêtre

• rendu CPU (sans effets): 19W
• rendu GPU (sans effets): 14.9W
• rendu GPU (transparent): 15.1W
• rendu GPU (wobbly + transparent): 15.8W

Tu pourrais refaire des tests sur ton ordi? Essaye de faire durer chaque test environ 10 secondes et dans les mêmes conditions.

Quand KDE supportera wayland, il pourrait même faire usage des KMS planes ce qui ferait que bouger une fenêtre consommerait ~0W coté rendu. Comme y'aura aussi moins de changement de contextes, le temps CPU sera aussi plus faible ce qui diminuera aussi la conso.

Cool pour le alt-tab, mais le "ça" était "80% des plugins de compiz" ;)

Si Weston n'en reprend pas au moins 80% je ne suis pas prêt de migrer. Je déteste "Exposé" par exemple et je lui préfères le carrousel de fenêtres avec alt+tab.

Weston n'aura jamais ça. Son rôle est d'être un démonstrateur et une implémentation de référence. Cela dit, tu peux quand même charger des plugins pour changer son comportement et ajouter les effets que tu veux.

Ça ne colle pas pour moi avec le fait que les autres fabricants de cœurs graphiques pour l'embarqué en ont rien à battre des pilotes du noyau si Google avait vraiment du pouvoir à ce niveau… Non, je pense que le fait que NVIDIA soit challenger sur ce marché les pousse à se différencier tout simplement, bref que c'est une stratégie NVIDIA pure.

Possible que ce soit un mélange des deux. Je sais de source sûre que c'est quelque chose que Google voulait aussi. La spéculation était sur Google payant pour ce développement.

Je ne pense pas que le userspace ait un grand intérêt pour Google. Ils peuvent fournir un binaire facilement pour avoir la libgles. Le reste est vraiment pas nécessaire pour Android.

Cela dit, je pense qu'ils vont essayer de faire marcher notre userspace avec le Tegra K1 car Dave Airlie a déjà refusé des drivers en espace noyau open source si le userspace ne l'était pas. Avoir un embryon de truc qui marche en userspace, ça suffirait à Dave Airlie et NVIDIA peut avoir son driver proprio à lui.

Je ne pige pas : Nouveau et Android, ça fait bien deux pilote pour le même matos ?!

Oui.

Je vois pas le rapport entre les stratégies de NVIDIA et de Google ?

NVIDIA fourni un driver codé vite fait pour Android, faut que ça marche. Ensuite Google demande à NVIDIA de faire un effort et de rendre ce support disponible upstream pour diminuer les différences entre Linux et le noyau Android. L'avantage de diminuer les différences, c'est de diminuer les risques de problèmes lorsque android se re-base sur un nouveau noyau. Google doit vraiment pas vouloir trop diverger et c'est très bien!

Comme Google a de l'argent et doit probablement être prêt à payer, NVIDIA est prêt à dépenser cet argent pour faire le travail demandé. Tout simplement.

Merci Tanguy. Ça doit vraiment être un anglicisme, mais je trouvais que ça sonnait bien le "contribuer quelquechose".

Si on rajoute le "à", ça veut potentiellement dire qu'il y avait déjà quelque chose avant. Sans le "à", plus d'ambiguïté possible. C'est pas Français de ne pas mettre le "à"?

C'est vrai, mais c'est un détail d'implémentation, pas une stratégie d'entreprise ;)

Ces optimisations sont généralement très dépendentes de l'architecture matérielle et logicielle.

Et ce qui fait peur, en général, c'est d'exposer trop de comment ça marche et que quelqu'un se rende compte qu'un brevet avait été déposé sur une technique utilisée. C'est pour ça qu'AMD a une procédure aussi longue de vérification du code avant publication.

Quel est leur intérêt ? Là aussi d'avoir un support partiel des cartes AMD lorsque le pilote propriétaire n'est pas installé ?
Aussi, qu'est-ce qui retiens les constructeurs de publier des pilotes libres ? Y a-t-il un vrai risque que les pilotes révèlent des « secrets de fabrication » qu'ils voudraient cacher à la concurrence ?

Oui, je me suis posé la question aussi mais voilà mon analyse. Jérôme Glisse pourra l'améliorer si il nous lit.

Les pilotes propriétaires sont écrits pour Windows et doivent être disponibles et faciles à installer dès la sortie du matériel, avec le maximum de performance pour faire beau dans les benchmarks. Du coté du libre, le but est d'avoir le support mais surtout de pouvoir le maintenir dans le futur. Le pilote est plus simple, moins orienté performance (moins de hacks et de complexité pour améliorer les perfs dans tel ou tel jeu) et il est donc plus petit. D'ailleurs, il me semble me souvenir qu'AMD a embauché des développeurs pour porter le driver libre à Windows mobile, pour les tablettes AMD, car le pilote était plus petit et plus facile à porter.

Pour résumer:

• Pilote proprio: Course pour avoir le device le plus rapidement possible sur le marché. Performance maximale, duplication de code, peu maintenable;
• Pilote libre: Pilote plus simple, plus facilement portable et qui préfère prendre son temps pour bien faire les choses. Développé par une équipe réduite ce qui veut dire que l'équipe connait mieux le matériel dans son ensemble.

Oui, c'est bien de s'enthousiasmer et c'est pas mal si c'est le signe que NVIDIA va ENFIN se mettre à libérer ses puces… Mais je n'y crois pas trop… En effet, si c'était vraiment le cas, ils auraient libéré le source de leurs drivers CATALYST proprios…

Oh, faut pas réver, ils libèrent en effet pas grand chose. Mais en a t'on vraiment besoin? On peut tracer le pilote priopriétaire rapidement et maintenant, on peut poser des questions sur notre code ou sur une partie qu'on a pas bien comprise. Que demander de plus à part qu'ils nous envoient le matériel en avance sur la sortie officielle et qu'ils payent des ingénieurs pour améliorer Nouveau? Oh, c'est exactement ce qu'ils viennent de faire!

Pour le moment, ne nous réjouissons pas trop vite, ce ne sont que 16 petits patches pour /1 processeurs spécifique/ pour /1 plateforme spécifique/… Et en plus dans Nouveau, qui est encore plus pourri que les drivers proprios d'NVIDIA (ceux d'NVIDIA ils plantent à peu près une fois par jour, Nouveau, c'est toutes les heures…).

Je suis navré de savoir que ta carte plante autant, mais c'est une exception plutôt que la norme. Le bug est connu ou pas? Tu es certain que c'est pas ton matériel qui a un problème?

La vrai raison parce qu'ils ne voudraient pas louper des marchés dans le mobile (d'où ARM), parce leurs concurrents, Intel et AMD, intègrent et libèrent (presque) tout ! On est TRÈS LOIN avec ces gentils petits patches de ce que font ATI/AMD ou Intel !!!

Oui, c'est exactement ce qui est dit dans l'article. Tu sais, les entreprises vont pas dépenser d'argent si ça n'apporte rien en retour (en image de marque ou en cash). Documenter un chipset wifi, c'est une chose. Documenter un GPU NVidia, c'est VRAIMENT autre chose. C'est plus complexe que tout le reste de ton pc réuni et ça change dans chaque famille.

Qu'ils donnent les specs précises de leur matos et la communauté se chargera de faire des drivers libres corrects !

Les specs sont rarement exactes et bonne chance pour en écrire une de qualité. On essaye de le faire et c'est pas trivial.

AMD propose un pilote propriétaire pour le matériel récent, mais le libre lui permet de simplifier celui-ci en ne gardant que très peu de temps le support (les Radeon 4xxx ne sont plus supportés en propriétaire)

Le travail sur le pilote libre radeon est fait par une équipe payée par AMD. AMD produit donc deux pilotes :)

Nvidia ne propose qu'un pilote propriétaire, mais commence à améliorer le pilote libre, après avoir abandonné le libre obfusqué.

C'est une bonne façon de résumer, oui.

Nouveau supporte VDPAU sur toutes les geforce 8+.

Le streaming video est disponible pour presque toutes les salles. Le lien pour la salle Graphics est ici.

La pile graphique a une dev room qui lui est dédiée(Graphics). J'y serai normalement toute la journée pour enregistrer en vidéos les présentations.

Notre salle habituelle étant habituellement remplie, on nous a changé de salle pour une pouvant accueillir 200 personnes. Ça devrait permettre à tout le monde de rentrer, contrairement aux années précédentes où on devait avoir des personnes empêchant de rentrer lorsque la salle était trop pleine (question de sûreté).

Je crois que tu sous-estimes à quel point c'est dur de prédire combien de CPU tu vas utiliser sur une machine pour exécuter une tâche.

Le noyau se rendra bien vite compte que la machine est IO/CPU/memory bound avec les compteurs de performance, il pourra faire les modifications nécessaire à ce moment là.

Pour la mémoire volatile, y'a la v10 d'un patchset qui est sorti le 2 janvier 2014. Des gens bossent dessus.

Sinon, pour l'ordonnanceur, ça va t'apporter quoi de connaitre ces infos de ce que l'application PENSE qu'elle va avoir comme problème (oui, ça veut dire qu'elle doit soit utiliser les compteurs de performance et apprendre de ses expériences précédentes, soit elle doit avoir un modèle de performance du matériel sur lequel elle s'exécute)?

Comme tu peux le voir, ce que tu demandes n'a pas vraiment de sens. À la limite, elle pourrait connaitre le nombre d'appels mémoire à faire et d'instructions à exécuter, mais comme elle a aucune idée de la topologie matérielle (NUMA) et de l'état des caches, elle pourra pas trop avoir une idée du temps qu'elle va mettre ou de ce qui sera le bottleneck.

La premiere chose, c'est la collaboration user-space/kernel space quand le systeme est sous pression memoire.

Yep, je suis d'accord! Comme tu dis, Android a quelque chose et ça va venir dans le noyau.

Le deuxieme endroit qui nécessite des ameliorations, c'est le scheduling.

Ne pas confondre prise de décision sur la disponibilité des ressources (qui est une prise de décision sur la gestion d'énergie, basée sur les compteurs de performances) avec le scheduling. Le scheduling est là pour partager les ressources disponibles, la prise de décision sur combien d'unité de calculs à charger est indépendante de ça.

Perso, je pense pas que demander aux applis ce qu'elles ont besoin soit pertinent. Surtout que le hw évolue. Les systèmes coopératifs, ça marche que si tu contrôles tous les programmes. Même Apple a laissé tombé ça!

No idea! Comme dit plus bas, j'ai vraiment peu d'expérience là dessus. Déjà, je fais de mon mieux pour écrire dessus dans les dépêches! Maintenant que j'y fais plus attention, j'espère apprendre des choses et pouvoir vous répondre ;)

Oula, on avait parlé de ça ensemble? Je dois perdre la mémoire.

Bon, je crois que tu te mélanges en effet bien les pinceaux. Quand je dis que le support de la 2D et de la 3D est possible, ça veut dire que le noyau est capable d'initialiser le ou les blocs nécessaire pour faire marcher le tout. Ensuite, il est capable de récupérer les commandes générées par le userspace et les envoyer à la carte, vers le bon moteur (chez NVIDIA, c'est le hw qui se charge de ça).

Je ne sais pas pourquoi la 2D et la 3D sont séparés, probablement pour des questions d'économies d'énergie. Le moteur ayant plein de transistors et n'étant pas optimisé pour le rendu 2D.

Quoi qu'il en soit, le projet grate est un driver gallium qui permet de générer des commandes à envoyer aux processeurs Tegra. Et pour ça, il a besoin de pouvoir communiquer avec le driver en espace noyau (drm/tegra). Ce driver est écrit par kusma, semble t'il. Ça fait un moment que je le vois plus sur #nouveau et j'avoue que j'ai pas trop prêté attention aux pilotes graphiques ARM jusqu'en Septembre ou j'avais demandé à Rob Clark si il pouvait pas faire un récapitulatif pour l'XDC2013. Voilà la présentation avec la vidéo.

Ce pilote a été écrit par Russel King. C'est un pilote communautaire qui n'a rien à voir avec le pilote officiel.

Maintenant, le driver libre Vivante, et_naviv, peut utiliser ce driver directement pour afficher ses images, probablement sans recopie (si Armada, le CPU et Vivante partagent la même mémoire et que les IOMMUs sont programmées relativement pareil.

Vu que Wladimir a l'air de vouloir faire un driver gallium, ça veut dire qu'on devrait bientôt un support totalement upstream et libre sur certains SoC! C'est super cool :)