pepp a écrit 82 commentaires

Ma question est donc la suivante, est ce que ce comportement est attendu ?

La mise en veille quand la carte n'est pas utilisée et les quelques secondes pour la réveiller : oui.

Que le branchement sur le port HDMI ne réveille pas la carte : non.

Je te suggère d'ouvrir un ticket ici : https://gitlab.freedesktop.org/drm/amd/-/issues/ avec les mêmes infos que celle tu as déjà indiquées ici + dmesg.

Les dmabuf sont un concept dans le noyau qui permettent d'exposer une zone mémoire d'un composant matérial sous la forme d'un pseudo-fichier ; justement pour ne pas faire de copie.

Par exemple, une application utilisant OpenGL va effectuer son rendu, et transmettre le contenu de la fenêtre au compositeur sous la forme d'un dmabuf fd (file descriptor). Ensuite le compositeur va pouvoir utiliser ce dmabuf comme une texture pour dessiner le bureau complet. Comme le rendu du jeu et du compositeur sont effectués sur le même GPU, il n'y a besoin d'aucune copie.

Mais dans certains cas, comme j'imagine une vidéo ou un jeu en mode fenêtré, GTK va faire quelque chose comme ça pour dessiner la zone de la vidéo :
1) faire décoder au GPU la vidéo -> le résultat est un dmabuf
2) importer ce dmabuf qui contient la vidéo
3) dessiner la vidéo
4) exporter le résultat dans un nouveau dmabuf pour le compositeur

Dans le cas général, le contenu du dmabuf obtenu à l'étape 4 sera exactement le même que celui obtenu à l'étape 1. L'optimisation décrite c'est de permettre de sauter les étapes 2, 3, et 4 et de directement transmettre le dmabuf de 1 au compositeur.

L'étape d'après étant de sauter aussi l'étape "envoyer le dmabuf au compositeur" et à la place l'envoyer directement à la partie affichage du GPU pour dessiner la vidéo "au dessus" du bureau produit par le compositeur (direct scanout).

Cette année à la XDC il y avait une présentation (en anglais) sur le support du HDR sous Linux : https://www.youtube.com/watch?v=yTO8QRIfOjA&t=21172s

Je pense que user1 est dans le groupe video pour avoir le droit de lancer Xorg.

Comme ce groupe gère /dev/dri/card0, je suppose qu'user1 hérite de la possibilité d'ouvrir /dev/dri/renderD128 (vu que c'est le même GPU, avec moins de droits).

Cela étant dit, la bonne façon d'accèder au GPU pour GL/Vulkan c'est d'être dans le groupe render.
xhost permet uniquement de communiquer avec X ; il se trouve que pour les applis GLX c'est également un moyen d'avoir accès au GPU.

(et donc si user2 est ajouté à render, il faudra quand même utiliser xhost pour l'autoriser à discuter avec X pour créer sa fenêtre etc)

Il faut que ton user2 soit dans le groupe render.

Je pense que OpenGL fonctionne parce qu'il obtient l'accès au GPU via X/GLX alors que Vulkan requiert l'accès direct.

Merci pour le journal.

Comme je n'utilise pas nginx et php, j'ai cherché à utiliser ces possibilités pour des applications classiques (= pas des services).

C'est possible en utilisant systemd-run.

Par exemple, pour lancer un shell qui n'aura pas d'accès au réseau, et pour lequel le répertoire Home sera en lecture seule:

systemd-run --user --property=PrivateUsers=true --property=PrivateNetwork=true --property=ProtectHome=read-only --wait -q --shell

Ou encore pour lancer gedit sans accès réseau ni accès au Home:

systemd-run --user --property=PrivateUsers=true --property=PrivateNetwork=true --property=ProtectHome=yes --wait -q gedit

(PrivateUsers=true semble être nécessaire pour pouvoir utiliser PrivateNetwork=true sans droits particuliers)

En utilisant un alias, ça donne un moyen simple de lancer des applis avec des droits limités.

Si le noyau supporte dynamic debugging (ce qui je pense est le cas sur Ubuntu) alors il doit être possible de l'utiliser pour désactiver ce log qui provient d'un dev_err avec quelque chose comme :

# echo -n "file pl2303.c -p" > /sys/kernel/debug/dynamic_debug/control

Contributeurs de code : bootchk, Des McGuinness, Ian Martins, Jacob Boerema, Jehan, Lloyd Konneker, Luca Bacci, Marc Espie, Massimo Valentini, Michael Bazzinotti, Michael McLaughlin, Øyvind Kolås, saul, Simon McVittie et Stanislav Grinkov.

Oh… mitch (Michael Natterer) ne contribue plus à Gimp (cf https://linuxfr.org/news/entretien-avec-michael-natterer-mainteneur-de-gimp) ?

Merci pour la chouette dépêche !

Une suggestion d'amélioration pour la prochaine : 25 Mo d'images c'est beaucoup…

Sur les 16 images, 3 sont en jpg, les autres sont en png (entre 1Mo et 4.5Mo chacune). En utilisant imagemagick ou https://linuxfr.org/news/sortie-de-yoga-image-optimizer-1-0 on peut diviser la taille de chaque image par 5 sans perte de qualité visible.

Par exemple avec 1675011643_nightscene.png.5bc0141ea08e15c12daf172c2e5730b8.png :
- version png : 4.7 Mo
- version jpg (convert image.png image.jpg) : 1.1 Mo
- avec jpegoptim en plus (jpegoptim -s -m85 image.jpg) : 730 ko
- en webp (convert image.png image.webp) : 440 ko

(PS : oui j'avais fait le même commentaire sur une ancienne dépêche https://linuxfr.org/news/0-a-d-empires-ascendant-rapport-de-developpement-septembre-2019-mai-2020, désolé pour la répétition :))

L'option de passer par le partage d'écran de Jitsi fonctionne et c'est la solution utilisée quand il y a des participants non présents dans la salle.

Par contre quand tout le monde est sur place, c'est moins pertinent : la compression dégrade la qualité et la conso CPU sur le mini-PC est sans commune mesure avec la version waypipe (à la louche 100% vs 5%).

de grosses nouveautés arrivent en septembre (temps réel, notifications, mentions)

Ah chouette ! Je retesterai à ce moment là parce que c'est le principal retour négatif qu'on m'avait fait quand j'avais fait tester Tracim (les testeurs étaient perturbés par la latence entre chaque action "ça a marché ? ou faut que je reclique ?")

La dépêche est intéressante et bien détaillée, merci !

Un bémol : le poids des images, environ 20mo. Les png qui n'utilisent pas de transparence pourraient être remplacés par des jpg. Par exemple en utilisant convert image.png -quality 75 image.jpg la taille est divisée par 10 sans que la qualité ne soit affectée.

Il y a aussi la quadplay : https://github.com/morgan3d/quadplay qui est sous licence LGPL3.

Pour jouer : https://morgan3d.github.io/quadplay/console/quadplay.html

La documentation est par là (générée avec un autre projet du même auteur : Markdeep)

En gros la manip MSword -> Libreoffoce.writer -> MSword fait perdre de l'information de mise en page.

Pourquoi supposes-tu que le format docx (ou sa spécification) est l'unique responsable ?

Mon expérience me pousse à penser que l'implémentation dans LO est largement aussi responsable, voir plus.

Cette présentation d'un dév LO : http://conference.libreoffice.org/assets/Conference/Bern/slides/SushilShinde.pdf semble en accord avec mon point de vue (cf page 12, 13 notamment) :

Reasons For Data Loss
- MS Office feature is not supported
- XML Nodes not handled
- XML elements not mapped properly
- Properties lost in shape conversions

Un autre outil qui génère peut servir pour générer des diagrammes (et plein d'autre choses) : Markdeep. (NdM: lien corrigé)

Comme c'est du markdown on peut soit le créer / l'éditer à la main, soit faire un outil qui génére le markdown à partir d'un langage comme le tiens.

Pour ton exemple ça donnerait ça: http://soupeaucaillou.com/test.md.html

Le graph proposé par Michael Meeks pour la sortie de LibreOffice 5.0 est plus représentatif, même si les couleurs sont discutables (voir l'article original ou la dépêche linuxfr) :

On voit que les commits sont globalement partagés en 3 parts égales : Collabora (ex-SUSE), RedHat et «Assigned» (je suppose que ce sont les «Individual» de ton graph).

La Document Foundation n'emploie pas (ou peu) de développeurs.
Son budget est utilisé pour des appels d'offres pour des développements particuliers (LO pour Android par ex) mais surtout aider la communauté à développer LibreOffice (Hackfest, infrastructure, etc) ; cf le budget 2014 pour plus de détails.

Le découpage en fichier correspond aussi en général au découpage fonctionnel

Ça n'implique pas qu'un découpage fonctionnel nécessite un découpage en fichiers.

un fichier cpp qui commence à faire plus de 1000 lignes, c’est probablement une classe qui a trop de responsabilités

Comment ça marche si tu as 2 classes dans le même fichier ? ou 10 ?

Bref, chercher à appliquer les mêmes règles à tous les projets me parait absurde au plus haut point. Si l'auteur préfére 1 fichier, tant mieux pour lui.
Accessoirement, avoir 1 seul fichier a un énorme avantage : ça rend l'intégration dans d'autres projets triviale.

Les I-frame (images complètes) sont assez espacées dans le temps en VoIP.
Donc avant si tu avais une erreur dans le flux il y avait 2 options : demander une nouvelle I-frame (au prix d'une bande passante plus élevée) ou ne rien faire (image dégradée).
Je suppose que ça permet de demander une I-frame "partielle" qui permet de corriger l'erreur sans faire exploser la bande passante utilisée.

Si tu parles du fait que le code Python fait moins de choses dans le cas qui nous concerne, et est donc naturellement plus court, c'est le point principal que je voulais montrer, effectivement.

Tu es sûr de ça ? LibreOffice a quand même pas mal de tests autour de l'import des doc/docx et ça m'étonnerait que Miklos ait accepté une solution qui introduise des régressions.

Pour ceux qui aimerait avoir plus de contexte sur cette citation souvent utilisée, il y a un article intéressant à lire ici.

(spoiler : l'usage courant de cette citation s'approche du contre-sens de ce qu'a voulu exprimer Knuth)

On peut faire beaucoup de connerie en Rust en unsafe

Je n'en doute pas - je ne connais de Rust que le tutorial.

Mais là encore c'est manquer l'objectif de Rust et de l'article : dans Rust tu peux faire des conneries en mode unsafe (en demandant explicitement le droit de les faire), en C++ tu peux faire des conneries tout le temps.

mais ce n'est pas pour ça qu'il faut taper sur C++ pour le plaisir

Ce n'est pas taper sur le C++ que de dire qu'il est facile de faire des erreurs avec, si ?

Pour le 'broken iterator', il y a plus que le problème de boucle; c'est qu'il touche au conteneur pendant l'itération; et on ne fait jamais ça en c++;

C'est justement le but de son article. Il illustre comment Rust «protège» le développeur en l'empêchant de faire des trucs dangereux.
C++ te laisse faire ce que tu veux, mais s'il s'avère que ton usage était foireux ça va planter à l'éxecution.
Rust détecte et bloque les usages foireux à la compilation.

Tu es sûr que ce n'est pas simplement compressé ?

Sinon avant d'attaquer avec un décompilateur ou autre grosse artillerie, je commencerais plutôt par produire plusieurs fichiers avec de légères différences et voir l'influence sur le fichier de sortie (ou par ex: est-ce qu'enregistrer 2 fois le même fichier change le contenu ? ou sa taille ?).

En tout cas c'est un challenge intéressant :)

Sur github https://github.com/SoupeauCaillou/sac

chaque entité créé provoque une allocation égale à la taille de tous les composants

Si tu utilises un vector par type de composant tu peux limiter sa taille du tableau à "entité_max qui a ce composant - entité_min qui a ce composant + 1".
Mais oui, ce stockage gaspille de la mémoire

Si tu as des idées d'autres layouts, je cherche de l'inspiration!

Pas tellement. J'avais commencé avec une implémentation simple : chaque système avait une map.
Après quelques tests et benchmarks (cf mon commentaire sur perf), chaque système contient finalement :
* un tableau (brut) de Composant (moins coûteux qu'un vector)
* un std::vector d'entités, pour savoir quelles entités ont ce composant. Ce vector est trié pour optimiser l'utilisation du cache quand le système est mis à jour.

Rien de bien original, mais ça me suffit pour mon usage :-)