En ce mardi 28 avril, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora Linux 44.

Fedora Linux est une distribution communautaire développée par le projet Fedora et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora Linux peut être vue comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• La communauté francophone
  • L'association
  • La documentation
• Comment se procurer Fedora Linux 44 ?

Expérience utilisateur

L'environnement de bureau GNOME est proposé dans sa version 50.

Après avoir introduit lors de la version précédente un moniteur du temps d'écran dans le panneau de configuration, ce menu s'étoffe avec la possibilité de configurer un réel contrôle parental. Ainsi il est possible de verrouiller l'écran automatiquement après un temps passé dans la journée sur l'ordinateur ou après une certaine heure. Il reste possible d'étendre l'usage de l'ordinateur manuellement en cas de besoin après validation par l'administrateur.

Côté accessibilité, le lecteur d'écran Orca se dote d'un rafraîchissement de son outil de configuration pour être aligné avec l'apparence des autres applications GNOME. Par défaut ses paramètres sont également globaux, évitant de devoir reconfigurer le lecteur d'écran pour chaque application bien que des personnalisations précises restent possibles application par application si nécessaire. Il est aussi possible de réduire les animations dans l'interface de GNOME pour éviter les distractions pour ceux qui en souffriraient.

Le lecteur de documents se dote, enfin, d'une possibilité d'annoter les documents autrement qu'en ajoutant un champ de texte dans une zone précise. Il est possible de surligner ou de tracer des lignes au sein du document et de varier le style de l'ensemble au gré des besoins.

Le navigateur de fichiers quant à lui continue dans l'amélioration des performances et de la stabilité, que ce soit un chargement des miniatures et icônes de documents plus rapide, ou une consommation moindre de mémoire pour l'application en général. Côté fonctionnel, le renommage de fichiers en masse a une interface plus claire et il est possible lors de la recherche de fichiers de sélectionner simultanément plusieurs filtres.

En terme de performances, pour ceux qui utilisent une session distante de GNOME la carte graphique de la machine qui reçoit le flux vidéo est sollicitée pour le décodage ce qui rend l'expérience bien plus fluide tout en consommant moins d'énergie. Pour ceux utilisant une carte graphique Nvidia l'expérience devrait être également plus stable par rapport aux versions précédentes. Il est possible de coupler l'accès distant avec une authentification Kerberos, de même il peut être exploité même si la session a été démarrée depuis un ordinateur sans écran tel un serveur.

Il y a eu de nombreuses améliorations pour l'affichage à fréquence variable et l'affichage avec mise à l'échelle fractionnée. Si ces fonctions étaient déjà activées dans Fedora, pour ceux bénéficiant d'un matériel compatible, elles bénéficient d'une plus grande stabilité. Les possesseurs d'une carte graphique Nvidia devraient également noter une plus grande fluidité dans l'interface. Le partage et la capture d'écran peuvent prendre en compte l'affichage HDR pour avoir le même rendu que sur l'écran physique. Enfin GNOME prend en charge le protocole des couleurs v2 de Wayland afin d'être compatible avec les évolutions futures des applications graphiques qui peuvent en faire un usage fin comme un éditeur d'images.

Le calendrier continue sa mutation. Dans un contexte professionnel, il permet maintenant de voir, pour un événement donné, qui a reçu l'invitation et parmi ces invités, lesquels doivent obligatoirement être présents. L'interface pour ajouter rapidement un nouvel événement a été revue pour être plus intuitive. Il est dorénavant possible d'exporter un calendrier complet avec le format ICS au lieu d'un événement seulement. L'interface prend en compte maintenant les paramètres régionaux concernant le premier jour de la semaine.

D'ailleurs il est possible au niveau de GNOME de changer ce paramètre du premier jour de la semaine. Pour les paramètres, les entrées et sorties sonores sont dissociées pour identifier clairement si on contrôle le volume d'une entrée ou d'une sortie audio.

Les variantes de Fedora reposant sur l'environnement KDE Plasma utiliseront le configurateur Plasma Setup pour la post installation de manière analogue à GNOME avec GNOME init setup. Cet utilitaire a été récemment introduit avec KDE Plasma 6.6. Les étapes redondantes au niveau d'Anaconda sont supprimées pour une plus grande cohérence. Ainsi les images Live comme non Live fourniront la même expérience ce qui sera particulièrement visible pour ceux utilisant la variante KDE Plasma Mobile. Et comme pour GNOME, il devient possible d'installer Fedora en mode OEM, où le système peut être installé et le premier utilisateur peut créer son compte et le configurer à sa guise sans nécessiter un compte factice à l'installation.

De même ces variantes utiliseront Plasma Login Manager (PLM) comme gestionnaire de connexions au lieu de SDDM. Ce changement a également été introduit dans KDE Plasma 6.6 pour avoir un contrôle total du projet KDE dans l'expérience utilisateur. L'objectif de Fedora est de suivre la décision du projet pour améliorer la maintenance et l'expérience utilisateur en ayant un tout intégré. Cependant — même si PLM dérive de SDDM — il reste légèrement moins personnalisable à ce stade. Ce changement n'affecte par défaut que les nouvelles installations. Pour ceux qui veulent en bénéficier après une mise à niveau, voici les commandes à exécuter :

$ sudo dnf install plasma-login-manager kcm-plasmalogin

$ sudo systemctl enable --force plasmalogin.service

L'environnement de bureau Budgie passe à la version 10.10 et tourne avec Wayland au lieu de X11. Il utilise labwc comme compositeur qui permet de définir des raccourcis claviers globaux, l'accélération du curseur de la souris, d'adapter le thème des applications en fonction de la configuration de l'environnement. La variante spin utilisera SDDM comme gestionnaire de connexions pour avoir une expérience native Wayland de bout en bout. Outre cela, l'environnement fournit un nouvel utilitaire pour configurer les écrans.

La variante Games Lab est remaniée pour passer de Xfce à KDE Plasma et ainsi utiliser Wayland pour avoir une couche graphique plus moderne. En effet Wayland permet de plus en plus d'exploiter le matériel moderne ce qui est particulièrement utile dans ce contexte. La liste des jeux fournis par défaut a été revue, la documentation autour rafraîchie pour rendre compte des progrès dans le domaine et une tentative de fournir certains correctifs pour gérer le matériel des jeux aux projets d'origine plutôt que de les garder dans Fedora ou d'autres distributions dérivées comme Bazzite.

Le module noyau NTSYNC est activé quand les paquets Steam ou WINE sont installés pour améliorer les performances et la compatibilité des applications Windows et en particulier les jeux. Cela passe par l'ajout du paquet ntsync-autoload qui une fois installé remplit ce rôle en écrivant ntsync dans le fichier /usr/lib/modules-load.d/ntsync.conf afin de charger ce module automatiquement.

Ce module noyau améliore les performances car globalement les applications Windows, mais en particulier les jeux, pouvaient synchroniser leurs fils d'exécution avec des sémaphores, mutex et événements via des primitives noyau Windows. Mais comme ces mécanismes ne sont pas disponibles dans le noyau Linux, WINE les émulait dans l'espace utilisateur ce qui a des performances moindre. Le module noyau fournit cette abstraction au sein du noyau Linux lui-même ce qui reproduit la conception originale de Windows à ce niveau.

Le spin MiracleWM remplace l'environnement nwg-shell avec Dank Material Shell (qui est basé sur QuickShell). En effet le premier était difficile à maintenir et à stabiliser avec des mises à jour qui cassaient fréquemment la compatibilité. L'expérience devrait donc être plus stable pour les utilisateurs et ils devraient disposer de plus de fonctionnalités également.

Le gestionnaire de paquets universel PackageKit, utilisé par GNOME Logiciels entre autre, exploite dorénavant dnf5 au lieu de la version précédente. Cela permet d'avoir une expérience unifiée quel que soit l'outil employé pour utiliser DNF dans l'arrière coulisse. En particulier, les bases de données internes ne seront plus dupliquées et l'historique des actions est ainsi unique. Les notifications de mise à jour et la réalisation des mises à niveau devrait être également plus fiables et efficaces.

L'installateur Anaconda ne fournira plus de configuration réseau par défaut pour les interfaces filaires mais uniquement pour les installations n'utilisant pas une image Live. Jusqu'ici, à l'installation il y a la possibilité de configurer les interfaces réseaux mais pour les interfaces filaires non configurées (pour l'être avec des outils dédiés plus tard, par exemple) une configuration par défaut basique et potentiellement inadaptée était installée. Cela pouvait poser des problèmes à certains utilisateurs, mais c'était aussi un effort de maintenance pour que les valeurs par défaut correspondent à celles de NetworkManager par exemple. Ce changement permet également d'ouvrir la voie à la réutilisation du module de configuration réseau de Cockpit dans le futur.

La suite TeXLive nouveau millésime 2025 est proposée. Fedora en profite pour revoir l'empaquetage passant d'un SRPM unique pour le millier de modules à une cinquantaine. Ainsi mettre à jour un seul composant ne nécessite pas de reconstruire l'ensemble de ces paquets avec la tonne de mises à jour que cela implique pour les utilisateurs. Le découpage des SRPM suit celui du projet officiel pour avoir du sens en terme de dépendances. Cependant le nombre de sous-paquets générés ne change pas.

Outre cela, cette mise à niveau permet l'usage du format PDF 1.7 par défaut. Changer l'échelle des polices au-delà de 2048 points génère une erreur propre plutôt qu'un problème silencieux en arrière plan. LuaTeX comme pdfTeX sont améliorés.

Le paquet d'intégration avec la bibliothèque Qt5 pour LibreOffice est supprimé, les environnements de bureaux utilisant Qt6 maintenant.

Gestion du matériel

Pour les systèmes Aarch64 avec un EFI, la sélection du device tree sera automatique au démarrage de l'image Live pour les ordinateurs portables Windows ARM. En effet une problématique dans le monde ARM, contrairement à l'univers PC avec l'architecture x86, la table ACPI et les protocoles avec une énumération des périphériques dynamiques tels que USB / PCIe ne suffisent pas à décrire le matériel de manière suffisamment complète pour démarrer la machine. Il est nécessaire pour cela de fournir un fichier additionnel, le device tree, qui est en général maintenu au sein du noyau Linux.

Et dans le cadre d'une image Live, il faut une image unique qui peut démarrer sur n'importe quelle machine. Pour les ordinateurs portables ARM, jusqu'ici il était nécessaire de personnaliser l'image Live à la main pour permettre un tel démarrage afin de fournir et de sélectionner le bon device tree à employer. La nouvelle procédure rend l'ensemble bien plus simple pour les utilisateurs. Cela repose sur une image noyau unifiée sans initrd mais avec systemd-stub et hardware-id pour identifier le bon device tree pour cette machine. Ainsi un initrd adapté et la ligne de commande pour charger le noyau Linux final seront générés et fournis à GRUB pour lancer le démarrage avec l'ensemble des informations nécessaires.

Internationalisation

L'outil d'aide à la saisie IBus évolue à la version 1.5.34. Il prend en charge le protocole des méthodes de saisie de Wayland ce qui permet de tirer profit de deux changements pour les environnements Wayland non basés sur GNOME (qui ne le prend pas en charge à ce jour). Il peut en effet automatiquement supprimer le texte environnant suivant le contexte, comme par exemple retirer un caractère ayant servi à la composition d'une autre ou de corriger le placement de la ponctuation dans un texte. Il peut également adapter la couleur du texte et du surlignage lors de la pré-édition pendant l'aide à la saisie en fonction du contexte (comme la prédiction complète d'un mot, la détection d'une faute d'orthographe, etc.). Enfin les annotations des émojis sont affichées dans la table de sélection.

Le module Ibus pour la transcription vocale est mis à jour à la version 0.7.0 qui propose un module pour utiliser la famille de modèles Whisper d'OpenAI en plus du modèle Vosk déjà employé. Il est possible de choisir le modèle souhaité dont les variantes exécutées en local ou ceux disponibles en ligne via la plateforme Hugging Face. Le module essaye de trouver automatiquement le modèle adapté à la langue employée mais il reste possible de définir cela manuellement en cas de besoin. Normalement la qualité du rendu de la transcription vocale devrait être améliorée tout en ayant la flexibilité dans le choix du modèle.

Administration système

Les images Fedora Cloud n'ont plus une partition /boot dédiée mais utilisent un sous-volume btrfs à la place. Cela ne s'appliquera cependant pas aux images UEFI-UKI ou pour l'architecture s390x à cause des limitations de ces systèmes. L'objectif est de réduire la taille de l'image initiale car il n'est plus nécessaire de fournir de l'espace libre dédié à cette partition. Et par conséquent, cela permet au reste du système de pouvoir utiliser plus d'espace librement sans devoir tenir compte de cette dite réserve.

L'émulateur QEMU n'aura plus de paquets compatibles avec l'architecture 32 bits i686 car cette architecture n'est plus maintenue par le projet officiel. Par ailleurs cette architecture posait quelques soucis de maintenance par le passé avec des échecs de compilation à gérer pour un paquet très peu utilisé sur de tels systèmes. Mais exécuter un système 32 bits depuis un QEMU 64 bits reste évidemment toujours possible.

Le gestionnaire de paquets nix est introduit dans Fedora Linux. Ce gestionnaire de paquets connu pour être celui de NixOS peut en effet être utilisé sur d'autres environnements Unix sans problèmes ce qui permet ici de bénéficier ou de contribuer à son écosystème de paquets pour ceux qui le souhaitent. Il est possible de s'en servir au niveau système (mode multi-utilisateur) ou pour un utilisateur spécifique. Cependant le projet Fedora ne souhaite pas s'en servir comme gestionnaire de paquets officiel, de la même façon que npm ou pip peuvent être utilisés depuis Fedora Linux pour récupérer des utilitaires JavaScript ou Python sans utiliser dnf.

Le gestionnaire de paquets Kubernetes Helm utilise la version 4 dorénavant tandis que la version 3 reste disponible avec le paquet helm3. En effet cette nouvelle version brise la compatibilité ascendante et comme il est très employé dans un contexte d'intégration continue ou de gestion de systèmes de conteneurs, la migration peut prendre du temps d'où la conservation de l'ancienne version qui sera retirée probablement pour Fedora Linux 45.

En terme de nouveautés, il prend en charge des extensions écrites en WebAssembly, il prend en charge également les OCI digest ou des arguments en format JSON. Son architecture a été revue pour utiliser des paquets versionnés et restructurer l'empaquetage. Le format Chart v3 est également pris en charge.

Le gestionnaire de bases de données MariaDB passe par défaut de la version 10.11 à la version 11.8. La version 11.8 était déjà proposée dans les dépôts, elle remplace juste la version 10.11 en tant que version de base. Cette dernière reste disponible via le paquet mariadb10.11.

L'outil Ansible est mis à jour à sa 13e version. Depuis la précédente version proposée dans Fedora Linux, Ansible 11, il fournit majoritairement des améliorations de sécurité et une plus grande robustesse dans le moteur de templates. De nombreux comportements invalides ignorés auparavant peuvent générer des erreurs et doivent être corrigés. D'ailleurs la gestion des erreurs a été également améliorée. Les modules plus spécifiques ont été mis à jour ce qui peut nécessiter une adaptation des playbooks existants.

Les paquets pour le gestionnaire de bases de données MySQL avec le nom community-mysql sont supprimés. L'objectif est de simplifier la maintenance et de rendre la situation plus claire pour les utilisateurs qui peuvent se référer uniquement aux paquets nommés mysql et dérivés.

Les paquets rust-coreutils et rust-nu qui vont respectivement de la version 0.0.27 à 0.5.x et de la version 0.99.1 à 0.109.2. Cette implémentation des outils de base de système en Rust gagnent en popularité et en maturité, étant utilisés par défaut dans Ubuntu maintenant. Cette version apporte une meilleure compatibilité avec les outils GNU. Son évolution très rapide jusqu'alors gênait les possibilités de mettre à jour ses dépendances telles que le shell Nu qui peut maintenant être mis à jour plus souvent. Les utilitaires GNU restent toujours les versions de référence dans Fedora Linux.

Développement

La chaine de compilation GNU progresse avec GCC 16.1, binutils 2.46, glibc 2.43 et gdb 17.1.

Le compilateur GCC a beaucoup travaillé sur la prise en charge initiale de la nouvelle version du langage C++26, mais des améliorations notables concernant C++23 sont également de la partie. Concernant le langage Ada, des extensions GNAT sont ajoutées et qui diffèrent du standard pour simplifier l'écriture du code ou se rapprocher des autres langages comme de nouvelles méthodes de constructions et de finalisation des objets. Côté matériel, les derniers processeurs Intel ont leurs optimisations spécifiques disponibles pour ceux qui le souhaitent tandis que le surcoût d'utiliser une carte graphique AMD avec les technologies OpenMP et OpenACC a été drastiquement réduit. OpenMP peut utiliser l'allocateur mémoire de l'API CUDA pour les cartes graphiques Nvidia afin d'améliorer les performances.

Les utilitaires binutils, outre la prise en charge de matériel plus moderne, il gère le format SFrame version 3 ce qui permet notamment de charger des sections .text de plus de 2 Gio.

La bibliothèque C glibc quant à elle, s'occupe d'améliorer la prise en charge de la version du langage C23. Elle peut gérer des caractères Unicode 17.0 et optimise certaines fonctions mathématiques comme acosh, asinh ou atanh pour les fonctions trigonométriques et la famille de fonctions fma pour le calcul de fonctions affines. Elle prend en charge les nouveaux appels systèmes mseal et openat2, le premier permettant de protéger une zone mémoire d'un changement de permissions ou de taille ultérieurement tandis que le second ajoute de nombreuses options supplémentaires à openat pour l'ouverture de fichiers.

Enfin le débogueur GNU peut gérer sur des architecture x86_64 une shadow stack avec des pointeurs 32 bits. Dans le protocole Debugger Adapter il accepte les requêtes pour la complétion d'une commande. Il devient plus simple de changer le style des couleurs de la sortie dans le terminal en fonction de ses préférences. Il peut également tirer parti des espaces de nom de l'éditeur de liens pour afficher cette information lors du débogage, notamment lors de l'affichage des informations concernant les bibliothèques partagées utilisées par le programme en cours d'analyse.

La chaine de compilation LLVM version 22 est proposée. Comme souvent l'alter égo de la chaine de compilation GNU n'est pas en reste avec la prise en charge initiale de la future version du langage C nommée C2y à ce jour. Plus d'optimisations matérielles peuvent être exploitées avec les expressions constantes de C++. comme les instructions SSE, AVX, et AVX-512. De même plus de micro architectures sont prises en charge pour des optimisations supplémentaires pour le matériel récent.

L'outil de configuration de l'environnement de compilation CMake passe à la version 4.2. Cela entraîne une rupture de compatibilité pour les projets ayant besoin de la version 3.5 ou inférieure. Outre l'évolution de son File API, il prend en charge la copie d'arborescence, via l'option -E copy_if_newer, basée sur la valeur de la date du dernier changement plutôt que celui de la différence de contenu pour être plus rapide. Une nouvelle option de ligne de commande --project-file permet d'utiliser un fichier alternatif à CMakeLists.txt à des fins de développement pour des tests temporaires. Le préfixe LINKER: peut être ajouté à différentes variables et commandes. Enfin, la variable CMAKE_FIND_REQUIRED peut être employée pour forcer toutes les commandes de recherche d'un fichier, d'une bibliothèque ou d'un programme d'émettre une erreur par défaut s'il n'est pas trouvé, au lieu de devoir le préciser à chaque commande. Le projet Fedora a dû proposer beaucoup de correctifs aux paquets compilés avec CMake pour permettre leur bonne compilation.

La bibliothèque C++ Boost passe à la vitesse supérieure avec la version 1.90. C'est la première mise à jour de ce composant depuis Fedora Linux 40, entre temps de nombreuses sous-bibliothèques sont apparues comme Charconv, Cobalt, Hash2, MQTT5, OpenMethod, Parser, Redis et Scope. La plupart des sous-bibliothèques ne prennent plus en charge C++03 et nécessitent au moins C++11 voire C++14 maintenant ce qui peut impacter la compatibilité des vieux projets.

Le langage de programmation Ruby prend de la valeur avec sa version 4.0 carats. Les opérateurs logiques binaires utilisés dans des conditions sont dorénavant compatibles en multi-lignes pour simplifier la lecture. En cas d'erreurs concernant les arguments pour appeler une fonction, un extrait du code de l'appelant et de l'appelé est affiché pour simplifier le débogage. Concernant les compilateurs juste à temps proposés, RJIT est retiré tandis que ZJIT est introduit. Il n'est pas encore recommandé de se servir de ce dernier en production, l'objectif est d'en faire une référence pour la prochaine version, quand il sera plus performant que la référence actuelle YJIT. Enfin Ractor comme mécanisme d'exécution parallèle a vu ses performances améliorées en ayant moins de données partagées et en utilisant moins de verrous globaux, l'objectif est — pour lui aussi — d'en retirer son statut expérimental pour la prochaine version.

Le paquet ruby-build est d'ailleurs scindé en plusieurs sous paquets pour rendre son utilisation plus modulaire. Ainsi au lieu de tirer l'ensemble des composants pour permettre de compiler n'importe quelle implémentation de Ruby, uniquement ceux nécessaires peuvent être téléchargés et installés ce qui peut éviter de devoir télécharger la chaine de compilation Rust ou OpenJDK et ainsi passer de 400 Mio de paquets à obtenir à quelques Mio seulement. Donc maintenant les dépendances essentielles pour cela sont regroupées dans le paquet ruby-build-core, si l'objectif est de compiler JRuby, le paquet ruby-build-jruby peut être installé, pour PicoRuby c'est ruby-build-picoruby, etc.

Le langage Go saute vers sa version 1.26. Le langage permet maintenant de spécifier une expression comme valeur par défaut pour une nouvelle variable en construction, comme par exemple une référence vers un champ JSON à parser. Il permet aussi de spécifier des contraintes de type pour des paramètres d'une fonction, qui réfère à un type générique, qui se réfère à lui même. Niveau outillage, la commande go fix permet de facilement porter un code existant vers une construction plus moderne à l'aide de moderniseurs qu'il fournit. Le ramasse miettes Green Tea est activé par défaut et doit fournir une réduction de son impact de 10 à 40% dans des programmes classiques. Pour les architectures x86_64, par défaut l'adresse mémoire du tas est initialisée à une adresse aléatoire au lancement de l'application pour réduire le risque d'attaques. Les appels de code C sont aussi 30% plus rapides.

Le langage PHP passe à la version 8.5. Parmi les nouveautés, il propose une nouvelle classe URI pour faciliter la manipulation des liens, il introduit également le concept de pipe avec |> pour enchainer les opérations sans nécessiter de variables intermédiaires ce qui simplifie l'écriture et la relecture du code. Il devient également possible de cloner un objet tout en éditant des propriétés à la volée ce qui est particulièrement utile pour les objets avec des champs en lecture seule. Une fonction peut ajouter la propriété #[\NoDiscard] pour générer une alerte si un appelant ne récupère pas la valeur de retour de cette fonction, ce qui permet d'améliorer la conception et l'utilisation des APIs. Les erreurs fatales fournissent aussi une trace d'appel pour mieux déboguer le programme. Et bien d'autres changements encore.

Le langage Haskell devient plus fonctionnel avec son compilateur GHC version 9.10 et sa suite de paquets Stackage 24. Le langage dispose de quelques petites améliorations comme la possibilité pour la boucle forall d'avoir le qualificatif visible afin de spécifier le type de l'objet employé dans la boucle sans inférence. Ou encore de déprécier une instance de classe afin de générer une alerte en cas d'utilisation. Sinon le compilateur dispose de la possibilité pour le backend JavaScript de se lier à du code C grâce à l'usage de WebAssembly, tandis que le backend WebAssembly permet d'appeler du code JavaScript et inversement du code JavaScript qui peut appeler du code Haskell.

Le projet Fedora en profite pour supprimer les paquets de profilage ghc-*-prof pour les architectures non x86_64 et aarch64, sauf pour la bibliothèque standard, car leur usage était probablement rare et le coût de maintenance trop important pour les empaqueteurs.

La boîte à outils web pour Python nommé Django serpente à la version 6. Le changement majeur est l'introduction de la prise en charge interne du Content Security Policy pour facilement bloquer les attaques par injection de contenu comme XSS. Il faut déclarer dans ce cas les ressources externes, comme les scripts ou images, auxquelles le navigateur peut accéder et bloquer ainsi les autres. Il intègre aussi la gestion des templates partiels qui étaient auparavant dans un module externe. Il propose également le concept de tâche pour exécuter des actions potentiellement longues en arrière plan en dehors du cycle de requête-réponse HTTP tel que l'envoi d'un courriel suite à un appel particulier. Enfin il adopte l'usage de l'API Python moderne pour la gestion des courriels. Cette version présente de nombreuses incompatibilités, l'usage de Django 5 reste possible par l'installation du paquet python3-django5.

Des paquets nodejsXX-bin et nodejsXX-npm-bin sont fournis pour créer les fichiers /usr/bin/node et /usr/bin/npm sans nom de versions qui pointent vers la version voulue par l'utilisateur. Ils ne peuvent pas être installés en parallèle ce qui permet de garantir l'unicité de ces fichiers dans un système. Cela signifie qu'il n'y a plus vraiment de version de NodeJS de référence dans Fedora Linux et qu'il est aisé de passer d'une version à une autre selon ses besoins. Pour les mainteneurs, c'est plus facile également de gérer les changements de versions car il n'y a pas la question de gérer la transition d'une version de référence à une autre.

Cette propriété signifie également que passer d'une version à une autre nécessite d'utiliser la commande dnf swap. Par exemple : dnf swap --allowerasing nodejs24-bin nodejs22-bin

La bibliothèque rust-bindgen pour lier du code Rust avec du code C ou C++ est empaquetée à la version 0.72. Avant les versions de 0.68 à 0.72 étaient proposées, mais la nouvelle version LLVM 22 décrite plus haut casse la compatibilité pour représenter l'AST ce qui rend ces anciennes versions non compatibles. Cela a impliqué des adaptations pour les dépendances impactées.

La bibliothèque d'édition des métadonnées des fichiers audio taglib passe à la version 2.0. Cette version ne préserve pas la compatibilité de son ABI et API ce qui a nécessité une adaptation pour ses dépendances comme Ardour et Easytag. Beaucoup de fonctions obsolètes ont été supprimées pour avoir une API plus propre. Le code a été modernisé avec beaucoup de correctifs et un usage de C++17. La prise en charge des propriétés des formats MP4 et RIFF a été également étendue.

Le parseur et moteur de rendu de CommonMark cmark progresse vers la version 0.31.

La machine virtuelle Java OpenJDK 21 n'est plus proposée dans les dépôts. Cela permet de concentrer les ressources sur OpenJDK 25 et 26 qui sont plus utilisées. Ce temps économisé peut être alloué dans la finition de la compatibilité avec Eclipse Temurins.

Le paquet python-mock a été supprimé des dépôts. Son retrait prochain avait été annoncé avec Fedora 34 mais de nombreux paquets en avaient encore besoin jusqu'ici.

Projet Fedora

Les paquets avec des fichiers identiques utilisent des liens physiques par défaut au sein du répertoire /usr. Notamment certains paquets Python peuvent avoir des contenus générés automatiquement qui sont dupliqués avec la macro %__os_install_post_python. Mais la manière de faire n'était pas toujours cohérente entre les paquets et des effets de bord existaient car il pouvait y avoir une différence de date d'édition de fichiers entre deux liens physiques ce qui nuisait à la reproductibilité de la génération des paquets. Maintenant cela est géré de manière uniforme via la macro %__os_install_post qui effectue cette tâche pour tous les fichiers dans %{buildroot}%{_prefix}, que les fichiers soient dans le même paquet ou sous-paquet. Uniquement ce répertoire est pris en compte car les fichiers en son sein sont en général en lecture seule ce qui évite les problèmes liées à l'édition ultérieure du contenu. Un autre aspect positif est une légère réduction de la taille de certains paquets et que différents utilitaires de recherche ou de sauvegarde des fichiers peuvent éviter de parcourir inutilement plusieurs fois le même contenu.

Les systèmes atomiques ne fournissent plus de bibliothèques et de binaires FUSE 2. Les paquets fuse et fuse-libs sont retirés de l'image de base pour permettre l'usage exclusif de FUSE 3, FUSE 2 n'étant plus maintenu. Ces paquets étaient maintenus depuis Fedora Linux 40 car le format AppImage s'en servait dans la première version de son format mais l'ajout d'une seconde version qui exploite FUSE 3 permet de s'en affranchir.

Pour les images Kinoite et Kinoite Mobile, cela signifie que les backends EncFS et CryFS ne sont plus accessibles, si vous êtes concernés vous pouvez les convertir avant ou alors installer les paquets fuse-encfs et cryfs avec rpm-ostree.

Cela ne concerne pas pour l'instant les autres versions de Fedora Linux qui ont un usage plus général et qui peuvent très facilement l'installer en cas de besoin pour ceux qui le souhaitent. Les systèmes atomiques sont quant à eux orientés pour des systèmes minimaux en lecture seule où cet utilitaire n'est plus indispensable par défaut comme expliqué.

Ces systèmes bureautiques atomiques ne prennent plus en charge les règles obsolètes pkla polkit. Les autres systèmes atomiques de Fedora avaient déjà supprimé par défaut ces règles de leur image de base car c'est un format obsolète qui est d'ailleurs peu à peu retiré des autres distributions Linux telles qu'Ubuntu ou Debian.

Les variantes non atomiques ne sont pas concernées à ce stade pour la même raison que le changement précédent, d'autres paquets peuvent en dépendre ce qui rend la suppression totale définitive difficile à ce jour. Les systèmes atomiques n'ont plus de tels composants dans l'image de base ce qui permet une telle transition.

Packit remplace Fedora CI et Zuul pour démarrer les instances d'intégration continue pour compiler et exécuter les tests des paquets après un pull request. En effet le premier est développé par Red Hat et est plutôt bien maintenu avec plus de fonctionnalités que les seconds qui n'avaient pas assez de personnes pour s'en occuper et fournir une bonne stabilité. Cela permet de simplifier la gestion de cette partie de l'infrastructure en se concentrant sur l'intégration plutôt que le développement. Il offre par exemple la possibilité de ré-exécuter certains tests seulement ou d'utiliser des étiquettes associées à une tâche pour définir quels tests doivent être exécutés ou non, afin de gagner du temps lors du développement d'un paquet. Il fournit de fait une interface unique pouvant aller de dist-gist en passant par Koji et Bodhi pour ces différentes tâches. Il est également indépendant de la forge git employée grâce à une API unifiée. À ce jour Gitlab et Pagure sont gérées et Forgejo sera ajoutée plus tard, qui sera à priori la future forge logicielle de Fedora ce qui facilitera la transition à ce moment là.

Koji ne prend plus en charge le service distant Red Hat Image Builder Service, uniquement les instances locales peuvent être utilisées. En effet depuis la version précédente de Fedora Linux, toutes les images peuvent être produites localement. Fedora IoT et Minimal étaient construites via l'infrastructure Red Hat Image Builder, Koji ne servant que d'orchestrateur côté Fedora. Cela posait quelques soucis dont la possibilité d'intervenir en cas de problèmes mais aussi le fait qu'il était impossible de geler les changements de l'infrastructure aux moments adéquats pour l'élaboration des nouvelles images. En plus de s'affranchir du service de Red Hat, cela autorise aussi de supprimer le plugin Koji qui permettait une telle opération. Il devient également possible de réallouer les ressources matérielles associées pour d'autres tâches.

Les labels des images pour conteneurs passent à org.opencontainers.image.title et org.opencontainers.image.licenses pour suivre la spécification OpenContainers. Cela simplifiera l'outillage pour récupérer cette information de manière générique en ayant une nomenclature standard pour toutes les images.

Par ailleurs CMake utilisera le générateur ninja au lieu de make par défaut pour compiler un projet. En effet CMake permet d'utiliser les deux en fonctions des préférences, avec la mise à niveau de CMake décrite plus haut, la prise en charge de ninja est encore meilleure ce qui le rend plus intéressant. Ninja est plus moderne et rapide pour effectuer la compilation d'un projet ce qui est intéressant pour le projet Fedora qui en compile beaucoup. Il prend également mieux en compte le concept récemment introduit des modules C++. C'était d'ailleurs déjà le choix effectué manuellement par certains paquets, maintenant tous les utilisateurs de la macro cmake en bénéficieront par défaut.

Les paquets autour du langage R ont de nouvelles macros et une meilleure uniformisation des bonnes pratiques pour simplifier leur maintenance. Cela représente 400 paquets dans la distribution qui avaient jusqu'ici une gestion assez artisanale et demandait beaucoup de temps pour gérer des situations similaires. De nouvelles macros dédiées ont été ajoutées dans R-rpm-macros tandis que les macros R-srpm-macros ont été ajoutées à la config globale redhat-rpm-config pour permettre leur réutilisation.

Ces macros simplifient beaucoup la maintenance, maintenant la génération de la version et des URLs des projets empaquetés sont gérés de manière uniforme. De même, la procédure d'installation et de la vérification des fichiers est faite de manière identique. Enfin, cela permet de rendre ces paquets reproductibles également.

La communauté francophone

L'association

Borsalinux-fr est l'association qui gère la promotion de Fedora dans l'espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l'association.

Nous lançons donc un appel à nous rejoindre afin de nous aider.

L'association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l'ensemble des évènements majeurs concernant le libre à travers la France principalement.

Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :

• Adhérer à l'association : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
• Participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l'association sur différents évènements francophones ;
• Concevoir des goodies ;
• Organiser des évènements type Rencontres Fedora dans votre ville.

Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution, même minime, est appréciée.

Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions mensuelles chaque premier lundi soir du mois à 20h30 (heure de Paris). Pour plus de convivialité, nous l'avons mis en place en visioconférence sur Jitsi.

La documentation

Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les 5 années de retard accumulées sur le sujet.

Le moins que l'on puisse dire, c'est que le travail abattu est important : près de 90 articles corrigés et remis au goût du jour.
Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège, Sylvain Réault et les autres contributeurs et relecteurs pour leurs contributions.

La synchronisation du travail se passe sur le forum.

Si vous avez des idées d'articles ou de corrections à effectuer, que vous avez une compétence technique à retransmettre, n'hésitez pas à participer.

Comment se procurer Fedora Linux 44 ?

Si vous avez déjà Fedora Linux 43 ou 42 sur votre machine, vous pouvez faire une mise à niveau vers Fedora Linux 44. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Autrement, pas de panique, vous pouvez télécharger Fedora Linux avant de procéder à son installation. La procédure ne prend que quelques minutes.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

De plus, pour éviter les mauvaises surprises, nous vous recommandons aussi de lire au préalable les bogues importants connus à ce jour pour Fedora Linux 44.

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
• DLSS, FSR, XeSS, Reflex, Anti-Lag
• DLSS 5
• Implémentation par moteurs
• Impact sur les performances
• Impact sur le développement
• De nouveaux venus (Moore Threads, Lisuan Technology)
• Et les performances dans tout ça

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.

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 :

• La documentation de Godot sur l’illumination globale (sondes de réflexion)
• La documentation de Godot sur les effets de rendu
• La documentation de Godot sur l’anticrénelage
• Un article de PC Gamer sur l’occlusion ambiante
• The state-of-art of Dynamic Global Illumination in video-games (En)

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.

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.

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 !

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.

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.

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 ?

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

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 épeingle 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 impacte é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.

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.

É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

• Site de l'événement : https://educalibre.eu
• Formulaire de proposition : https://propositions.educalibre.eu
• Liste de discussion organisatrice : https://chahut.domainepublic.net/mailman3/postorius/lists/org.educalibre.eu/
• Contact : org@educalibre.eu
• Visio hebdomadaire d'organisation : https://visio.educalibre.eu tous les lundis à 21h

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