Steam on Linux Numbers Dropped to 2.23% in February
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Nous avions appris avant l’été que la pile graphique d’AMD serait désormais entièrement libre et qu’AMD abandonnait ses derniers pilotes propriétaires au sens de privateur, mais AMD s’est également séparé du pilote libre AMDVLK au profit du pilote libre RADV de Mesa !
![]()
L’ombre de Valve plane sur les pilotes graphiques AMD sous Linux. Ici une Steam Deck de 2022 et une AlienWare Alpha (Steam Machine originelle de 2015) en variante AMD, fonctionnant toutes deux avec RADV.
Le 17 novembre 2025, avec la sortie de la version 25.20.3, RADV est devenu le pilote Vulkan universel pour les cartes AMD sous Linux. Cette dépêche vous emmène sur les traces du pilote RADV et comment celui-ci a remplacé AMDVLK, remémore l’aventure d’ACO pour battre LLVM, raconte comment un changement récent du pilote Linux amdgpu active la prise en charge de Vulkan sur de nombreux matériels anciens, et soyons fou, vous explique comment installer RADV sur une Xbox.
Précédemment, dans la dépêche du 3 juillet dernier La pile graphique d’AMD sous Linux est désormais complètement libre nous découvrions qu’AMD était sur le point de se défaire de ses derniers pilotes graphiques propriétaires. C’est désormais chose faite !
Mais il y a un rebondissement ! En effet l’annonce portait sur l’abandon des pilotes « propriétaires » (AMD proprietary OpenGL and Vulkan drivers). L’adjectif « propriétaire » pouvait s’entendre dans le sens de « contraire de libre », et donc, à code fermé.
Nous savions donc que le pilote à code fermé Vulkan AMDVLK-Pro était poussé vers la sortie. Cette affirmation et cette interprétation laissait ouverte la possibilité que le pilote Vulkan libre AMDVLK puisse survivre. Mais l’adjectif « propriétaire » pouvait aussi s’entendre dans le sens de « non-communautaire » ou « propre à AMD », et le temps a parlé : pour AMDVLK aussi, c’est fini. AMDVLK ne fait plus partie de la Suite Radeon Software for Linux.
L’appellation historique AMDGPU-Pro de la suite Radeon Software for Linux tient toujours même quand il n’y a plus de code propriétaire car le suffixe « Pro » signifie « professionnel ». Tous les pilotes distribués dans la suite Radeon Software for Linux font l’objet d’un support professionnel, et cela inclus désormais RADV qui remplace AMDVLK et sa variante AMDVLK-PRO.
![]()
Le choc des simplifications… On peut se demander si après Vulkan, la prochaine technologie à passer intégralement chez Mesa serait OpenCL ⁉
AMDVLK (AMD VuLKan) était le pilote Vulkan maison de AMD. Historiquement AMDVLK était un pilote Vulkan propriétaire qu’AMD promettait de libérer (et qu’ils ont libéré). Ce fut le tout premier pilote Vulkan pour cartes AMD sous Linux, et donc un composant incontournable de l’écosystème vidéoludique sous Linux.
AMDVLK avait été libéré, mais AMD maintenait en parallèle la version propriétaire que l’on peut appeler par convenance AMDVLK-Pro, et qui était généralement en avance sur AMDVLK concernant les fonctionnalités implémentées, et possiblement la prise en charge du matériel dans certains cas.
La mort d’AMDVLK-Pro était certaine, le futur d’AMDVLK était lui, incertain.
Valve avait de son côté investi dans le développement d’un autre pilote Vulkan pour carte graphiques AMD : RADV. RADV est développé communautairement au sein de Mesa, mais initialement financé par Valve. Mesa étant très bien intégré dans les distributions Linux (de multiples composants Mesa sont déjà requis de toute façon !), RADV est le pilote distribué par défaut sous Linux. AMDVLK avait conservé son avance sur RADV pendant un temps, mais ça fait déjà un moment que RADV n’a plus à rougir de la comparaison. RADV étant mieux intégré qu’AMDVLK et de bonne qualité, AMDVLK devenait moins pertinent.
Mais surtout, RADV devenait meilleur qu’AMDVLK. Par exemple un compilateur de shader nommé ACO a été développé pour RADV, et il est désormais utilisé dans d’autres pilotes AMD chez Mesa comme le pilote OpenGL RadeonSI. ACO (pour Amd COmpiler) est beaucoup beaucoup plus rapide que le compilateur LLVM utilisé par AMDVLK. ACO a été écrit pour faire mieux que LLVM, c’est son but premier.
Cerise sur le gâteau, faisant partie de Mesa, ACO rend plus facile de compiler les composants AMD de Mesa sans avoir à se soucier des compatibilité de versions avec LLVM. Mais le but premier d’ACO, c’est d’être plus performant et plus efficace que LLVM pour le cas particulier des cartes graphiques.
À l’origine tous les pilotes pour cartes graphiques AMD utilisaient LLVM comme compilateur de shaders : les pilotes Vulkan RADV et AMDVLK, le pilote OpenGL RadeonSI, le pilote OpenCL RustiCL et le pilote ROCm pour nommer des pilotes libres, mais aussi les pilotes AMD propriétaires OpenGL OGLP et OpenCL basés sur Orca ou PAL. LLVM était le compilateur de shader utilisé par tous ces pilotes.
Attention, il ne s’agit pas ici du compilateur utilisé pour compiler ces pilotes pour qu’ils tournent sur votre machine, par exemple pour compiler RADV pour un processeur amd64. Non il s’agit ici du compilateur utilisé par le pilote lui-même pour compiler le code natif qui va s’exécuter sur la carte graphique, ce qu’on appelle un « shader » dans le domaine graphique, ou un « kernel » dans le domaine du calcul. Ce sont des programmes qui s’exécutent dans la carte graphique, et LLVM était le compilateur utilisé pour l’architecture amdgcn.
ACO est venu bouleverser tout cela, et ACO est carrément plus rapide que LLVM. ACO est non seulement plus rapide à compiler des shaders (temps de chargement plus court), mais le code compilé s’exécute plus vite (meilleures performances d’éxécution). Il est probablement inutile pour AMD d’investir dans le portage d’AMDVLK sur ACO, alors qu’il suffit de se focaliser sur RADV.
Bien que l’annonce d’AMD fut ambiguë concernant le devenir d’AMDVLK (celui-ci n’était pas mentionné du tout), dans les faits ça faisait longtemps qu’on n’avait pas vu une nouvelle version d’AMDVLK. Le temps passant, cela laissait deviner que celui-ci aussi voyait sa fin très proche, et qu’il était peut-être déjà mort.
Sur le dépôt amdvlk pour Ubuntu hébergé par AMD sur repo.radeon.com, les plus récents paquets sont datés d’avril 2025 avec la version 2025.Q2.1.
Sur le dépôt amdgpu pour Ubuntu hébergé par AMD sur repo.radeon.com, les plus récents paquets sont distribués pour la version 6.4.3 de la suite AMDGPU-Pro en août 2025, aucune version plus récente de la suite AMDGPU-Pro ne fournit de pilote AMDVLK.
La dernière version publiée sur GitHub est la version 2025.Q2.1 datée du 30 avril 2025 (ça fait déjà plus de six mois).
L’avant dernier commit sur le dépôt datait de mars et donc contribuait à la version 2025.Q2.1. Le dernier commit est daté du 15 septembre 2025 et ajoute à la documentation un lien redirigeant vers l’annonce de l’abandon d’AMDVLK.
AMDVLK est finito. Publiée le 15 septembre 2025 sur la forge GitHub d’AMDVLK, l’annonce intitulée « AMDVLK open-source project is discontinued » est on ne peut plus explicite : « Le projet open source AMDVLK a été abandonné ».
L’annonce peut se traduire ainsi :
Afin de rationaliser le développement et de renforcer notre engagement envers la communauté open-source, AMD unifie sa stratégie en matière de pilotes Linux Vulkan et a décidé de mettre un terme au projet open source AMDVLK, afin d'apporter tout son soutien au pilote RADV en tant que pilote Vulkan open-source officiellement pris en charge pour les cartes graphiques Radeon.
Cette consolidation nous permet de concentrer nos ressources sur une unique base de code hautement performante qui bénéficie du travail incroyable de l'ensemble de la communauté open-source. Nous invitons les développeurs et les utilisateurs à utiliser le pilote RADV et à contribuer à son avenir.
Ça faisait un moment que certains constataient le fait qu’AMD ne publiait plus de nouvelles versions d’AMDVLK et donc, on commençait à s’en douter, mais cela n’avait pas encore été annoncé officiellement.
Les notes de version de Radeon Software for Linux 25.20.3 annoncent la prise en charge effective de RADV. L’annonce discutée dans la précédente dépêche à l’occasion de la version 25.10.1 n’était encore qu’une annonce pour le futur, maintenant c’est fait.
Étonnamment cette nouvelle annonce ne mentionne pas AMDVLK, mais cette version ne fournit plus AMDVLK, et ça faisait un moment qu’on pouvait voir la chose venir.
Un point intéressant à noter dans cette nouvelle annonce, est que pour contourner un bug ils recommandent d’installer la version 32-bit du pilote Vulkan fourni par leur suite Radeon Software for Linux, et ce pilote est… le pilote Mesa, comme l’indique le nom explicite mesa-amdgpu-vulkan-drivers:i386. Et le pilote Mesa, c’est RADV. Cette formulation peut paraître cryptique pour le néophyte, mais sans ambiguïté quand on sait décoder les termes : le pilote Vulkan est celui de Mesa.
Ainsi donc, sans mentionner explicitement le retrait d’AMDVLK, AMD mentionne que leur pilote Vulkan est désormais RADV.
Comme de nombreux pilotes AMD historiques pour Linux, AMDVLK était basé sur un unique pilote utilisable sur d’autres systèmes d’exploitation, comme Windows. Et en effet, AMDVLK utilisait PAL (Platform Abstraction Library), qui comme son nom l’indique est une bibliothèque d’abstraction de plateforme.
C’est PAL qui permettait à AMD de porter ses pilotes OpenCL, OpenGL et Vulkan sous Windows et Linux. Leur proposition OpenCL fait désormais partie de la suite ROCm et utilise donc le backend ROCr au lieu de PAL. Leur proposition OpenGL et Vulkan ne sont plus ni OGLP ni AMDVLK et leurs remplaçants RadeonSI et RADV n’utilisent pas PAL.
Ainsi AMDVLK était le dernier consommateur de PAL. C’est donc sans surprise que le 15 septembre 2025, le même jour que l’annonce de l’abandon d’AMDVLK, le dépôt PAL a été archivé, ce qui — dans le jargon de GitHub — signifie qu’il est placé en lecture seule pour consultation uniquement. PAL n’est plus développé. PAL aussi est finito.
Goodbye old pal! Salut mon pote !
RADV est le pilote Vulkan pour les cartes AMD sous Linux. Vulkan est une interface de programmation graphique pour effectuer le rendu 3D très efficacement, utilisé désormais à la place d’OpenGL dans de très nombreux logiciels, en particulier les jeux, mais pas seulement. Par exemple le composant GSK de la bibliothèque GTK utilisée par de nombreux logiciels y compris l’environnement de bureau GNOME peut déjà utiliser Vulkan pour le rendu. La bibliothèque Qt peut aussi faire le rendu d’interfaces QML avec Vulkan.
Vulkan prend aussi en charge les « compute shaders » qui permettent d’exploiter une carte graphique pour d’autres calculs que du rendu graphique. En général les éditeurs de logiciels préfèrent utiliser des API comme CUDA pour Nvidia, HIP (ROcm) pour AMD, OneAPI pour Intel, ou MUSA pour Moore Threads, car ces API viennent avec beaucoup de bibliothèques (ce sont des écosystèmes complets), une intégration très poussée, et sont très performantes. Mais si Vulkan Compute a un écosystème moins riche, Vulkan Compute profite du fait que Vulkan est bien plus universel. La spécification OpenCL est aussi pensée pour être universelle, mais en pratique, il est plus courant de trouver une implémentation Vulkan disponible sur une machine.
Par exemple dans le domaine de l’IA, le LLM (large langage model) d’inférence llama.cpp peut utiliser Vulkan en utilisant le cadriciel Kompute, ce qui rend ce logiciel massivement portable ! Si votre carte graphique est une carte AMD, alors vous pourrez utiliser llama.cpp avec RADV !
De même, le logiciel de transcription vocale whisper.cpp peut utiliser Vulkan et donc RADV. Ceux qui ont visité en décembre dernier le salon Open Source Expérience ont pu voir au stand Videolan une démonstration de la future version 4.0 de VLC qui intégrera whisper.cpp pour tricoter automatiquement des sous-titre pour vos films et séries préférés. Ça veut dire qu’avec le pilote Vulkan RADV et la généralisation du pilote noyau amdgpu (voir ci-après), cette fonctionnalité de VLC pourrait tourner sur toutes les cartes AMD depuis la première génération GCN (il y a 14 ans), à condition cependant que la mémoire vidéo soit suffisante…
![]()
VLC + whisper.cpp + RADV + amdgpu = sous-titres automatiques. Ici une AMD R9 280X (HD 7970 rafraîchie) avec architecture GCN1 Tahiti (j’ai vérifié que whisper.cpp fonctionne dessus avec RADV).
Ce que l’abandon d’AMDVLK signifie aussi, c’est qu’AMD est désormais fortement impliqué dans la maintenance et le développement de RADV. Quand AMD avait annoncé qu’ils prendraient en charge officiellement RADV, cela garantissait qu’ils allaient participer au développement et à la maintenance de celui-ci, mais il était toujours possible qu’une partie des ressources soit affectée à AMDVLK.
Aujourd’hui c’est sûr : plus aucun développeur de chez AMD ne travaille sur AMDVLK pour Linux, toutes les ressources Vulkan pour Linux chez AMD sont entièrement affectées au développement et à la maintenance de RADV.
Comme expliqué dans la précédente dépêche sur le sujet, RADV est fourni par défaut dans toutes les distributions de bureau Linux. Le fait qu’AMD soutienne officiellement le développement de ce pilote est une garantie pour les utilisateurs que ce pilote soit au niveau de leurs attentes, et le fait qu’AMD affecte toutes ses ressources Vulkan pour Linux sur ce pilote augmente encore cette garantie.
Nous pouvons donc refaire le tableau récapitulatif de compatibilité des pilotes AMD pour Linux, en retirant simplement la ligne AMDVLK :
| GCN1 | GCN2 | GCN3 | GCN4 | GCN5 | RDNA1 | RDNA2 | RDNA3 | RDNA4 | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Noyau | Linux amdgpu | 🐧️ | ⭐️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ |
| Vulkan | Mesa RADV | 🐧️ | ⭐️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ |
| OpenGL | Mesa RadeonSI | 🐧️ | ⭐️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ |
| VA-API | Mesa RadeonSI | 🐧️ | ⭐️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ |
| OpenCL | Mesa RustiCL | 🐧️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | |
| OpenCL | AMD ROCm | ⭐️ | ❌️ | ❌️ | ❌️ | ❌️ | ❌️ | ❌️ | 🧐️ | 🧐️ | 🧐️ | |
| HIP | AMD ROCm | ⭐️ | ❌️ | ❌️ | ❌️ | ❌️ | ❌️ | ❌️ | 🧐️ | 🧐️ | 🧐️ |
✅️ = Pilote fonctionnel.
🧐️ = Pilote fonctionnel pour une sélection de modèles.
❌️ = Pilote non-fonctionnel.
🐧️ = Pilote empaqueté en standard dans les distributions Linux usuelles.
⭐️ = Pilote faisant partie de la suite officielle Radeon Software for Linux.
L’acquisition d’ATI par AMD en 2006 faisait partie de la stratégie « Fusion » d’AMD : acquérir et intégrer les compétences graphiques d’ATI pour pouvoir fusionner les puces graphiques et les processeurs AMD et diriger le développement conjoint de ces composants pour pouvoir le vendre comme un produit unique et fortement intégré. Cette stratégie a été très payante dans le domaine des consoles de jeu vidéo : AMD domine le marché des consoles.
Ce qui se passe c’est que depuis 2013, les fabricants de console achètent le processeur qui est intégré avec la carte graphique :
![]()
AMD domine le marché des consoles de jeu vidéo.
À cela s’ajoute un changement de paradigme : la majorité des modèles de console qui sortent sont désormais des PC tournant sous Linux ou sous Windows. Nous parlons bien ici de modèles, pas de nombre de ventes par modèle. Microsoft et Sony font des ventes confortables de Xbox Series X/S ou de PlayStation 5 et Nintendo inonde le marché de ses Switchs. Ces consoles utilisent des systèmes spécifiques et privateurs (Microsoft utilise une variante de Windows, Nintendo et Sony se basent sur FreeBSD), mais dès que vous sortez de ces modèles, tous les modèles que vous trouverez tournent sous GNU/Linux ou Windows.
La tendance a commencé en 2020, d’abord avec la Chuwi AerobBox, une console chinoise tournant sous Windows et qui serait secrètement un dérivé de la Xbox One, suivie franchement de l’Atari VCS 400/800 en 2020 (sous Linux), suivie par la Steam Deck de Valve en 2022 (également sous Linux). La Steam Deck a atteint un succès suffisamment critique pour déclencher une explosion de nouvelles consoles produites par une multitude de fabricants : Asus ROG Ally, Lenovo Legion Go, Acer Nitro Blaze… Toutes ces machines sont compatibles PC et qu’elles soient installées par défaut avec Linux ou Windows selon le modèle, vous pourrez installer Linux sur celles-ci. Excepté la MSI Claw 7/8 qui a tenté l’expérience Intel (c’est très courageux après 24 ans d’absence d’Intel dans ce marché), toutes ces machines sont propulsées par un APU AMD, une puce intégrée mêlant CPU et GPU AMD. Si l’Atari VCS est une console de salon, toutes ces autres consoles sont des machines portables dans la lignée de la Switch.
L’année 2026 verra l’arrivée de la Steam Machine (la vraie, pas la tentative échouée de 2015), l’offre de Valve pour concurrencer le marché des consoles de salon à côté des Xbox Series et PlayStation 5. Cette concurrence se fait désormais sur le positionnement : le salon. Comparées à ces autres machines, la Steam Machine fera partie d’une nouvelle génération de consoles.
Les Xbox Series et PlayStation 5 faisaient partie de la génération « Zen 2 en CPU et RDNA 2 en GPU » qui était la reine des années 2020. Mais en 2026 la Steam Machine fera partie de la génération suivante fondée sur les architectures Zen 4 en CPU et RDNA 3 en GPU : en plus d’apporter des améliorations naturelles à ces composants, c’est la génération qui introduit AVX512 dans les consoles.
L’offre de Microsoft pour cette nouvelle génération est l’Asus ROG Xbox Ally X sortie ce 16 octobre 2025. L’Asus ROG Xbox Ally X tourne sous Windows, est compatible PC et vous pouvez l’utiliser sous Linux. Si vous achetez la plus récente console de marque Xbox — la première Xbox pour cette nouvelle génération de consoles — vous pouvez installer Linux et dans ce cas, RADV sera votre pilote graphique. Vous pouvez dès aujourd’hui utiliser RADV sur une console Xbox officielle, il vous suffit de démarrer la ROG Xbox Ally X sur une clé USB Linux… Trop simple ! À ce niveau de simplicité l’accroche dans le chapô relève presque du putaclic (assumé 😄️).
![]()
AMD utilise AMDVLK sous Windows, pourrait-il être remplacé par RADV là aussi ?
Comme écrit plus tôt le pilote AMDVLK était partagé avec d’autres systèmes d’exploitation, comme Windows.
La solution AMDVLK était pertinente pour AMD car ils pouvaient ainsi mutualiser leurs efforts. Mais se pose alors la question : s’ils souhaitent continuer à mutualiser leurs efforts, pourraient-t-ils remplacer leur pilote Windows par RADV et profiter en-même temps de toutes les améliorations apportées par la communauté ?
Techniquement, c’est possible, et ça a déjà été tenté. Pas par AMD mais par un développeur de chez Collabora. En juillet 2024 Faith Ekstrand a proposé un merge request à Mesa pour porter le pilote RADV sous Windows. En octobre 2024 lors de l’XDC (X.Org Developer's Conference), Faith Ekstrand avait présenté l’avancement de son travail lors de sa conférence « A little Windows with your Mesa » [pdf] et a fait une démonstration technique en montrant une démo Vulkan tourner sous Windows 11 avec RADV.
En l’occurrence il s’agit de faire fonctionner RADV sur WDDM (Windows Driver Display Model) au lieu du DRM (Direct Rendering Manager) de Linux.
Il s’agit pour le moment d’une démonstration, le code n’a pas été fusionné dans Mesa, et le fil de discussion de cette merge request n’a pas bougé depuis 2024.
Mais cela prouve que oui c’est tout à fait faisable, et que si AMD le souhaite, ils savent même à qui demander pour que cela devienne une réalité, il leur suffit de contracter avec Collabora à cette intention.
Les cartes graphiques AMD modernes, c’est-à-dire à partir de l’architecture GCN (RDNA est une évolution de GCN), peuvent toutes utiliser le pilote noyau amdgpu. Les cartes les plus récentes requièrent amdgpu, mais les cartes les plus anciennes peuvent utiliser soit l’ancien pilote radeon, soit le pilote amdgpu plus moderne. Jusqu’à très récemment sous Linux les cartes de génération GCN1 et GCN2 utilisaient encore le pilote radeon par défaut.
Le pilote amdgpu est requis pour faire autre chose que de l’OpenGL. Si vous utilisez le pilote radeon, RADV ne fonctionne pas (pas de Vulkan pour vous !). RustiCL ne fonctionne pas (pas d’OpenCL pour vous), et OpenGL ne propose pas une implémentation aussi complète. Par exemple vous pourriez n’avoir qu’OpenGL 4.1 au lieu d’OpenGL 4.5.
Utiliser le pilote amdgpu et donc débloquer toutes ces fonctionnalités de Mesa est une simple option de démarrage, mais puisque cette option n’est pas activée par défaut, la plupart des utilisateurs de ces cartes n’utilisent donc pas Vulkan.
Un gros travail a été fait pour s’assurer que le pilote amdgpu soit au même niveau que le pilote radeon pour ces anciennes carte, et à partir de la version 6.19 du noyau Linux, toutes les cartes GCN sans exceptions utilisent le pilote amdgpu. Cela signifie que tout le monde ayant une carte graphique AMD de génération GCN ou suivante aura accès à RADV et donc à Vulkan sans rien configurer !
Dans tous les cas, utiliser amdgpu était nécessaire pour utiliser Vulkan avec ces cartes, AMDVLK aussi ne fonctionnait qu’avec amdgpu.
Ça fait longtemps que les utilisateurs de ces cartes utilisent RADV avec amdgpu, car AMDVLK avait abandonné ces cartes depuis longtemps. Par exemple la prise en charge des cartes GCN 1 à 3 avait été abandonnée par AMDVLK après la version 2021.Q2.5, et donc en 2021. La prise en charge des cartes GCN 4 et 5 avait été quand à elle abandonnée après la version 2023.Q3.3, et donc en 2023.
RADV était déjà la meilleure solution pour les utilisateurs de ces cartes, car c’était le pilote Vulkan le plus à jour. Mais jusqu’à maintenant les utilisateurs de carte GCN 1 et 2 devaient modifier leur configuration d’amorçage pour profiter de RADV et donc de Vulkan !
Cette situation est désormais terminée ! Timur Kristóf de chez Valve a travaillé dur pour compléter et fiabiliser la prise en charge GCN 1 et 2 dans le pilote amdgpu. Il a présenté ce travail en novembre lors de la XDC 2025 pendant sa conférence « A love song for gamers with old GPUs » [pdf, blog]. Une « pull request » été ensuite été proposée par le mainteneur Alex Deucher pour faire d’amdgpu le pilote par défaut à partir du noyau Linux 6.19.
Timur Kristóf ne s’arrête pas en si bon chemin, et pour ceux qui lisent l’anglais, Phoronix rapporte la progression incroyable qu’il apporte à amdgpu :
AMD abandonne peut-être son pilote (AMDVLK)… mais c’est parce que le pilote AMD (RADV) est vraiment très bon. 😉️
Et tout ceci a été rendu possible par l‘initiative amdgpu qu’AMD a initié en 2014, il y a 12 ans ! Grâce à ce pilote noyau taillé comme la brique fondamental de tout ce qui peut être fait avec une carte AMD, toutes sortes de pilotes divers et variés ont pu être écrits, comme RADV et d’autres. 🙂️
Commentaires : voir le flux Atom ouvrir dans le navigateur
Read more of this story at Slashdot.
Read more of this story at Slashdot.
![]()
La version 2.0 d’AsteroidOS débarque huit ans après le lancement de la version 1.0 et dix ans après le début de son développement. Ce système vise à remplacer celui installé par défaut sur des montres lancées par différentes marques.
![]()
Dans la liste des montres compatibles avec AsteroidOS 2.0, on retrouve des solutions Asus, TicWatch, Oppo, Huawei, LG, Fossil, Moto mais aussi Samsung, Sony et Casio de manière plus expérimentale.
Le système reprend les fonctions les plus classiques de ces différentes montres dans pas moins de 49 langues. Il supporte évidemment les spécificités de chaque montre suivant leur déploiement. Boutons, écrans tactiles capacitifs, pilotage de l’écran pour adapter sa luminosité, contrôle des alarmes et des vibrations. Mais la version 2.0 apporte également son lot de nouvelles fonctionnalités utiles.
![]()
Affichage permanent de l’heure, détection des mouvements de poignet pour réveiller la montre, mise en veille avec la paume de la main, lecture du rythme cardiaque, contrôle de la musique, Bluetooth, boussole, mode nuit, podomètre et fonction « lampe de poche » avec l’écran. On retrouve évidemment les basiques avec des fonctions d’alarme, de chronomètre, de météo ou de calculatrice. Les notifications et le dialogue avec votre smartphone seront possibles. Certaines de ces fonctions semblent évidentes mais manquaient cruellement à AsteroidOS 1.0.
Evidemment, il faut prendre en compte l’étendue du travail demandé pour porter ces éléments sur un panel si différent de montres. Chaque constructeur a sa propre recette matérielle. Tant sur le plan des composants embarqués que sur la manière dont ils communiquent avec le système. AsteroidOS cherche à faire correspondre un tableau de bord logiciel unique sur différentes solutions. Ce qui ne doit pas être une mince affaire mais plutôt un travail exploratoire de fourmi qui demande aux développeurs d’avoir accès à chaque modèle de montre.
Le reste doit être du gâteau en comparaison et quand AsteroidOS propose un nouveau menu de gestion interne baptisé QuickPanel pour piloter des raccourcis et adapter l’interface à son goût, cela doit sonner comme une récréation bien méritée.
![]()
C’est la bonne question. Qui voudrait changer le système de sa montre connectée ? On se demande bien à quoi cela pourrait servir ? La réponse à cette question est assez simple en réalité. Il suffit d’avoir porté une montre de ce type depuis un moment pour y répondre. Il se trouve que le secteur des montres de ce type est souvent concerné par le fléau de l’enshitification. Plus le temps passe et plus votre produit devient lent et désagréable. Au fil des mises à jour, la montre qui était super fluide à ses débuts se transforme en un outil peu pratique, voire désagréable.
Certes, ce système propose une nouvelle fonction commune avec les nouveaux modèles sortis deux ou trois ans plus tard, mais au prix d’une autonomie divisée par deux ou d’un défilement façon diapositive. J’ai ainsi porté une montre de marque qui a rajouté une fonction parfaitement inutile en transformant radicalement le confort globalement proposé. Il a été possible de revenir en arrière, de réinstaller l’ancien système au prix de quelques manipulations hasardeuses. En revanche, cela n’a plus empêché la montre de me proposer chaque matin au réveil de télécharger une mise à jour dont je ne voulais pas. Ici, le système propose même une option d’installation « temporaire » pour vérifier que votre montre va bien supporter une nouvelle fonctionnalité.
![]()
Une autre raison pour avoir envie de basculer vers un outil comme AsteroidOS ? Se détacher d’un possible mouchard technique qui sait où vous allez, vos horaires et peut même relever des éléments concernant votre santé. Avec un système Linux que l’on peut contrôler, dont on peut adapter les outils et l’interface. On est à même de retrouver les éléments de son choix et même de les afficher comme bon nous semble. Il suffit de regarder la vidéo de présentation ci-dessus pour comprendre à quel point l’interface proposée est plus malléable que celle des fabricants.
![]()
Pour chaque montre compatible, un énorme travail de prise en main est réalisé. Bien mieux fait que beaucoup de solutions commerciales d’ailleurs. Cela commence par un listing des éléments supportés par chaque montre comme ci-dessus. Le site vous demande ensuite de choisir quelle version du système vous souhaitez, sur quel système tourne actuellement votre montre et depuis quel système vous l’installez.
![]()
Le téléchargement adapté est proposé puis le détail de la méthode d’installation pas à pas. L’idée est de rendre l’opération très facile et sans mauvaises surprises techniques. Vous savez dès le début ce qui risque de marcher ou non.
Le point négatif actuel de ce système est son absence de store, vous ne trouverez pas l’équivalent de ce que propose un WearOS par exemple. Pas de jeux, pas d’applications, aucun loisir de se balader dans un choix de centaines de cadrans. L’équipe en charge du projet y réfléchit mais ce n’est pas pour maintenant.
AsteroidOS 2.0 : une dose de libre pour montres connectées © MiniMachines.net. 2026