Le noyau Linux est pratiquement prêt à sortir en version 4.4. Actuellement en Release Candidate 2, il apporte une foule de nouveautés, notamment sur les pilotes pour les GPU d’AMD, avec à la clé une hausse sensible des performances. Passage en revue des principales améliorations.
Depuis la version 3.0 du noyau Linux, le cycle de développement est passé pour rappel sur un modèle plus fluide, permettant d’apporter des nouveautés aux distributions qui l’emploient avec un rythme plus régulier. Ce qui n’empêche pas chaque version d’apporter des éléments significatifs, souvent dans la catégorie des pilotes graphiques d’ailleurs. La future version 4.4, pratiquement terminée, ne fera pas exception, surtout du côté d’AMD.
Cartes graphiques : il manque toujours la gestion de l'énergie sur des GPU AMD
Les GPU des générations Carrizo, Tonga et Fiji sont en effet beaucoup mieux gérés, et même la future génération Stoney d’APU est de la partie. Les nouveaux pilotes corrigent une foule de bugs et activent par défaut l’ordonnanceur AMDGPU. Les utilisateurs devraient donc observer une hausse des performances, mais la gestion renforcée de l’énergie n’est toujours pas au programme. Il faudra attendre l’arrivée du noyaux Linux 4.5 pour voir arriver les premières prises en charge de PowerPlay, avec à la clé évidemment une gestion plus fine de la consommation d’énergie et donc de la vitesse de rotation des ventilateurs.
Toujours au rayon des pilotes graphiques, signalons l’arrivée d’un pilote KMS pour le Raspberry Pi, mais uniquement en espace kernel pour l’instant, et sans accélération 3D ni gestion de l’énergie. Côté NVIDIA, on trouve également des améliorations diverses, mais comme le signale Phoronix, l’accélération matérielle pour la gamme GTX 900 n’est toujours pas disponible. La faute au fondeur qui n’a toujours pas fourni aux développeurs du pilote Nouveau les firmwares nécessaires. Enfin, côté Intel, la fiabilité des pilotes est renforcée, particulièrement pour les parties graphiques intégrées aux puces de génération Skylake.
Support matériel et fiabilité des systèmes de fichiers
Le noyau Linux 4.4 fournit aussi tout un lot d’améliorations pour la plateforme ARM, surtout sa déclinaison 64 bits. C’est bien la prise en charge elle-même qui est améliorée avec une meilleure exploitation de l’architecture matérielle. Parallèlement, la norme UEFI 2.5 est mieux gérée pour les architectures ARM64 et AArch64. Pour le réseau, là encore une foule de petites améliorations réparties entre de meilleurs pilotes, notamment pour certaines cartes Realtek, ainsi que le support de quelques technologies supplémentaires telles que le VRF (virtual routing and forwarding) pour IPv6.
Les systèmes de fichiers ont eux aussi droit à une flopée d’améliorations et/ou de correctifs. C’est particulièrement le cas avec EXT4 qui reçoit un patch important réglant plusieurs soucis liés au chiffrement. Les autres systèmes reçoivent également des corrections, notamment Btrfs pour sa gestion des RAID 5 et 6 ou encore F2FS pour la fiabilité et les performances.
À ces corrections s’ajoutent le meilleur support général du matériel, l’un des principaux créneaux d’évolution de chaque nouvelle version du noyau Linux. Ce support peut concerner des produits précis comme le clavier K90 de Corsair ou le volant G29 de Logitech, ou bien des catégories entières comme les touchpad de précision pour Windows 8/8.1/10 qui accompagnant les ordinateurs portables Skylake. Les portables Toshiba sont globalement mieux gérés, de même que le Pixel 2015 de Google (sous ChromeOS), les puces TPM 2.0 et un renforcement de l’ACPI.
Cette version 4.4 en étant déjà à la Release Candidate 2, l’arrivée de la mouture finale est maintenant imminente. Elle pourrait donc avoir lieu la semaine prochaine si aucun bug important n’a été trouvé. Comme toujours dans ce genre de cas, la mise à jour sera déployée par chaque éditeur dans les dépôts de sa propre distribution, mais l’installation manuelle reste toujours possible.
Commentaires (119)
#1
C’est pas les gpu AMD qui ont des perfs désatreuses sous Linux quel que soit le pilote utilisé (libre comme non libre) ? Côté nvidia en tout cas, le pilote non libre fonctionne très bien.
Je me demande d’ailleurs quel utilisateur de Linux reste sous les pilotes libres, vu l’écart de perf (Intel excepté, vu qu’ils sont libres, bien sur).
#2
Bel article mais je note une erreur.
> Cette version 4.4 en étant déjà à la Release Candidate 2,
l’arrivée de la mouture finale est maintenant imminente. Elle pourrait
donc avoir lieu la semaine prochaine si aucun bug important n’a été
trouvé.
C’est plutôt faux. Les release candidates du noyau Linux est assez différent des RC traditionnels ailleurs.
Si la théorie est vraie, en pratique il y a au minimum 6-7 RC avant la publication finale (nous en sommes plutôt loin).
En effet, le jour même de la fermeture de la fenêtre de merge donne lieu à la 1ère RC. Après 2 semaines d’intenses développement, il est toujours nécessaire d’avoir au moins 6 semaines de corrections. ;)
#3
#4
Je confirme qu’en fait les RC du noyau Linux sont plutôt des versions de développement. Mais comme le développement fonctionne par micro-releases ben il y a une certaine logique à ce que toutes les versions soient des RC.
Voir les topics des nouveaux noyaux sur linuxfr comme ici :
 https://linuxfr.org/news/sortie-du-noyau-linux-4-2
#5
Les portables Toshiba sont globalement mieux gérés
En même temps, c’est pas compliqué d’améliorer leur support.
Quand j’avais installé un Tux sur un Toshiba il y a de cela quelque temps, j’ai été surpris de voir que c’était la seule bécane sur laquelle le port réseau n’était pas géré en natif… Jamais vu ça ailleurs, y compris sur des zinzins tordus d’autres marques.
#6
Voire la cata des deux côtés (libre et proprio)
Sur mon HTPC (AMD A6 6400K, HD8450, un bon Richland des familles), sous Mint 17.2 KDE :
Sous LMDE 2 Cinnamon, le driver proprio me provoque aussi des freezes, et le libre m’envoie un Kernel Panic au démarrage.
Sous Mageia 5, j’ai juste quelques effets sous KDE 4 qui manquent de fluidité (en contrepartie, j’ai pulseaudio qui déconne à fond les manettes).
Bilan : passage sous W10.
#7
#8
#9
#10
En espérant que ce foutu bug soit définitivement corrigé et pas que momentanément pour revenir sur le 4.5, comme c’est le cas en ce moment.
" />
#11
Suivant le type de jeu il n’y a pas vraiment besoin de perfs. Évidemment exit les derniers AAA photo-réalistes (de toute façon sous linux ils se bousculent pas trop pour le moment) mais c’est pas vraiment ce que je cherche dans un jeu.
Et sinon pour répondre à la première question, il y a aussi ceux qui n’ont plus le choix vu que ma cg est trop vieille et qu’AMD ne fournit plus de drivers pour depuis à peu près 3 ans
#12
La gestion de la vidéo (et des pilotes en général) c’est vraiment la bête noire de Linux, parce que sinon pour tout le reste c’est un bel OS, bien passionnant…
Sinon je me demandais, pour Steam OS si certaines cartes ne sont pas encore gérées (ou certaines fonctionnalité) ça veux dire que cet OS utilise les driver non-free ou ses propres driver ? Comment ils font ?
#13
#14
Même sans parler du fait de jouer avec les options graphiques à fond la caisse, jouer avec le pilote libre est parfois (souvent même) assez anecdotique selon les PC.
Sur mon ancien PC (qui avait une Nvidia 9500GS), nouveau provoquait des freeze du système de manière aléatoire. Mais à côté de ça, j’arrivais à lancer Penumbra: Overture sans soucis et le jeu tournait de manière relativement fluide.
Sur mon PC actuel (GTX 750 Ti de MSI), changer le moindre paramètre graphique d’OpenArena (qui démarre par défaut en 800x600) et quelques autres jeux fait sauter le DE (que ce soit Gnome ou XFCE) et retour illico-presto vers l’écran de login de la distrib (j’ai eu le même comportement douteux avec Mageia, Fedora et ArchLinux). Du coup, je me sens un peu obligé d’utiliser le driver proprio, même pour les “petits” jeux pas spécialement gourmands.
#15
Bon , j’attendais un mieux sur l’autonomie globale sous haswell par exemple avec 4.2 et je vois que ça ne change pas grand chose, a part que TLP déconne avec 4.2 ….
Globalement vous voyez du mieux sur l’autonomie ?
#16
#17
Oui mais tu as une nvidia :). Le pilote nouveau, c’est assez aléatoire en fonction du matériel.
Le pilote amd libre fonctionne mieux que le nvidia libre. Par contre, le pilote proprio, c’est l’inverse : impossible de lancer gnome-shell avec fglrx, par exemple.
#18
Pour l’heure, je suis aussi sur la 3.16 mais avec Xubuntu 14.04. La Kernel Team de Canonical maintiendra ce kernel jusqu’en Août prochain donc je croise les doigts pour que ça soit corrigé d’ici là. De plus, le 4.4 devrait être celui utilisé par Ubuntu 16.04.
Cela dit, le kernel 4.1 semble avoir été épargné par ce soucis d’après certains retours et comme il est LTS, je verrais pour le tester sur Arch pour voir ce que ça donne un de ces jours !
Si vraiment ça ne donne rien et que je n’ai pas envie de bidouiller sur ma machine de tout les jours, je reviendrai à Xubuntu 14.04.1 et son kernel 3.13, supporté jusqu’en 2019 ou Debian.
#19
Je sais qu’on est tous pressé d’être en week end avec ces températures mais commencer comme ça dès Lundi
" />
#20
Dites, petite question bête de ma part (je n’ai pas encore migré à linux, mais à la vue de Windows 10 je crains que mon dernier daily OS microsoft soit 7…) : les cartes AMD HD7000 ne sont pas inclues dans ces mises à jour de pilotes, si ?
J’ai une HD7970 + Phenom II 955BE et j’hésite à installer Mint ou autre en dual boot à moyen terme ; peut-être vaudrait-il mieux que j’attende de renouveler mon GPU ?
#21
Normalement, ça devrait être bon mais rien ne t’empêche de tester en live
#22
C’est pas faux que les performances graphique sont un peu devenu un gros problème avec le temps. Avant ca allait encore car la différence pouvait se faire oublier. Aujourd’hui avec la puissance a disposition qui n’est pas utilisée ça se voit comme un pustule rouge au bout du nez sur le point d’éclater.
D’un autre coté c’est toujours aussi con d’avoir X versions de driver pour X OS. Ça manque clairement de guide (type RFC) dans le monde des programmes. Chaque OS fait ca sauce et ses protocoles et envoie bouler le reste du monde façon “j’ai raison”. Ca pourrait clairement faire mieux et faciliter la vie des utilisateurs finaux (puisque c’est la finalité).
#23
#24
Quel est l’intérêt de changer de version de noyau linux ?
Je suis sous Mint 17.1 et noyau 3.13-037,La version 4.2 est disponible, ai je intérêt a l’installer ?
#25
d’un côté si tout roule, tu aurais presque tort de changer.
" /> 
" /> 
" />
d’un autre côté les mises à jours intègre aussi des patchs de sécurité.
du coup tu es potentiellement vulnérable à des failles de sécurité pourtant connues, documentées et corrigés sur les versions postérieures. mais ça reste anecdotique car vu que tu utilises un système qui n’intéresse pas les pirates, tu es un peu plus à l’abri qu’un Windows.
donc non, mais oui mais pas vraiment.
#26
Au contraire, dans le driver libre à l’heure actuelle les Sea Islands sont mieux supportées que les Volcano Islands, qui dépendent d’un nouveau driver pas encore finalisé.
Si tu souhaite utiliser le driver propriétaire, il n’est pas concerné par les mises à jour du noyau.
#27
Si tout fonctionne bien chez toi, il n’y a aucun intérêt à changer. Maintenant, si le support de ton matériel n’est pas parfait, de mettre à jour le noyau mettra également à jour la plupart des pilotes, ce qui pourrait éventuellement améliorer la situation.
En passant, Linux Mint 17.3 ne devrait plus trop tarder à sortir.
#28
Le 3.13 n’est plus supporté par les développeurs de Linux, donc si ta distribution ne porte pas les correctifs de sécurité, il est vulnérable. Si tu ne mets pas à jour souvent, prends plutôt le 4.1, qui est support étendu.
#29
Aucun intérêt si tu ne ressens pas de manque particulier et et ce kernel est supporté jusqu’à 2019 par l’Ubuntu Kernel Team donc tu es tranquille. Idem pour les patchs de sécurité, aucune inquiétude à avoir, ils sont distribués sur tout les kernels maintenus, si besoin.
@Quiproquo Qu’un noyau soit LTS ou non n’a que peu d’importance dans des distributions comme Ubuntu/Mint qui dispose d’une “Kernel Team”. Tout comme Debian utilise un kernel 3.16, pourtant plus supporté “officiellement” mais toujours maintenu au niveau de la sécurité
#30
Les correctifs sont rétroportés. Même si la version ne change pas, tant qu’il applique bien les mises à jour proposées par sa distribution, tout va bien.
C’est issu de la FAQ sécurité de Debian, mais comme c’est repris par Ubuntu, elle-même reprise par Mint, c’est du pareil au même
#31
le kernel 3.13 est encore supporté sur Ubuntu 14.04.1 jusqu’en 2019, donc patch sécu inclus.
#32
Sur Debian Jessie ta config tournera très bien, catalyst compatible. J’ai une 7750 et aucun souci.
Bon c’est pas le dernier noyau, ni les tout derniers catalyst.
Le problème des distribs avec les derniers paquets et kernels, ou
changements de Xorg, on passe son temps les mains dans le cambouis pour
refaire tourner sa carte graphique (avec les pilotes proprios qui
suivent pas les mises à jours ou abandonnent tout bonnement le support
des modèles anciens), mais comme dis Yseader rien ne t’empêche de tester
en live tout court.
#33
#34
Sur Debian Jessie ta config tournera très bien, catalyst compatible. J’ai une 7750 et aucun souci.
Bon c’est pas le dernier noyau, ni les tout derniers catalyst.
Le problème des distribs avec les derniers paquets et kernels, ou
changements de Xorg, on passe son temps les mains dans le cambouis pour
refaire tourner sa carte graphique (avec les pilotes proprios qui
suivent pas les mises à jours ou abandonnent tout bonnement le support
des modèles anciens), mais comme dis Yseader rien ne t’empêche de tester
en live tout court.
#35
OK
" /> ça doit changer le numéro derrière.
comme je suis sur arch et que si je veux un noyau à jour il faut que je passe sur une version supérieure, j’ai pas été chercher plus loin.
#36
#37
#38
Il y a au moins un avantage avec les pilotes Linux : on peut utiliser les officiels, même sur un notebook. Sous Windows je ne sais pas comment c’est fait, mais sur un notebook il faut toujours utiliser les pilotes du fabriquant. Ceux de chez Nvidia ou AMD refuseront de s’installer.
Je joue en ce moment à KSP, sur Manjaro + Steam, avec une carte graphique Nvidia à travers Optimus, et pour le moment ça fonctionne plutôt bien.
AMD je préfère éviter, le pilote libre est à la bourre avec de mauvaises performances, et fglrx est bugué/impossible à maintenir (d’ailleurs Archlinux l’a exclu de ses dépôts il y a longtemps, je n’ai pas vérifié si c’est toujours le cas).
J’espère que ce nouveau pilote “hybride” sera meilleur.
#39
Les gens qui tiennent à ne pas s’emmerder avec les drivers proprio (par idéologie ou par choix pratique) choisissent leurs matos en fonction.
C’est mon cas : Portable et PC fixe avec partie graphique Intel. J’évite les drivers proprio plus pour le côté pratique (n’importe quel distrib s’installera facilement) que par idéologie (j’utilise quelques logiciels non libres).
#40
#41
Oui, mais pour le cas de NVdia, ca fait des années qu’ils bossent sous OS Linux au niveau pro. Donc oui ce choix est meilleur si l’on choisis Linux.
Quand je parle de gestion, je ne pense pas au niveau de l’OS mais au niveau de l’utilisateur. La partie matériel sous Linux est quand même pas super accessible par rapport aux OS MS (même sous DOS la gestion du matos était plutôt accessible).
Il manque, je pense un niveau d’abstraction supplémentaire pour un accès facile aux fonction de base. Et je parle en interface graphique, pas en shell.
#42
Qu’est-ce que tu entends par fonctions de base ?
Quelle est la GUI qui te manque ?
#43
Pour faire quoi ? Avec des distributions comme Manjaro ou Mint, installer le pilote nVidia se fait en deux cliques de souris, et ça se met à jour tout seul par la suite.
En dehors des pilotes graphiques propriétaires, le reste des pilotes (audio, contrôleurs…) sont généralement fournis de base avec le noyau. C’est donc encore plus simple que sous Windows, puisque l’utilisateur n’a rien à installer, et qu’il suffit de mettre à jour le noyau pour mettre à jour quasiment tous les pilotes.
#44
Oui, le pilote proprio est toujours hors dépôt pour ArchLinux, ne serait-ce que parce qu’il est régulièrement en retard d’une version du serveur X. En ce moment, il n’est même pas compatible avec le noyau par défaut.
Pour ce qui est du pilote libre, il a pas mal progressé ce dernières années (c’est probablement lié au fait qu’AMD salarie des développeurs).
#45
#46
#47
Je ne me contente jamais des pilotes de base, on ne sais pas s’il sont correctement optimisés matériellement parlant. C’est a dire qu’il utilisent au mieux toutes les fonctions matérielles de la puce libérant ainsi des ressources processeur.
C’est un peu comme se contenter des pilotes par défaut sous Windows. Et que dire du matos nouveau qui sort après la publication d’une distrib, il faut qu’il puisse être supporté aussi. Non ?
Quand tu administres des PC, que tu cherche l’identification du périphérique, les IRQ utilisés ou les adresses mémoire. C’est beaucoup plus accessible sous Windows que sous Linux. Par exemple configurer un port COM sous Linux c’est nettement moins accessible que sous Windows.
#48
Oui, Linux nous apprend la patience :)
Ne pas se jeter sur la dernière nouveauté bien alléchante…
#49
Ah heureusement que certains ici nous rabâchent depuis des années que Linux dominera le monde, en attendant, même si ce n’est pas totalement de leur faute, il semble souffrir d’un retard technologique assez impressionnant à la lecture de l’article.
#50
#51
#52
Les pilotes Open Source AMDGPU pour GNU/Linux sont arrivés.
#53
On s’en fout un peu des pilotes Linux pour GPU de bureau. Ça fait 20 ans que GNU/Linux n’arrive pas à percer dans ce marché.
Sur Android, les pilotes fonctionnent parfaitement (même si ils sont rarement libres et souvent figés sur une version du noyau).
#54
les pilotes “de base” sont parfois des pilotes rétro-ingénéré, d’autre fois c’est carrément le constructeur qui les ajoute (c’est le cas pour intel).
il est vrai que la littérature n’est pas claire sur ce point là. il est difficile de trouver de l’information grand public.
c’est une nuance que j’essaye de faire comprendre a des défendeurs un peu aveugle de linux. Etant moi meme un utilisateur qui n’a plus de windows, je suis quand meme assez conscient de ses limites.
#55
non, on ne s’en fou pas.
parce que les GPU de bureau de nos jour décodent le h264 en hardware, et ca peux pas mal servir pour les HTPC
#56
Précisons que ce pilote est principalement destiné aux GPUs de dernière génération (GCN 1.2). Il gère la génération précédente de façon expérimentale et temporaire.
#57
De nos jours on peut décoder le h264 en JavaScript, et un smartphone récent peut encoder un flux 4K à la volée.
#58
#59
#60
Oui justement, le fait de pouvoir aujourd’hui décoder du H264 en JavaScript montre bien que le problème est réglé et qu’on a pas besoin de décodeur hardware sur PC.
Et sinon, selon moi Linux a déjà gagné. La part de marché cotés serveur et mobile est énorme. Il reste juste le marché moribond des PCs à conquérir, mais on s’en fout un peu.
#61
#62
#63
La situation n’a strictement rien à voir. Sous Windows, de base, il s’agit effectivement de pilotes génériques. Mais à côté de ça, les constructeurs fournissent des pilotes complets (mais propriétaires) qu’ils développent eux-mêmes. L’utilisateur peut donc installer ces derniers pour jouir d’une meilleure expérience.
En ce qui concerne Linux, ces mêmes constructeurs ne s’y intéressant généralement pas (il existe tout de même quelques exceptions bienvenues, comme Intel), c’est à la communauté de se débrouiller par elle-même. On tente donc de fournir de base les meilleurs pilotes possibles, puisque il n’y a généralement pas d’autres pilotes fournis à côté (et que nombre d’utilisateurs ne souhaiteraient pas s’emmerder avec des pilotes comme sous Windows).
Les pilotes de cartes graphiques sont plutôt une exception. La carte graphique est, de loin, l’élément le plus complexe de nos machines. Développer des pilotes libres par rétro-ingénierie est un travail de titan. Et pour le reste des pilotes propriétaires (typiquement le cas de certains chipsets Wi-Fi), en général il n’existe pas de pilote libre, et c’est donc ça ou rien.
#64
Je suis sous Debian Jessie avec les pilotes libres et aucun problème.
Par contre j’avais les pilotes proprio avant et c’était la catastrophe… Résolution de merde, déchirure d’images, sursaut…
Bref, c’est surtout sur mon pc pour bosser sur du dev que je l’utilise, donc pas de jeux. Je ne peux donc pas juger à fond.
#65
#66
je ne vais pas ré-argumenter, mais croire que sous linux les pilotes serait plus complet parce que la philosophie est differente est completement faux.
le fait d’avoir une interface n’est pas la traduction d’une bonne qualité d’un pilote.
sous windows, les pilotes sont livré avec l’interface qui controle le materiel
Sous linux il en est parfois de meme, il suffit de voir nvidia server settings, ou HPlip
Parfois ce logiciel tier est inlus dans un composant de l’OS (pulseaudio pour les cartes sons)
Mais souvent, ca manque.
Le pilote tout seul, ne se suffit pas a lui meme. (essaye de configurer une manette xbox sans calibration..) Il faut d’une manière ou d’une autre sur un desktop, avoir une interface pour le controler
#67
Je suis le seul avec un gpu AMD utilisé avec le driver libre et qui a des perf ?
Sur certain jeux ça lag un peut plus que sous windows mais pour le reste tout mes jeux tourne sous linux (je parle des jeux natif).
#68
la consommation électrique n’est pas la meme..
si on prend ce qui s’est passé autrefois concernant une autre techno : le mixage audio
il a longtemps été hardware, mais pour que les constructeur l’abandonne au profit du tout sofware, il a fallu attendre que ca passe en dessous des 1 a 2% de CPU…
#69
Je pense qu’il faisait plus référence au fait que certaines distributions étaient pleinement fonctionnelles de base, sans avoir besoin d’installer tout un tas de pilotes et autres applications, comme ça peut être le cas sous Windows.
Puis avec les environnements de bureau modernes, on a également tout le nécessaire pour configurer son matériel. Sous GNOME, PulseAudio est bien intégré pour le son, Cheese est installé pour les webcams, on peut configurer son imprimante, sa tablette Wacom…
La philosophie n’est vraiment pas la même. Les distributions et les environnements de bureau partent du principe que tous les pilotes sont bien présents, et qu’il faut donc construire une expérience utilisateur au-dessus de tout ça. Ce qui permet d’obtenir au final une solution parfaitement bien intégrée, homogène avec le reste de l’environnement, offrant ainsi une bonne expérience utilisateur.
À l’inverse, sous Windows chaque constructeur arrive avec sa propre solution, ses propres outils.
#70
#71
oui sous windows chaque constructeur arrive avec sa propre solution, ses propres outils, ce qui est parfois inutile et redondant. (et parfois compliqué)
#72
Je n’utilise que des drivers libres, sur le laptop avec carte AMD, cela me permet de brancher plus d’écrans externes (3 écrans au total, pas testé 4, contre 2 avec le driver proprio) et j’ai également de meilleurs perfs sur le scrolling des pages web. Le seul intérêt du driver proprio c’est pour les perfs 3D, mais j’en ai pas besoin.
#73
#74
Bref, NVidia continue à faire chier le monde, raison pour laquelle je vais continuer à acheter exclusivement du GPU AMD… Ben oui : pourquoi j’irais payer plus cher quelque chose que je ne peux pas exploiter pleinement ?
#75
#76
#77
#78
En fait je parle d’interconnexion avec les OS qui ont chacun une façon de faire.
Ex: Avoir un équivalent DirectX dans un Linux permettrai un tas de choses plus mature que ce que l’on peu voir.
Mais ce serait mieux d’avoir directement le programme (la suite en fait) DirectX fonctionnant sur toutes les plateformes. Rien n’empercherai non plus un concurrent de DirectX.
C’est juste que aujourd’hui tu dis DirectX tu entends Windows. Il y a vraiment mieux a faire en matière de “Digital Jazz”. On est quand même en 2015.
#79
#80
#81
#82
dans ce cas pourquoi y en a t-il qui senbete a deblober le noyau ?
http://www.fsfla.org/ikiwiki/selibre/linux-libre/index.fr.html
#83
#84
#85
Je me trompe peut-être mais un OS n’est pas sensé apporter des pilotes de base pour des périphériques de base et non pas des pilotes pour tel ou tel périphérique de telle ou telle marque ?
#86
ne mets pas le kernel 4.X.X pour les pilotes AMD proprio, sinon tu vas pleurer après le reboot.
#87
#88
si nividia a changé sa politique.
ils y a eu des commit pour le driver legacy nv
il y a aussi de la coopération pour des cartes reservé aux arm
et enfin, il y a les pilotes pour tegra
rien qui interesse les gamers, mais il y a eu un peu de changement.
#89
dualboot
sous steam y’a aucun pblm, mais des jeux pas prévu pour, n’ont pas forcement le remapping, et cela devrait etre inclus dans les environnement de bureau (je sais qu’il existe anti-micro, mais je crois pas qu’il soit vraiment adapté)
#90
de ce que j’ai compris, tu confond blob et firmware.
le blob est du binaire déjà compilé.
le firmware aussi est du binaire déjà compilé, donc c’est aussi un blob.
blob c’est un terme générique pour dire que c’est du binaire.
le terme est emprunté au “type” de donnée qu’on trouve dans une base de donnée
(varchar, int, float, blob)
#91
en fait, wine, a eu récemment comme projet test de directement réimplémenter directX, plutot que d’utiliser une couche de traduction des appel directX en opengl
(directX state tracker)
donc, si cela abouti, on aura donc directX 10⁄11 (une parti de ses composant), sous linux.
si on rajoute .Net, et toute les librairies windows déjà récrite sous linux via wine, on peux dire que ça commence a devenir interessant
#92
#93
#94
Utilisateur d’Archlinux depuis un moment, je vois une très très nette amélioration des performances du driver AMD libre depuis la version 3.18 environ (désolé pour les utilisateurs Debian Jessie :p).
Sur ma 7970 (plus de 2 ans d’âge) je peux faire tourner beacoup de jeux Steam OS en ultra HD sans aucun souci. Les déchirements n’existent plus depuis un moment également.
Exemples de jeu fonctionnant très bien en qualité ultra:
Foirages complets de portage:
La 4.3 a apporté encore quelques éléments de stabilité et de rapidité supplémentaires et on attend avec impatience les patchs futurs pour la 4.4, d’ici 5 semaines
#95
#96
#97
#98
Il y a eu des patchs pour ça il me semble.
Je n’ai plus ce problème par exemple sous Fedora.
#99
#100
#101
Juste pour signaler que depuis dimanche chez moi, xorg 1.18 et NVidia proprio sous archlinux marche au poil.
#102
#103
#104
#105
Et dans ce cas précis, quelle est la plus-value de Fedora, sachant que Mint est la distribution des développeurs de Cinnamon, qui bénéficiera sans contexte de la meilleure expérience qui soit ?
" />
Si tu me sors des applications plus récentes, alors autant opter pour Arch
#106
#107
#108
[HS]N’étant pas “linuxien”, c’est un régal de lire ces commentaires d’INpactiens avisés[/HS]
" />
#109
On a justement vu que c’était pas le cas dans le test comparatif entre Steam OS et Windows.
Pour semble t il pleins de raisons différentes, pas forcément liées à l’OS, mais au final…
Pour les type de fichiers, Mac OS qui ne supporte toujours pas le NTFS, ça c’est un retard, les formats non supportés par Windows sont pour le coup pas très utilisés.
Heureusement que l’exFat est là !
#110
C’est très variable. Certains jeux semblent mieux tourner sous Linux que sous Windows.
" />
En ce qui concerne OS X, les clients Apple aimant bien payer, la prise en charge du NTFS ne devrait pas trop leur poser problème
#111
#112
Il faut en plus savoir que les portages de jeux sous Linux utilisent la plupart du temps une version plus ancienne d’OpenGL (pour des raisons de compatibilité, notamment avec MacOSX qui reste bloqué sur 4.1).
Du coup c’est comme comparer des softs qui tourneraient en DX9 avec ceux qui tournent en DX11.
#113
Pas vu cette possibilité, je reteste de suite ! Merci du tuyau :jap:
#114
oui, il n’y a pas de blob dans les sources du noyau, je le sais bien.
je dit simplement que les blobs ne représentent pas seulement les firmware, mais tout ce qui est un fichier binaire sans queue ni tete pour le systeme.
ce n’est pas un synonyme de firmware.
#115
#116
Je le sait bien ;)
En tout cas pour l’instant le 4.3 semble particulièrement réussi, aucune révision depuis sa sortie :) Et moi qui attend désespérément une MàJ pour tester des trucs :/
#117
Bonjour,
Tu as d’autre distrib comme Ubuntu qui fonctionne des fois mieux avec les CG. Ne craches pas dessus, ça pourrait-être bien.
Je l’utilise depuis un certain temps et je joue sur win. Plus pratique et plus beau.
#118
J’attends les progrès avec impatience. J’en ai marre d’utiliser un système non libre.