Le noyau Linux 4.4 améliore le support des GPU AMD et de l'architecture ARM64

Le noyau Linux 4.4 améliore le support des GPU AMD et de l’architecture ARM64

Des pilotes, des pilotes, encore des pilotes

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

11/01/2016 3 minutes
56

Le noyau Linux 4.4 améliore le support des GPU AMD et de l'architecture ARM64

Après de nombreuses semaines de test, la version 4.4 du noyau Linux est finalement disponible depuis cette nuit. Elle apporte comme à son habitude de nombreuses améliorations, particulièrement du côté des pilotes graphiques.

Il aura fallu finalement huit Release Candidates pour que la version finale de Linux 4.4 soit mise à disposition. Comme souvent avec le kernel, une bonne partie des améliorations concerne avant tout les pilotes, particulièrement ceux des cartes graphiques.

Du neuf pour les GPU AMD, mais PowerPlay ne sera géré qu'avec Linux 4.5

Côté AMD, les générations Carrizo, Tonga et Fiji sont ainsi beaucoup mieux prises en charge, de nombreux bugs ayant été corrigés. Malheureusement, il faudra attendre Linux 4.5 pour profiter de la gestion avancée de l’énergie. Conséquence, la vitesse des ventilateurs n’évolue pas en fonction de la température, donc de la charge.

Côté NVIDIA, les nouveautés sont moins nombreuses, d’autant que l’accélération graphique n’est toujours pas prise en charge sur la série GTX 900. On trouvera davantage à se mettre sous la dent avec les processeurs Intel de la génération Skylake, dont le support des IGP est renforcé, avec une meilleure fiabilité à la clé. Un pilote KMS fait également son apparition pour le Raspberry Pi, mais il ne contient aucune gestion de l’énergie ni de la 3D encore.

Un meilleur support de l'architecture ARM64

Le noyau Linux 4.4 représente cependant une étape importante pour le support de la plateforme ARM, particulièrement sa déclinaison 64 bits. L’architecture ARM64 est donc mieux gérée, avec par exemple le support des pages mémoire de 16 ko ou encore une détection plus efficace des niveaux de fonctionnalités offerts par les puces. Des éléments de la norme UEFI 2.5 ont également été pris en charge pour améliorer encore le support d’ARM64/AArch64.

Outre l’habituelle flopée de changements apportés dans les pilotes, notamment réseau, le kernel 4.4 fournit de nombreuses améliorations pour les systèmes de fichiers. D’importantes corrections ont ainsi été apportées aux fonctions de chiffrement dans Ext4. Il est d’ailleurs recommandé à ceux qui utilisent ce système d’installer le nouveau noyau rapidement. Les RAID 5 et 6 sous Btrfs gagnent aussi des correctifs, tandis que F2FS se veut plus rapide et plus fiable.

Comme toujours avec les nouveaux kernel Linux, il faudra attendre que les éditeurs de distributions mettent à jour leurs dépôts pour récupérer la version 4.4 et ses 20,8 millions de lignes de code. Ceux qui souhaitent en savoir davantage sur les améliorations de cette version pourront lire le résumé publié par Phoronix. Notez que les sources du noyau peuvent être récupérées depuis le site officiel.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Du neuf pour les GPU AMD, mais PowerPlay ne sera géré qu'avec Linux 4.5

Un meilleur support de l'architecture ARM64

Fermer

Commentaires (56)


En même temps, il faut être un barbu intégriste pour utiliser les pilotes “nouveau” pour les carte NV… Il n’y a que les drivers propriétaires qui tiennent la route…








otto a écrit :



En même temps, il faut être un barbu intégriste pour utiliser les pilotes “nouveau” pour les carte NV… Il n’y a que les drivers propriétaires qui tiennent la route…





J’utilise nouveau car au taf, le blob proprio ne sais pas bien gérer le dock avec 2 écrans…









esver a écrit :



J’utilise nouveau car au taf, le blob proprio ne sais pas bien gérer le dock avec 2 écrans…





Bossant dans la 3D de pointe, il est impossible d’utiliser certaines features super importantes pour faire du dev moderne… sans compter les performance qui s’en suivent…









otto a écrit :



En même temps, il faut être un barbu intégriste pour utiliser les pilotes “nouveau” pour les carte NV… Il n’y a que les drivers propriétaires qui tiennent la route…







Ma carte n’est plus gérée par les proprio à jour. J’ai donc migré sur “nouveau” pour pouvoir mettre à jour le kernel… l’accélération 2D fonctionne mieux qu’avec le proprio <img data-src=" />

Par contre je ne joue pas sur cette machine.









otto a écrit :



En même temps, il faut être un barbu intégriste pour utiliser les pilotes “nouveau” pour les carte NV… Il n’y a que les drivers propriétaires qui tiennent la route…







C’est vrai que pour les gens qui ont besoin de performances le pilote nVidia est définitivement plus performant.



Maintenant, tout le monde ne bosse pas dans la 3D, ni ne fait de jeux hein… Pour les gens qui ont une carte graphique bas de gamme et/ou font juste de la bureautique (sur PC desktop ou laptop), le pilote “nouveau” suffit amplement.





Comme toujours avec les nouveaux kernel Linux, il faudra attendre que les éditeurs de distributions mettent à jour leurs dépôts pour récupérer la version 4.4 et ses 20,8 millions de lignes de code.





-Ou alors télécharger les sources et le patchset qui va bien, décompresser dans /usr/src/linux-4.4 , make menuconfig (ou récupérer la config existante d’une précédente compilation ou via /proc et faire make oldconfig) et compiler le noyau avec make <img data-src=" />



-Utiliser Gentoo, qui ne fait qu’automatiser le téléchargement source/patchset/décompression <img data-src=" />









otto a écrit :



En même temps, il faut être un barbu intégriste pour utiliser les pilotes “nouveau” pour les carte NV… Il n’y a que les drivers propriétaires qui tiennent la route…



Vu la politique de Nvidia avec les pilotes libres (= démerdez-vous, on ne vous donnera jamais de documentation ni de support), ce n’est pas étonnant…





Comme toujours avec les nouveaux kernel Linux, il faudra attendre que les éditeurs de distributions mettent à jour leurs dépôts pour récupérer la version 4.4 et ses 20,8 millions de lignes de code.





Oui d’ailleurs ce passage n’est pas très exact : il ne « faut » pas attendre que le nouveau noyau soit dispo sur les dépôts, il existe d’autres voies… Sur n’importe quelle distribution il est possible de récupérer le code source du noyau sur kernel.org.


Vous voulez dire comme ce qui est indiqué à la fin du paragraphe ? Et ce n’est pas une mise à jour, c’était déjà dans l’actu&nbsp;<img data-src=" />








Vincent_H a écrit :



Vous voulez dire comme ce qui est indiqué à la fin du paragraphe ? Et ce n’est pas une mise à jour, c’était déjà dans l’actu <img data-src=" />







On pinaillait juste sur le choix du verbe : « il faut attendre », qui peut donner l’impression que c’est la seule option et que l’utilisateur dépend entièrement de l’éditeur. D’ailleurs maintenant que tu le dis, c’est bizarre de dire « il faut faire ceci », et ensuite de donner une autre possibilité <img data-src=" />



C’est du détail, mais on aime bien la tétrapilectomie <img data-src=" />



&nbsp;







esver a écrit :



J’utilise nouveau car au taf, le blob proprio ne sais pas bien gérer le dock avec 2 écrans…





Le monsieur en #1 a dit que tu étais un barbu intégriste <img data-src=" />&nbsp;&nbsp;



Allez,&nbsp; on ne discute pas. Tu prends ta fiche S et tu vas pointer quatre fois par jour au poste.









esver a écrit :



J’utilise nouveau car au taf, le blob proprio ne sais pas bien gérer le dock avec 2 écrans…





Normalement avec les derniers pilotes + des versions de noyaux assez récent ça doit fonctionner.

Je suis sur un dock avec 2 ecran 24” + mon écran de portable, ça fonctionne pas trop mal.



Suffit pour les performances, c’est certain. Mais une gestion plus efficace, c’est aussi une bien meilleure autonomie sur un portable, même quand tu ne fais que de la bureautique.








seb2411 a écrit :



Normalement avec les derniers pilotes + des versions de noyaux assez récent ça doit fonctionner.

Je suis sur un dock avec 2 ecran 24” + mon écran de portable, ça fonctionne pas trop mal.





Ok, il y a 2 ans j’avais des problèmes.

Bon comme ça marche bien actuellement , je ne vais toucher à rien car le blob ne m’apporterait rien.



Penser à aller acheter du café aussi <img data-src=" />








otto a écrit :



En même temps, il faut être un barbu intégriste pour utiliser les pilotes “nouveau” pour les carte NV… Il n’y a que les drivers propriétaires qui tiennent la route…





avec une 9800 en mono écran ça marche plutôt bien.



Bon, ça va pas tarder avec ma Fedora, comme d’hab…



Dommage pour NVidia que j’en ai eu marre qu’ils s’en foutent des développeurs Tux, je ne prends plus désormais que des Intel avec IGP incorporé à cause de ça. Comme je ne fais guère plus poussé que du traitement d’images, ça me suffit point de vue puissance.








CryoGen a écrit :



-Ou alors télécharger les sources et le patchset qui va bien, décompresser dans /usr/src/linux-4.4 , make menuconfig (ou récupérer la config existante d’une précédente compilation ou via /proc et faire make oldconfig) et compiler le noyau avec make <img data-src=" />



-Utiliser Gentoo, qui ne fait qu’automatiser le téléchargement source/patchset/décompression <img data-src=" />





T’aurais pas un .exe, ou mieux un .msi ?









esver a écrit :



Ok, il y a 2 ans j’avais des problèmes.

Bon comme ça marche bien actuellement , je ne vais toucher à rien car le blob ne m’apporterait rien.





Ok <img data-src=" />









John Shaft a écrit :



Penser à aller acheter du café aussi <img data-src=" />







Bof, un linux ne redémarre pas tout seul en fermant plus ou moins en force tes applications en cour <img data-src=" />

Pas besoin de rester devant la machine <img data-src=" />







tazvld a écrit :



T’aurais pas un .exe, ou mieux un .msi ?







Tu prends une distrib binaire et voilà <img data-src=" />



C’était dans le sens “pour l’écrasante majorité des utilisateurs”&nbsp;<img data-src=" />


donc finalement tout ceux qui argumentent&nbsp; “je prend pas du AMD parce que ça marche moins bien sous linux qu’NVIDIA” c’est du bidon?


C’est quoi ce pilote nouveau? Ma radeon n’est plus supportée par le constructeur et je ne peux pas lire de vidéos en plein écran sans saccades sous mint


Non, nVidia fonctionne très bien avec les drivers proprios.








Reparateur a écrit :



donc finalement tout ceux qui argumentent&nbsp; “je prend pas du AMD parce que ça marche moins bien sous linux qu’NVIDIA” c’est du bidon?





<img data-src=" /> C’est l’informatique… ce qui est vrai au temps x ne l’est plus forcement au temps y



Mais pour le coup c’est toujours vrai. Ça s’est un peu amélioré du coté d’AMD, mais les performances restent très en retrait par rapport à nVidia. C’est d’autant plus dommage que sous Windows les cartes AMD surclassent les nVidia donc le potentiel est là.







chris.tophe a écrit :



C’est quoi ce pilote nouveau? Ma radeon n’est plus supportée par le constructeur et je ne peux pas lire de vidéos en plein écran sans saccades sous mint





Nouveau c’est pour les cartes nVidia.



En fait tout dépend de quoi on parle. Si l’on utilise pas les fonctionnalités non prises en charge par le pilote propriétaire, que l’on possède une carte supportée par le pilote propriétaire et que l’on en a rien a carer de l’open source (je schématise), le pilote Nvidia semble permettre de mieux profiter des performances de sa carte graphique. Si l’on est pas dans ces conditions on se retrouve avec le pilote libre “nouveau” qui, bien que progressant rapidement, n’est pas (encore) au niveau des autres pilotes libres.

Le pilote propriétaire d’AMD (fglrx) ne permet pas de profiter d’autant du potentiel de la carte mais AMD étant en train de transitionner vers une architecture de pilote plus libre, le pilote libre progresse plus rapidement et permet de meilleures performances que le pilote libre Nvidia.



Globalement:

Nvidia: Pilote proprio : ++++ Pilote libre : +

AMD:&nbsp;&nbsp; Pilote proprio : +++&nbsp;&nbsp; Pilote Libre : ++

Intel:&nbsp;&nbsp; Pilote proprio : inexistant, Pilote Libre : ++








pyrignis a écrit :



Globalement:

Nvidia: Pilote proprio : ++++ Pilote libre : +

AMD:&nbsp;&nbsp; Pilote proprio : +++&nbsp;&nbsp; Pilote Libre : ++

Intel:&nbsp;&nbsp; Pilote proprio : inexistant, Pilote Libre : ++





L’exception Intel étant:

Intel GMA950: Pilote libre inexistant, pilote proprio caca :/



Mais c’est un bon résumé sinon



Je vais tester en croisant un max de doigts pour voir si le bug bien chiant des Intel BayTrail a été corrigé


je n’ai pas vu de màj pour nvidia sur rpmfusion depuis un moment.

kmod-nvidia-358.16-1.fc23.x86_64

Linux virt 4.2.3-300.fc23.x86_64 #1 SMP Mon Oct 5 15:42:54 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux








pyrignis a écrit :



[…]



Globalement:

Nvidia: Pilote proprio : ++++ Pilote libre : +

AMD:&nbsp;&nbsp; Pilote proprio : +++&nbsp;&nbsp; Pilote Libre : ++

Intel:&nbsp;&nbsp; Pilote proprio : inexistant, Pilote Libre : ++





Sur une echelle de 5+ (+++++), le niveau max étant au niveau des pilotes sous win?



il n’y a pas de niveau maximum :)



Là c’est 4 et pi c’est tout :p


Tu prends pas de carte Nvidia si tu ne fais que de la bureautique


Je rajouterais qu’il y à deux chose qui importe sous linux pour les drivers libres :




  • Les drivers en eux même.

  • L’implémentation OpenGL/DirectX/Squetuveux sous le doux nom de mesa 3D.



    Du coup tu peut avoir à la fois de bon driver limité par le support de Mesa 3D ou l’inverse.

    Typiquement, il y à pas si longtemps (peut être un an) mesa ne supportais pas OpenGL 4 alors

    que des jeux AAA pour linux l’utilisaient (ex : tropico 5), ce qui empêchais de fait de jouer

    (pas un problème de performance).


Il n’y a pas que la performance …

Sans gestion par le driver de la ventilation, AMD c’est juste un hélicoptère dans ton PC.

Côté AMD, … Malheureusement, il faudra attendre Linux 4.5 pour profiter de la gestion avancée de l’énergie. Conséquence, la vitesse des ventilateurs n’évolue pas en fonction de la température, donc de la charge.



Visiblement, ce n’est pas la priorité des développeurs libre.








luxian a écrit :



Il n’y a pas que la performance …

Sans gestion par le driver de la ventilation, AMD c’est juste un hélicoptère dans ton PC.

Côté AMD, … Malheureusement, il faudra attendre Linux 4.5 pour profiter de la gestion avancée de l’énergie. Conséquence, la vitesse des ventilateurs n’évolue pas en fonction de la température, donc de la charge.



Visiblement, ce n’est pas la priorité des développeurs libre.





ce genre de geek est en watercooling <img data-src=" />









luxian a écrit :



Conséquence, la vitesse des ventilateurs n’évolue pas en fonction de la température, donc de la charge.





Sûr de ça  ?

Me semble qu’il y à un support bourrin “hélicoptère” de la gestion de les ventilateur, mais un support tout de même.

J’ai perso, pas de problème de ventilo casse-pied tant que j’ouvre pas un jeu vidéo ou autre, rien à voir avec le support de ventilateur inexistant que j’avais précédemment ( il y à 4,5 ans) en utilisant le pilote nouveau ou le ventilateur était tout simplement bloqué en continu sur la puissance maximum.



Qu’en est il de la prise en charge d’optimus ? &nbsp;J’imagine que c’est aussi lié à wayland.


Ou alors tu prends ce que tu as. Sur mon portable (sous Windows), j’ai une carte nvidia certes peu puissante, mais tout de même meilleure que le chipset intel intégré.

Si je devais installer Linux, ça me ferait chier de savoir que mon pilote me bouffe 2h de batterie juste parce qu’il est mal optimisé, même si les performances sont bonnes.


Pour info, la gestion du DPM est complète pour toutes les générations de cartes sauf la dernière (et les premières, vu que ça n’existait pas avant R600).



“Les développeurs libre”, qui selon toi ont des difficultés à bien cerner leurs priorités, sont principalement des employés d’AMD.


Merci pour l’info, donc pas de solution miracle pour moi… snif<img data-src=" />


Le problème avec Wayland, c’est justement pas Wayland. C’est plutôt de devoir réimplémenter ou modifier tout ce qui utilise une brique qu’on s’est imaginé indéboulonable depuis 25 ans : X

Les frameworks/applis/autres… qui utilisaient des fonctions fournies par X.org doivent tout modifier pour supporter Wayland (gestion des fenetres, captures ecran, etc) ou passer par la surcouche XWayland quand c’est possible.



Si je ne me trompe pas, le support dans GTK est pas mal avancé, Qt/KDE 5.5 a qqch qui tourne correctement en “tech preview”, mais quand tu lances qqch qui soit pas fourni avec les bureaux (jeu par exemple), c’est la loterie pour le moment.


Apparemment, il est “utilisable” dans la dernière Fedora (sortie il y a 2 mois).

Un retour d’expérience pour Gnome

Un autre dans un test de KDE 5.5



Quand on lit ca, on peut être optimiste. Je croise les doigts moi aussi pour qqch genre fin de cette année…


Wayland fonctionne aussi sous Archlinux, dans l’environnement Gnome, avec aiguillage automatique vers le bon backend en fonction des applications.








hurd a écrit :



Me semble qu’il y à un support bourrin “hélicoptère” de la gestion de les ventilateur, mais un support tout de même.









Quiproquo a écrit :



la gestion du DPM est complète pour toutes les générations de cartes sauf la dernière





Et bien messieurs, j’ai testé tout ce que j’ai pu sur ma HD6850 .. et si vous avez mieux que cela … je suis preneur …

aticonfig -q –pplib-cmd “set fanspeed 0 4” –tls=off –signal-block=on –od-enable –od-commitclocks –od-gettemperature –effective=now –pxl

Vitesse de rotation de … 4 % pour que le bruit soit inférieur à mon alimentation Seasonic !!! à 20 %, je met des bouchons dans les oreilles.





Quiproquo a écrit :



“Les développeurs libre”, qui selon toi ont des difficultés à bien cerner leurs priorités, sont principalement des employés d’AMD.





Vu les résultats, je ne sais pas si je dois être rassuré ou avoir peur.

Depuis que j’ai ma carte graphique, sur une même configuration aucune amélioration de performance de plus de 1 % d’un driver à l’autre, Unigine Valley faisant foi … le changement de noyau était plus efficace !

Seul le driver catalyst-15.9-linux-installer-15.201.1151 a fait un réel mieux, sans être aussi performant que le driver Windows. Et je suis désolé, mais les drivers libres ne m’ont jamais fait croire aux miracles à chaque fois que je les ai testés.



La même carte, sur le PC de mon épouse, est plutôt discrète avec le driver libre sans aucun réglage particulier. En charge elle est en effet potentiellement bruyante (y compris sous Windows).



Je ne sais&nbsp; pas trop comment fonctionne le driver proprio, mais ça me parait étrange de régler la vitesse du ventilateur à la main. Il n’y a pas les profils dpm ?


Hé hé … si tu as une solution ou un mode opératoire, un URL de début d’aide, pour ce qui est des profils DPM, je suis preneur.

Jusqu’à aujourd’hui, je n’ai rien trouvé qui marche.





Pour ma part, je fais la différence entre “discret”, “suportable” et “inaudible”.

Le driver windows m’empêche de descendre en dessous de 20% de la vitesse maximum de ventilateur : la carte est supportable à discrète (selon que je fais attention à la carte ou à mon travail).

Le driver linux me permet de descendre à 4 % : la carte est discrète (si je fais attention à la carte) à inaudible (si je me concentre sur mon travail).





[quote:5572302:QuiproquoEn charge elle est en effet potentiellement bruyante (y compris sous Windows)[/quote]

Là, l’OS windows/linux n’y est pour rien … c’est le ventilateur matériel qui tourne à fond pour assumer la consommation du processeur.

Quoique … la révision 2 du firmware de ma carte avait fait un “léger” mieux que l’originale.