Skylake a reçu l'acceleration 2D que très récemment. Cela dit, même sans, je vois quand même dans tous les benchmarks que modesetting est bien moins performance que le pilote xf86-video-intel.
Du coup, je me demande si la personne utilise un processeur Skylake et quel DE cette personne utilise? Perso, je suis au courant de bien plus de problèmes avec modesetting que Intel.
Euh, presque personne n'est en IPv6-only et ce n'est pas recommandé. Du coup, je pense qu'une question plus pertinente serait:
Comment se passe votre utilisation d'IPv6?
- Je n'en veux pas, IPv4 fait ce que je veux
- Mon fournisseur d'accès ne me donne pas d'IPv6 et je ne veux pas monter de tunnel, j'attend!
- Mon fournisseur d'accès me permet d'utiliser IPv6, mais je l'ai désactivé car ca m'apportait plus de problèmes que de solutions
- Je suis en Dual stack v4-v6: J'ai des problèmes de timeout avec certains sites mais je suis quand même content
- Je suis en Dual stack v4-v6: Tout se passe super
- Je suis en IPv6-only: J'ai des problèmes de timeout avec certains sites mais je suis quand même content
- Je suis en IPv6-only: Tout se passe bien
Et sur ce, je prédis que tous les utilisateurs v6 diront "Je suis en Dual stack v4-v6: J'ai des problèmes de timeout avec certains sites mais je suis quand même content". Et la majorité des autres diront "Mon fournisseur d'accès ne me donne pas d'IPv6 et je ne veux pas monter de tunnel, j'attend!".
C'est ca, sans la gestion atomique des plan graphiques, on ne peut pas garantir quand la mise à jour se fera, donc on doit toujours utiliser les shaders ou tjs utiliser le meme plan graphique pour la meme fenêtre (si l'on se fiche de faire des captures d'écran).
Bon, avec un peu de chance, ils vont beneficier des outils développés par nouveau pour savoir ce que fait exactement chaque instruction du GPU. Je me demande si Vulkan va pouvoir les aider car ils pourront traduire ca en SPIR-V. Reste à savoir comment les applications utilisaient le GPU à l'époque et si la création de pipeline states sera pas un facteur limitant les performances!
Quant au merge des équipes, le pilote Vulkan sera développé en Open Source (pas initialement, mais presque). Du coup, il restera que OpenGL et quelques petites extensions proprios. Tout le reste sera libre bientôt! Source: Slide 4 de http://www.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf
J'en ai parlé avec Alex Deucher, et il a confirmé que les gens de Catalysts se mettaient au dev Open Source :)
Cool! Tu te mets en mainteneur de système de fichiers? Et pourquoi pas aussi bosser sur la partie audio (ça doit pas être trop dur vu le peu de changements)?
Si tu n'as pas d'acceleration matérielle, alors ca n'a aucun intérêt que X ou un compositeur wayland gère le YUV car il va devoir faire la conversion lui même en utilisant le CPU! Le seul but de garder le format original dans le conpositeur, c'est de pouvoir utiliser les plans graphiques pour faire la transformation colorimétrique en matériel ou, au pire, avec des shaders.
X supporte depuis des années de faire passer des images en YUV, via XV. Pitivi peut utiliser ca! Pas besoin de DRI2/3. D'ailleurs, je ne me souviens pas que DRI3 supporte de multiples formats, mais c'est possible.
Concernant Wayland, y'a encore pas mal de problèmes a résoudre mais les plans graphiques universels aident beaucoup pour exposer de façon uniforme entre les pilotes ces plans. C'est pas encore parfait car les informations de format sont pas assez évolués pour vraiment exploiter au max le matériel (compression et options de pavage)! On y travaille mais faudrait déjà que Wayland s'impose pour que nos employeurs nous laisse y bosser plus :p On y arrive!
Je trouve au contraire que "systèmes monopuce" est une excellente traduction de SoC, c'est presque une relation 1-1.
Cela dit, je comprend ta remarque sur la francisation a outrance. J'ai aussi vécu au Canada. Perso, je n'utilise presque aucun mot que j'utilise dans la dépêche dans la vie de tous les jours car personne d'autre ne les connait, mais c'est ma faute et j'aimerai bien éviter qu'on se retrouve avec une langue ou la moitié des mots sont d'origine étrangère avec une prononciation vraiment différente (Hello Canada!). On est un des rare pays a avoir une seule langue comprise et utilisée en majorité par tout les habitants des pays francophones et si on commence a faire ca, on va encore plus diverger. Il est totalement possible d'avoir plusieurs mots dans différentes langues sans trop s'embrouiller!
Je vis actuellement en Finlande ou une bonne majorité des habitants est bilingue (Finlandais, Anglais) ou trilingue (Finlandais, Suédois et Anglais). Il y a quelques mots importés en Finnois, mais la majorité ne le sont pas (et c'est un bonheur d'apprendre des mots qui n'ont aucune racine grecque ou latine, hmm hmm). Même les ingénieurs a Intel Finlande utilisent très peu l'anglais quand ils parlent entres eux. Alors oui ça donne des mots bien rigolos (PC = tietokone = knowledge-machine) mais au final, y'a plein de mots composés qu'on a qui ne veulent rien dire, surtout chez les animaux :D Tant que le mot est unique, c'est tout ce qui importe.
TL;DR: Pour résumer, on est dans une situation ou il y a de nouveaux mots anglais qu'on ne prend pas le temps de traduire ce qui fait quand une traduction est proposée, c'est limite déjà trop tard. Je n'aime pas les langues ou la moitié des mots viennent d'autres langues (canada et certains pays du Maghreb font ça avec le fr, du moins a l'oral). Ce n'est pas un probleme d'avoir plusieurs mots pour designer la même chose tant que c'est dans une autre langue. Du coup, je pense que le meilleur endroit pour faire connaitre des nouvelles traductions est dans les articles techniques tels que cette dépêche et je suis content qu'on le fasse, même si parfois on oublis de marquer le mot original et si ça fait un poil chier de devoir apprendre de nouveaux mots.
Hey, tu veux aider sur la partie graphique? Je dis pas non!
Disons que je fais en fonction du temps disponible. Il y a beaucoup de variance suivant les releases aussi. Quand je comprend tout se qu'il se passe, j'ai peu de boulot a faire en plus de regarder les pull requests sur dri-devel et la liste des commits. Du coup, je dirai que tout écrire serait l’équivalent de 5-10h.
Parfois, les pull requests sont peu clairs et je regarde les commits, les bug reports associés et les articles de blog. Par exemple, je n'avais aucune idée que les télés avaient un espace de couleur différent des écrans de PC! Ça m'a prit une grosse demi heure de lecture en partant de l'acronyme pour avoir une bonne compréhension des patchs! Pareil sur PPGTT, les commits sont pas fait pour etre compris par ceux qui n'ont pas lu la doc, alors il faut se renseigner avec des ressources publiques (les ingés intel bloguent pas mal!) et la, on peut facilement passer 1 ou 2h sur un paragraphe.
En général, je passe une soirée pour collecter les liens + écrire la partie DRM. Ensuite je passe une soirée par gros driver (intel, radeon et nouveau). Je réserve ensuite une demi soirée pour les pilotes ARMs.
Concernant le travail d’édition, c'est probablement une vingtaine d'heure si on veut bien faire! Il faut tout homogénéiser, organiser, relancer les contributeurs, etc… Récemment, ce travail s'est résumé a faire plusieurs relectures et bouger les paragraphes qui n'ont rien a faire dans Arch/, mais c'est pour ça que je résigne! Je ne fais plus un bon boulot!
Disons que je sais pourquoi je fais le travail sur la partie graphique (apprendre et me tenir a jour), concernant l’édition, c'est vraiment pas ma passion mais je le faisais, faute de trouver quelqu'un d'autre pour le faire!
La majorité du code du noyau est due aux pilotes. De ce coté la, tu peux attendre une meilleure gestion du matériel existant, meilleures performances, moins de bugs.
De temps en temps, il y a de nouvelles interfaces qui apparaissent et qui, quelques mois plus tard, sont utilisées par des programmes que tu utilises. Sans le savoir, tu vas probablement donner tout le mérite au développeur de cette application, alors que c'est un travail partagé! Par exemple, les namespaces permettent a systemd beaucoup de choses telles que rendre certains dossiers inaccessibles a certains services (sans avoir a changer les droits). Une autre est la gestion atomique du mode graphique qui va permettre aux compositeurs Wayland d'utiliser les plans graphiques matériels pour faire la conversion d'espace colorimétrique de façon transparente ce qui va permettre de réduire la consommation électrique!
Au final, le noyau n'est pas sensé être visible donc ce n'est pas étonnant que tu ne te rendes pas compte des changements!
Pour le coup, je n'ai aucune idée! je suppose que Radeon devrait pouvoir gérer ca plus ou moins rapidement. Cela dit, je doute qu'il soit possible de faire de l'adaptative-sync sur du hw pas prévu pour!
# Skylake?
Posté par Martin Peres (site web personnel) . En réponse au journal Les drivers Xorg inutiles avec un noyau récent?. Évalué à 10.
Skylake a reçu l'acceleration 2D que très récemment. Cela dit, même sans, je vois quand même dans tous les benchmarks que modesetting est bien moins performance que le pilote xf86-video-intel.
Du coup, je me demande si la personne utilise un processeur Skylake et quel DE cette personne utilise? Perso, je suis au courant de bien plus de problèmes avec modesetting que Intel.
[^] # Re: Cette question n'a pas vraiment de sens...
Posté par Martin Peres (site web personnel) . En réponse au sondage Utilisez-vous IPv6 ?. Évalué à 2.
Pas con ca! Merci pour l'info!
# Cette question n'a pas vraiment de sens...
Posté par Martin Peres (site web personnel) . En réponse au sondage Utilisez-vous IPv6 ?. Évalué à 10.
Euh, presque personne n'est en IPv6-only et ce n'est pas recommandé. Du coup, je pense qu'une question plus pertinente serait:
Comment se passe votre utilisation d'IPv6?
- Je n'en veux pas, IPv4 fait ce que je veux
- Mon fournisseur d'accès ne me donne pas d'IPv6 et je ne veux pas monter de tunnel, j'attend!
- Mon fournisseur d'accès me permet d'utiliser IPv6, mais je l'ai désactivé car ca m'apportait plus de problèmes que de solutions
- Je suis en Dual stack v4-v6: J'ai des problèmes de timeout avec certains sites mais je suis quand même content
- Je suis en Dual stack v4-v6: Tout se passe super
- Je suis en IPv6-only: J'ai des problèmes de timeout avec certains sites mais je suis quand même content
- Je suis en IPv6-only: Tout se passe bien
Et sur ce, je prédis que tous les utilisateurs v6 diront "Je suis en Dual stack v4-v6: J'ai des problèmes de timeout avec certains sites mais je suis quand même content". Et la majorité des autres diront "Mon fournisseur d'accès ne me donne pas d'IPv6 et je ne veux pas monter de tunnel, j'attend!".
[^] # Re: Bilan en chiffre
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.5. Évalué à 2.
C'est ca, sans la gestion atomique des plan graphiques, on ne peut pas garantir quand la mise à jour se fera, donc on doit toujours utiliser les shaders ou tjs utiliser le meme plan graphique pour la meme fenêtre (si l'on se fiche de faire des captures d'écran).
[^] # Re: Bilan en chiffre
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.5. Évalué à 5.
Ouais, sauf que ca marche pas comme ca ;)
http://www.nytimes.com/2013/04/21/jobs/deadline-pressure-the-great-motivator.html?_r=0
[^] # Re: QEMU
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.4. Évalué à 6.
Bourrins! Non mais sérieux, c'est des malades…
Bon, avec un peu de chance, ils vont beneficier des outils développés par nouveau pour savoir ce que fait exactement chaque instruction du GPU. Je me demande si Vulkan va pouvoir les aider car ils pourront traduire ca en SPIR-V. Reste à savoir comment les applications utilisaient le GPU à l'époque et si la création de pipeline states sera pas un facteur limitant les performances!
[^] # Re: QEMU
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.4. Évalué à 5.
Euh, non, ca va pas le faire. Faudrait écrire un pilote 3D pour windows…
[^] # Re: Erreur?
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.4. Évalué à 3.
Euh, oui! Désolé!
[^] # Re: QEMU
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.4. Évalué à 5.
C'est pas encore vraiment hyper stable, mais ca arrive!
[^] # Re: QEMU et accelération 3D
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.4. Évalué à 3.
Oui, il y en a une, OpenGL 3.3. Ca devrait être étendu dans le futur :)
# Lien rapide avant une réponse plus complete!
Posté par Martin Peres (site web personnel) . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). Évalué à 9.
Je pense que c'est encore une idée qui sous estime plein de problemes.
J'aime bien cette idée là par contre: https://blog.martin-graesslin.com/blog/2015/12/gaming-on-linux-move-to-next-generation/
# Felicitations!
Posté par Martin Peres (site web personnel) . En réponse à la dépêche DragonFly BSD 4.4. Évalué à 5.
Bravo Francois pour ton travail à la fois de développement et de rédaction de cette dépêche! Au plaisir de te recroiser (FOSDEM et/ou XDC)!
[^] # Re: Radeon versus commerce
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.2. Évalué à 3.
Yep, c'est ce que j'ai compris de nos discussions :)
[^] # Re: Radeon versus commerce
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.2. Évalué à 8. Dernière modification le 22 septembre 2015 à 15:13.
La partie noyau sera écrite qu'une seule fois.
Quant au merge des équipes, le pilote Vulkan sera développé en Open Source (pas initialement, mais presque). Du coup, il restera que OpenGL et quelques petites extensions proprios. Tout le reste sera libre bientôt! Source: Slide 4 de http://www.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf
J'en ai parlé avec Alex Deucher, et il a confirmé que les gens de Catalysts se mettaient au dev Open Source :)
[^] # Re: participation en rédaction
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.2. Évalué à 5.
Cool! Tu te mets en mainteneur de système de fichiers? Et pourquoi pas aussi bosser sur la partie audio (ça doit pas être trop dur vu le peu de changements)?
[^] # Re: Bof Bof
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 5.
Dur a dire. Ca depend de trop de facteurs. Mais ca devrait etre visible!
Tu peux voir un exemple de difference de performance dans un cas extreme, le rasp pi: https://fooishbar.org/tell-me-about/wayland-on-raspberry-pi/
[^] # Re: Bof Bof
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 7.
Si tu n'as pas d'acceleration matérielle, alors ca n'a aucun intérêt que X ou un compositeur wayland gère le YUV car il va devoir faire la conversion lui même en utilisant le CPU! Le seul but de garder le format original dans le conpositeur, c'est de pouvoir utiliser les plans graphiques pour faire la transformation colorimétrique en matériel ou, au pire, avec des shaders.
X supporte depuis des années de faire passer des images en YUV, via XV. Pitivi peut utiliser ca! Pas besoin de DRI2/3. D'ailleurs, je ne me souviens pas que DRI3 supporte de multiples formats, mais c'est possible.
Concernant Wayland, y'a encore pas mal de problèmes a résoudre mais les plans graphiques universels aident beaucoup pour exposer de façon uniforme entre les pilotes ces plans. C'est pas encore parfait car les informations de format sont pas assez évolués pour vraiment exploiter au max le matériel (compression et options de pavage)! On y travaille mais faudrait déjà que Wayland s'impose pour que nos employeurs nous laisse y bosser plus :p On y arrive!
[^] # Re: socks5
Posté par Martin Peres (site web personnel) . En réponse au journal Vacances & Réseaux hostiles. Évalué à 5.
Le problème de cette approche est que potentiellement, tout n'est pas redirigé.
C'est pas grave, tu peux utiliser redsocks pour ca!
[^] # Re: Francisation
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 10.
Je trouve au contraire que "systèmes monopuce" est une excellente traduction de SoC, c'est presque une relation 1-1.
Cela dit, je comprend ta remarque sur la francisation a outrance. J'ai aussi vécu au Canada. Perso, je n'utilise presque aucun mot que j'utilise dans la dépêche dans la vie de tous les jours car personne d'autre ne les connait, mais c'est ma faute et j'aimerai bien éviter qu'on se retrouve avec une langue ou la moitié des mots sont d'origine étrangère avec une prononciation vraiment différente (Hello Canada!). On est un des rare pays a avoir une seule langue comprise et utilisée en majorité par tout les habitants des pays francophones et si on commence a faire ca, on va encore plus diverger. Il est totalement possible d'avoir plusieurs mots dans différentes langues sans trop s'embrouiller!
Je vis actuellement en Finlande ou une bonne majorité des habitants est bilingue (Finlandais, Anglais) ou trilingue (Finlandais, Suédois et Anglais). Il y a quelques mots importés en Finnois, mais la majorité ne le sont pas (et c'est un bonheur d'apprendre des mots qui n'ont aucune racine grecque ou latine, hmm hmm). Même les ingénieurs a Intel Finlande utilisent très peu l'anglais quand ils parlent entres eux. Alors oui ça donne des mots bien rigolos (PC = tietokone = knowledge-machine) mais au final, y'a plein de mots composés qu'on a qui ne veulent rien dire, surtout chez les animaux :D Tant que le mot est unique, c'est tout ce qui importe.
TL;DR: Pour résumer, on est dans une situation ou il y a de nouveaux mots anglais qu'on ne prend pas le temps de traduire ce qui fait quand une traduction est proposée, c'est limite déjà trop tard. Je n'aime pas les langues ou la moitié des mots viennent d'autres langues (canada et certains pays du Maghreb font ça avec le fr, du moins a l'oral). Ce n'est pas un probleme d'avoir plusieurs mots pour designer la même chose tant que c'est dans une autre langue. Du coup, je pense que le meilleur endroit pour faire connaitre des nouvelles traductions est dans les articles techniques tels que cette dépêche et je suis content qu'on le fasse, même si parfois on oublis de marquer le mot original et si ça fait un poil chier de devoir apprendre de nouveaux mots.
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 3.
Ça semble être un bon plan pour du bon boulot d’édition!
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 6.
Oops pour la transitivité! Mais oui, je voulais pas démissionner, juste donner ma place à quelqu'un capable de faire un meilleur travail.
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 4.
Hey, tu veux aider sur la partie graphique? Je dis pas non!
Disons que je fais en fonction du temps disponible. Il y a beaucoup de variance suivant les releases aussi. Quand je comprend tout se qu'il se passe, j'ai peu de boulot a faire en plus de regarder les pull requests sur dri-devel et la liste des commits. Du coup, je dirai que tout écrire serait l’équivalent de 5-10h.
Parfois, les pull requests sont peu clairs et je regarde les commits, les bug reports associés et les articles de blog. Par exemple, je n'avais aucune idée que les télés avaient un espace de couleur différent des écrans de PC! Ça m'a prit une grosse demi heure de lecture en partant de l'acronyme pour avoir une bonne compréhension des patchs! Pareil sur PPGTT, les commits sont pas fait pour etre compris par ceux qui n'ont pas lu la doc, alors il faut se renseigner avec des ressources publiques (les ingés intel bloguent pas mal!) et la, on peut facilement passer 1 ou 2h sur un paragraphe.
En général, je passe une soirée pour collecter les liens + écrire la partie DRM. Ensuite je passe une soirée par gros driver (intel, radeon et nouveau). Je réserve ensuite une demi soirée pour les pilotes ARMs.
Concernant le travail d’édition, c'est probablement une vingtaine d'heure si on veut bien faire! Il faut tout homogénéiser, organiser, relancer les contributeurs, etc… Récemment, ce travail s'est résumé a faire plusieurs relectures et bouger les paragraphes qui n'ont rien a faire dans Arch/, mais c'est pour ça que je résigne! Je ne fais plus un bon boulot!
Disons que je sais pourquoi je fais le travail sur la partie graphique (apprendre et me tenir a jour), concernant l’édition, c'est vraiment pas ma passion mais je le faisais, faute de trouver quelqu'un d'autre pour le faire!
[^] # Re: Bof Bof
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 10.
La majorité du code du noyau est due aux pilotes. De ce coté la, tu peux attendre une meilleure gestion du matériel existant, meilleures performances, moins de bugs.
De temps en temps, il y a de nouvelles interfaces qui apparaissent et qui, quelques mois plus tard, sont utilisées par des programmes que tu utilises. Sans le savoir, tu vas probablement donner tout le mérite au développeur de cette application, alors que c'est un travail partagé! Par exemple, les namespaces permettent a systemd beaucoup de choses telles que rendre certains dossiers inaccessibles a certains services (sans avoir a changer les droits). Une autre est la gestion atomique du mode graphique qui va permettre aux compositeurs Wayland d'utiliser les plans graphiques matériels pour faire la conversion d'espace colorimétrique de façon transparente ce qui va permettre de réduire la consommation électrique!
Au final, le noyau n'est pas sensé être visible donc ce n'est pas étonnant que tu ne te rendes pas compte des changements!
[^] # Re: Résignation du poste d’éditeur de la dépêche
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 3.
Pour le coup, je n'ai aucune idée! je suppose que Radeon devrait pouvoir gérer ca plus ou moins rapidement. Cela dit, je doute qu'il soit possible de faire de l'adaptative-sync sur du hw pas prévu pour!
[^] # Re: Erreur de calcul
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 2.
Bien vu! Erreur de copier/coller, vérifié sur LWN.