Je n'ai pas eu le temps de regarder en detail l'ISA, mais a premiere vu, ca manquait de calcul vectoriel et flottant. Je trouve ca assez domage au final surtout aujourd'hui avec le support de l'auto-vectorisation dans les compilateurs et l'utilisation des flottants dans quasiment tous les languages de script. Je me trompe peut etre, mais c'est probablement du fait de leur volonte de faire le grand ecart entre Rocket et BOOM. Du coup, pour les avoir rencontre et avoir regarde le sujet de plus pres, tu en penses quoi ? C'est vraiment necessaire l'approche Rocket quand des projets comme j-core addresse deja ce marche ?
Par curiosite, j'ai juste regarde les exemples sur la premiere page de chisel, et ce n'est pas evident la difference avec VHDL. Tu pourrais un peu elabore ce que tu as appris sur le sujet ? Ou donner des pointeurs sur les morceaux que tu trouves interressant.
Sinon je n'avais pas vu pour le 5eme workshop. Vu que c'est a cote de chez moi, je viendrais bien. Tu as une date plus precise et une annonce pour s'enregistrer ?
Oui, tout aussi interressant. Les auteurs du J2 ont d'ailleurs discuste avec l'equipe de riscv avant de partir sur le J2 et c'est sur leur recommendation qu'ils sont parti sur l'architecture du super hitachi. Mais partir de zero est bien plus complex et couteux, sans compter les risques des brevets qui sont plus difficile a trouver. Pas forcement un probleme pour le RISCV qui se veut plus une architecture pour la recherche.
Juste pour réagir à ta remarque concernant les processeurs libres. C'est un sujet si l'intéressé énormément depuis bien longtemps. Du coup lors du derniers ELC, j'ai été très agréablement surpris par la présentation de l'équipe du J2. C'est gens ont compris pas mal de problème (efficience du jeu d'instruction, brevets, compilateur et portage d'os). Ils viennent juste de release leur premier code en vhdl sous licence bsd et sans brevet aucun sur leur site: http://0pf.org/.
Pourquoi c'est intéressant, parce que en faite ils ne font que reimplenter le super Hitachi ! Version 2 pour l'instant, mais la 4 devrait arriver en fin d'année, car les brevets auront tous expiré à ce moment la. Ils ont juste rajouter quelque primitive supplémentaire pour permettre le smp en se basant aussi sur une vieille architecture dont les brevets ont expiré. Du coup, on se retrouve avec une architecture complètement libre, plus efficace que arm et au niveau d'Intel sur la densité de code (arm avait à l'époque pris une licence des brevets d'Hitachi pour implémenter l'extension thumb). Cerise sur le gâteau, gcc et linux, voire même certaine distribution supporte déjà cette plateforme !
Enfin le coup de production part d'ancienne fab permet d'atteindre facilement 250MHz pour 25000$ par wafer. A priori, c'est le moment avec le ralentissement en Chine pour faire de petit batch. Toujours d'après les mêmes membre de l'équipe, ils sont déjà à un coup par cpu largement inférieur à arm du fait de l'absence de licence (sans compter le support logiciel). J'attend avec impatience de voir le multi coeur J4 !
pour un kilo de photovoltaïque moderne il te faut moins de matière que pour un kilo de photovoltaïque d'il y a 15 ans
Je suis a peu pres certain que ce n'etait pas ca que tu voulais dire. Du coup, j'en profites pour expliquer plus precisement le probleme du recyclage et des terres rares. Tout d'abord la raison de l'amelioration des cellules photovoltaique est du a l'utilisation de processus impliquant les terres rares, telle que le cadmium. Il y a d'ailleur une exclusion des panneaux photovoltaique des directive RoHS europeennes jusqu'en 2018. Maintenant toutes les technique de recyclage implique des pertes. A priori, on recycle les panneaux photovoltaiques jusqu'a 90%. Ce qui veut dire qu'on perd 10% de terre rare pour chaque panneau qu'on fabrique. Sur un stock finis et rare, c'est pas forcement le choix le plus judicieux…
C'est comme pour un ordinateur, un ordinateur moderne est moins polluant à fabriquer qu'un ordinateur des années 90. (genre un raspberry pi demande 100x moins de matière que ce genre de truc et tu atteint plus facilement (sans faire d'autres achats) la puissance dont tu as besoin)
Oui et non. Certe a MIPS equivalent, on a besoin de moins de ressource pour les produire. Par contre, la puissance des machines utilisees a continuer a augmenter de maniere exponentielle… Du coup, on utilise aujourd'hui plus de terre rare et d'energie pour tous les appareils electroniques qu'une personne utilise qu'il y a 20 ans. Est-ce que tu avais un telephone portable, un laptop a ecran plat, une tv a ecran plat, une set top box, un routeur, il y a 20 ans ? Et le recyclage des composant electronique est tres tres mauvais. Globalement, on ne recupere que un peu d'or, toutes les terres rares sont perdu et les autres metaux sont degrade pour des usages moins complexe.
Il faut attendre les batteries aux graphènes (chinoise vu que l'occident sait rien faire sans breveter) pour avoir un truc écolo.
Je veux bien un lien. Je n'ai jamais entendu parle de batterie aux graphenes, uniquement de super capacites.
Penser un système énergétique sans capacité de stockage d'énergie c'est juste risible, ou à pleurer selon le point de vue. (tu peux par contre stocker de l'énergie sans batterie chimique, y a plein d'exemple DIY sur youtube)
Tu te rend bien comptes que personne ne fait ca ? On a aujourd'hui sur la planete 11min de batterie (Si on prend toutes les batteries utilisable). Tu sais aussi que les batteries ne s'ameliore pas comme la loi de Moore, mais suivent une courbe de seulement +10% tous les deux ans (Que tu peux repartir entre le poid, l'energie et la capacite de charge/decharge). Enfin, tu sais que tous les design de batteries consomme des ressources encore plus limite que le petrole. Les batteries les plus efficace requiere toutes des nanostructure tres difficilement recyclable.
Du coup, reste les STEP. Mais on manque de place et de site… Autant dire que non, les energies a faible densite ne sont pas plus une solution.
Il n'y a pas corrélation entre volume produit et prix du pétrole. Il y a une corrélation entre la différence consommée et produite, il y a aussi une corrélation avec la valeur du dollar. Ainsi se baser sur le prix pour estimer si on a passer le pic ou non n'est pas une bonne idée. De même cela renforce l'affirmation autre quand le pic sera passé on ne pourra pas investir, car le prix continuera de varier énormément entre les crises économiques du à une consommation atteignant la production et les reprises lorsque la consommation se sera effondré.
Note qu'on a passé en 2005/2006, le pic mondiale du pétrole conventionnel et qu'on a probablement passé celui du schiste l'année derrière étant donné les baisses de production actuelle. Dire que le pic du pétrole n'arrivera jamais, c'est juste ignoré l'histoire. Mais ne t'inquiète pas, on a encore le pic du gaz, du potassium, et de globalement toutes nos matières première pour réviser ca dans les 50 ans à venir.
Je crois que tu te meprends. Les panneaux photovoltaïques les plus performants utilisent des terres rares et des structures nanométrique qui rendent le recyclage extrêmement difficile du fait de l'intrication de tous ce petit monde. Sans compter que sans batterie, tu pars du principe que quelqu'un va consommer ou arrêter de produire quand cela t'arrange et payer rubis sur l'ongle quand tu produira (d'ailleurs quand tu y réfléchis, le photovoltaïque subventionné, c'est un moyen pour les riches d'investir sur le dos des pauvres)… Ah, oui, les batteries aussi pour être performante ne sont pas très recyclables…
J'espère que ton flair à tort, car je doute que la chandelle soit une solution… Il est intéressant de regarder comment nos voisins très organisés tente de sortir eux même du nucléaire et on déjà dépensé l'intégralité de ce que cela nous coûterait de remplacer nos centrale par des epr, alors qu'ils leur restent encore 20% de nucléaire et un paquet de charbon…
L'énergie pas chère, abondante et non polluante est un mythe. Il y a toujours des effets. Par exemple, si tu avais lu l'âge des low Tech, tu serais horrifiés de voir ce gaspi qu'est une éolienne ou la densification des lignes électriques…
La seule chose qui peut globalement résoudre nos problèmes énergétique, serait une énergie dense, compact à consommer, avec une capacité à s'adapter à la charge rapidement et stabilisant le réseau en évitant les emballement de fréquences. Idéalement il faudrait qu'on puisse l'utiliser aussi dans l'espace très rapidement (étant donné nos consommation de matières premières, probablement 30 à 40 ans). Des propositions ?
Clairement le scheduler du noyau Linux a plus d'un probleme. Un des sujets non aborde dans l'article, qui est tres interressant. C'est les problemes de consommation d'energie et de scheduling lie a cela. Typiquement sur les taches interactives fonctionnant avec un device sur batterie, le scheduler est globalement toujours faux.
Le principe du scheduler est de regarder le passe d'une tache pour en deviner son usage futur. Le probleme des taches interactives, c'est que par design le process principal fait un peu de tout a une frequence eleve (Hop, une IO, un peu de CPU bound pour calculer le nouveau layout, puis un peu de memory bound pour regarder si il y a des trucs a dessigner, …). Il devient assez evident que ce qu'une tache a fait dans le passe aide peu.
La solution evidente, c'est de creer plusieurs process/thread qui chacun doit faire un seul truc. Meme si ils ne sont pas execute en parallele et si ils consomment plus de RAM, au final, le noyau devrait etre capable de scheduler tout ca de maniere plus efficace… Sauf que non, pour tout un tas detail, qu'on peut resumer a la non integration de cpufreq et cpuidle dans le scheduler, le noyau est incapable d'utiliser les ressources du materiel de maniere optimal. On se retrouve alors avec des gros hack pas beau. Comme par exemple sur certain telephone ou un process en tache de fond regarde quel est l'application active et change les parametres de frequence et du nombre de CPU en fonctionnement pour avoir un resultat un peu plus optimal… Gros hack, franchement pas terrible.
Tout ca pour dire que sans le boulot en court du scheduler energy aware, et bien, on a encore de la marge… Oh, et bien entendu, l'user space doit aussi s'adapter ! On a encore du boulot pour quelques annees…
Il n'y a que moi que ca derange cette approche du courcircuitage des distributions pour aller plus vite dans la gestion des problemes de dependences… sans addresser un moyen robuste de mettre a jour les tonnes de bibliotheque duplique !?! Heureusement que Linux sur le Desktop, c'est pas pour demain, sinon on est bien parti pour faire aussi bien que Windows…
Ça y est, je crois que je vois l'un des malentendus: tu parles des animations du compositeur lui-même ("le positionnement d'une fenêtre"), je parle des animations dessinées par l'application dans le contenu de la fenêtre ("la geometrie dessinée dans la fenêtre").
Ok, donc on parlait bien de la meme chose, juste ta phrase etait un peu confuse pour moi, car quand on parle de geometrie, on parle generalement de la geometrie de la fenetre.
Si tu relis ce que j'écris sur la qualité d'animation, ce n'est pas nécessairement (peut-être, peut-être pas) quelque-chose que l'on peut mesurer par un quelconque procédé logiciel. A priori, cela se mesure avec une camera qui filme physiquement l'écran a au moins 60 images par seconde. C'est réellement comme ca que l'on fait dans l'industrie quand on tient vraiment a garantir la qualite réelle d'animation, par exemple les constructeurs d'appareils mobiles ont généralement recours a cette technique. Bien entendu, c'est très coûteux.
En fait, ce genre d'appareil n'est pas necessaire. Tu peux juste mesurer a l'aide d'un timestamp general au systeme quand tu recois un input et quand tu pousses un buffer avec le changement resultant de cet input a l'ecran. Avec un peu de bidouillage dans le protocol wayland et dans le toolkit de l'application, tu peux assez facilement propager ce timestamp de l'input au buffer d'output pour collecter ces informations. En correlant ces informations avec la vsync, tu pourras facilement voire lorsque tu perds des frames.
L'utilisation principal des cameras hautes vitesse que l'on (Samsung) a, c'est pour essayer de "voir" exactement ce que contient une frame avec un glitch graphique (Generalement du a un bug de driver). Pouvoir verifier les pixels a la sortie de l'ecran frame apres frame. On les utilise aussi lorsqu'on a des problemes d'input qui envoie en fait l'information trop tardivement. Mais a part un probleme reellement lie aux drivers, c'est rarement utilise, car franchement pas pratique comme outil d'experimentation et sans valeur ajoute pour la majorite des cas.
Par contre ce qui est amusant, c'est que apres avoir travaille suffisament longtemps dans ce domaine, tes propres yeux savent "sentir" un glitch, un lag, un frame drop. Tu peux meme avoir une estimation du framerate juste avec tes yeux et estimer le lag d'une application en nombre de frame. C'est, je trouve, plus dur de venir avec un chiffre correct pour l'estimation du lag au juge, mais definitivement tu le sens quand ce n'est pas bon.
Desole, je n'ai pas acces au code de Mac OS X et je n'ai aucune idee de ce qu'ils font. Par contre, je suis nettement plus a l'aise avec Weston et Enlightenment. Weston supporte aussi le scaling, si j'ai bien compris ce a quoi cela correspond dans Mac OS X. Globalement changer la taille d'un buffer est supporte par les unites de scanout moderne (En tout cas celle de telephone mobile auquel j'ai acces et a priori Intel, mais je n'ai pas verifier).
Globalement le principe est le suivant, quand tu ne peux pas utiliser le "compositeur" simple qui se trouve dans le scanout, tu fallback sur l'utilisation du GPU effectivement (Cela frame apres frame). Maintenant les conditions dans lesquels tu peux utiliser l'unite de scanout uniquement varie d'un hardware a l'autre. Pour faire simple, la plus part support up et down scaling de 5 plan graphiques avec des characteristiques de colorspace qui alloue en general un ou 2 plan YUV et un certain nombre de plan RGBA (Oui, cela inclut la transparence). Ce nombre de plan graphique peut aussi varier en fonction du nombre d'ecran. Ainsi si tu as 2 ecrans, mais que tu as un total de 5 plans, tu te retrouves effectivement a devoir les partager entre tous les ecrans.
Enfin, dans le cas de Weston/Wayland, seul les applications qui fonctionnent en utilisant wayland_gl, ont un interet a etre mis dans un plan hardware (Ca ne couvre pas le terminal par exemple). Celles qui passent par wayland_shm, finissent, a priori, dans un buffer qui devrait etre copie de toute facon vers un nouveau buffer drm pour pouvoir se passer du GPU. Mais cette copie revient techniquement exactement au meme que de passer directement par le GPU avec un support de la mise a jour partiel de buffer pour faire la copie (J'avoue ce n'est pas toujours aussi tranche et des fois il vaut mieux passer faire une copie depuis le CPU dans un buffer drm que de passer par le GPU pour des raisons de consommation d'energie).
Enfin quand tu dois renoncer temporairement a l'utilisation direct de l'unite de scanout, par exemple lorsque le compositeur fait lui meme une animation (a la compiz), ce n'est pas un vrai probleme. Dans ces cas la, tu pourrais meme faire tomber le framerate des applications a 30 fps et reduire de moitie leur resolution que personne ne s'en renderait compte en fait ! Du moment que l'animation du compositeur lui meme est reactive et s'execute a 60fps, personne ne se rendra compte que tu as temporairement diminue les performances de l'application. Sur un PC, tu n'as probablement peu de cas ou tu aurais besoin de faire de tel choix, mais sur un mobile, cela arrive que tu sois limite en bande passante GPU/CPU au point ou tu doivent faire ce genre de chose.
Donc le cas principale d'utilisation est bien l'utilisation unique de l'unite de scanout. J'entend bien par cela le temps d'utilisation d'une application a l'ecran dans une situation interactive.
Bien sur, il faut finir par dessiner un framebuffer. Je dis simplement qu'on peut ne dessiner que ce framebuffer final, directement a partir de command buffers fournis par les fenetres, plutot que de le dessiner a partir de framebuffers intermediaires fournis par les fenetres. Comme tu le dis,
On est bien d'accord que dans le cas de la fenetre ayant le focus ou dans le cas d'une application plein ecran, le compositeur ne dessine rien. Il ne fait que dire a l'entite de scanout d'afficher le dit buffer directement a l'ecran. Exactement la meme operation que ferait une application qui a directement acces a l'ecran. Il n'y a pas de surcout dans ce cas.
Maintenant en quoi le probleme change si tu as un compositeur dans l'histoire, tu as juste deux etapes supplementaire.
Et ces etapes supplementaires rajoutent une dose de latence, non-constante, entre le moment ou les fenetres dessinent leur propre framebuffer en positionnant leurs objets animes, et le moment ou ces pixels atteignent l'ecran. C'est ca qui limite la fluidite des animations dans les fenetres, independamment des performances.
La latence dont on parle ici est de deux context switch. Dans le pire cas, cela represente, sur une machine de moins de 5 ans, moins de 1% des 16ms que ton application va utiliser pour dessiner une frame. Les chances de manquer la deadline a cause de ces deux context switch est franchement tres tres tres basse. La variabilite reste sur juste quelques choses >1%, donc j'ai du mal a voir en quoi tu peux imaginer que c'est la que ce trouve le probleme. Est-ce que tu as des mesures qui montre des problemes de ce cote la ?
Je pense que ton probleme pour l'instant, c'est que tu n'as pas de benchmark qui montre ton probleme. Si tu essayes de convaincre qui que ce soit qui connait le sujet et bosse dans le domaine, ils auront beaucoup de mal a te croire voir meme a faire l'effort de faire un benchmark eux-meme pour verifier tes dires. Essaye d'en construire un et d'analyser le comportement du systeme. Je serais interresse de voir des traces de latence ou l'on voit le probleme de stabilite d'une animation dont tu parles. Je te conseille de le construire au dessus de Weston. Cela te donnera aussi une bonne idee de comment marche la stack graphique.
ceci ne garantit en rien la fluidite reelle des animations, qui depend du positionnement de la geometrie dessinee dans la fenetre en fonction du temps reel d'affichage a l'ecran.
Alors la, je ne te suis pas du tout du tout ! En quoi le positionnement d'une fenetre va avoir le moindre impact sur les performances !?! Relis mes postes plus haut sur l'utilisation des plan hardware.
J'ai pourtant bien explique pourquoi on avait du double ou triple buffer et pourquoi cette latence etait necessaire techniquement. Tu as toujours un framebuffer, que ce soit lorsque tu passes par un compositeur ou non. Le GPU ne dessine jamais directement a l'ecran (Il ne dessine d'ailleur generalement pas dans tout le framebuffer, mais par zone appele tile pour des raisons de cache et de calcul parallele). C'est inherent a comment fonctionne tous les accelerateurs 3D. Ceux-ci remplisse un buffer, qui sera pousse sur le scanout qui l'affichera l'ecran. Quand tu parles de latence, tu parles du temps necessaire entre la reception d'un input et sa reaction visible a l'ecran.
L'objectif etant que la prochaine frame affiche apres cet evenement le soit le plus tot possible. Il y a deux cas. Soit tu as deja commence a dessiner une image et tu vas perdre le temps de ta vsync + 16ms (sur un ecran a 60hz). Soit tu n'as pas encore commence a dessiner une image, auquel cas, tu auras moins de 16ms avant ta prochaine image qui aura l'input correct. Ca c'est dans le cas du double buffer avec aucun compositeur (Je laisse de cote le cas du triple buffer).
Maintenant en quoi le probleme change si tu as un compositeur dans l'histoire, tu as juste deux etapes supplementaire. L'input est d'abord lu dans le process du compositeur et envoye au jeu. Celui-ci se retrouve alors dans la meme situation que precedemment seulement, il n'a plus 16ms, mais 16ms - le coup du context switch pour l'input. Mais comme cela ne s'arrete pas la et qu'il te faut aussi faire un autre context switch pour pousser le buffer a l'ecran, tu te retrouves avec globalement 16 ms - 2 * context switch. Le reste est strictement egal par ailleur.
Le veritable probleme est donc bien de maintenir le maximum de stabilite dans la capacite de ton process a pouvoir pousser une frame toutes les 16ms.
Pour répondre littéralement à ton objection, "un buffer qui pourra etre utilise directement par le compositeur", certes, mais comment est-ce qu'un compositeur utilise ce buffer? Réponse: il l'utilise comme texture et il dessine un quad avec. Ce qui revient à faire une copie --- juste une forme un peu généralisée de copie, qui permet le genre d'effets qu'on voit dans les compositeurs de bureau d'aujourd'hui.
Mon explication n'a pas du etre evidente sur le sujet. Le compositeur recoit un EGLImage directement qu'il va lier directement a un plan hardware. En gros, ca part direct sur le scanout sans repasser par le GPU, donc pas de copie. Et il faut maintenir ce buffer dans cette position tant que l'image est affiche a l'ecran. Cela que ce soit le job du compositeur ou du jeu.
Mais je ne veux pas pinailler là-dessus, car ce n'est pas le point qui me semblait intéressant. Même sans aucune "copie", il y a tout un tas de coûts à demander aux fenêtres de fournir un framebuffer pré-rendu, comme j'essayais de l'expliquer dans mon journal: latence importante et non-constante qui rend difficile d'avoir des animations parfaitement fluides, ce qui entretient le besoin pour les applications graphiques exigentes de pouvoir contourner le système, voir la discussion ci-dessus sur les jeux 3D en plein-écran.
Alors il y a des coups, mais principalement que celui du changement de contexte. Mais si tu fais cela dans le meme process, tu as exactement la meme contrainte, la seule chose que tu vas eliminer, c'est le coup du changement de process. Le reste restera la. Binder le buffer au scanout est un besoin technique, ainsi que se synchroniser sur la vsync. La seule difference, c'est qui le fait et par ou ca passe.
C'est bien pour ca que je ne pense pas que le coup de passer par un compositeur soit si problematique. Ton OS fait des changements de process en permanence. Tu as toujours plusieurs applications qui tournent et qu'il faut scheduler sur plusieurs CPU. Je doute tres tres fortement que c'est la source de probleme aujourd'hui.
Je serais bien plus facilement convaincu, si on parlait de la difficulte en OpenGL de faire du multi thread, d'uploader une texture en zero copie, de melanger calcul CPU/GPU et rendu graphique… Je pense que Vulkan va permettre de lever bien plus de probleme de fluidite que la possibilite de rendre directement a l'ecran sans passer par un compositeur (et encore cela necessite de revoir profondement la maniere dont fonctionne les moteurs graphiques).
Globalement, je suis d'accord sur le diagnostic. On a des problemes de performance et de stabilite du frame rate sous Linux et il y a du boulot pour avoir des animations fluides, mais la solution n'est pas la ou tu penses :-)
Juste un point que tu as peut etre manque, avec Wayland, tu n'envois pas une bitmap qui sera copie par le serveur, mais un buffer qui pourra etre utilise directement par le compositeur. Dans le cas ou ton compositeur fonctionne en software, bon, pas trop de chance, tu vas devoir faire un memcpy. C'est pas comme si tu avais le choix. Dans le cas ou ton compositeur fonctionne avec drm et autorise wayland_egl pour tes applications, celui-ci va recevoir un EGLImage qu'il pourra mettre directement dans un plan hardware sans meme faire de composition (GPU ou software).
Cela veut dire deux choses, tout d'abord une commande est courte, c'est juste une serie de buffer, plus la region de ces buffer qui a ete mis a jour. Ensuite contrairement a X, le compositeur peut utiliser le buffer directement (donc le bloquer temporairement) meme pour une application qui n'est pas full screen si le hardware qui gere les plans graphiques autorisent le layout actuellement a l'ecran (Pour l'instant, c'est globalement la top window qui sera dans son propre plan hardware). Ce qui permet d'avoir les perfs du full screen meme quand on n'est pas en fullscreen (Bon, c'est non trivial a implementer et il y a encore du boulot dans tous les compositeurs wayland sur le sujet).
Tu conviendras que contrairement a envoyer un buffer de commande qui peut etre mal interprete par le compositeur et plutot long, tu as un pipeline plutot simple avec peu d'erreur potentiel et court. Aussi un autre point que tu n'as pas mentionne, mais les API modernes tel que Vulkan permette de faire du calcul sur le GPU dont tu obtiens le resultat pour le reutiliser potentiellement par le CPU. Dans ton modele, ca fera un round-trip supplementaire assez couteux a mon avis (sans compter la complexite a gerer les aller-retour).
Enfin concernant la latence des frames a l'affichage. Tout d'abord la raison pour laquelle les flux videos ont generalement une dizaine de frame bufferise est du au codec qui a des images partielles qui references des images dans le passe et le futur. Si tu n'avais pas autant de frame bufferise, tu ne pourrais juste pas les decoder :-) La solution est plutot effectivement d'ajouter un timestamp sur les dites frames pour les presenter le plus tot possible aux compositeurs et lui permettre de les afficher au bon moment (encore une fois, c'est un boulot important que chaque compositeur va avoir a implementer lui meme, donc ca prendra du temps avant d'etre utilisable).
Pour ceux qui est des applications 3D, la raison est assez simple. Tu as besoin de 3 buffers en general pour ne pas bloquer ton pipeline de rendu graphique. L'idee est que tu as actuellement un buffer bloque dans un plan hardware, car il est affiche. Tu as la frame suivante qui est pret a etre affiche, mais le switch de plan hardware au nouveau buffer n'a pas encore eu lieu, donc tu ne as un deuxieme buffer cote serveur en attente. Enfin l'application elle meme est prete a dessiner et decide que plutot que d'attendre que le serveur lui dise de dessiner une frame, elle va le faire en avance. Resultat, tu as effectivement besoin de 3 buffer pour ne jamais bloquer dans le scenario ou tu pousses tes frames sans te synchroniser avec le display server.
Maintenant si tu utilises le frame callback de wayland, tu auras toujours un buffer de bloque dans le hardware plane, mais wayland te dit que maintenant qu'il va affiche un nouveau buffer en fonction de la vsync de l'ecran. Donc tu n'envoie un buffer que lorsque celui ci te le demande. Et tu n'as besoin que de deux buffers. Le second avantage est que tu pousses a l'ecran une image de ton application qui est le reflet exacte de ce qu'elle est cense etre durant cette vsync. Par contre, cela veut dire que tu n'as besoin que du temps de la vsync pour dessiner une frame. Cela peut etre trop court pour certain jeux complexe.
Je ne suis pas fan personnellement. La complexite de la gestion du multi ecran, de kms/drm/dmabuff est suffisament eleve pour dire qu'a minima il faudrait avant de pouvoir realiser cela une bibliotheque partageant le boulot (clairement quelque chose que devrait fournir le projet wayland, mais c'est une autre discussion).
Le second probleme que je vois, c'est qu'on repasse en mode cooperatif totalement. Si le jeu n'est pas capable de gerer alt-tab, et bien on reste coince dans le jeu. D'un point de vue securite, c'est juste une potentiel horreur a gerer. On perdrait aussi la possibilit d'avoir un ecran dedie a irc/chat d'un cote et au jeu de l'autre.
Surtout que je ne suis pas convaincu que ce soit un vrai probleme. Si le compositeur ne fait que mettre les buffers gl dans un plan hardware directement, le coup est globalement uniquement sur le switch de context a 60fps. C'est franchement pas la mer a boire pour un PC meme de 10 ans d'age…
Par design, tu ne peux pas courcicuite X, si tu parles au serveur X :-) Ce que propose Martin, c'est de ne plus faire les round trip avec le serveur wayland ou X. Dans les deux cas, tu as une latence sur l'input et l'output vu qu'ils sont tous les deux gere par le serveur (X et Wayland) avec un peu plus de probleme potentiel avec le serveur X etant donnee que tu peux passer par un compositeur pour l'output.
D'ailleur le seul cour circuit qui existe sur X, c'est le cour circuitage du compositeur pour les fenetres pleins ecran si il l'autorise. Et c'est tout.
Le "truc" amusant actuellement, c'est que le noyau Linux est tres mauvais a estime la bonne frequence et le nombre de CPU au bon moment. Les systemes de cpu idle et de cpu freq etant decouple du scheduler qui lui meme perd tout l'historique des qu'il bouge une tache sur un nouveau coeur. Le resultat actuel, c'est que le CPU se retrouve dans les taches graphiques souvent a la mauvaise frequence au mauvais moment.
La raison est simple, vous avez une serie de tache globalement plutot seriel, qui enchaine une etape IO bound, MEM bound, CPU bound, MEM bound, pour retourner en IO bound. Le tout par cycle de 16ms.
Le probleme est connu, et c'est pour cela qu'il y a du travail sur la gestion d'energie et le scheduler en cour. Mais cela affecte aussi l'user space. Le noyau n'a des statistiques que par process, il ne sait pas si un bout de code est IO, MEM ou CPU bound. Par contre, un process, a terme, il saura quel est potentiellement la frequence ideal de fonctionnement. Cela n'est vrai bien entendu que si dans un meme process ne tourne que des taches qui ont les meme proprietes !
Donc il faut bien s'orienter vers du multi thread, mais les mesures actuelles de consomation ne sont probablement pas tres pertinente tant que le noyau n'aura pas ete corrige.
Pour une explication potentielle du pourquoi, 2 * 50%, c'est mieux que 1 * 100%, c'est probablement lie a la disponibilites de plus de bande passante memoire du cache L1 (un par core) qui permet d'eviter des acces dans les sous systemes memoire plus lointain et plus couteux en energie pour y acceder (Acceder un registre etant moins energivore qu'un acces en L1, un L1 moins qu'un L2 et un L2 moins qu'un acces en RAM). C'est potentiellement une explication que je vois, surtout si la frequence des core est alors adapte a la consommation de bande passante memoire offert par le cache.
Si tu l'utilise en conjonction avec encfs sur le client, tu auras une solution où le risque pour les données qui quittent ton pc sera nul. Chiffrement local des données avant de les envoyer sur le réseau et protection Man in the middle/interception avec ssh. Probablement ce que l'on fait de mieux en terme de sécurité.
Ca dépend ! Si tu utilises un compositeur, je suis près à parier qu'il recompose la surface yuv dans le buffer écran. Le seul cas à peu près gérer, c'est le cas plein écran et encore il y a pas mal de driver qui ont des problèmes…
Et comme dit Martin, pour wayland, il y a encore beaucoup de boulot pour tout le monde ! Du kernel aux applications, il y a plein de chose a juste faire marcher. On en est pas encore aux optimisations. Même si l'architecture de wayland devrait rendre les choses plus facile. Peut être dans le courant de l'année prochaine…
Il y a un truc que je n'ai pas compris. Si on envoie un mail non chiffre sur une adresse d'un serveur gere par Own-Mailbox, est-ce que ca marche ? Et est-ce que de maniere automatique le systeme detecte que le mail n'est pas chiffre et le chiffre avec la clef publique du/des destinataire locaux pour eviter toute compromission du mail si quelqu'un avait un acces future a la machine (A la gpgit) ? Est-ce que le systeme de backup permettrait d'avoir cette fonctionnalite aussi sur les backup ?
De la meme maniere, quels sont les defenses mise en place pour limiter la compromission de la machine herbergeant Own-Mail ?
La definition n'est pas debile, mais elle a des implications techniques tres differente. Quand on parle de meta data et que cela ne concerne que la couche IP, on n'est pas intrusif comme on peut l'etre lorsque on recupere les meta data du protocole SMTP. Mettre tout dans le meme sac est au mieux brouillon, au pire une tentative d'enfumage.
Dans tous les cas, la semantique de meta data est suffisament flou pour assumer que cela veut dire DPI. On peut avoir un discour philosophique sur ce que veut dire meta data, mais au final, c'est la technique qui compte. Et la ca veut dire, j'ouvre la lettre et je regarde ce qui m'interresse dedans a ma convenance.
Le problème est à mon avis que les "gens qui connaissent le web" n'ont pas le recul pour comprendre qu'un mot utilisé dans leur domaine ne se réduit pas à l'usage qui est fait dans leur domaine.
Ou inversement, quelqu'un qui ne connait pas la technique penserait que observer les "meta-data" est comme lire l'enveloppe d'une lettre. Sauf que techniquement, il faut l'ouvrir pour pouvoir voir certaine de ces meta-data. Ce qui fait qu'on est deja entrain de parser le stream et franchement si on en est a sauvergarder, le from/to d'un mail… autant y ajouter le subject et pourquoi pas le corps. Il n'y a techniquement plus de difference a partir du moment ou on est brancher sur le niveau applicatif.
Si un politicien fait cette erreur, il est considéré comme "déconnecté de la réalité" et "incompétent sur le sujet dont il est question".
Ou parfaitement conscient qu'il met en place un systeme de DPI. Ceux qui ne le sont pas, ceux sont ceux qui croit que les meta data dont on nous parle ici sont accessible sans regarder le contenu, les data. Or c'est faux !
# Note du workshop
Posté par cedric . En réponse au journal De retour du 4e workshop RISC-V. Évalué à 2.
Je viens de voir passer les notes prises par lowRISC lors du workshop: http://www.lowrisc.org/blog/2016/07/notes-from-the-fourth-risc-v-workshop/ . Une bonne lecture pour qui veut plus de detail et probablement assez de matiere pour qui aurait envie de faire une news sur le sujet.
# Interressant
Posté par cedric . En réponse au journal De retour du 4e workshop RISC-V. Évalué à 2.
Je n'ai pas eu le temps de regarder en detail l'ISA, mais a premiere vu, ca manquait de calcul vectoriel et flottant. Je trouve ca assez domage au final surtout aujourd'hui avec le support de l'auto-vectorisation dans les compilateurs et l'utilisation des flottants dans quasiment tous les languages de script. Je me trompe peut etre, mais c'est probablement du fait de leur volonte de faire le grand ecart entre Rocket et BOOM. Du coup, pour les avoir rencontre et avoir regarde le sujet de plus pres, tu en penses quoi ? C'est vraiment necessaire l'approche Rocket quand des projets comme j-core addresse deja ce marche ?
Par curiosite, j'ai juste regarde les exemples sur la premiere page de chisel, et ce n'est pas evident la difference avec VHDL. Tu pourrais un peu elabore ce que tu as appris sur le sujet ? Ou donner des pointeurs sur les morceaux que tu trouves interressant.
Sinon je n'avais pas vu pour le 5eme workshop. Vu que c'est a cote de chez moi, je viendrais bien. Tu as une date plus precise et une annonce pour s'enregistrer ?
[^] # Re: Materiel libre ?
Posté par cedric . En réponse au journal Le matériel libre où en sommes nous ?. Évalué à 3.
Oui, tout aussi interressant. Les auteurs du J2 ont d'ailleurs discuste avec l'equipe de riscv avant de partir sur le J2 et c'est sur leur recommendation qu'ils sont parti sur l'architecture du super hitachi. Mais partir de zero est bien plus complex et couteux, sans compter les risques des brevets qui sont plus difficile a trouver. Pas forcement un probleme pour le RISCV qui se veut plus une architecture pour la recherche.
Sinon tu penses a quelle architecture ?
[^] # Re: Materiel libre ?
Posté par cedric . En réponse au journal Le matériel libre où en sommes nous ?. Évalué à 10.
Juste pour réagir à ta remarque concernant les processeurs libres. C'est un sujet si l'intéressé énormément depuis bien longtemps. Du coup lors du derniers ELC, j'ai été très agréablement surpris par la présentation de l'équipe du J2. C'est gens ont compris pas mal de problème (efficience du jeu d'instruction, brevets, compilateur et portage d'os). Ils viennent juste de release leur premier code en vhdl sous licence bsd et sans brevet aucun sur leur site: http://0pf.org/.
Pourquoi c'est intéressant, parce que en faite ils ne font que reimplenter le super Hitachi ! Version 2 pour l'instant, mais la 4 devrait arriver en fin d'année, car les brevets auront tous expiré à ce moment la. Ils ont juste rajouter quelque primitive supplémentaire pour permettre le smp en se basant aussi sur une vieille architecture dont les brevets ont expiré. Du coup, on se retrouve avec une architecture complètement libre, plus efficace que arm et au niveau d'Intel sur la densité de code (arm avait à l'époque pris une licence des brevets d'Hitachi pour implémenter l'extension thumb). Cerise sur le gâteau, gcc et linux, voire même certaine distribution supporte déjà cette plateforme !
Enfin le coup de production part d'ancienne fab permet d'atteindre facilement 250MHz pour 25000$ par wafer. A priori, c'est le moment avec le ralentissement en Chine pour faire de petit batch. Toujours d'après les mêmes membre de l'équipe, ils sont déjà à un coup par cpu largement inférieur à arm du fait de l'absence de licence (sans compter le support logiciel). J'attend avec impatience de voir le multi coeur J4 !
[^] # Re: Bonus écologique, et puis quoi encore ?
Posté par cedric . En réponse au journal Moto journal: Le nucléaire passera-t-il ?. Évalué à 4.
Je suis a peu pres certain que ce n'etait pas ca que tu voulais dire. Du coup, j'en profites pour expliquer plus precisement le probleme du recyclage et des terres rares. Tout d'abord la raison de l'amelioration des cellules photovoltaique est du a l'utilisation de processus impliquant les terres rares, telle que le cadmium. Il y a d'ailleur une exclusion des panneaux photovoltaique des directive RoHS europeennes jusqu'en 2018. Maintenant toutes les technique de recyclage implique des pertes. A priori, on recycle les panneaux photovoltaiques jusqu'a 90%. Ce qui veut dire qu'on perd 10% de terre rare pour chaque panneau qu'on fabrique. Sur un stock finis et rare, c'est pas forcement le choix le plus judicieux…
Oui et non. Certe a MIPS equivalent, on a besoin de moins de ressource pour les produire. Par contre, la puissance des machines utilisees a continuer a augmenter de maniere exponentielle… Du coup, on utilise aujourd'hui plus de terre rare et d'energie pour tous les appareils electroniques qu'une personne utilise qu'il y a 20 ans. Est-ce que tu avais un telephone portable, un laptop a ecran plat, une tv a ecran plat, une set top box, un routeur, il y a 20 ans ? Et le recyclage des composant electronique est tres tres mauvais. Globalement, on ne recupere que un peu d'or, toutes les terres rares sont perdu et les autres metaux sont degrade pour des usages moins complexe.
Je veux bien un lien. Je n'ai jamais entendu parle de batterie aux graphenes, uniquement de super capacites.
Tu te rend bien comptes que personne ne fait ca ? On a aujourd'hui sur la planete 11min de batterie (Si on prend toutes les batteries utilisable). Tu sais aussi que les batteries ne s'ameliore pas comme la loi de Moore, mais suivent une courbe de seulement +10% tous les deux ans (Que tu peux repartir entre le poid, l'energie et la capacite de charge/decharge). Enfin, tu sais que tous les design de batteries consomme des ressources encore plus limite que le petrole. Les batteries les plus efficace requiere toutes des nanostructure tres difficilement recyclable.
Du coup, reste les STEP. Mais on manque de place et de site… Autant dire que non, les energies a faible densite ne sont pas plus une solution.
[^] # Re: Article interessant.
Posté par cedric . En réponse au journal Moto journal: Le nucléaire passera-t-il ?. Évalué à 5.
Il n'y a pas corrélation entre volume produit et prix du pétrole. Il y a une corrélation entre la différence consommée et produite, il y a aussi une corrélation avec la valeur du dollar. Ainsi se baser sur le prix pour estimer si on a passer le pic ou non n'est pas une bonne idée. De même cela renforce l'affirmation autre quand le pic sera passé on ne pourra pas investir, car le prix continuera de varier énormément entre les crises économiques du à une consommation atteignant la production et les reprises lorsque la consommation se sera effondré.
Note qu'on a passé en 2005/2006, le pic mondiale du pétrole conventionnel et qu'on a probablement passé celui du schiste l'année derrière étant donné les baisses de production actuelle. Dire que le pic du pétrole n'arrivera jamais, c'est juste ignoré l'histoire. Mais ne t'inquiète pas, on a encore le pic du gaz, du potassium, et de globalement toutes nos matières première pour réviser ca dans les 50 ans à venir.
[^] # Re: Bonus écologique, et puis quoi encore ?
Posté par cedric . En réponse au journal Moto journal: Le nucléaire passera-t-il ?. Évalué à 6.
Je crois que tu te meprends. Les panneaux photovoltaïques les plus performants utilisent des terres rares et des structures nanométrique qui rendent le recyclage extrêmement difficile du fait de l'intrication de tous ce petit monde. Sans compter que sans batterie, tu pars du principe que quelqu'un va consommer ou arrêter de produire quand cela t'arrange et payer rubis sur l'ongle quand tu produira (d'ailleurs quand tu y réfléchis, le photovoltaïque subventionné, c'est un moyen pour les riches d'investir sur le dos des pauvres)… Ah, oui, les batteries aussi pour être performante ne sont pas très recyclables…
[^] # Re: Bonus écologique, et puis quoi encore ?
Posté par cedric . En réponse au journal Moto journal: Le nucléaire passera-t-il ?. Évalué à 2.
J'espère que ton flair à tort, car je doute que la chandelle soit une solution… Il est intéressant de regarder comment nos voisins très organisés tente de sortir eux même du nucléaire et on déjà dépensé l'intégralité de ce que cela nous coûterait de remplacer nos centrale par des epr, alors qu'ils leur restent encore 20% de nucléaire et un paquet de charbon…
L'énergie pas chère, abondante et non polluante est un mythe. Il y a toujours des effets. Par exemple, si tu avais lu l'âge des low Tech, tu serais horrifiés de voir ce gaspi qu'est une éolienne ou la densification des lignes électriques…
La seule chose qui peut globalement résoudre nos problèmes énergétique, serait une énergie dense, compact à consommer, avec une capacité à s'adapter à la charge rapidement et stabilisant le réseau en évitant les emballement de fréquences. Idéalement il faudrait qu'on puisse l'utiliser aussi dans l'espace très rapidement (étant donné nos consommation de matières premières, probablement 30 à 40 ans). Des propositions ?
[^] # Re: Bonus écologique, et puis quoi encore ?
Posté par cedric . En réponse au journal Moto journal: Le nucléaire passera-t-il ?. Évalué à 2.
https://fr.m.wikipedia.org/wiki/R%C3%A9acteur_nucl%C3%A9aire_naturel_d%27Oklo
Bonne lecture.
# Le scheduler, il est a l'ouest !
Posté par cedric . En réponse au journal Linux: une décennie de coeurs gaspillés. Évalué à 6.
Clairement le scheduler du noyau Linux a plus d'un probleme. Un des sujets non aborde dans l'article, qui est tres interressant. C'est les problemes de consommation d'energie et de scheduling lie a cela. Typiquement sur les taches interactives fonctionnant avec un device sur batterie, le scheduler est globalement toujours faux.
Le principe du scheduler est de regarder le passe d'une tache pour en deviner son usage futur. Le probleme des taches interactives, c'est que par design le process principal fait un peu de tout a une frequence eleve (Hop, une IO, un peu de CPU bound pour calculer le nouveau layout, puis un peu de memory bound pour regarder si il y a des trucs a dessigner, …). Il devient assez evident que ce qu'une tache a fait dans le passe aide peu.
La solution evidente, c'est de creer plusieurs process/thread qui chacun doit faire un seul truc. Meme si ils ne sont pas execute en parallele et si ils consomment plus de RAM, au final, le noyau devrait etre capable de scheduler tout ca de maniere plus efficace… Sauf que non, pour tout un tas detail, qu'on peut resumer a la non integration de cpufreq et cpuidle dans le scheduler, le noyau est incapable d'utiliser les ressources du materiel de maniere optimal. On se retrouve alors avec des gros hack pas beau. Comme par exemple sur certain telephone ou un process en tache de fond regarde quel est l'application active et change les parametres de frequence et du nombre de CPU en fonctionnement pour avoir un resultat un peu plus optimal… Gros hack, franchement pas terrible.
Tout ca pour dire que sans le boulot en court du scheduler energy aware, et bien, on a encore de la marge… Oh, et bien entendu, l'user space doit aussi s'adapter ! On a encore du boulot pour quelques annees…
# Securite
Posté par cedric . En réponse à la dépêche Subuser, une sur‐couche à Docker. Évalué à 6.
Il n'y a que moi que ca derange cette approche du courcircuitage des distributions pour aller plus vite dans la gestion des problemes de dependences… sans addresser un moyen robuste de mettre a jour les tonnes de bibliotheque duplique !?! Heureusement que Linux sur le Desktop, c'est pas pour demain, sinon on est bien parti pour faire aussi bien que Windows…
[^] # Re: Petite erreur
Posté par cedric . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). Évalué à 2.
Ok, donc on parlait bien de la meme chose, juste ta phrase etait un peu confuse pour moi, car quand on parle de geometrie, on parle generalement de la geometrie de la fenetre.
En fait, ce genre d'appareil n'est pas necessaire. Tu peux juste mesurer a l'aide d'un timestamp general au systeme quand tu recois un input et quand tu pousses un buffer avec le changement resultant de cet input a l'ecran. Avec un peu de bidouillage dans le protocol wayland et dans le toolkit de l'application, tu peux assez facilement propager ce timestamp de l'input au buffer d'output pour collecter ces informations. En correlant ces informations avec la vsync, tu pourras facilement voire lorsque tu perds des frames.
L'utilisation principal des cameras hautes vitesse que l'on (Samsung) a, c'est pour essayer de "voir" exactement ce que contient une frame avec un glitch graphique (Generalement du a un bug de driver). Pouvoir verifier les pixels a la sortie de l'ecran frame apres frame. On les utilise aussi lorsqu'on a des problemes d'input qui envoie en fait l'information trop tardivement. Mais a part un probleme reellement lie aux drivers, c'est rarement utilise, car franchement pas pratique comme outil d'experimentation et sans valeur ajoute pour la majorite des cas.
Par contre ce qui est amusant, c'est que apres avoir travaille suffisament longtemps dans ce domaine, tes propres yeux savent "sentir" un glitch, un lag, un frame drop. Tu peux meme avoir une estimation du framerate juste avec tes yeux et estimer le lag d'une application en nombre de frame. C'est, je trouve, plus dur de venir avec un chiffre correct pour l'estimation du lag au juge, mais definitivement tu le sens quand ce n'est pas bon.
[^] # Re: Petite erreur
Posté par cedric . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). Évalué à 2.
Desole, je n'ai pas acces au code de Mac OS X et je n'ai aucune idee de ce qu'ils font. Par contre, je suis nettement plus a l'aise avec Weston et Enlightenment. Weston supporte aussi le scaling, si j'ai bien compris ce a quoi cela correspond dans Mac OS X. Globalement changer la taille d'un buffer est supporte par les unites de scanout moderne (En tout cas celle de telephone mobile auquel j'ai acces et a priori Intel, mais je n'ai pas verifier).
Globalement le principe est le suivant, quand tu ne peux pas utiliser le "compositeur" simple qui se trouve dans le scanout, tu fallback sur l'utilisation du GPU effectivement (Cela frame apres frame). Maintenant les conditions dans lesquels tu peux utiliser l'unite de scanout uniquement varie d'un hardware a l'autre. Pour faire simple, la plus part support up et down scaling de 5 plan graphiques avec des characteristiques de colorspace qui alloue en general un ou 2 plan YUV et un certain nombre de plan RGBA (Oui, cela inclut la transparence). Ce nombre de plan graphique peut aussi varier en fonction du nombre d'ecran. Ainsi si tu as 2 ecrans, mais que tu as un total de 5 plans, tu te retrouves effectivement a devoir les partager entre tous les ecrans.
Enfin, dans le cas de Weston/Wayland, seul les applications qui fonctionnent en utilisant wayland_gl, ont un interet a etre mis dans un plan hardware (Ca ne couvre pas le terminal par exemple). Celles qui passent par wayland_shm, finissent, a priori, dans un buffer qui devrait etre copie de toute facon vers un nouveau buffer drm pour pouvoir se passer du GPU. Mais cette copie revient techniquement exactement au meme que de passer directement par le GPU avec un support de la mise a jour partiel de buffer pour faire la copie (J'avoue ce n'est pas toujours aussi tranche et des fois il vaut mieux passer faire une copie depuis le CPU dans un buffer drm que de passer par le GPU pour des raisons de consommation d'energie).
Enfin quand tu dois renoncer temporairement a l'utilisation direct de l'unite de scanout, par exemple lorsque le compositeur fait lui meme une animation (a la compiz), ce n'est pas un vrai probleme. Dans ces cas la, tu pourrais meme faire tomber le framerate des applications a 30 fps et reduire de moitie leur resolution que personne ne s'en renderait compte en fait ! Du moment que l'animation du compositeur lui meme est reactive et s'execute a 60fps, personne ne se rendra compte que tu as temporairement diminue les performances de l'application. Sur un PC, tu n'as probablement peu de cas ou tu aurais besoin de faire de tel choix, mais sur un mobile, cela arrive que tu sois limite en bande passante GPU/CPU au point ou tu doivent faire ce genre de chose.
Donc le cas principale d'utilisation est bien l'utilisation unique de l'unite de scanout. J'entend bien par cela le temps d'utilisation d'une application a l'ecran dans une situation interactive.
[^] # Re: Petite erreur
Posté par cedric . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). Évalué à 4.
On est bien d'accord que dans le cas de la fenetre ayant le focus ou dans le cas d'une application plein ecran, le compositeur ne dessine rien. Il ne fait que dire a l'entite de scanout d'afficher le dit buffer directement a l'ecran. Exactement la meme operation que ferait une application qui a directement acces a l'ecran. Il n'y a pas de surcout dans ce cas.
La latence dont on parle ici est de deux context switch. Dans le pire cas, cela represente, sur une machine de moins de 5 ans, moins de 1% des 16ms que ton application va utiliser pour dessiner une frame. Les chances de manquer la deadline a cause de ces deux context switch est franchement tres tres tres basse. La variabilite reste sur juste quelques choses >1%, donc j'ai du mal a voir en quoi tu peux imaginer que c'est la que ce trouve le probleme. Est-ce que tu as des mesures qui montre des problemes de ce cote la ?
Je pense que ton probleme pour l'instant, c'est que tu n'as pas de benchmark qui montre ton probleme. Si tu essayes de convaincre qui que ce soit qui connait le sujet et bosse dans le domaine, ils auront beaucoup de mal a te croire voir meme a faire l'effort de faire un benchmark eux-meme pour verifier tes dires. Essaye d'en construire un et d'analyser le comportement du systeme. Je serais interresse de voir des traces de latence ou l'on voit le probleme de stabilite d'une animation dont tu parles. Je te conseille de le construire au dessus de Weston. Cela te donnera aussi une bonne idee de comment marche la stack graphique.
Alors la, je ne te suis pas du tout du tout ! En quoi le positionnement d'une fenetre va avoir le moindre impact sur les performances !?! Relis mes postes plus haut sur l'utilisation des plan hardware.
[^] # Re: Petite erreur
Posté par cedric . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). Évalué à 4.
J'ai pourtant bien explique pourquoi on avait du double ou triple buffer et pourquoi cette latence etait necessaire techniquement. Tu as toujours un framebuffer, que ce soit lorsque tu passes par un compositeur ou non. Le GPU ne dessine jamais directement a l'ecran (Il ne dessine d'ailleur generalement pas dans tout le framebuffer, mais par zone appele tile pour des raisons de cache et de calcul parallele). C'est inherent a comment fonctionne tous les accelerateurs 3D. Ceux-ci remplisse un buffer, qui sera pousse sur le scanout qui l'affichera l'ecran. Quand tu parles de latence, tu parles du temps necessaire entre la reception d'un input et sa reaction visible a l'ecran.
L'objectif etant que la prochaine frame affiche apres cet evenement le soit le plus tot possible. Il y a deux cas. Soit tu as deja commence a dessiner une image et tu vas perdre le temps de ta vsync + 16ms (sur un ecran a 60hz). Soit tu n'as pas encore commence a dessiner une image, auquel cas, tu auras moins de 16ms avant ta prochaine image qui aura l'input correct. Ca c'est dans le cas du double buffer avec aucun compositeur (Je laisse de cote le cas du triple buffer).
Maintenant en quoi le probleme change si tu as un compositeur dans l'histoire, tu as juste deux etapes supplementaire. L'input est d'abord lu dans le process du compositeur et envoye au jeu. Celui-ci se retrouve alors dans la meme situation que precedemment seulement, il n'a plus 16ms, mais 16ms - le coup du context switch pour l'input. Mais comme cela ne s'arrete pas la et qu'il te faut aussi faire un autre context switch pour pousser le buffer a l'ecran, tu te retrouves avec globalement 16 ms - 2 * context switch. Le reste est strictement egal par ailleur.
Le veritable probleme est donc bien de maintenir le maximum de stabilite dans la capacite de ton process a pouvoir pousser une frame toutes les 16ms.
[^] # Re: Petite erreur
Posté par cedric . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). Évalué à 2.
Mon explication n'a pas du etre evidente sur le sujet. Le compositeur recoit un EGLImage directement qu'il va lier directement a un plan hardware. En gros, ca part direct sur le scanout sans repasser par le GPU, donc pas de copie. Et il faut maintenir ce buffer dans cette position tant que l'image est affiche a l'ecran. Cela que ce soit le job du compositeur ou du jeu.
Alors il y a des coups, mais principalement que celui du changement de contexte. Mais si tu fais cela dans le meme process, tu as exactement la meme contrainte, la seule chose que tu vas eliminer, c'est le coup du changement de process. Le reste restera la. Binder le buffer au scanout est un besoin technique, ainsi que se synchroniser sur la vsync. La seule difference, c'est qui le fait et par ou ca passe.
C'est bien pour ca que je ne pense pas que le coup de passer par un compositeur soit si problematique. Ton OS fait des changements de process en permanence. Tu as toujours plusieurs applications qui tournent et qu'il faut scheduler sur plusieurs CPU. Je doute tres tres fortement que c'est la source de probleme aujourd'hui.
Je serais bien plus facilement convaincu, si on parlait de la difficulte en OpenGL de faire du multi thread, d'uploader une texture en zero copie, de melanger calcul CPU/GPU et rendu graphique… Je pense que Vulkan va permettre de lever bien plus de probleme de fluidite que la possibilite de rendre directement a l'ecran sans passer par un compositeur (et encore cela necessite de revoir profondement la maniere dont fonctionne les moteurs graphiques).
Apres on peut aussi parler des problemes du scheduler du kernel, incapable de nos jours de faire un boulot correct lorsqu'on est sur batterie ou qu'on ne lui demande pas de pousser la machine en permanence a fond (Je vais me faire de la pub sur le sujet, mais tu peux lire : http://blogs.s-osg.org/introduction-problems-modern-linux-kernel-cpu-scheduling/ et http://blogs.s-osg.org/improving-user-space-take-advantage-kernel-scheduler-evolution-better-energy-efficiency/). Et je peux te promettre qu'aucun code user space n'est pres pour utiliser correctement un scheduler qui n'est pas lui meme pres :-D
Globalement, je suis d'accord sur le diagnostic. On a des problemes de performance et de stabilite du frame rate sous Linux et il y a du boulot pour avoir des animations fluides, mais la solution n'est pas la ou tu penses :-)
# Petite erreur
Posté par cedric . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). Évalué à 9.
Juste un point que tu as peut etre manque, avec Wayland, tu n'envois pas une bitmap qui sera copie par le serveur, mais un buffer qui pourra etre utilise directement par le compositeur. Dans le cas ou ton compositeur fonctionne en software, bon, pas trop de chance, tu vas devoir faire un memcpy. C'est pas comme si tu avais le choix. Dans le cas ou ton compositeur fonctionne avec drm et autorise wayland_egl pour tes applications, celui-ci va recevoir un EGLImage qu'il pourra mettre directement dans un plan hardware sans meme faire de composition (GPU ou software).
Cela veut dire deux choses, tout d'abord une commande est courte, c'est juste une serie de buffer, plus la region de ces buffer qui a ete mis a jour. Ensuite contrairement a X, le compositeur peut utiliser le buffer directement (donc le bloquer temporairement) meme pour une application qui n'est pas full screen si le hardware qui gere les plans graphiques autorisent le layout actuellement a l'ecran (Pour l'instant, c'est globalement la top window qui sera dans son propre plan hardware). Ce qui permet d'avoir les perfs du full screen meme quand on n'est pas en fullscreen (Bon, c'est non trivial a implementer et il y a encore du boulot dans tous les compositeurs wayland sur le sujet).
Tu conviendras que contrairement a envoyer un buffer de commande qui peut etre mal interprete par le compositeur et plutot long, tu as un pipeline plutot simple avec peu d'erreur potentiel et court. Aussi un autre point que tu n'as pas mentionne, mais les API modernes tel que Vulkan permette de faire du calcul sur le GPU dont tu obtiens le resultat pour le reutiliser potentiellement par le CPU. Dans ton modele, ca fera un round-trip supplementaire assez couteux a mon avis (sans compter la complexite a gerer les aller-retour).
Enfin concernant la latence des frames a l'affichage. Tout d'abord la raison pour laquelle les flux videos ont generalement une dizaine de frame bufferise est du au codec qui a des images partielles qui references des images dans le passe et le futur. Si tu n'avais pas autant de frame bufferise, tu ne pourrais juste pas les decoder :-) La solution est plutot effectivement d'ajouter un timestamp sur les dites frames pour les presenter le plus tot possible aux compositeurs et lui permettre de les afficher au bon moment (encore une fois, c'est un boulot important que chaque compositeur va avoir a implementer lui meme, donc ca prendra du temps avant d'etre utilisable).
Pour ceux qui est des applications 3D, la raison est assez simple. Tu as besoin de 3 buffers en general pour ne pas bloquer ton pipeline de rendu graphique. L'idee est que tu as actuellement un buffer bloque dans un plan hardware, car il est affiche. Tu as la frame suivante qui est pret a etre affiche, mais le switch de plan hardware au nouveau buffer n'a pas encore eu lieu, donc tu ne as un deuxieme buffer cote serveur en attente. Enfin l'application elle meme est prete a dessiner et decide que plutot que d'attendre que le serveur lui dise de dessiner une frame, elle va le faire en avance. Resultat, tu as effectivement besoin de 3 buffer pour ne jamais bloquer dans le scenario ou tu pousses tes frames sans te synchroniser avec le display server.
Maintenant si tu utilises le frame callback de wayland, tu auras toujours un buffer de bloque dans le hardware plane, mais wayland te dit que maintenant qu'il va affiche un nouveau buffer en fonction de la vsync de l'ecran. Donc tu n'envoie un buffer que lorsque celui ci te le demande. Et tu n'as besoin que de deux buffers. Le second avantage est que tu pousses a l'ecran une image de ton application qui est le reflet exacte de ce qu'elle est cense etre durant cette vsync. Par contre, cela veut dire que tu n'as besoin que du temps de la vsync pour dessiner une frame. Cela peut etre trop court pour certain jeux complexe.
[^] # Re: Lien rapide avant une réponse plus complete!
Posté par cedric . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). Évalué à 5.
Je ne suis pas fan personnellement. La complexite de la gestion du multi ecran, de kms/drm/dmabuff est suffisament eleve pour dire qu'a minima il faudrait avant de pouvoir realiser cela une bibliotheque partageant le boulot (clairement quelque chose que devrait fournir le projet wayland, mais c'est une autre discussion).
Le second probleme que je vois, c'est qu'on repasse en mode cooperatif totalement. Si le jeu n'est pas capable de gerer alt-tab, et bien on reste coince dans le jeu. D'un point de vue securite, c'est juste une potentiel horreur a gerer. On perdrait aussi la possibilit d'avoir un ecran dedie a irc/chat d'un cote et au jeu de l'autre.
Surtout que je ne suis pas convaincu que ce soit un vrai probleme. Si le compositeur ne fait que mettre les buffers gl dans un plan hardware directement, le coup est globalement uniquement sur le switch de context a 60fps. C'est franchement pas la mer a boire pour un PC meme de 10 ans d'age…
[^] # Re: Lien rapide avant une réponse plus complete!
Posté par cedric . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). Évalué à 2.
Par design, tu ne peux pas courcicuite X, si tu parles au serveur X :-) Ce que propose Martin, c'est de ne plus faire les round trip avec le serveur wayland ou X. Dans les deux cas, tu as une latence sur l'input et l'output vu qu'ils sont tous les deux gere par le serveur (X et Wayland) avec un peu plus de probleme potentiel avec le serveur X etant donnee que tu peux passer par un compositeur pour l'output.
D'ailleur le seul cour circuit qui existe sur X, c'est le cour circuitage du compositeur pour les fenetres pleins ecran si il l'autorise. Et c'est tout.
[^] # Re: Remarque à la c...
Posté par cedric . En réponse à la dépêche Servo fin 2015 : où en est-on ?. Évalué à 7.
Le "truc" amusant actuellement, c'est que le noyau Linux est tres mauvais a estime la bonne frequence et le nombre de CPU au bon moment. Les systemes de cpu idle et de cpu freq etant decouple du scheduler qui lui meme perd tout l'historique des qu'il bouge une tache sur un nouveau coeur. Le resultat actuel, c'est que le CPU se retrouve dans les taches graphiques souvent a la mauvaise frequence au mauvais moment.
La raison est simple, vous avez une serie de tache globalement plutot seriel, qui enchaine une etape IO bound, MEM bound, CPU bound, MEM bound, pour retourner en IO bound. Le tout par cycle de 16ms.
Le probleme est connu, et c'est pour cela qu'il y a du travail sur la gestion d'energie et le scheduler en cour. Mais cela affecte aussi l'user space. Le noyau n'a des statistiques que par process, il ne sait pas si un bout de code est IO, MEM ou CPU bound. Par contre, un process, a terme, il saura quel est potentiellement la frequence ideal de fonctionnement. Cela n'est vrai bien entendu que si dans un meme process ne tourne que des taches qui ont les meme proprietes !
Donc il faut bien s'orienter vers du multi thread, mais les mesures actuelles de consomation ne sont probablement pas tres pertinente tant que le noyau n'aura pas ete corrige.
Pour une explication potentielle du pourquoi, 2 * 50%, c'est mieux que 1 * 100%, c'est probablement lie a la disponibilites de plus de bande passante memoire du cache L1 (un par core) qui permet d'eviter des acces dans les sous systemes memoire plus lointain et plus couteux en energie pour y acceder (Acceder un registre etant moins energivore qu'un acces en L1, un L1 moins qu'un L2 et un L2 moins qu'un acces en RAM). C'est potentiellement une explication que je vois, surtout si la frequence des core est alors adapte a la consommation de bande passante memoire offert par le cache.
# astuce sécurité pour les paranoïaques
Posté par cedric . En réponse au journal SSHFS est un vrai système de fichiers en réseau. Évalué à 0.
Si tu l'utilise en conjonction avec encfs sur le client, tu auras une solution où le risque pour les données qui quittent ton pc sera nul. Chiffrement local des données avant de les envoyer sur le réseau et protection Man in the middle/interception avec ssh. Probablement ce que l'on fait de mieux en terme de sécurité.
[^] # Re: Bof Bof
Posté par cedric . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 4.
Ca dépend ! Si tu utilises un compositeur, je suis près à parier qu'il recompose la surface yuv dans le buffer écran. Le seul cas à peu près gérer, c'est le cas plein écran et encore il y a pas mal de driver qui ont des problèmes…
Et comme dit Martin, pour wayland, il y a encore beaucoup de boulot pour tout le monde ! Du kernel aux applications, il y a plein de chose a juste faire marcher. On en est pas encore aux optimisations. Même si l'architecture de wayland devrait rendre les choses plus facile. Peut être dans le courant de l'année prochaine…
# Mail entrant
Posté par cedric . En réponse à la dépêche Own-Mailbox: la boite mail confidentielle qui vous appartient vraiment!. Évalué à 3.
Il y a un truc que je n'ai pas compris. Si on envoie un mail non chiffre sur une adresse d'un serveur gere par Own-Mailbox, est-ce que ca marche ? Et est-ce que de maniere automatique le systeme detecte que le mail n'est pas chiffre et le chiffre avec la clef publique du/des destinataire locaux pour eviter toute compromission du mail si quelqu'un avait un acces future a la machine (A la gpgit) ? Est-ce que le systeme de backup permettrait d'avoir cette fonctionnalite aussi sur les backup ?
De la meme maniere, quels sont les defenses mise en place pour limiter la compromission de la machine herbergeant Own-Mail ?
[^] # Re: YakaFokon : ouvrir le courrier du voisin
Posté par cedric . En réponse au journal Adoption du projet de loi relatif au renseignement en première lecture. Évalué à 4.
La definition n'est pas debile, mais elle a des implications techniques tres differente. Quand on parle de meta data et que cela ne concerne que la couche IP, on n'est pas intrusif comme on peut l'etre lorsque on recupere les meta data du protocole SMTP. Mettre tout dans le meme sac est au mieux brouillon, au pire une tentative d'enfumage.
Dans tous les cas, la semantique de meta data est suffisament flou pour assumer que cela veut dire DPI. On peut avoir un discour philosophique sur ce que veut dire meta data, mais au final, c'est la technique qui compte. Et la ca veut dire, j'ouvre la lettre et je regarde ce qui m'interresse dedans a ma convenance.
[^] # Re: YakaFokon : ouvrir le courrier du voisin
Posté par cedric . En réponse au journal Adoption du projet de loi relatif au renseignement en première lecture. Évalué à 5.
Ou inversement, quelqu'un qui ne connait pas la technique penserait que observer les "meta-data" est comme lire l'enveloppe d'une lettre. Sauf que techniquement, il faut l'ouvrir pour pouvoir voir certaine de ces meta-data. Ce qui fait qu'on est deja entrain de parser le stream et franchement si on en est a sauvergarder, le from/to d'un mail… autant y ajouter le subject et pourquoi pas le corps. Il n'y a techniquement plus de difference a partir du moment ou on est brancher sur le niveau applicatif.
Ou parfaitement conscient qu'il met en place un systeme de DPI. Ceux qui ne le sont pas, ceux sont ceux qui croit que les meta data dont on nous parle ici sont accessible sans regarder le contenu, les data. Or c'est faux !