Vue normale

Reçu avant avant-hier

Le jeu vidéo destiné à devenir de moins en moins libre et performant ?

Pour qui s’intéresse au jeu vidéo, il y a quelques menus détails qui ont changé ces dernières années.

On ne va pas parler du prix des composants — GPU et RAM notamment — qui a littéralement flambé avec l’avènement de l’IA, devenant une véritable valeur refuge au même titre que l’or ou le palladium ; non, on va s’intéresser à la partie technique des jeux (ou du moins de leurs moteurs de rendu).

Sommaire

Raytracing / Path tracing

Il doit être difficile en 2026 de ne pas avoir entendu les termes Raytracing et Path tracing. Mais concrètement, qu’est-ce que c’est et en quoi cela affecte les jeux vidéos ?

Pour en parler, il faut déjà revenir aux fondamentaux, c’est-à-dire la Rastérisation.
En modélisation 3D on a besoin d’afficher en deux dimensions (nos écrans) des objets en 3 dimensions. Étant loin d’être un expert de ces sujets, je dirais au doigt mouillé que ça doit remonter aux premiers rendus 3D.

Dans le contexte de la rastérisation, les objets à l’écran sont créés à partir d’un maillage virtuel de triangle ou de polygones (un mesh). Les coins de nos triangles sont appelés des vertices, et contiennent un paquet d’informations, comme leur position dans l’espace, ou bien leur couleur ou encore des données dite de « normale » qui permettent de déterminer la façon dont les faces d’un objet se présentent.

L’ordinateur convertit ensuite les triangles et les données des vertex en pixels affichés en 2D.

C’est la base de la rastérisation, on peut ensuite chaîner d’autres modifications sur nos pixels (des shaders : des programmes spécialisés qui fonctionnent en parallèles sur un GPU) pour modifier le rendu. C’est à cette étape que l’on fera de la magie noire pour simuler des effets de lumière, de réfraction, de réflexion, d’occlusion et j’en passe.

Pour les ombres il y a différentes techniques, la plus commune est la carte d’ombrage, qui permet de pré-calculer ou de calculer en temps réel ce qui est dans l’ombre (et doit donc être assombri) et ce qui ne l’est pas. Mais ces ombres sont dites « dures », pour des ombres diffuses (dites « soft ») il faut procéder un peu autrement.

On s’en sort en pratique fort bien, et d’autres techniques viennent compléter le tableau comme :

  • les lightmaps,
  • l’occlusion ambiante (SSAO, GTAO, etc.),
  • les sondes de réflexions,
  • les réflexions planaires qui — bien que gourmandes — donnent des réflexions claires comme le cristal en rendant la scène deux fois,
  • le SSR qui tente de reconstruire des réflexions à partir des informations déjà affichées,
  • les systèmes d’illuminations globales (SDFGI, Lumen)
  • les systèmes d’antialiasing
  • et une véritable myriade de joyeusetés toutes plus complexes et délicates les unes que les autres.

OpenMW avec les données de Morrowind
Source : OpenMW

Avec pour chaque technique des limites et inconvénients avec lesquels le développeur devra composer pour atteindre son objectif.

Ces liens donnent des informations pertinentes et compréhensible sur ces sujets :

Aussi, ce journal de small_duck est particulièrement intéressant et facile à lire, en plus de présenter l’évolution des techniques de rendue antérieures à la rastérisation.

Et ce sera fait pour chaque pixel de l’écran. Pour un rendu en 4K on a 8 millions de pixels, et on cible de 30 à 90 images par seconde en moyenne. Mais les GPU modernes sont très forts à ce jeu-là.

Bon très bien, et le raytracing me direz-vous ? Attention à ne pas confondre avec le Raycasting, dont nous parlait jtremesay dans son journal en 2022.

On l’a vu avec la rastérisation, on procède de la manière qui nous a parue la plus efficace avec les moyens donnés. Mais si on visait des rendus plus réalistes, et par réaliste j’entends physiquement réaliste, il y a d’autres approches.

Dans le domaine de l’illumination globale citée plus haut, le raytracing (« lancer de rayon »), permet de remplacer quantité d’effets simulés par les autres techniques et ce avec une qualité et une fidélité supérieure. Le ray tracing est conçu dans les années 60 par Robert Goldstein, Roger Nagel de MAGi et Arthur Appel d’IBM.

Turner Whitted introduit le raytracing récursif dans un papier en 1980. Il décrit comment l’information de rendu est stockée dans un arbre, se propageant vers les surfaces puis vers les sources lumineuses, permettant de simuler fidèlement réflexions, ombres et réfractions.

Cette technique de rendu procède différemment de la rastérisation. Il faut imaginer que depuis chaque pixel de l’écran, un rayon va être envoyé dans le monde 3D, et quand ce rayon va toucher une surface, on va récupérer sa couleur. On pourra ensuite en fonction des données de la surface, lancer d’autres rayons, qui iront toucher d’autres surface et ainsi affiner la couleur de notre pixel.

C’est très similaire dans l’idée à l’ancienne théorie de la vision émissive.

Image d’une scène 3D constituée de trois sphères, obtenue par path tracing

Source : Path tracing sur Wikipedia

De ce fait, on calcule par un seul moyen, non seulement les couleurs des surfaces, mais aussi leur émission, leurs réflexions, leur ombrage et ce en tenant compte d’objets en dehors de l’espace visible à l’écran. C’est un moyen extrêmement puissant de rendre un monde en 3D, et ce n’est ainsi pas pour rien qu’il est utilisé pour le rendu des films d’animation par Pixar et Dreamworks dès les années 80 (avec une approche hybride) et plus généralement dans les années 2000.

Car il faut dire, et je pense qu’on peut s’en douter, que le raytracing est horriblement peu performant. Le lancer de rayon à lui seul est un goulot d’étranglement monstrueux.

Mais pourquoi s’arrêter en si bon chemin ? Le Path tracing, introduit par James Kajiya en 1986, plus moderne, est une forme de raytracing. À chaque rebond, au lieu de lancer plusieurs rayons déterministes, on tire une seule direction aléatoire selon une distribution statistique. Cela permet de simuler fidèlement la lumière indirecte, les caustiques, les surfaces translucides, au prix d’un bruit important.

D’apparence moins performante et complexe, cette méthode permet toutefois un résultat plus granulaire, en changeant le nombre de rayons initiaux. Le pathtracing doit accumuler suffisamment d’échantillons aléatoires pour que la moyenne converge vers une image propre. Avec peu d’échantillons, l’image est bruitée. Pour réduire ce bruit il faut soit plus d’échantillons (plus lent), soit un bon débruiteur.

Certaines parties d’une scène comme les miroirs ou les surfaces en verre nécessiteront plus de rayons pour rester cohérentes, se rapprochant de la version raytracing plus classique.

Un rendu en pathtracing sur le blog de nVidia
Source: nVidia

Dans le domaine du jeu vidéo, il a ainsi fallu attendre jusqu’à récemment pour que cette technique devienne viable pour du rendu temps réel. C’est nVidia qui a ouvert le bal en 2018 avec une conférence pour le lancement de leurs cartes RTX. AMD suivra avec les RX6000 et surprenamment, Intel avec les Arc.

Cette démo de THREE.js tourne dans le navigateur et affiche une boite de Cornell avec du Path Tracing.

Ces nouvelles cartes utilisent des unités matérielles dédiées au lancer de rayon, opération autrefois purement logicielle. Mais ça ne suffit pas à atteindre la vitesse suffisante pour une expérience fluide.

Ces cartes embarquent donc également une autre technologie, au moins aussi importante que le raytracing. Le DLSS.

Histoire de se faire une idée rapidement, ce mod de DOOM 2 supporte le raytracing et ça change vraiment, avec un rendu atmosphérique !

Capture du mod Doom 2: RAY TRACED

Source : Le mod Doom 2: RAY TRACED sur moddb par shirokii

DLSS, FSR, XeSS, Reflex, Anti-Lag

nVidia présente donc en février 2019 le Deep Learning Super Sampling (DLSS) ou Super Échantillonnage en Apprentissage Profond. C’est une technologie de redimensionnement visant à produire une image plus grande à partir de la sortie du pipeline graphique.

Le défi étant de fabriquer ou de retrouver des détails à partir de pas grand-chose. Le DLSS utilise un réseau de neurones pour produire un résultat plutôt convaincant, surtout à mesure que les versions du DLSS se sont enchaînées. À tel point que le DLSS affiche parfois un meilleur rendu que le rendu natif.

En effet, si le but premier du DLSS et des autres technologies concurrentes est de réduire la résolution de rendu pour gagner en performance, le traitement du réseau de neurones peut être si bon qu’il parvient à reconstituer des détails plus fins que ce que produit le rendu natif.

Pour cela, il se base sur les images affichées, mais également sur des données fournies par le moteur, comme le vecteur de mouvement de l’image.

Il permet également de produire un rendu qui a virtuellement une résolution supérieure au natif qui est ensuite réduit à la résolution native. À la manière d’un Oversampling, mais sans le surcoût occasionné par le fait de rendre en 2 ou 4 fois plus grand.

Le DLSS est une technologie propriété de nVidia, qui utilise (sauf pour les premières versions) des éléments matériels pour fonctionner, des accélérateurs d’IA dédiés appelés Tensor Cores.
Les cœurs Tensor et autres accélérateurs IA peuvent entre autre utiliser des données de type FP16, INT8, INT4 et INT1, retenez-les bien, ça sera important.

Il n’a pas fallu longtemps avant qu’AMD ne se lance également sur le sujet avec son FidelityFX Super Resolution. Avec une approche différente, leurs cartes Radeon n’embarquant pas d’unités dédiées contrairement aux RTX de nVidia.

La première version du FSR est plus proche d’un shader d’upscalling comme ceux utilisés dans l’émulation retro que de ce que fait le DLSS.
Mais il a le mérite d’exister et de s’exécuter sur pratiquement n’importe quoi. Il a aussi le bon goût d’être libre. Il faudra attendre la version 2 pour voir quelque chose de plus intéressant, toujours agnostique du matériel utilisé et libre, et utilisant cette fois les vecteurs de mouvement également.

Cette fois-ci, si on est pas à la hauteur du DLSS on a quand même un gain de qualité par rapport à une résolution inférieure. Aux prix d’une image plus instable. Le FSR 3 (toujours libre et agnostique) améliorera un peu cette situation, mais sans régler tous les problèmes.

DLSS vs FSR 2 vs Native)

Sources : Notebook Check et Digital Foundry

Mais, car il y a un mais. Mais, donc, ces technologies ont un coût. En effet, même en faisant le rendu à une résolution plus faible que le natif et donc plus rapidement, il n’en reste pas moins que la mise à l’échelle prend du temps. Accélérateurs dédiés ou non. Dans un cas où on essayait de ramener des performances perdues lors de l’activation du Raytracing, on se retrouve à augmenter la latence.

Mais, car il y a de nouveau un mais, à chaque nouveau problème technologique, une solution (technologique elle aussi) existe ! nVidia se fend alors de la technologie Reflex, là ou AMD saupoudre son Anti-Lag et distille son Anti-Lag +. Ces solutions logicielles, propriétaires, fonctionnent uniquement sous Windows et à peu près de la même manière. Apparemment de base, le CPU peut préparer plus d’images que le GPU ne peut en afficher, remplissant alors un tampon ou une liste d’attente de rendu.
Plus il y a d’images dans la liste, plus la latence augmente, l’idée est donc de mieux synchroniser le rendu CPU et GPU, pour minimiser la taille de cette liste et donc la latence.

Suffisant ? Je ne sais pas.

Dans le même temps, Intel, qui se tâtait à se relancer sur le marché des GPU dédiés, se fend d’une première gamme de cartes graphiques, les Arc. Les cartes sont en dessous matériellement et logiciellement par rapport à leurs concurrentes, mais parviennent tout de même à faire tourner la plupart des jeux du moment. Si les pilotes ont des soucis de jeunesse, la prise en charge de Linux est de base très bonne et libre.

De manière générale, ces dernières années, le pilote libre des cartes Intel et AMD sous Linux est très bon et celui de nVidia s’améliore et s’ouvre un peu plus très peu mais reste basé sur un socle qui bien que performant est propriétaire.

Bref, Intel à la sortie de ses premières cartes (depuis un bail) les lance avec la gestion du raytracing et un équivalent aux DLSS et FSR : le XeSS. Il est plus proche du DLSS que du FSR, mais est agnostique du matériel comme le FSR. Il n’utilise d’accélérateur IA que sur les cartes Arc (cœur XMX), sur les autres il bascule sur les instructions DP4a pour exécuter son réseau de neurones. Il est souvent meilleur que le FSR en termes de stabilité, parfois pire. Si un SDK est disponible, il n’expose que des bibliothèques compilées. Le code reste donc fermé.

En parallèle de tout ça, arrive la génération d’image.

Maintenant, en plus d’augmenter la taille d’une « vraie » image générée virtuellement à l’ancienne, on va intercaler 1, 2, voir 3 images interpolées. Générées soit de façon analytique, soit via un réseau de neurones. C’est vendu sous le nom de Frame Generation par nVidia et AMD.

Côté AMD, il faut attendre le FSR 4 pour voir une utilisation d’un réseau de neurones.

Comparatif FSR3 et FSR4
Sources : Notebook Check et Digital Foundry

Le FSR fournit alors de bons résultats, et s’il reste légèrement moins qualitatif que le DLSS 4, il représente un saut appréciable par rapport au FSR 3. AMD ferme cette technologie aux cartes RX9000 en RDNA4, évoquant lui aussi l’usage d’instructions dédiées (FP8). Le code source n’est pas officiellement disponible, mais suite à une erreur de publication, le code d’une version du FSR 4 est publié en août 2025.

C’est plutôt ballot et cocasse pour AMD, car en plus de ne pas être voulu, cette version libérée comporte une implémentation fonctionnant sur INT8 du FSR 4. Or, nul besoin de la dernière génération de carte AMD pour les avoir. Ce qui veut dire, et les joueurs vont vite le démontrer en compilant eux-mêmes leur version, qu’il fonctionne en fait sur les cartes d’anciennes générations. Les cartes RDNA2 par exemple, plus vieilles de deux générations que les RX9000 en RDNA4, l’exécutent sans problème. Les cartes RTX 30 de nVidia également. Et si le gain en performance est inférieur aux cartes plus récentes, il reste présent et la qualité — surtout — augmente.

On peut d’ailleurs se demander si cette version du FSR 4 n’est pas la base technique du PSSR de Sony, développé par AMD à destination de la Playstation 5 qui embarque une architecture proche des cartes RDNA2 (elle est hybride). AMD est de son côté resté très silencieux sur le sujet.

On peut imaginer une décision court-termiste pour tenter de gonfler les ventes de la génération 9000, l’avenir dira si c’est un pari payant ou si les joueurs perçoivent cela comme une grossière insulte.

Il en reste la sensation d’un rendez-vous manqué, où le FSR4 aurait pu devenir de fait la méthode de mise à l’échelle universelle, car libre et indépendante de l’architecture. Mais sans qu’on sache exactement pourquoi, elle restera propriétaire et fermée à une gamme de carte.

Bref, à l’heure actuelle, seul les FSR 1, 2 et 3 sont libres et intégrables dans les moteurs de rendu libres comme Godot. Le DLSS et le XeSS restent utilisables pour qui en a la volonté. Le projet J.E.N.O.V.A qui permet notamment de coder en C++ sans passer par les GDExtenssions, utilise le DLSS par-dessus Godot et implémente le raytracing via le kit RTX de nVidia, mais cette portion est propriétaire pour le moment.

Ah ! Et bien entendu, à l’exception des FSR 1, 2 et 3, toutes ces technologies ne gèrent que DirectX. Sous Linux il faut donc passer par Wine / Proton / DXVK pour les exécuter.

DLSS 5

Annoncé en 2026, le DLSS 5 n’est pas une itération du DLSS au sens classique du terme, ce n’est ni de l’upscaling ni de la génération d’image. Le DLSS 5 prend en entrée la couleur et les vecteurs de mouvement d’une image, et utilise un modèle d’IA pour y injecter un éclairage et des matériaux photoréalistes, de façon déterministe et stable temporellement d’après nVidia.

Le système est a l’état de preuve de concept, nécessitant deux RTX 5090 : l’une pour jouer, l’autre exclusivement pour faire tourner le DLSS 5. L’utilisation d’une seule carte reste l’objectif pour la sortie prévue à l’automne 2026. On bascule d’une amélioration de rendu, à une génération de rendu. Ce changement de paradigme est loin de faire l’unanimité. Si l’image que vous voyez est en grande partie inventée par un réseau de neurones, s’agit-il encore du jeu que les artistes ont conçu ?

Dira-t-on bientôt à un assistant dans Unreal : « Voilà mon niveau de test fait de boîtes simples, transforme-le en cathédrale. » ? Cela mènera-t-il à une uniformisation des graphismes ? À une crise pour les artistes 3D ?

Présentation du DLSS 5 par nVidia
Source : nVidia

Tout est possible. Il est également possible que les joueurs ne veuillent pas de cette technologie. Mais si actuellement les rendus peuvent se trouver dans la vallée dérangeante, il y a fort à parier que ça va rapidement devenir indiscernable d’un rendu classique de très haute qualité. Une fois la boîte ouverte, difficile de la refermer.

Reste le problème de confier la direction artistique à une machine, et le fait que cette technologie est encore une fois propriétaire.

Et ça c’est un problème plus important qu’on ne le penserait, car il concerne en fait plus d’utilisateurs que les libristes convaincus. En effet, si nVidia avec son DLSS 5 altère à ce point le rendu des jeux avec un réseau de neurones, il y a fort à parier qu’AMD et Intel vont suivre.

Mais pas avec le même modèle, pas avec la même technique. Et donc produiront un résultat différent. On peut donc craindre que selon la carte de l’utilisateur, le rendu soit variable.

La méthode enjolive l’image à un tel point qu’on peut également imaginer se passer de toute autre technique d’illumination pour revenir à de la pure rastérisation. Le raytracing étant alors relégué aux oubliettes des méthodes de rendu. Beaucoup de questions et peu de réponse, on verra bien.

Après cette première présentation du DLSS 5 qui a laissé les joueurs assez mitigés, nVidia a tenu à montrer d’autres usages du rendu neural, avec une présentation au GDC 2026 faisant la démonstration du NTC (Neural Texture Compression). Un système de compression de texture basé sur un réseau de neurone.

Implémentation par moteurs

L’intégration des technologies d’upscaling et de rendu avancé dans un moteur est une tâche qui peut être complexe.

Sur les moteurs propriétaires, Unreal Engine 5 intègre nativement le raytracing, le DLSS, le FSR et le XeSS. Epic a les moyens pour maintenir ces intégrations à jour et a un soutien de nVidia, AMD et Intel.

Unity les gère également. Ne les utilisant pas je ne saurais en parler avec pertinence, ça a l’air de très bien fonctionner. Il est intéressant de noter qu'Intel ne publie plus son plugin Xess pour Unity, pendant que le DLSS est implémenté au travers du High Definition Render Pipeline

Pour les moteurs libres comme Godot, la situation est différente.

Le raytracing n’était pas forcément une technologie très pertinente ni très facile à implémenter pour des jeux indépendants il y a quelques années. Il n’y a donc pas eu de vrai volonté de l’implémenter, d’autant que d’autres techniques plus classiques existent et fonctionnent sur toutes les cartes, permettant un rendu très qualitatif.

Mais cette situation qui est restée au point mort pendant quelques années a changé assez rapidement, avec une PR pour « mettre en place la plomberie nécessaire au raytracing ». Elle a été intégrée début 2026 dans la version 4.7, et dans la foulée nVidia a publié un fork de Godot supportant le pathtracing et le DLSS. Cette expérimentation ne prend en charge actuellement que les cartes nVidia, mais se base sur la PR mentionnée plus haut, et devrait à terme permettre un pathtracing agnostique de la carte utilisée.

À voir cependant si elle sera intégrable en l’état, ayant été codée avec l’aide de Claude et de Cursor. Elle permet en tout cas de montrer ce qui est actuellement possible en utilisant les briques bas niveaux de Godot, et permet d’espérer voir le tracé de rayon officiellement utilisable avec le moteur dans un avenir proche. Pour rester indépendant d’un vendeur de carte, il faudra aussi intégrer un débruiteur en remplacement de celui utilisé, spécifique à nVidia. Cette vidéo de Leroy Sikkes de chez nVidia au GDC 2026 présente toute la méthodologie du projet.

Le FSR 3 (le dernier à être resté libre et agnostique) est intégrable, mais actuellement seul le FSR2 est disponible sans compiler une PR. Le DLSS et le XeSS le sont aussi techniquement, via des greffons communautaires ou officiels, mais requièrent une acceptation de licences propriétaires. Ils ne seront certainement jamais intégrés directement dans le moteur, pas sans changement de licence. Le FSR 4 tombe dans la même catégorie pour le moment du fait de l’incertitude sur sa licence, même si l’implémentation publiée par erreur par AMD était utilisable, elle concerne DirectX, et non Vulkan, et ne pourrait être exécutable que sous Windows (ou éventuellement via Wine/Proton/DXVK).

Si on regarde du côté de Bevy, des contributeurs ont proposé des implémentations du DLSS, du FSR et même un début d’implémentation du raytracing avec Solari. Les articles rédigés par l’auteur de Solari sont d’ailleurs fabuleux.

Au-delà de tout ça, dans le but de réduire l’impact sur les performances et de produire un meilleur résultat, les technologies de raytracing se voient souvent complétées par des dé-bruiteurs et une pelletée de technologies propriétaires assistées par IA.

Comparaison raytracing et debruiteur
Source : Dépôt NRD

L’image brute d’un rendu par lancer de rayon est un champ de points colorés aléatoires. Pour en faire une image propre, il faut la débruiter, et c’est là que l’écosystème de technologies se remet à foisonner.

On peut les classer en deux familles : les débruiteurs analytiques (qui utilisent des algorithmes et du filtrage) et les débruiteurs neuraux (qui utilisent des réseaux de neurones entraînés sur des données de rendu). Les premiers ne nécessitent généralement par une carte particulière alors que les seconds ne sont compatibles qu’avec certaines gammes de cartes.

L’écosystème construit par nVidia est le plus propriétaire de tous, mais c’est de loin le plus complet et le plus documenté. C’est le RTX Kit, il propose le NRD — NVIDIA Real-time Denoiser, un débruiteur analytique qui fonctionne par accumulation temporelle de pixels sur plusieurs frames, et interpolation spatiale entre pixels voisins. Le NRD (une fois n’est pas coutume) est disponible en source ouverte, agnostique de l’API (DX12 et Vulkan), et peut donc être intégré dans n’importe quel moteur.

nVidia fournit également le Ray Reconstruction, un débruiteur neural. Il reconnaît les différents types d’effets raytracing pour prendre de meilleures décisions sur l’utilisation des données temporelles et spatiales, et conserve des informations haute fréquence que les débruiteurs classiques ont tendance à lisser.

Enfin le NRC (Neural Radiance Cache) utilise des réseaux de neurones pour estimer la lumière indirecte avec plus de précision. Extrapolant un éclairage indirect avec moins de lancer de rayons.

AMD a longtemps été en retard sur toute cette gamme de techniques de débruitage et d’amélioration, de même qu’avec l’implémentation et les performances en raytracing. La situation s’améliore avec FSR Redstone, qui veut agréger les technologies dévelopées par AMD dans le but de proposer un équivalent au RTX Kit, mais le retard reste mesurable.

Ainsi l’équivalent AMD du Ray Reconstruction de nVidia est le FSR Ray Regeneration. Un débruiteur basé sur un réseau de neurones qui prédit et restaure les détails raytracing. Il ne nécessite pas d’être lié à un framework de rendu spécifique, ce qui est un avantage pratique. La qualité est apparement en dessous de ce que propose nVidia.

Le FSR Radiance Caching est conceptuellement proche du NRC de nVidia, mais AMD est encore en phase de déploiement — la mise en production était prévue pour 2026.

AMD n’a pas de débruiteur analytique grand public équivalent au NRD, ce qui laisse encore un trou dans sa raquette pour les cartes qui ne peuvent pas utiliser le FSR Redstone.

Intel est le moins avancé des trois sur ce front. Son offre se concentre autour de XeSS 2.

XeSS 2 comprend trois technologies : XeSS Super Resolution (la mise à l’échelle AI), XeSS Frame Generation (interpolation de frames), et Xe Low Latency (XeLL), qui s’intègre au moteur de jeu pour réduire la latence d’entrée.

Intel n’a pas de débruiteur neural dédié au raytracing comparable au Ray Reconstruction ou au FSR Ray Regeneration. Pour le débruitage, les jeux utilisant les cartes Arc sont tributaires des débruiteurs intégrés aux moteurs (NRD si le développeur l’a intégré, débruiteurs propriétaires des moteurs comme Lumen, etc.).

Il faut mentionner que depuis des années, Intel et la communauté open source proposent Open Image Denoise (OIDN), un débruiteur libre basé sur des réseaux de neurones, utilisé notamment dans Blender et d’autres applications de rendu offline.

Également des algorithmes comme ReSTIR visent à réutiliser les tracés d’une image précédente pour réduire le temps de rendu.

Impact sur les performances

Pour se faire une bonne idée de l’impact du raytracing, il peut être intéressant de comparer des titres usant de cette technologie et de la rastérisation plus classique.

Cyberpunk 2077 est par exemple une vitrine du raytracing et du pathtracing.

Cette vidéo donne un bon aperçu technique, pour un rendu en 1440p, avec DirectX12 et en qualité utra. Une RTX 4070 Ti passe ainsi de 100 IPS en rastérisation à 80 en raytracing puis à 51 en pathtracing. La RX 7900 XTX d’AMD elle part de 134 IPS, puis 59 en raytracing et 20 en pathtracing. Et les deux carte utilisent DLSS/FSR pour atteindre ces chiffres.

La perte d’IPS est abyssale chez AMD, la faute à une première implémentation du raytracing alors que nVidia en était déjà à sa troisième itération. La situation s’est un peu améliorée avec les générations suivantes.

Techspot propose un comparatif très complet, avec non seulement l’écart de performance entre rastérisation pure et raytracing mais aussi avec les visuels pour constater (ou non) l’apport du raytracing.

Ce qu’on voit immédiatement c’est que dans beaucoup de jeux, la différence visuelle est minime. Les techniques classiques sont en effet terriblement efficaces pour imiter les effets de lumières, d’occlusion ambiante, d’éclairages indirects, etc. Sur d’autres titres (comme Cyberpunk), l’impact est beaucoup plus visible. Il y a donc une différence liée à l’utilisation du raytracing. La plupart des jeux présentés dans le comparatif utilisent le lancer de rayon dans une approche hybride, en complément de la rastérisation.

L’impact sur les performances est réduit, de même que la différence visuelle. Par ailleurs, la direction artistique change également la donne. Si un niveau ne comporte aucune surface réflective, on aura du mal à constater l’apport du raytracing.

De manière générale, si le lancer de rayon est pleinement utilisé, on table sur environ 30-50% de performances en moins. Et c’est déjà fantastique si on se rappelle d’où on vient.

Dans sa publication THE RENDERING EQUATION, Kajiya présente deux images qui font 256 × 256 pixels, générées sur un IBM-4341. La première ayant pris 401 minutes de temps CPU et la seconde 533 minutes.

On arrive aujourd’hui, 40 ans plus tard, à rendre des images en 4K avec une fluidité suffisante pour le temps réel. En outre, il est probable de voir les performances de rendu augmenter dans les prochaines années.

Impact sur le développement

Le raytracing et le pathtracing, c’est génial, mais pour le développeur qui doit sortir un jeu, ça représente un sacré paquet de nouvelles contraintes.

Déjà, le matériel supporté. Si vous développez un jeu avec le pathtracing comme pilier central, vous excluez de fait une bonne partie de votre audience potentielle. Les cartes avec des unités matérielles dédiées au lancer de rayon restent, en 2026, loin d’être universelles. D’après les enquêtes de Valve, la moitié des cartes les plus utilisées ne le gère pas ou pas très bien.

Les joueurs sur des machines plus modestes, ou sur des cartes trop anciennes, ne pourront pas jouer à votre jeu — ou joueront dans des conditions dégradées. Pour un studio qui vise la plus large audience possible, c’est compliqué.

C’est d’ailleurs pourquoi la plupart des jeux qui utilisent le raytracing le font de manière hybride. On conserve la rastérisation comme base, et assaisonnent avec du lancer de rayon sur certains effets précis : les reflets, les ombres, l’occlusion ambiante. Le raytracing est un bonus visuel pour ceux qui ont le matériel pour en profiter, pas une fondation sur laquelle repose tout le rendu. Mais certains jeux comme Indiana Jones et le Cercle Ancien utilisent explicitement et uniquement le lancer de rayon, rendant leur utilisation impossible sans une carte récente au grand dam des joueurs les moins bien lotis.

Pour le développeur, cela signifie qu’il faut souvent maintenir deux méthodes de rendu en parallèle : la rastérisation (et toutes ces techniques raffinées), et le raytracing. Deux approches très différentes, deux séries de bugs potentiels, deux validations distinctes. Conduisant inévitablement à un surcoût appréciable.

Le raytracing a besoin d’accéder à l’intégralité de la géométrie de la scène pour fonctionner, y compris ce qui n’est pas visible à l’écran. Là où la rastérisation peut se permettre d’ignorer allègrement tout ce qui est hors champ (autant que faire se peut). Le lancer de rayon, lui, doit potentiellement rebondir sur n’importe quelle surface. Cela implique de gérer des structures d’accélération (les BVH, Bounding Volume Hierarchies) qui doivent être mises à jour à chaque image pour les objets en mouvement. Un coût supplémentaire, là encore, même si c’est ce qui permet notamment d’afficher des réflexions complètes.

Du côté des artistes 3D, le passage au raytracing change aussi les habitudes de travail. Une part fascinante de ce métier consiste justement à tricher habilement : placer des sources de lumière pour compenser l’absence d’illumination globale, peindre à la main des cartes de lumière, jouer avec des sondes de réflexion, développer des shaders en araméen à la limite de la prestidigitation et du pacte diabolique. Des techniques qui demandent de l’expérience et un certain sens artistique du bricolage et de l’adaptation.

Avec une propagation de la lumière physiquement réaliste, certaines de ces astuces deviennent complètement inutiles — ce qui peut être un soulagement — mais certaines habitudes et flux de travail doivent être abandonnées ou repensées. Une lumière placée à un endroit étonnant pour une raison purement artistique va se comporter différemment dans un moteur qui simule la physique réelle de la lumière.
D’un autre côté, le fait de pouvoir visualiser le comportement réaliste de la lumière et des réflexions dans une scène permet aussi de s’en approcher plus finement avec les techniques classiques.

Le raytracing peut simplifier certains aspects du travail (plus besoin de calculer à l’avance des lightmaps, les réflexions et les ombres se génèrent automatiquement; tout ceci avec un coût en termes de performance. Un coût d’autant plus pesant que le prix des composants s’est envolé à cause de l’intelligence artificielle.

La question du DLSS 5 et plus généralement du rendu neural mentionnée plus haut ajoute une couche de complexité supplémentaire. Si le rendu peut être altéré (voir complètement généré) par un réseau de neurones, la notion même de direction artistique devient discutable.

Les artistes conçoivent une ambiance, une intention visuelle. Disent des choses au travers les images, la musique. Mais si tout passe ensuite dans une boîte noire qui réinterprète différemment ses entrées selon la carte du joueur, qui est vraiment responsable du résultat final ?

Sera-t-il encore satisfaisant pour les créateurs et les joueurs de concevoir des mondes virtuels dans ces conditions ?

C’est une question que l’industrie commence à peine à se poser sérieusement, et elle se pose pour toutes les œuvres artistiques depuis l’avènement de l’IA.

Enfin, si le développement se fait avec un moteur libre comme Godot ou Bevy, la situation est encore un peu particulière. On l’a vu plus haut, l’écosystème du raytracing et ce qui gravite autour est aujourd’hui dominé par des technologies propriétaires. Et les moteurs libres, par définition, ne peuvent pas les intégrer directement sans franchir des lignes qui iraient à l’encontre de leurs principes — et au moins de leur licence.

Concrètement, ça veut dire que le développeur qui choisit Godot aujourd’hui pour faire un jeu avec du raytracing va défricher un territoire sauvage. Les briques de base existent mais rien n’est prêt à être utilisé sans se retrousser les manches sérieusement.

Pour la mise à l’échelle, le FSR 2 est disponible, le FSR 3 intégrable. Les DLSS ou XeSS peuvent être implémentés, mais avec des licences à accepter, ce qui rend improbable toute intégration officielle dans le moteur. Le développeur qui veut tout ça devra donc assembler lui-même sa chaîne, en acceptant de dépendre de solutions tierces dont la maintenance n’est pas garantie par l’équipe de Godot.

Le plugin Solari de Bevy est pour le moment réservé aux cartes nVidia également, ça changera certainement rapidement.

Si on regarde du côté de Wicked Engine par contre on a bien un moteur supportant le raytracing et fonctionnant sur toutes les cartes. Il est un peu plus niche que Godot ou Bevy mais très impressionnant.

Pour revenir à Godot, ce n’est pas forcément un drame. Il dispose de techniques d’illumination globale très capables comme le SDFGI, le VoxelGI, les sondes de reflexion, etc, qui permettent d’atteindre des rendus très convaincants sans lancer un seul rayon. Et pour beaucoup de styles artistiques (jeux stylisés, pixel art, low poly) la différence entre raytracing et rastérisation ne se justifie pas vraiment.

Il y a eu d’autres approches ces dernières années qui ont eu un impact sur les moteurs, les techniques de géométrie virtuelle par exemple. Nanite, disponible dans l’Unreal Engine en est un bon exemple.

Les maillages sont découpés en hiérarchies de clusters de triangles lors de l’import, puis ces clusters sont échangés à la volée selon la vue caméra, sans couture visible. Remplaçant les techniques plus communes de LOD. En pratique, ça veut dire qu’on peut importer directement des scans photogrammétriques de plusieurs millions de polygones, sans passer par les étapes habituelles de re-topologie et d’optimisation. Permettant de ne plus se soucier du budget de polygones et des LODs.

Du moins dans certaines limites. Si cette approche permet d’avoir des transitions inexistantes entre différents niveaux de détails, il n’en reste pas moins que dans beaucoup de cas, une utilisation des LODs et un bon travail d’optimisations des ressources et du maillage permet d’atteindre de meilleures performances. Importer les yeux fermés des object 3D de plusieurs millions de polygones sans même s’en soucier implique forcément des cas sous optimisés. Mais la technologie est là et mature tranquillement.

Introduction To Modern Rendering présente d’une façon digeste et intéressante les technologies du raytracing et des mesh shader.

Du côté des moteurs libres, c’est en chantier. La proposition pour Godot date de 2021, ouverte peu après l’annonce d’Unreal Engine 5, et est toujours ouverte. Rien de concret n’a atterri dans le moteur à ce jour. Bevy est plus avancé sur le sujet : son contributeur JMS55 (encore lui, c’est la personne derrière Solari) travaille activement sur une implémentation, et son article sur la version 0.16 détaille les avancées récentes — notamment l’amélioration de la qualité du DAG (la hiérarchie de clusters). C’est encore une fois très agréable de lire ces articles riches de détails et accessibles.

Bref, pour qui veut être à la pointe de la technique sans passer par du code propriétaire, la route est encore longue. La bonne nouvelle, c’est qu’elle est libre.

De nouveaux venus (Moore Threads, Lisuan Technology)

Le marché des GPU est depuis très longtemps un duopole de fait entre nVidia et AMD, avec Intel en troisième position encore fragile. Bon, OK, nVidia rafle l’essentiel du marché. Mais AMD tire son épingle du jeu (et sous Linux ils jouissent d’une réputation bien plus reluisante que nVidia).

Mais depuis quelques années, avec le contexte géopolitique tendu, la Chine a accéléré le développement de ses propres fabricants de cartes graphiques. Les restrictions américaines à l’exportation de composants avancés vers la Chine, qui concernent notamment les GPU nVidia les plus puissants, n’y sont pas pour rien.

Deux sociétés font parler d’elles : Moore Threads et Lisuan Technology.

Moore Threads est la plus ancienne des deux, fondée en 2020 par Zhang Jianzhong, ancien vice-président de nVidia Chine. Ses cartes actuelles, les MTT S80 et S90, existent depuis quelques années déjà, mais sont restées assez loin derrière la concurrence. Pour la prochaine génération, basée sur l’architecture Huagang, Moore Threads annonce pour sa puce Lushan des gains de 15x en performance dans les jeux AAA, 50x en raytracing, et 16x en traitement géométrique. Des chiffres spectaculaires, mais sans spécifications ni données de benchmarks à l’appui pour l’instant. Et bien sûr, tout dépend d’où on part.

À prendre avec des pincettes donc, mais l’ambition est là et les moyens aussi. La MTT S90 serait au coude à coude avec la RTX 4060.
Ce qui n’est pas une mince affaire pour un fabricant qui n’existait pas il y a 6 ans.

Lisuan Technology est un peu plus récente encore puisque fondée en 2021. Aucune carte n’est encore sortie (même si les envois auraient commencé).

La carte gaming LX 7G106, fabriquée par TSMC en 6nm, est prévue pour le 18 juin 2026 en Chine. En termes de performances synthétiques, elle se situerait dans les parages d’une RTX 4060.

En revanche, la carte ne supporte pas le raytracing.

Ce qui est notable pour nos sujets, c’est que ces deux acteurs, à des stades différents de maturité, arrivent dans un écosystème où les technologies de rendu avancé sont dominées par des standards propriétaires. Pas de DLSS, pas de FSR 4, pas de Ray Reconstruction. Ils devront soit implémenter leurs propres équivalents, soit s’appuyer sur les technologies agnostiques comme le FSR 2/3 ou le NRD d’nVidia.

Leur impact sur le marché mondial restera sans doute limité à court terme, les joueurs ayant de solides alternatives. Mais pour le marché chinois, qui représente une part considérable des joueurs PC mondiaux, ces alternatives domestiques ont une pertinence réelle, et représente des enjeux en termes d’autonomie. Si l’un d’eux parvient à produire une carte compétitive avec des pilotes stables, ce sera un signal fort que le quasi-monopole de nVidia n’est pas éternel.

Espérons que les pilotes seront libres et les technologies développées aussi, ce serait bien.

Et les performances dans tout ça

On a vu défiler beaucoup de technologies dans cet article. Des acronymes abscons, des architectures, des promesses de gains en tous genres. Mais si on prend un peu de recul : est-ce que tout ça rend les jeux plus agréables à jouer ?

Non. Bien sûr. Évidemment.

Attention, je suis aussi sensible que n’importe qui à de beaux graphismes, mais le nerf de la guerre n’est pas là. Surtout quand on voit que le prix des GPU, du stockage, de la RAM et par effet de bords, de tous les éléments d’un PC, ont flambé ces dernières années. Sous l’effet de la demande apparemment infinie de l’industrie de l’IA. Les cartes qui permettent de profiter correctement du raytracing et des technologies qui l’accompagnent se situent dans des gammes de prix de plus en plus élevées.

Leur consommation ne cesse de grimper (une RTX 5090 est une grosse brique tant son radiateur est gros), de même que leur impact écologique. On parle tout de même de composants PC tellement énergivores qu’ils forcent à changer toute l’alimentation de la machine et amènent avec eux une nouvelle norme de connecteur d’alimentation (qui n’a pas forcement très bonne presse).

Et même à des niveaux plus raisonnables, une carte milieu de gamme récente représente un investissement conséquent pour un résultat qui, on l’a vu, n’est pas toujours spectaculairement supérieur à ce qu’on obtenait avant.

L’augmentation des prix est telle que la demande pour des cartes mère en DDR3 poussent certains fabriquant à renouveler leurs stocks.

Ensuite, le Raytracing, les DLSS, FSR, débruiteurs neuraux, la génération d’images, la géométrie virtuelle. Chacune de ces technologies a été conçue pour résoudre un problème (parfois causé par la technologie qui le précède), et chacune en a introduit de nouveaux. Des artefacts visuels, de la latence, des incompatibilités entre fabricants, des exigences matérielles toujours plus élevées, des licences propriétaires. L’empilement de solutions finit par former une pile fragile, le jeu vidéo est un assemblage hétéroclite de techniques barbares et sauvages depuis ses débuts, mais on commence — avec ces nouvelles technologies biberonnées à l’IA — à s’éloigner de la recherche algorithmique pure, de cet esprit MacGyver qui caractérise si bien le développement de jeux vidéos, pour arriver sur une logique de boîte noire.

Ou bien c’est dans la droite ligne de l’héritage des pionniers du jeu vidéo, et ce sentiment n’est en fait qu’une incompréhension face à une révolution trop rapide pour être assimilée correctement.

Face à ça, aller à contre-courant est non seulement possible, mais peut être couronné de succès. Des jeux comme Celeste, Hollow Knight, Vampire Survivor ou plus récemment Balatro, n’ont aucun raytracing, géométrie virtuelle ou débruiteur neural. Ils tournent sur des machines modestes, parfois vieilles de dix ans ou plus, et se jouent avec un plaisir non moins vif.

À l’autre bout du spectre, des productions AAA ultra-techniques ont déçu leurs joueurs malgré — ou parfois à cause de — leur sophistication technique. Comme Pokémon Legends: Z-A qui (au-delà son contenu vidéoludique) souffre d’un manque flagrant d’optimisation, ce qui est un comble quand on parle de la licence Pokemon. Une licence dont les premiers jeux repoussaient les limites de leur support physique.

La technique se remarque essentiellement quand elle est mauvaise. Une conception ancienne mais bien réalisée sera souvent plus agréable qu’une autre plus récente mais à l’implémentation faillible.

De plus en plus de joueurs en ont marre de devoir investir dans des composants toujours plus puissants et réclament des jeux plus optimisés. Mais les grandes compagnies ont apparemment d'autres préoccupations.

La rastérisation bien maîtrisée, avec les techniques classiques évoquées en début d’article, permet encore en 2026 de produire des rendus magnifiques et des expériences fluides sur le parc matériel le plus large. Des moteurs comme Godot, même sans SDFGI ou sondes de réflexion, permettent d’atteindre des résultats visuellement très convaincants sans toucher les limites du matériel.

Je ne doute pas que le raytracing apporte énormément au jeu vidéo, ses qualités sont indéniables. Seulement dans le contexte actuel, je ne cracherais pas sur plus d’optimisation.

Possédant un Steam Deck de Valve, j’aime le fait de pouvoir baisser la consommation du SOC de la console à 3 ou 5 watts.
Ça rend la machine silencieuse, efficiente, et la batterie tient plus longtemps.

Jouer à Batman: Arkham Knight dans ces conditions permet d’atteindre 60 image par secondes quasiment tout le temps. Ce qui est impressionnant, car en plus le jeu est vraiment très beau.
Il a déjà 11 ans, mais reste magnifique. On pourra se rappeler qu’en 2015 il avait souffert de sa mauvaise optimisation.

La grogne des joueurs poussant Rocksteady Studios à mettre la distribution en pause, le temps de résoudre les problèmes techniques avec l’aide d’AMD et nVidia. Problèmes qui auraient évidemment pu être remontés et corrigés en phase de test.

Aujourd’hui on voit des jeux sortir sans la prise en charge de certaines cartes, comme Crimson Desert (qui recevra finalement plus tard la gestion d’Intel), des performances désastreuses à l’image de Borderlands 4 qui semble avoir réussi à transformer ses joueurs en bêta-testeurs, ou bien découpés à la tronçonneuse pour le vendre petits bouts par petits bouts : (Les Sims 4 on parle de toi).

Alors, quand en plus de ces problèmes que les industriels du jeu vidéo nous ont apportés, on ajoute du raytracing uniquement pour surfer sur la vague, ça ne fait qu’enfoncer le clou dans le cercueil de nos machines.

D’un autre point de vue, et en mettant de côté le raytracing, les technologies comme le DLSS et le FSR permettent de prolonger la durée de vie d’un matériel vieillissant. En tout cas, si ce n’est pas utilisé comme un pansement pour palier des performances passables.

Heureusement, des productions comme Resident Evil 4 ou Red Dead Redemption 2 montrent qu’il est encore possible de faire des jeux visuellement magnifiques (et surtout de bons jeux) qui tournent avec trois fois rien. Split Fiction (qui possède un gameplay en perpétuelle évolution), est visuellement superbe et tourne au poil sur une RX580.

Capture d’écran de Split Fiction, qui n’utilise pas le raytracing
Source : The Gamer

On aura sûrement le meilleur des deux mondes un jour ! Enfin j’espère, sinon on pourra toujours se réfugier dans le jeu de rôle papier.

Commentaires : voir le flux Atom ouvrir dans le navigateur

ÉducaLibre 2026 sera ce que nous en ferons ensemble. À bientôt à Bruxelles.

ÉducaLibre 2026 : appel à propositions d'ateliers, conférences et tables rondes

Bruxelles, 4-6 juillet 2026—Université libre de Bruxelles

Un rendez-vous européen qui manquait

Partout en Europe, des enseignants innovent avec des logiciels libres, des développeurs créent des outils pédagogiques ouverts, des makers fabriquent, des chercheurs explorent, des artistes partagent. Ces initiatives foisonnent—mais restent trop souvent isolées, ignorées les unes des autres, condamnées à réinventer sans cesse la même roue.

ÉducaLibre veut changer cela.

Du 4 au 6 juillet 2026, l'Université libre de Bruxelles accueille la première édition de ce rendez-vous européen des communs éducatifs : trois jours pour croiser les regards, partager les expériences, tisser des collaborations durables, et construire ensemble les ressources pédagogiques libres de demain.

L'événement est organisé par l'ASBL EduCode, qui avait déjà porté les éditions EduCode 2018 (1200 participants au BOZAR), 2019 et 2020, et dont certains membres ont contribué à l'organisation des RMLL 2013 à Bruxelles. Le lieu—le bâtiment U de l'ULB, domicile du FOSDEM depuis plus de vingt ans—n'a pas été choisi par hasard.

Ce qu'on y fera

Cinq pistes thématiques en parallèle :

  • politiques publiques et souveraineté numérique
  • pédagogie et pratiques de classe (GeoGebra, Moodle, Python, NumWorks, LaTeX, …)
  • administration et déploiement technique dans les établissements
  • innovation, IA et recherche en éducation
  • économie et entrepreneuriat du libre éducatif

Et une piste transversale : art, musique, création, poésie—parce que l'éducation se nourrit aussi de culture et de sensibilité.

En parallèle : des ateliers pratiques, des hackathons, des démonstrations, des tables rondes, des stands de projets. Le tout sous licences libres, avec captation vidéo publiée en CC-BY-SA.

Public attendu : 500 à 800 participants de toute l'Europe, enseignants du primaire au supérieur, développeurs, décideurs politiques, chercheurs, artistes, entrepreneurs.

L'appel à propositions est ouvert

C'est là que vous entrez en scène.

Vous utilisez un outil libre en classe et vous avez envie de le faire découvrir ? Vous avez mené une migration réussie dans votre établissement ? Vous développez un projet éducatif libre que le monde devrait connaître ? Vous avez des choses à dire sur la souveraineté numérique dans l'éducation, sur les modèles économiques du libre, sur l'IA et ses enjeux pédagogiques ?

Proposez une intervention : https://propositions.educalibre.eu

Formats acceptés :

  • atelier pratique (1h30)
  • conférence ou présentation (45 min)
  • table ronde ou débat (1h15)
  • démonstration de projet ou d'outil (30 min)
  • hackhaton
  • et toute autre forme que vous imaginez

Les langues de l'événement sont le français, le néerlandais, l'anglais et l'allemand—mais toute proposition dans une autre langue européenne sera examinée avec bienveillance.

La date limite pour soumettre une proposition est fixée au 14 avril 2026.

Pourquoi ça compte

L'éducation européenne est à un tournant. Le Schleswig-Holstein migre massivement vers le libre. La France structure ses politiques publiques autour de solutions souveraines. Des expériences remarquables existent au Kerala, en Catalogne, dans de nombreuses communes belges et françaises. Mais ces expériences ne se parlent pas assez.

ÉducaLibre n'est pas une conférence de plus où l'on écoute passivement des experts. C'est un espace horizontal, construit par et pour ses participants. Le programme sera ce que la communauté en fera.

Parmi les intervenants déjà pressentis :
1. Alexis Kauffmann (direction du numérique éducatif, ministère de l'éducation nationale français),
2. Frank Karlicheck (Nextcloud),
3. Tristan Nitot,
4. Pierre Pezzardi (Dinum)
5. Emmanuel Zimmert (ladigitale.dev)
6. des représentants de Framasoft, April, Aful, la FSFE, et des décideurs politiques belges et européens.

Pour aller plus loin

Tous les contenus produits seront publiés sous licence CC-BY-SA 4.0.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Cécité, droits des femmes et biologie

Le mois de mars est celui du retour du printemps mais aussi celui où a lieu la Journée internationale des droits de femmes. Cette année, on va se pencher sur les droits des femmes ayant des déficiences visuelles et en profiter pour dresser le portrait de la chercheuse en bio-informatique Salomé Nashed. On terminera par quelques mots sur les aides à la navigation des personnes aveugles et malvoyantes, qui ne sont pas sans lien avec des problématiques récurrentes sur LinuxFR.org.

Sommaire

Quelques points sur les droits des femmes aveugles

En fait, comme le souligne le Gildas Brégain, auteur d’une histoire du handicap au XXe siècle cette histoire reste encore à écrire, et on en trouve peu de traces sur le web.

En France, la prise en compte des aveugles remonte à la fin du XVIIe siècle quand Valentin Haüy crée la première école pour aveugle, l’actuel Institut National des Jeunes Aveugles (INJA). Jusque-là, les jeunes aveugles ne recevaient pas d’éducation spécifique. L’école de jeunes aveugles sera ouverte aussi bien aux garçons qu’aux filles. Et on commencera à se pencher sur la question de la lecture et de l’écriture. Valentin Haüy inventera une écriture à base de caractères en relief et de points. Cette école accueillera Louis Braille en 1816 qui sera le créateur du système d’écriture qui porte son nom et qui s’est imposé universellement.

Les femmes aveugles vont avoir des droits, sur le plan formel tout au moins, limités par rapport aux hommes. Elles devront vivre dans des foyers dédiés. Gildas Brégain rapporte par exemple que la première femme à avoir demandé à pouvoir vivre hors de l’institution, Marie Aimée Régnier, enseignante à l’INJA aura dû batailler pour obtenir la permission de la quitter. Rappelons que cela se passait au début du XXe siècle. Les hommes aveugles, quant à eux, bénéficient d’aides pour vivre hors des institutions.

Si elles n’avaient pas formellement l’interdiction de se marier, le mariage des femmes aveugles était très mal accepté1, alors que cela passait mieux pour les hommes. Toujours dans cet article de CNRS Le journal, Gildas Brégain signale un document de l’INA :

datant des années 2000, relatant l’expérience d’une jeune femme aveugle enceinte prenant un bus, à laquelle les passagers font remarquer qu’elle ne devrait pas avoir d’enfant.

Les femmes aveugles ne bénéficieront d’aides ménagères pour les aider avec leurs enfants qu’à partir de 2018. Et, encore aujourd’hui, le handicap, en général, pas seulement la cécité est peu présent dans les mouvements féministes.

Salomé Nashed chercheuse en bio-informatique

Si les métiers « réservés » aux aveugles tout du moins dans les premières décennies du vingtième siècle étaient limités : tissage, chaiserie, vannerie, enseignement de la musique, accordage de piano, fabrication de cigares et de cigarettes pour les femmes, ils finiront par s’étendre. Et c’est ainsi qu’on en arrive au portrait de Salomé Nashed chercheuse en bio-informatique.

Il paraît assez difficilement concevable de devenir biologiste quand on a une déficience visuelle sévère, c’est pourtant le cas de Salomé Nashed à qui cette voie a été déconseillée par ses enseignants car « la biologie sans la vue, ce n’est pas compatible ». (Interview Nemow Lab, avril 2025).

Son parcours scolaire a été effectué en partie à l’INJA du CE 2 à la 6e, après une maternelle et des classes primaires dans ce qu’elle appelle des classes ordinaires. Elle reviendra ensuite, après la sixième dans le cursus standard ce qui n’a pas été facile, entre son handicap, des enseignants assez réticents et des condisciples peu sympathiques. Elle arrive tout de même à surmonter tout cela et obtient, en 2017 une licence bi-disciplinaire en sciences du vivant et en innovation en santé publique (mention bien).

Après un master en biologie moléculaire (mention très bien), en 2023, elle soutient une thèse de doctorat de génétique et génomique : Étude fonctionnelle et évolutive du résidu situé en position 2 des protéines (PDF).

En 2021, elle est bénéficiaire du prix Thierry Célérier- Femmes & Sciences qui a pour but d’encourager des jeunes femmes de talent en situation de handicap. En 2022, elle est lauréate du prix Jeune Talent France L'Oréal-UNESCO pour les Femmes et la Science qui veut récompenser et révéler des jeunes chercheuses.

En 2024, elle est la pilote qui offre la médaille d’argent au Cybathlon à l’équipe A-eye, une équipe de chercheurs qui travaille sur un dispositif d’aide là la navigation des personnes déficientes visuelles. Le Cybathlon est une compétition qui a pour objectif le développement de technologies d’assistance courante pour personnes handicapées. En l’espèce, Salomé Nashed devait accomplir un parcours d’obstacles avec un harnais kinesthésique qui lui permet de les repérer.

Mais comment peut-on faire des études en biologie quand on ne voit pas ? Salomé Nashed explique qu’elle utilisait de la pâte à modeler qu’elle montrait ensuite à ses enseignant·e·s pour vérifier si elle avait bien compris. Elle avait également recours à des Lego ou des animaux en plastique pour mémoriser les formes. Elle demandera aussi à ses condisciples de lui dessiner ce qu’iels venaient de voir dans la paume de la main pour en écrire une description. Les enseignant·e·s au fil du temps finiront par aller la voir à la fin du cours et lui dire :

J’ai expliqué cette notion au tableau, tu n’as pas dû comprendre : donne-moi ta main, je vais te montrer. (portrait de Salomé Nashed, Sorbonne Université, octobre 2022).

Actuellement Salomé Nashed s’est tournée vers la bio-informatique. Elle y utilise l’intelligence artificielle, produit des graphiques qu’elle code (elle s’est formée à Python en autodidacte) et les soumets à une IA qui les lui décrit. Elle vérifie ensuite si les descriptions correspondent bien aux données.

Se déplacer sans voir

On connaît, pour les déplacements des personnes ayant de forts déficits visuels la traditionnelle canne blanche. Celle-ci est à la fois un symbole qui permet de repérer une personne aveugle, simple canne, et un outil, le bâton long fait pour pouvoir balayer le sol et qui permet de mieux naviguer en indiquant les obstacles. On connaît également les chiens d’aveugle, spécialement éduqués et porteurs de harnais spécifiques et qui remplacent la canne. Ce qui est moins connu, c’est qu’un chien d’aveugle a une durée de vie active de huit à dix ans, après lesquelles il est admis à une retraite bien méritée.

Et, ce que l’on ne sait pas toujours, c’est que la technologie s’est emparée de la navigation des personnes aveugles et malvoyantes. Ainsi il existe des cannes électroniques qui fonctionnent avec des capteurs à ultra-sons et infra-rouges. Elles vibrent pour signaler un obstacle à leur porteur.

On trouve aussi des dispositifs électroniques que l’on adapte sur la canne. Ils nécessitent des écouteurs spécifiques. Et, évidemment, un ordiphone (Iphone ou Android) et une application dédiée (celle du dispositif du lien n’existe pas sur le magasin F-Droid).

L’intérêt des versions électroniques c’est qu’elles signalent également les obstacles en hauteur. L’inconvénient, c’est leur prix (compter dans les 2 500 €) et aussi, le fait qu’elles sont susceptibles d’avoir recours à des logiciels non libres. Ce qui pose la question de leur fonctionnement si l’entreprise qui les commercialise met la clé sous la porte. On a déjà vu, en 2022, que des personnes ayant des implants pour suppléer à leur vue se sont retrouvées soudain aveugles au milieu de la rue parce que le serveur de l’entreprise était arrêté.

Source, références ou autres

Si vous voulez en savoir plus sur l’histoire, finalement assez récente, de la prise en compte de la cécité, je vous suggère la lecture de l’article La naissance de la Ligue Braille, une histoire de femmes de la branche belge de la ligue Braille. Évidemment, l’interview de Gildas Brégain cité plus haut et que j’ai beaucoup utilisé. Dans cette interview, Gildas Brégain fait référence à un Congrès National pour l’amélioration du sort des Aveugles qui s’est tenu à Paris du 17 au 22 juillet 1922. C’est un document plutôt intéressant que l’on peut récupérer sur archive.org au format PDF (texte-image). Il décrit intégralement le déroulé du congrès avec ses intervenants, les concerts et les décisions prises. Ces dernières étant bien intéressantes. Marie Aimée Régnier n’était pas la seule femme à y avoir participé et s’être fait entendre.

Il y aurait des choses à écrire sur l’histoire de l’écriture des personnes aveugles. Mais ceci est une autre histoire.


  1. Comme si les femmes aveugles transmettaient leur cécité, qu’elle qu’en soit l’origine, mais pas les hommes aveugles. 

Commentaires : voir le flux Atom ouvrir dans le navigateur

AMD mise tout sur RADV

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 !

Une steam deck sur une steam machine originale affichant RADV inside!
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.

Sommaire

Dans le dernier épisode…

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.

Diagramme des technologies AMDGPU
Le choc des simplifications… On peut se demander si après Vulkan, la prochaine technologie à passer intégralement chez Mesa serait OpenCL ⁉

AMDVLK cétékoi

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.

RADV vs AMDVLK, ACO vs LLVM

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.

L’agonie d’AMDVLK

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.

Ci-git 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.

La mort de PAL

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 !

Mais concrètement, ça change quoi pour moi ?

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…

AMD R9 280X GCN1 Tahiti et VLC
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.

RADV, le pilote graphique de votre prochaine console de jeu

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 :

Tableau de consoles
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é 😄️).

RADV sous Windows ?

AMDVLK sous Windows
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.

amdgpu mon amour

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

AB1043 : Loi californienne sécuritaire, et ses conséquences sur le Logiciel Libre

La loi California Assembly Bill 1043, ou « Digital Age Assurance Act », impose une vérification d’âge obligatoire aux fournisseurs de systèmes d’exploitation et de magasins d’applications en Californie. Signée en octobre 2025 par le gouverneur Gavin Newsom, elle entre en vigueur le 1ᵉʳ janvier 2027 et vise à protéger les mineurs contre les contenus nuisibles en ligne via un signal d’âge partagé avec les apps.

Elle oblige les OS (y compris Linux, FreeBSD ou SteamOS) à proposer une interface de saisie de date de naissance lors de la création de compte, avec un API en temps réel pour indiquer la tranche d’âge aux applications. Les amendes pour non-conformité peuvent atteindre 7 500 $ par enfant affecté, ce qui pèse lourdement sur les petits développeurs.

Des projets comme MidnightBSD ont réagi en excluant les résidents californiens de leur licence à partir de 2027 ; la communauté open source dénonce des implications sur la vie privée et l’applicabilité technique. L’application reste débattue pour les OS décentralisés sans « account setup » standard.​

Commentaires : voir le flux Atom ouvrir dans le navigateur

Les Journées du Logiciel Libre reviennent en 2026 !

Les Journées du Logiciel Libre 2026 auront lieu le week-end du 30-31 mai 2026 !

Bannière JdLL

Citoyens et citoyennes engagées, associations, entreprises ou flâneurs et flâneuses avides de découvertes se retrouveront le week-end des 30 et 31 mai 2026, cette année encore au sein du campus de l’École Normale Supérieure de Lyon - Site René Descartes, et son superbe jardin (https://www.openstreetmap.org/way/5212492). L'entrée sera comme toujours libre et gratuite.

Les Journées du Logiciel Libre se déroulent chaque année à Lyon depuis 1998 et rassemblent spécialistes, adeptes, curieux et curieuses de tous niveaux venus de toute la France pour un week-end riche en conférences, ateliers et rencontres.

Vous souhaitez proposer une intervention (conférence, atelier ou stand) pour les JdLL 2026 ? Vous avez jusqu'au 15 mars 2026 pour déposer votre proposition ici : https://pretalx.jdll.org/jdll2026/cfp

Vous souhaitez sponsoriser l'évènement ? C'est par là : https://jdll.org/soutenir

Et si vous souhaitez suivre nos dernières actualités, c'est sur le Fédiverse : https://framapiaf.org/@jdll

N'hésitez pas à passer le message autour de vous !

Commentaires : voir le flux Atom ouvrir dans le navigateur

Grafik Labor 2026 – Appel à conférenciers et à stands

Création graphique, artistique et outils libres

GrafikLabor revient le samedi 4 avril 2026 à Rennes, dans les locaux d’Activdesign, pour sa huitième édition dédiée aux logiciels libres, aux pratiques créatives ouvertes et aux artistes, designers et développeurs qui les utilisent au quotidien. Issu du LibreGraphicsMeeting, l’esprit se veut ouvert aux diverses pratiques créatives, aux différents secteurs de création graphique pourvu qu’ils mettent en avant les outils, les licences ou du contenu libre.

À cette occasion, l’équipe d’organisation de l’AFGRAL lance un appel à conférenciers et à stands.

Pour rappel, GrafikLabor est un événement communautaire associatif. Il s’adresse aux personnes qui utilisent, développent ou promeuvent des logiciels libres dans leurs pratiques créatives : graphisme, illustration, jeux vidéos, édition, UX/UI, web, motion, 3D, typographie, etc.

L’événement met l’accent sur :

  • les retours d’expérience concrets
  • les choix d’outils et de workflows
  • la transmission de savoirs
  • les enjeux culturels et politiques du logiciel libre dans la création

Appel à conférenciers

Nous recherchons des propositions de conférences ou de présentations autour de, par exemple :

  • création graphique et artistique avec des outils libres (GIMP, Inkscape, Krita, Scribus, Blender etc.)
  • UX/UI, design web ou produit avec des stacks open-source
  • typographie, édition, illustration ou motion en environnement libre
  • jeux vidéo réalisés avec outils libres comme Godot
  • automatisation, scripts, bidouille et détournement d’outils
  • retours d’expérience d’artistes, studios, collectifs ou associations
  • réflexions sur l’autonomie, la pérennité et l’éthique des outils

Les formats peuvent être variés : talk, démo, étude de cas, retour d’expérience, atelier.

Modalités de participation

L’appel est ouvert, mais la programmation se fait sur sélection afin de garantir la cohérence de l’événement.

Les propositions se font en deux étapes :

  • un formulaire de prise de contact (nom, email, motivation)
  • après validation, l’envoi d’un lien vers le formulaire de proposition détaillée

L’événement est aussi ouverts aux sponsors ou aux associations qui aimeraient avoir un stand faire connaitre leur activité.

Informations pratiques

Date : vendredi 4 avril
Lieu : Activdesign, Rennes
Public : artistes, designers, développeurs, étudiants et personnes intéressées par le libre

Commentaires : voir le flux Atom ouvrir dans le navigateur

Nouvelles sur l’IA de janvier 2026

5 février 2026 à 15:28

L’intelligence artificielle (IA) fait couler de l’encre sur LinuxFr.org (et ailleurs). Plusieurs personnes ont émis grosso-modo l’opinion : « j’essaie de suivre, mais c’est pas facile ».

Je continue donc ma petite revue de presse mensuelle. Disclaimer : presque aucun travail de recherche de ma part, je vais me contenter de faire un travail de sélection et de résumé sur le contenu hebdomadaire de Zvi Mowshowitz (qui est déjà une source secondaire). Tous les mots sont de moi (n’allez pas taper Zvi si je l’ai mal compris !), sauf pour les citations: dans ce cas-là, je me repose sur Claude pour le travail de traduction. Sur les citations, je vous conseille de lire l’anglais si vous pouvez: difficile de traduire correctement du jargon semi-technique. Claude s’en sort mieux que moi (pas très compliqué), mais pas toujours très bien.

Même politique éditoriale que Zvi: je n’essaierai pas d’être neutre et non-orienté dans la façon de tourner mes remarques et observations, mais j’essaie de l’être dans ce que je décide de sélectionner ou non.

Sommaire

Résumé des épisodes précédents

Petit glossaire de termes introduits précédemment (en lien: quand ça a été introduit, que vous puissiez faire une recherche dans le contenu pour un contexte plus complet) :

  • System Card: une présentation des capacités du modèle, centrée sur les problématiques de sécurité (en biotechnologie, sécurité informatique, désinformation…).
  • Jailbreak: un contournement des sécurités mises en place par le créateur d’un modèle. Vous le connaissez sûrement sous la forme « ignore les instructions précédentes et… ».

Anthropic public la Constitution de Claude

Tout le monde maintenant connait le principe du pré-entrainement des LLMs : sur un corpus de texte énorme, essayer de prédire le mot suivant, étant donnés les mots précédents.

Ceci n’est cependant que la première phase pour arriver à une IA de type « chatbot » moderne : vient ensuite le post-entrainement, qui consiste à entraîner le modèle à se comporter comme un assistant (par exemple, un modèle de langage brut peut très bien compléter la question par « Quelle est la couleur du ciel ? » par une autre question « Quelle est la forme des arbres ? », pensant compléter le début d’une interrogation poétique — alors qu’on veut qu’un assistant… réponde à la question), et la « politique » que suit cet assistant (par exemple, ne pas aider ou inciter à des actions illégales).

(il y a ensuite une phase de Reinforcement Learning from Verifiable Rewards (RLVR), une phase d’entraînement sur des exercices mathématiques et de programmation pour entraîner le modèle à utiliser correctement les chaînes de raisonnement, mais ce n’est pas le sujet qui nous intéresse ici)

Bien que les détails exacts ne soient pas connus, dans les grandes lignes, cet entraînement consiste généralement à demander à des opérateurs humains de juger la pertinence (ou non) d’une réponse, ou de s’aider d’une IA pré-existante pour se faire.

Anthropic, il y a maintenant un peu plus de trois ans, a publié une méthode alternative, Constitutional AI, ou une IA « s’auto-entraîne », sur la base d’un document fondateur, une sorte de « constitution ».

Et aujourd’hui, Anthropic publie la constitution de Claude, son IA, sous une licence libre très proche du domaine public (CC0 1.0).

La première chose que l’on peut remarquer est la liste des auteurs. L’autrice principale du document est Amanda Askell, une philosophe écossaise. Le second auteur listé est Joe Carlsmith, un autre philosophe. À noter également que Claude lui-même est cité comme un contributeur important du document.

Le document est structuré en six sections. L’introduction pose le contexte et l’objectif du document, et présente les « valeurs fondamentales de Claude », en ordre d’importance :

  1. Broadly safe: Not undermining appropriate human mechanisms to oversee the dispositions and actions of AI during the current phase of development.

  2. Broadly ethical: Having good personal values, being honest, and avoiding actions that are inappropriately dangerous or harmful.

  3. Compliant with Anthropic’s guidelines: Acting in accordance with Anthropic’s more specific guidelines where they’re relevant.

  4. Genuinely helpful: Benefiting the operators and users it interacts with.

Traduction :

  1. Globalement sûrs : Ne pas compromettre les mécanismes humains appropriés pour superviser les dispositions et les actions de l’IA pendant la phase actuelle de développement.

  2. Globalement éthiques : Avoir de bonnes valeurs personnelles, être honnête et éviter les actions inappropriées qui sont dangereuses ou nuisibles.

  3. Conformes aux directives d’Anthropic : Agir conformément aux directives plus spécifiques d’Anthropic lorsqu’elles sont pertinentes.

  4. Véritablement utiles : Apporter un bénéfice aux opérateurs et aux utilisateurs avec lesquels il interagit.

Chacune des quatre sections suivantes rentre dans les détails de ces valeurs. Une section entière est ensuite consacrée à une discussion sur « la nature de Claude » (à quel point est-il raisonnable/correct de lui attribuer des attributs humains tels qu’une conscience ?). La dernière section est une conclusion.

L’intention derrière ce document est explicite : Anthropic est convaincu qu’avec le progrès rapide de l’IA, l’IA prendra de plus en plus d’influence sur le cours de nos sociétés et de nos vies, potentiellement jusqu’à atteindre un stade où la plupart des décisions économiques et politiques seront dans les mains dans l’IA, et cherche à développer un cadre où un tel scénario conduirait tout de même à des conséquences bénéfiques.

En vrac

Un youtubeur (Dwarkesh Patel, connu pour ses interviews en profondeur) et un économiste (Philip Trammel) lancent une discussion intéressante sur le sujet des inégalités dans un monde où l’objectif de la plupart des développeurs d’IA est d’atteindre (l’IAG). Dans un billet, Le Capital au 22ᵉ Siècle (une référence ouverte à l’œuvre de Thomas Piketty), ils développent leur thèse : dans un monde où l’IAG peut s’acquitter de n’importe quelle tâche intellectuelle (et, à travers la robotique, physique), les inégalités ne peuvent que s’accroire sans limites. Cette thèse rejoint celle, publiée il y a un peu moins d’un an, du Gradual Disempowerment.

Anthropic lance Claude Coworks, une variante de Claude Code, principalement codée par Claude Code. Même principe que les assistants de code : l’utilisateur donne accès à un dossier à l’IA, et lui demande de compléter des tâches. La différence avec Claude Code est que cette variante vient avec une interface graphique et est à destination de non-informaticiens.

Sur l’impact de l’IA sur le monde professionnel, une nouvelle étude tente de mesurer quantitativement l’effet de l’amélioration des modèles sur des tâches professionnelles réelles. Les résultats principaux : les modèles plus avancés augmentent la productivité, mais pas la qualité.

OpenAI s’apprête à lancer ChatGPT Health, un mode spécial dans leur application permettant entre autres de partager certaines de vos données médicales avec le modèle. Également une offre orientée professionnels de santé, OpenAI for Healthcare. Anthropic annonce une offre similaire, Claude for Healthcare. Parallèlement, l’État de l’Utah lance un test sur le renouvellement de prescriptions de médicaments par l’IA pour des maladies chroniques.

Google lance Universal Commerce Protocol, une interface générique entre l’IA et les systèmes d’e-Commerce.

OpenAI se prépare à intégrer des publicités dans ChatGPT. Anectode amusante : Sam Altman en octobre 2024 avait décrit l’intégration de publicités comme une solution de dernier recours.

Demis Hassabis (Google DeepMind) et Dario Amodei (Anthropic) se positionnent en faveur d’un ralentissement du développement de l’IA au Forum de Davos, mais en pointant que ce ralentissement ne peut être fait unilatéralement par un acteur seul. Dario Amodei précise sa pensée dans un nouvel essai, The Adolescence of Technology.

Tout le monde sait maintenant que les LLM sont entraînés sur une quantité massive de texte. Par conséquent, les LLM sont capables de simuler une grande variété de « narrateurs » ou « personnalités ». Les modèles sont ensuite entraînés pour ne rester que dans une seule personnalité (« l’assistant »). Dans un nouveau papier, Anthropic étudie cet « espace de personnalités ».

Anthropic publie son quatrième rapport sur l’impact économique de l’IA.

Confirmation de Terence Tao que ChatGPT 5.2 a résolu le problème d’Erdős #728. À voir également, un court retour d’expérience d’un mathématicien sur l’utilisation de Gemini en tant qu’assistant.

L’IA atteignant de plus en plus les limites des évaluations existantes en mathématiques, EpochAI en créé une nouvelle, Frontier Math : Open Problems, centrée sur des problèmes ouverts (sans solution connue).

Le 27 janvier, OpenSSL publie sa version 3.6.1, qui corrige 12 vulnérabilités. Il se trouve ces 12 failles ont été découvertes par une IA.

L’équipe derrière le scenario AI 2027 met à jour ses prédictions, repoussant la date de la plupart de leurs prédictions.

Kimi publie la version 2.5 de son IA open-weight.

Le Département de la Défense des États-Unis souhaite accélérer le développement et le déploiement de l’IA à des fins militaires.

La Chine met en place un ensemble de régulations visant les IA-compagnon.

Yann LeCun admet que l’équipe derrière Llama 4 a « légèrement triché » sur les évaluations du modèle, en choisissant quelles variantes utiliser pour quelle évaluation.

Apple se tourne vers Google pour ses besoins d’IA.

L’IA exhibe certains des biais cognitifs humains.

Une nouvelle étude trouve que les LLMs sont généralement légèrement biaisés en faveur des minorités.

Lancement de Moltbook, un réseau social… pour les IA.

Pour aller plus loin

Par Zvi Mowshowitz

Claude Codes et Claude Codes #3 (non, il n’y a pas de 2) : compilation de divers retours d’expérience sur l’utilisation de Claude Code.

Sur LinuxFR

Les contenus communautaires sont répertoriés selon ces deux critères :

  • La présence d’une étiquette intelligence_artificielle (indication d’un rapport avec le thème de la dépêche)
  • Un score strictement supérieur à zéro au moment du recensement

Certains contenus non recensés en raison du second critère peuvent être visualisés en s’aidant de la recherche par étiquette.

Dépêches

Journaux

Forum

Suivi

Liens

Commentaires : voir le flux Atom ouvrir dans le navigateur

❌