Rien du côté Xorg à ma connaissance, c’est le pilote KMS (côté noyau, donc) qui est concerné.
Par contre maintenant que je suis sur le 4.6, j’ai une régression quelque part qui fait que mon portable est grimpé à 15 W de consommation au lieu de 8.5 (avec le noyau 4.5 et psr/fbc réglés à 1), ce que je corrèle avec le fait qu’il ne descend plus dans l’état pc6…
Je sais, mais ça coûte encore un peu cher pour moi. Mais c’est prévu (en fait, pour être exact, j’ai un SSD M.2 de 32 Gio qui héberge le système, et un HDD de 1 Tio pour le /home et le /var, mais tout sur SSD ce serait quand même mieux pour beaucoup de choses — et accessoirement, entre SSD+HDD et SSD tout seul, avec dans les deux cas le SSD au format M.2, ça fait quand même moins de consommation).
Il y a aussi plein de choses dans les liens mentionnés (surtout ceux qui redirigent vers des threads complets de ML), ainsi que dans les commentaires, mais t’en prends pour la fin de la semaine si tu veux lire tout ça !
Ce qu’il faut retenir, c’est que Nvidia a réussi à bidouiller un peu pour pouvoir réaliser leur mode de fonctionnement « inversé », mais que le mode normal leur reste inaccessible.
Nope. L’idée, c’est que tu as deux cartes graphiques. L’une a l’écran (et tout ou partie des sorties vidéos dispos) de connecté dessus et est celle intégrée au CPU, l’autre est plus performante (on l’appelle dédiée) et a éventuellement une partie des sorties vidéos connectée dessus.
En temps normal la carte intégrée fait le boulot, et la carte dédiée est éteinte (ce point n’est déjà pas évident, mais passons).
Ensuite, de temps en temps, tu peux avoir envie de lancer des applications un peu plus lourdes, et donc de laisser la carte dédiée s’en occuper. Suffit de trouver un moyen de démarrer ces applis sur cette carte (pas trivial, plusieurs manières de faire). Seulement, même une fois ceci réussi, la carte dédiée ne peut pas afficher les images générées directement à l’écran, car elle n’est pas connectée à celui-ci. Il faut donc les transférer à la carte intégrée. Ce qui est à nouveau pas simple.
Pour Bumblebee, ça fonctionne ainsi : par défaut, un seul serveur X tourne, avec la carte intégrée. Si tout va bien, la carte graphique est éteinte. Quand tu déclares une application à lancer sur la carte dédiée avec optirun, bumblebeed (le daemon) démarre un second serveur X (sauf dans un cas particulier) avec uniquement la carte dédiée. Ensuite, selon le backend utilisé, il met en place un système de transfert.
Dans le cas de VirtualGL (l’ancien backend, qu’on garde juste au cas où), un client VGL est lancé sur le serveur X « intégré », et un serveur VGL sur le serveur X « dédié ». L’application est lancée sur le serveur X « dédié », et les images sont récupérées par le serveur VGL qui les transmet au client. C’est extrêmement lourd, et il faut savoir que VirtualGL sert normalement à faire tourner des applications à distance (le truc qu’on nous vend comme étant le futur depuis des années : un supercalculateur fait tourner ton application et te renvoie les images, dans le sens inverse il récupère les entrées type clavier/souris), donc c’est pas du tout prévu pour cet usage. Du coup, les performances sont pas au niveau du tout. Et les contraintes ne sont pas les mêmes.
Du coup, est arrivés Primus. L’idée ici, c’est un peu ce que fait la nouvelle libglvnd. En gros, on fait tourner l’application sur le serveur X normal, mais quand elle fait des appels graphiques (OpenGL), on les intercepte et redirige sur la carte dédiée (le second serveur X est toujours nécessaire pour des recevoir ces appels). On récupère les résultats en sortie et les réinjecte dans l’application.
Tout ça est lourd dans les deux cas, car ça implique plein de copies en plus. Du coup, les performances sont limitées, notamment quand la résolution d’écran est grande, car la taille des images à copier l’est d’autant plus.
De l’autre côté, il y a PRIME (et le fonctionnement natif d’Optimus sous Windows, qui ne doit pas être très loin). Ici, tout se passe à un niveau beaucoup plus bas : la mémoire partagée des cartes graphiques. Pour les applications spécifiées, la carte intégrée écrit directement les appels qu’elle reçoit dans la mémoire de la carte dédiée, et cette dernière écrit directement les résultats de ces appels dans la mémoire de la carte intégrée. En gros, PRIME permet à chaque carte d’écrire dans la mémoire de l’autre. Après il y a plein de subtilités et d’autres choses à considérer, mais ça donne l’idée générale. L’important, c’est que c’est beaucoup plus propre d’un point de vue technique, et qu’en termes de performances on ne peut pas faire mieux.
PRIME dispose aussi d’un mode dit « reverse », dans lequel une carte peut utiliser les sorties vidéos de l’autre. Du coup, tu peux aussi tout faire tourner sur la carte dédiée et écrire dans la mémoire de l’autre pour l’affichage uniquement. C’est ce mode qui est utilisé par Nibel et le paquet nvidia-prime.
Ah, j’avais pas compris que tu redémarrais carrément ta machine (en plus d’installer/désinstaller les drivers). Tu t’embêtes beaucoup trop !
Il est possible d’avoir les deux drivers installés en même temps, et de redémarrer seulement le serveur d’affichage (=déconnexion puis reconnexion) pour basculer. Le paquet nvidia-prime sous Ubuntu permet de faire ça très simplement (avec un bouton pour basculer), je peux éventuellement écrire la doc pour d’autres OS ou créer un paquet ArchLinux (s’il n’existe pas déjà) si besoin.
Quand au switch dynamique, je pense qu’il est implémenté, mais ne peut pas être publié car comme je disais, il faut que les drivers soient compatibles avec la licence GPL (donc libres) pour pouvoir utiliser ce mode sous Linux. Je n’ai plus les détails techniques en tête (c’est vieux tout ça…), mais je peux retrouver si ça intéresse.
Bumblebee est maintenu (même s’il y a eu de gros blancs et peu d’activité générale), mais un bug critique côté gestion d’énergie (y compris côté nouveau/PRIME, donc noyau) retarde la sortie de la version 4.0. L’ETA est d’environ 1 mois ou 2. S’il n’y a pas eu de MàJ pendant longtemps, c’est que rien ne le nécessitait (ce n’est plus tout à fait vrai depuis quelques temps avec la multiplication des modules noyau côté nvidia, et quelques menus bugs qui se sont ajoutés avec le temps).
Par contre, niveau performances, c’est parfaitement vrai, et il n’est pas possible de faire beaucoup mieux (dans Bumblebee) car c’est inhérent au mode de fonctionnement. La solution s’appelle PRIME, sauf que nvidia ne le gère pas, pour des raisons légales comme je disais plus haut.
Il reste la possibilité de faire du Reverse PRIME, avec les bugs que tu mentionnes en effet, et une assez grosse lourdeur côté basculement de carte graphique (personnellement, je ne peux pas me permettre de redémarrer mon serveur X à tout bout de champ).
L’idéal serait que nouveau, le pilote libre qui gère tous ces modes, s’affranchisse de ses gros problèmes de performances (qui sont au-delà des limitations de Bumblebee…).
Donc non, Optimus n’est pas géré nativement par le pilote proprio, seulement un ersatz d’Optimus, à tel point que la techno pré-Optimus fonctionnait mieux de ce point de vue-là. :p
Oui, et comme dit l’article, le gain est dans une fourchette 29 → 85 % sur un ensemble de systèmes testés. Ce qui n’est pas dit, c’est un gain de quoi, mesuré par rapport à quoi. De mémoire, il s’agit de la baisse de consommation, par exemple, en passant de 13.5 W à 8.5 W, j’ai gagné 37 %, mais mon autonomie, elle, en passant de 270 à 440 minutes, a obtenu un gain de 63 %. Imagine donc pour les systèmes concernés par des gains de l’ordre de 85 % ! (Réponse : autonomie multipliée par 6.66, soit un gain de 566 %)
Oui, évidemment, puisque la consommation est directement liée l’autonomie. ;) En utilisation standard, disposant d’une batterie de 61 Wh, je passe de 4 h 30 à 7 h 20 d’autonomie (ce que j’observe dans la pratique, et c’est assez agréable pour les trajets en train que je fais régulièrement). Et là je me dis que si j’avais eu un peu plus de sous à l’époque, j’aurais pu prendre la version SSD + batterie 91 Wh de mon PC (au lieu de HDD + batterie 61 Wh car le HDD prend de la place), et j’aurais eu facilement 11 ou 12 h d’autonomie.
Ce que j’entends par utilisation standard : quelques onglets dans mes terminaux, avec vim ouvert sur quelques fichiers, connecté en Wi-Fi avec Firefox et une quinzaine d’onglets, luminosité de l’écran à 50 % (soit 200 cd·m⁻² dans mon cas).
Évidemment, le gain exact dépendra de la machine de chacun (notamment, il faut forcément une machine pas trop vieille pour profiter de tout cela), de l’usage… Mais pour les machines concernées, le gain est toujours appréciable.
Et bien sûr, dans un jeu vidéo qui fait du 60 IPS, ça ne change rien, vu qu’il n’y a pas d’économies d’énergie à faire dans cette situation…
Je parlais plus spécifiquement des problèmes liés aux deux jeux que tu cites. Je n’en trouve pas trace dans les deux systèmes de suivi des bugs, donc ça m’aiderait beaucoup si tu pouvais me donner des liens précis. ;)
Et sinon, comme dit en-dessous, je suis d’accord que c’est un domaine où il y a encore des (gros) progrès à faire par rapport à Windows.
Ça dépend à quoi tu fais référence. Si c’est côté ordonnanceur, je ne peux pas encore répondre à cela (le paquet est bloqué dans [testing] pour l’instant sur Arch — qui se trouve être ma distro — à cause d’une régression des applications Qt5), mais a priori rien de fondamental. Le futur schedutil de cpufreq devrait en revanche être assez intéressant.
Côté GPU, le Panel Self-Refresh (PSR), « c’est de la bombe ». La conso de mon laptop en utilisation standard passe de ~13.5W à ~8.5W. Non négligeable, extrêmement appréciable. Je comprends mieux la différence d’autonomie entre Windows et Linux que j’observais à l’époque où j’avais encore un double boot. D’ailleurs, le noyau 4.6 apporte aussi la gestion d’énergie des contrôleurs AHCI, mais c’est expérimental. Pas encore eu le temps de tester car cela demande quelques précautions, mais a priori là aussi le gain ne devrait pas être négligeable.
Ce qu’il faut comprendre, c’est que de nos jours le « niveau d’énergie » (état) de beaucoup de composants dépend de celui d’autres, et que parfois rajouter la gestion d’un composant permet à beaucoup d’autres d’atteindre des niveaux encore plus bas. On pourra lire cette référence (en anglais) sur le sujet, par un développeur du noyau en partie responsable de ces améliorations : https://mjg59.dreamwidth.org/34868.html.
En fait le problème de vsync vient plutôt de chez Intel, qui n’en a pas grand chose à cirer apparemment car dans le fond Optimus c’est pas trop leur problème.
Le switch dynamique, c’est un problème légal pour ce que j’en sais, seuls les drivers compatibles GPL peuvent utiliser l’interface noyau qui permet de faire cela. Du coup ça fonctionne avec nouveau (et plutôt très bien, extrêmement simple d’utilisation surtout avec DRI3 et le .drirc), mais ne pourra pas fonctionner avec nvidia tant qu’il ne sera pas libre. C’est-à-dire probablement jamais.
Après, je suis d’accord que Nvidia aurait pu (et pourrais toujours évidemment) aider un peu plus au support de cette techno, mais ils n’ont pas rien fait non plus.
Est-ce que tu peux essayer ce qui t’as été demandé sur GitHub du coup (glsanity) ? Ou alors réexpliquer ta situation là-bas si ton problème n’est plus le même ? Merci.
Pour préciser : pour la première fois depuis extrêmement longtemps, le 4.3.1 est sorti plus d’un mois après le 4.3. Pendant ce temps, le 4.2 était arrivé à 4.2.8, mais sous Arch on en restait à 4.2.5 puisque le 4.3 était dans le dépôt testing.
Ça a entraîné une discussion pour savoir comment gérer ce genre de chose, surtout qu’à l’époque le fait d’avoir attendu le 4.3.1 s’est avéré être une très bonne idée (https://bugs.archlinux.org/task/46968). Et l’écart entre le 4.4.1 et le 4.4 a également été plus long que d’ordinaire, pareil pour le 4.5.1 qui se faisait attendre : apparemment, en l’absence de problème majeur répertorié, les mainteneurs du paquet linux sous Arch ont décidé, pour la première fois depuis que je suis sous Arch, de pousser le .0 dans les dépôts stables.
Car sinon en effet, la politique c’était d’attendre le .1 histoire que les gros bugs n’arrivent pas dans les dépôts stable. Quand un noyau passe du stade de -rc à release, le nombre d’utilisateurs augmente considérablement, donc les bugs apparaissent plus facilement. En gros, Arch attend que les utilisateurs de Gentoo essuient les plâtres. ;)
[^] # Re: Économies d'énergie
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 3.
Rien du côté Xorg à ma connaissance, c’est le pilote KMS (côté noyau, donc) qui est concerné.
Par contre maintenant que je suis sur le 4.6, j’ai une régression quelque part qui fait que mon portable est grimpé à 15 W de consommation au lieu de 8.5 (avec le noyau 4.5 et psr/fbc réglés à 1), ce que je corrèle avec le fait qu’il ne descend plus dans l’état pc6…
[^] # Re: Économies d'énergie
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 3.
Je sais, mais ça coûte encore un peu cher pour moi. Mais c’est prévu (en fait, pour être exact, j’ai un SSD M.2 de 32 Gio qui héberge le système, et un HDD de 1 Tio pour le /home et le /var, mais tout sur SSD ce serait quand même mieux pour beaucoup de choses — et accessoirement, entre SSD+HDD et SSD tout seul, avec dans les deux cas le SSD au format M.2, ça fait quand même moins de consommation).
[^] # Re: Merci
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 2.
Voilà, j’ai retrouvé ceci (tout en anglais, je ne suis pas sûr qu’il y ait des sources en français sur le sujet):
https://www.phoronix.com/scan.php?page=news_item&px=MTA0ODE
https://www.phoronix.com/scan.php?page=news_item&px=MTE3MzY
https://www.phoronix.com/scan.php?page=news_item&px=MTA1OTU
https://www.phoronix.com/scan.php?page=news_item&px=MTIwNDI
https://www.phoronix.com/scan.php?page=news_item&px=MTIwOTI
https://www.phoronix.com/scan.php?page=news_item&px=MTMwMjI
Il y a aussi plein de choses dans les liens mentionnés (surtout ceux qui redirigent vers des threads complets de ML), ainsi que dans les commentaires, mais t’en prends pour la fin de la semaine si tu veux lire tout ça !
Ce qu’il faut retenir, c’est que Nvidia a réussi à bidouiller un peu pour pouvoir réaliser leur mode de fonctionnement « inversé », mais que le mode normal leur reste inaccessible.
[^] # Re: Merci
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 2.
Poste déjà la sortie de glsanity (lis les instructions qui vont avec), après on verra. ;)
[^] # Re: Merci
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 10.
Nope. L’idée, c’est que tu as deux cartes graphiques. L’une a l’écran (et tout ou partie des sorties vidéos dispos) de connecté dessus et est celle intégrée au CPU, l’autre est plus performante (on l’appelle dédiée) et a éventuellement une partie des sorties vidéos connectée dessus.
En temps normal la carte intégrée fait le boulot, et la carte dédiée est éteinte (ce point n’est déjà pas évident, mais passons).
Ensuite, de temps en temps, tu peux avoir envie de lancer des applications un peu plus lourdes, et donc de laisser la carte dédiée s’en occuper. Suffit de trouver un moyen de démarrer ces applis sur cette carte (pas trivial, plusieurs manières de faire). Seulement, même une fois ceci réussi, la carte dédiée ne peut pas afficher les images générées directement à l’écran, car elle n’est pas connectée à celui-ci. Il faut donc les transférer à la carte intégrée. Ce qui est à nouveau pas simple.
Pour Bumblebee, ça fonctionne ainsi : par défaut, un seul serveur X tourne, avec la carte intégrée. Si tout va bien, la carte graphique est éteinte. Quand tu déclares une application à lancer sur la carte dédiée avec optirun, bumblebeed (le daemon) démarre un second serveur X (sauf dans un cas particulier) avec uniquement la carte dédiée. Ensuite, selon le backend utilisé, il met en place un système de transfert.
Dans le cas de VirtualGL (l’ancien backend, qu’on garde juste au cas où), un client VGL est lancé sur le serveur X « intégré », et un serveur VGL sur le serveur X « dédié ». L’application est lancée sur le serveur X « dédié », et les images sont récupérées par le serveur VGL qui les transmet au client. C’est extrêmement lourd, et il faut savoir que VirtualGL sert normalement à faire tourner des applications à distance (le truc qu’on nous vend comme étant le futur depuis des années : un supercalculateur fait tourner ton application et te renvoie les images, dans le sens inverse il récupère les entrées type clavier/souris), donc c’est pas du tout prévu pour cet usage. Du coup, les performances sont pas au niveau du tout. Et les contraintes ne sont pas les mêmes.
Du coup, est arrivés Primus. L’idée ici, c’est un peu ce que fait la nouvelle libglvnd. En gros, on fait tourner l’application sur le serveur X normal, mais quand elle fait des appels graphiques (OpenGL), on les intercepte et redirige sur la carte dédiée (le second serveur X est toujours nécessaire pour des recevoir ces appels). On récupère les résultats en sortie et les réinjecte dans l’application.
Tout ça est lourd dans les deux cas, car ça implique plein de copies en plus. Du coup, les performances sont limitées, notamment quand la résolution d’écran est grande, car la taille des images à copier l’est d’autant plus.
De l’autre côté, il y a PRIME (et le fonctionnement natif d’Optimus sous Windows, qui ne doit pas être très loin). Ici, tout se passe à un niveau beaucoup plus bas : la mémoire partagée des cartes graphiques. Pour les applications spécifiées, la carte intégrée écrit directement les appels qu’elle reçoit dans la mémoire de la carte dédiée, et cette dernière écrit directement les résultats de ces appels dans la mémoire de la carte intégrée. En gros, PRIME permet à chaque carte d’écrire dans la mémoire de l’autre. Après il y a plein de subtilités et d’autres choses à considérer, mais ça donne l’idée générale. L’important, c’est que c’est beaucoup plus propre d’un point de vue technique, et qu’en termes de performances on ne peut pas faire mieux.
PRIME dispose aussi d’un mode dit « reverse », dans lequel une carte peut utiliser les sorties vidéos de l’autre. Du coup, tu peux aussi tout faire tourner sur la carte dédiée et écrire dans la mémoire de l’autre pour l’affichage uniquement. C’est ce mode qui est utilisé par Nibel et le paquet nvidia-prime.
[^] # Re: Merci
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 1.
Ah, j’avais pas compris que tu redémarrais carrément ta machine (en plus d’installer/désinstaller les drivers). Tu t’embêtes beaucoup trop !
Il est possible d’avoir les deux drivers installés en même temps, et de redémarrer seulement le serveur d’affichage (=déconnexion puis reconnexion) pour basculer. Le paquet nvidia-prime sous Ubuntu permet de faire ça très simplement (avec un bouton pour basculer), je peux éventuellement écrire la doc pour d’autres OS ou créer un paquet ArchLinux (s’il n’existe pas déjà) si besoin.
Quand au switch dynamique, je pense qu’il est implémenté, mais ne peut pas être publié car comme je disais, il faut que les drivers soient compatibles avec la licence GPL (donc libres) pour pouvoir utiliser ce mode sous Linux. Je n’ai plus les détails techniques en tête (c’est vieux tout ça…), mais je peux retrouver si ça intéresse.
[^] # Re: Merci
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 1.
Ce que tu vois là, ce sont juste des problèmes d’install/de config.
On peut régler ça sur le fil GitHub, que ce soit pour faire fonctionner Bumblebee ou nvidia dans la configuration proposée par Nibel. ;)
[^] # Re: Merci
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 6.
Bumblebee est maintenu (même s’il y a eu de gros blancs et peu d’activité générale), mais un bug critique côté gestion d’énergie (y compris côté nouveau/PRIME, donc noyau) retarde la sortie de la version 4.0. L’ETA est d’environ 1 mois ou 2. S’il n’y a pas eu de MàJ pendant longtemps, c’est que rien ne le nécessitait (ce n’est plus tout à fait vrai depuis quelques temps avec la multiplication des modules noyau côté nvidia, et quelques menus bugs qui se sont ajoutés avec le temps).
Par contre, niveau performances, c’est parfaitement vrai, et il n’est pas possible de faire beaucoup mieux (dans Bumblebee) car c’est inhérent au mode de fonctionnement. La solution s’appelle PRIME, sauf que nvidia ne le gère pas, pour des raisons légales comme je disais plus haut.
Il reste la possibilité de faire du Reverse PRIME, avec les bugs que tu mentionnes en effet, et une assez grosse lourdeur côté basculement de carte graphique (personnellement, je ne peux pas me permettre de redémarrer mon serveur X à tout bout de champ).
L’idéal serait que nouveau, le pilote libre qui gère tous ces modes, s’affranchisse de ses gros problèmes de performances (qui sont au-delà des limitations de Bumblebee…).
Donc non, Optimus n’est pas géré nativement par le pilote proprio, seulement un ersatz d’Optimus, à tel point que la techno pré-Optimus fonctionnait mieux de ce point de vue-là. :p
J’ai écrit une réponse ici sur le choix entre ces différents modes de fonctionnement (en anglais): https://askubuntu.com/a/775161/493985.
Je peux faire une version française s’il y a de la demande, ou répondre aux questions si certains points ne sont pas clairs.
[^] # Re: Économies d'énergie
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 5.
Oui, et comme dit l’article, le gain est dans une fourchette 29 → 85 % sur un ensemble de systèmes testés. Ce qui n’est pas dit, c’est un gain de quoi, mesuré par rapport à quoi. De mémoire, il s’agit de la baisse de consommation, par exemple, en passant de 13.5 W à 8.5 W, j’ai gagné 37 %, mais mon autonomie, elle, en passant de 270 à 440 minutes, a obtenu un gain de 63 %. Imagine donc pour les systèmes concernés par des gains de l’ordre de 85 % ! (Réponse : autonomie multipliée par 6.66, soit un gain de 566 %)
[^] # Re: Économies d'énergie
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 10.
Oui, évidemment, puisque la consommation est directement liée l’autonomie. ;) En utilisation standard, disposant d’une batterie de 61 Wh, je passe de 4 h 30 à 7 h 20 d’autonomie (ce que j’observe dans la pratique, et c’est assez agréable pour les trajets en train que je fais régulièrement). Et là je me dis que si j’avais eu un peu plus de sous à l’époque, j’aurais pu prendre la version SSD + batterie 91 Wh de mon PC (au lieu de HDD + batterie 61 Wh car le HDD prend de la place), et j’aurais eu facilement 11 ou 12 h d’autonomie.
Ce que j’entends par utilisation standard : quelques onglets dans mes terminaux, avec vim ouvert sur quelques fichiers, connecté en Wi-Fi avec Firefox et une quinzaine d’onglets, luminosité de l’écran à 50 % (soit 200 cd·m⁻² dans mon cas).
Évidemment, le gain exact dépendra de la machine de chacun (notamment, il faut forcément une machine pas trop vieille pour profiter de tout cela), de l’usage… Mais pour les machines concernées, le gain est toujours appréciable.
Et bien sûr, dans un jeu vidéo qui fait du 60 IPS, ça ne change rien, vu qu’il n’y a pas d’économies d’énergie à faire dans cette situation…
[^] # Re: Merci
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 1.
Je ne me souviens pas avoir réussi non plus lorsque j’avais essayé, car il y a pas mal de subtilités. Mais il y a des binaires précompilés : https://github.com/amonakov/glsanity/releases/download/2/glsanity-bin.zip.
Je te propose qu’on continue plutôt sur GitHub, dans le fil dédié. ;)
[^] # Re: Merci
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 1.
Je parlais plus spécifiquement des problèmes liés aux deux jeux que tu cites. Je n’en trouve pas trace dans les deux systèmes de suivi des bugs, donc ça m’aiderait beaucoup si tu pouvais me donner des liens précis. ;)
Et sinon, comme dit en-dessous, je suis d’accord que c’est un domaine où il y a encore des (gros) progrès à faire par rapport à Windows.
[^] # Re: Économies d'énergie
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 10.
Ça dépend à quoi tu fais référence. Si c’est côté ordonnanceur, je ne peux pas encore répondre à cela (le paquet est bloqué dans [testing] pour l’instant sur Arch — qui se trouve être ma distro — à cause d’une régression des applications Qt5), mais a priori rien de fondamental. Le futur schedutil de cpufreq devrait en revanche être assez intéressant.
Côté GPU, le Panel Self-Refresh (PSR), « c’est de la bombe ». La conso de mon laptop en utilisation standard passe de ~13.5W à ~8.5W. Non négligeable, extrêmement appréciable. Je comprends mieux la différence d’autonomie entre Windows et Linux que j’observais à l’époque où j’avais encore un double boot. D’ailleurs, le noyau 4.6 apporte aussi la gestion d’énergie des contrôleurs AHCI, mais c’est expérimental. Pas encore eu le temps de tester car cela demande quelques précautions, mais a priori là aussi le gain ne devrait pas être négligeable.
Ce qu’il faut comprendre, c’est que de nos jours le « niveau d’énergie » (état) de beaucoup de composants dépend de celui d’autres, et que parfois rajouter la gestion d’un composant permet à beaucoup d’autres d’atteindre des niveaux encore plus bas. On pourra lire cette référence (en anglais) sur le sujet, par un développeur du noyau en partie responsable de ces améliorations : https://mjg59.dreamwidth.org/34868.html.
[^] # Re: Merci
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 7.
En fait le problème de vsync vient plutôt de chez Intel, qui n’en a pas grand chose à cirer apparemment car dans le fond Optimus c’est pas trop leur problème.
Le switch dynamique, c’est un problème légal pour ce que j’en sais, seuls les drivers compatibles GPL peuvent utiliser l’interface noyau qui permet de faire cela. Du coup ça fonctionne avec nouveau (et plutôt très bien, extrêmement simple d’utilisation surtout avec DRI3 et le .drirc), mais ne pourra pas fonctionner avec nvidia tant qu’il ne sera pas libre. C’est-à-dire probablement jamais.
Après, je suis d’accord que Nvidia aurait pu (et pourrais toujours évidemment) aider un peu plus au support de cette techno, mais ils n’ont pas rien fait non plus.
[^] # Re: Merci
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 3.
As-tu pensé à reporter ces problèmes ici : https://github.com/amonakov/primus/issues ? ;) Ou a minima là : https://github.com/Bumblebee-Project/Bumblebee/issues. Même si ici le premier est plus indiqué.
[^] # Re: Merci
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 2.
Est-ce que tu peux essayer ce qui t’as été demandé sur GitHub du coup (glsanity) ? Ou alors réexpliquer ta situation là-bas si ton problème n’est plus le même ? Merci.
[^] # Re: La toute première fois
Posté par Archange . En réponse à la dépêche Sortie du noyau Linux 4.5. Évalué à 10.
Pour préciser : pour la première fois depuis extrêmement longtemps, le 4.3.1 est sorti plus d’un mois après le 4.3. Pendant ce temps, le 4.2 était arrivé à 4.2.8, mais sous Arch on en restait à 4.2.5 puisque le 4.3 était dans le dépôt testing.
Ça a entraîné une discussion pour savoir comment gérer ce genre de chose, surtout qu’à l’époque le fait d’avoir attendu le 4.3.1 s’est avéré être une très bonne idée (https://bugs.archlinux.org/task/46968). Et l’écart entre le 4.4.1 et le 4.4 a également été plus long que d’ordinaire, pareil pour le 4.5.1 qui se faisait attendre : apparemment, en l’absence de problème majeur répertorié, les mainteneurs du paquet linux sous Arch ont décidé, pour la première fois depuis que je suis sous Arch, de pousser le .0 dans les dépôts stables.
Car sinon en effet, la politique c’était d’attendre le .1 histoire que les gros bugs n’arrivent pas dans les dépôts stable. Quand un noyau passe du stade de -rc à release, le nombre d’utilisateurs augmente considérablement, donc les bugs apparaissent plus facilement. En gros, Arch attend que les utilisateurs de Gentoo essuient les plâtres. ;)