Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierinformatique général
  • ✇LinuxFr.org : les dépêches
  • Le pilote open-source Vulkan pour AMD “RADV” de chez Mesa bientôt disponible sous Windows ?
    Nous en avions parlé en mars dans l’article « AMD mise tout sur RADV » : Maintenant qu’AMD a remplacé son pilote graphique AMDVLK sous Linux par le pilote RADV de chez Mesa, il est techniquement possible de faire de même sous Windows, unifiant les solutions graphiques sur un pilote libre quel que soit le système… RADV est le pilote graphique libre fournissant la prise en charge de l’accélération 3D via Vulkan sous Linux. Il est développé communautairement chez Mesa. Et cette fois-ci, c’est Val

Le pilote open-source Vulkan pour AMD “RADV” de chez Mesa bientôt disponible sous Windows ?

Nous en avions parlé en mars dans l’article « AMD mise tout sur RADV » : Maintenant qu’AMD a remplacé son pilote graphique AMDVLK sous Linux par le pilote RADV de chez Mesa, il est techniquement possible de faire de même sous Windows, unifiant les solutions graphiques sur un pilote libre quel que soit le système…

RADV est le pilote graphique libre fournissant la prise en charge de l’accélération 3D via Vulkan sous Linux. Il est développé communautairement chez Mesa.

Et cette fois-ci, c’est Valve qui mise tout sur RADV : l’éditeur de la plate-forme de jeu vidéo Steam finance des travaux explorant la faisabilité de RADV sous Windows !

Logo LinuxFr automnal près de la puce NAVI 31 XT sur une carte Radeon RX 7900 XT
L’automne arrive, mettons nos cartes graphiques AMD bien au chaud auprès de nos pilotes libres…

Cette dépêche est aussi l’occasion de détailler l’implication de Valve dans Mesa ainsi que la présence grandissante de Mesa dans le marché des pilotes graphiques, qui s’étend désormais bien au-delà de Linux !

Sommaire

Pour simplifier la rédaction et la lecture, cette dépêche fait le choix éditorial d’appeler « pilote graphique » un pilote qui implémente des interfaces de programmation graphique (Vulkan, DirectX, OpenGL, etc.), et pas seulement un pilote impliqué dans le pilotage d’une carte graphique. Ainsi l’expression « pilote graphique » est utilisée pour être distinguée du « pilote noyau » (ou KMD, Kernel Mode Driver) qui s’interface directement avec le matériel mais ne fournit pas d’interface de programmation graphique comme Vulkan et les autres.

Vulkan, la solution graphique multiplateforme

Vulkan est une API graphique multiplateforme utilisée pour accélérer des applications graphiques comme des jeux vidéo, les effets de composition de votre bureau, des applications de rendu 3D comme Blender, ou encore pour accélérer le calcul (Vulkan compute peut faire tourner des moteurs de LLM sur votre machine, par exemple).

RADV, le pilote Vulkan libre pour carte AMD de chez Mesa

À l’origine, le pilote Vulkan maison de chez AMD était AMDVLK, il était utilisé sous Linux et sous Windows. Initialement propriétaire, la version Linux avait été ensuite libérée.

Mais si vous utilisez Vulkan sous Linux, vous utilisez RADV, pas AMDVLK. Que s’est-il donc passé ?

RADV, le pilote qui s’impatientait d’AMD

En 2016, s’impatientant de cette libération promise qui ne venait pas encore, David Airlie — contributeur à Mesa — avait initié avec Bas Nieuwenhuizen le projet RADV, un compétiteur pour AMDVLK. Phoronix décrivait la situation ainsi en 2016 :

Plusieurs mois avant même la publication officielle de la spécification Vulkan, AMD avait annoncé qu’ils lanceraient dans un premier temps un pilote Linux Vulkan à code source fermé, qui serait ensuite ouvert. Plus de six mois se sont écoulés depuis la sortie de Vulkan 1.0, mais ce pilote Linux Vulkan n'a toujours pas été libéré, et AMD n'a pas non plus indiqué quand cette mise à disposition du code pourrait effectivement avoir lieu.

En l'absence de pilote Radeon Vulkan open source, David Airlie et Bas Nieuwenhuizen ont entrepris de développer leur propre pilote Radeon Vulkan « communautaire », au moins à titre de solution provisoire et éventuellement pour faire pression sur AMD afin qu’ils publient leur pilote Vulkan officiel. Bas Nieuwenhuizen est un contributeur indépendant, tandis que David Airlie est le responsable du sous-système DRM et un développeur chez Red Hat qui participe depuis longtemps aux efforts de développement de pilotes Linux AMD/ATI open source.
-- https://www.phoronix.com/review/radeon-vulkan-radv (30/08/2016)

David avait écrit à l’époque sur son blog :

J'attendais qu'un pilote open source fasse son apparition quand je me suis rendu compte que je ferais mieux de le développer moi-même. Après en avoir discuté avec Bas, nous avons décidé de voir jusqu'où nous pouvions aller.
-- https://airlied.livejournal.com/81460.html (20/07/2016)

RADV vient de souffler sa 10ème bougie, et RADV a remplacé AMDVLK sous Linux et s’attaque désormais à Windows…

RADV, le pilote qui a déjà remplacé AMDVLK sous Linux

Comme rapporté dans la précédente dépêche « La pile graphique d’AMD sous Linux est désormais complètement libre », AMD avait annoncé le 21 mai 2025 que la version 25.10.1 de la suite Radeon Software for Linux serait la dernière à livrer des composants logiciels propriétaires. À l’époque AMD avait dit que « le pilote Vulkan de Mesa », (et donc, RADV) « sera officiellement pris en charge », et qu’ils abandonnaient les « pilotes OpenGL et Vulkan propriétaires ». On pouvait alors se demander ce qui adviendrait d’AMDVLK, si « le pilote propriétaire » devait s’entendre au sens de « le pilote à code fermé », ou dans le sens de « le pilote de chez AMD ».

L’histoire a montré que RADV a totalement remplacé AMDVLK sous Linux.

RADV à l’attaque de Windows

Grâce au travail préliminaire de Collabora et aux investissements de Valve pour poursuivre ces efforts, RADV pourrait bientôt être disponible sous Windows…

L’expérimentation de Faith Ekstrand

En juillet 2024 Faith Ekstrand avait proposé une requête de fusion à Mesa pour porter le pilote RADV sous Windows. Faith est un développeur de chez Collabora.

Quelques mois plus tard en octobre 2024 Faith Ekstrand avait présenté l’avancement de son travail lors de sa conférence « A little Windows with your Mesa » [pdf] lors de l’XDC (X.Org Developer's Conference). Une démonstration technique montrant une démo Vulkan tourner sous Windows 11 avec RADV avait été présentée.

Il s’agissait donc de faire fonctionner RADV sur WDDM (Windows Driver Display Model) au lieu du DRM (Direct Rendering Manager) de Linux.

Ce n’était qu’une démonstration, le code n’a jamais été fusionné dans Mesa, et la discussion n’avait pas bougé depuis. Cela prouvait pourtant que oui, cela était tout à fait faisable, et que si AMD le souhaitait, il leur suffisait de contracter avec Collabora.

La confirmation de Louis-Francis Ratté-Boulianne

C’est ce que vient de faire… non pas AMD, mais Valve, l’éditeur de la plate-forme de jeu vidéo Steam.

Comme le rapporte Phoronix :

Valve finance des ingénieurs de Collabora pour mener des travaux exploratoires préliminaires visant à porter le pilote open source Radeon Vulkan « RADV » sous Microsoft Windows.
-- https://www.phoronix.com/news/Valve-Sponsors-RADV-Windows (29/07/2026)

Le développeur Louis-Francis Ratté-Boulianne a rendu public ces travaux préliminaires dans un article sur le blog de Collabora intitulé « Cracking Windows Open: Porting RADV to WIN32 », Ouvrir une brèche vers Windows : porter RADV sur WIN32.

Louis-Francis précise que cette nouvelle expérimentation est fondée sur le travail déjà réalisé par Faith en 2024. Le projet est désormais à un niveau d’avancement élevé : le jeu Counter-Strike 2 (distribué, édité et développé par Valve) tourne déjà !

Une alternative à Dozen

Dozen (aussi connu comme VulkanOn12 chez Microsoft) est un pilote Mesa implémentant Vulkan sur DX12 (DirectX 12). Il est donc déjà possible d’utiliser un pilote libre Vulkan sous Windows, mais il est moins avancé que RADV, et il requiert le pilote propriétaire DX12 de la carte graphique, donc ici le pilote d’AMD. RADV s’interface directement avec le pilote noyau AMD sans intermédiaire graphique, permettant de bénéficier de tous les avantages de RADV déjà disponible sous Linux, dès lors que ce pilote Windows implémente des interfaces compatibles, sans dépendre des interfaces DX12 (contrôlées par Microsoft) ou du niveau d’implémentation du pilote DX12 d’AMD.

Le niveau de libération de la pile Vulkan sur AMD sous Windows peut donc être comparé ainsi :

Implémentation RADV Dozen AMDVLK
Vulkan libre libre propriétaire
Intermédiaire (DX12) propriétaire
Pilote noyau (KMD) propriétaire propriétaire propriétaire

L’implication de Valve dans RADV et Mesa

David Airlie et Bas Nieuwenhuizen ne sont pas les seules personnes ayant travaillé ou travaillant sur RADV, Samuel Pitoiset en est aussi un développeur incontournable. Samuel Pitoiset a été embauché par Valve en 2015 et est membre de la « Valve Linux driver team ». Samuel était en 2024 et en 2025 le plus gros contributeur Mesa (7.87% des commits de l’année en 2024, 6.78% en 2025).

Samuel participe aussi au développement d’ACO (Amd COmpiler), le compilateur de shader (code qui s’exécute sur la carte graphique. Principalement développé par Daniel Schürmann, le compilateur ACO a remplacé LLVM dans RADV (pilote Vulkan), et petit-à-petit, a aussi remplacé LLVM dans RadeonSI (pilote OpenGL) et dans RustiCL (pilote OpenCL). Daniel a été recruté par Valve en 2019.

Valve est un contributeur majeur de Mesa, finançant le travail de très nombreux développeurs. Il est difficile de suivre la carrière de chacun mais voici rassemblées quelques informations glanées ici ou là :

Contributeur Mesa Relation avec Valve Période documentée Spécialité Références
Samuel Pitoiset Emploi 2016 → aujourd’hui RADV, ACO, NIR 1 2 3
Andres Rodriguez Emploi au moins 2016 RADV, RadeonSI, AMDGPU, DRM 1 2 3
Keith Packard Contrat (Indépendant) au moins 2017 → 2018 RADV, ANV, DRM, affichage 1 2
Pierre-Loup Griffais Emploi au moins 2017 → aujourd’hui RADV, Vulkan, Proton, Steam 1 2 3
Timothy Arceri Emploi 2017 → période ultérieure RadeonSI, GLSL, OpenGL 1 2
Connor Abbott Emploi 2017 → période ultérieure NIR, compilation, RADV, Turnip 1 2 3
Daniel Schürmann Contrat (Indépendant) 2018 → au moins 2025 ACO, RADV, NIR 1 2 3
Tony Wasserka Emploi 2020 → au moins 2024 RADV, Vulkan 1 2
Martin Roukala Contrat (Indépendant) 2020 → aujourd’hui Mesa CI, tests, infrastructure 1 2 3
Hans-Kristian Arntzen Contrat (Indépendant) au moins 2020 → aujourd’hui RADV, Vulkan, VKD3D-Proton 1 2 3
Andrés Gómez Sous-traitance (Igalia) au moins 2020 → au moins 2021 Mesa CI, RADV, ANV, DXVK 1 2
Timur Kristóf Contrat (Indépendant) au moins 2021 → aujourd’hui RADV, ACO, NIR 1 2
Natalie Vock Contrat (Indépendant) 2022 → aujourd’hui RADV, ACO, NIR, ray tracing 1 2 3 4
Charlie Turner Sous-traitance (Igalia) au moins 2022 Mesa CI, tests, RADV, ANV 1 2
Dhruv Mark Collins Sous-traitance (Igalia) 2022 → aujourd’hui Turnip, Adreno, Vulkan 1 2
Robin Kertels Contrat (Indépendant) au moins 2022 → aujourd’hui KosmicKrisp, Vulkan, DXVK 1 2 3
Alyssa Rosenzweig Contrat (Indépendant) 2023 → 2024 Panfrost, PanVK, AGX, NIR, compilation 1 2 3 4
Rhys Perry Contrat (Indépendant) au moins 2024 → 2026 RADV, ACO, NIR, ray tracing 1 2 3
Mike Blumenkrantz Contrat (Indépendant) au moins 2024 → aujourd’hui Zink, RADV, Vulkan, infrastructure 1 2 3
Anna Maniscalco Emploi au moins 2024 → aujourd’hui Turnip, Vulkan, Adreno 1 2 3
Mary Guillemard Contrat (Indépendant) 2025 → aujourd’hui NVK, Vulkan, pilotes NVIDIA 1
Thomas Andersen Contrat (Indépendant) au moins 2025 → aujourd’hui NVK, Vulkan, NVIDIA 1 2
Danylo Piliaiev Sous-traitance (Igalia) au moins 2025 → aujourd’hui Turnip, Adreno, Vulkan 1
Job Noorman Sous-traitance (Igalia) au moins 2025 → aujourd’hui Turnip, NIR, compilateur 1
Autumn Ashton Emploi au moins 2025 → aujourd’hui NVK, RADV, Vulkan, DXVK, VKD3D-Proton 1 2 3
Marek Olšák Emploi 2026 → aujourd’hui RadeonSI, Gallium3D, RADV 1 2
Louis-Francis Ratté-Boulianne Sous-traitance (Collabora) au moins 2026 → aujourd’hui RADV, Vulkan, WDDM 1 2

La liste est très certainement incomplète, car d’autres personnes comme Louis-Francis Ratté-Boulianne peuvent travailler sur des missions de Valve sans travailler directement pour Valve. Ces personnes travaillent pour d’autres entités intermédiaires comme Collabora ou Igalia et les relations et le détail des missions ne sont pas forcément publiques ou faciles à trouver.

Dans cette table, la période documentée tente de retranscrire les périodes de contrat. Par exemple il est connu que Charlie Turner a travaillé pour Valve sur la CI (Intégration Continue) de Mesa en 2022 et nous savons aussi qu’il travaillait déjà sur ce même projet en 2021 sans qu’il soit évident si c’était déjà à la demande de Valve ou non.

Igalia et Collabora sont des sous-traitants et intégrateurs spécialisés dans le développement de solutions libres (pas seulement graphiques).

Mesa part conquérir le monde

Si un même pilote Vulkan peut fonctionner à la fois sur Linux et Windows, d’autres pilotes pour d’autres API ou d’autres matériels peuvent-ils suivre le même chemin ?

Et pour OpenGL sous Windows ?

Il est déjà possible d’utiliser une solution Mesa pour OpenGL sous Windows, grâce au pilote GLON12 développé par Microsoft chez Mesa. GLON12 convertit à la volée les appels OpenGL vers la solution propriétaire DirectX 12, et l’on peut déjà tester cette solution grâce à pal100 qui empaquette ces pilotes pour Windows. Cela dit, c’est fragile. La rédaction a testé, et les versions actuelles ont des bugs d’affichage assez sérieux (au moins avec le pilote propriétaire AMD sous-jacent), il faut remonter à 2024 pour avoir un rendu correct.

Il existe aussi chez Mesa le pilote Zink traduisant les appels OpenGL vers Vulkan, et donc jusqu’à maintenant, vers AMDVLK sous Windows. Mais si RADV devenait une solution sérieuse sous Windows, alors Mesa pourrait fournir OpenGL sous Windows en prenant en charge toute la pile d’exécution depuis OpenGL, s’arrêtant seulement à la limite du pilote noyau Windows, sans aucun logiciel intermédiaire tiers.

Et DirectX 12 dans tout ça ?

Là encore, RADV sous Windows permettrait aussi d’utiliser une solution libre pour DirectX ! Il existe plusieurs pilotes DirectX écrits pour convertir les appels Direct3D vers Vulkan initialement développés pour être exécutés dans Wine ou Proton sous Linux. Ces pilotes DirectX sont donc déjà écrits pour tourner dans un environnement Windows. Bien qu’ils soient moins testés sur un véritable Windows que dans un environnement Wine, ils existent. RADV serait la dernière brique pour court-circuiter entièrement les pilotes propriétaires graphiques sous Windows.

La couche la plus basse, le pilote noyau AMD, resterait propriétaire.

Tout ce qui tourne sur RADV

Voici ce qui est déjà faisable sous Linux, et ce qui serait bientôt réalisable sous Windows :

API Solution possible Windows (aussi possible sous Linux)
Vulkan RADV
OpenGL Zink sur RADV
Direct3D 12 vkd3d sur RADV
Direct3D 9 à 11 DXVK sur RADV
Direct3D 8 D3D8-to-D3D9 sur DXVK sur RADV
OpenCL RustiCL Zink sur RADV

Pour OpenGL et OpenCL utiliser Zink sur RADV n’est pas la solution recommandée sous Linux (mieux vaut utiliser RadeonSI et RustiCL), mais techniquement ça marche, c’est pourquoi on sait que ça pourrait aussi marcher sous Windows.

Donc grâce à Zink, Mesa pourrait fournir OpenGL sur les systèmes qui auraient RADV mais pas RadeonSI. De même pour OpenCL.

Voici un tableau plus général des opportunités que propose ou pourrait proposer l’écosystème libre (si RADV sur Windows devient viable) :

API Solution recommandée Linux Solution possible Windows et Linux Autre solution possible Windows
Vulkan Mesa RADV Mesa RADV Mesa Dozen (VulkanOn12)
OpenGL Mesa Gallium3D avec Mesa RadeonSI Mesa Zink sur Mesa RADV Mesa GLON12 (OpenGLOn12)
Direct3D 12 vkd3d sur Mesa RADV vkd3d sur Mesa RADV vkd3d sur Mesa Dozen
Direct3D 9 à 11 DXVK sur Mesa RADV DXVK sur Mesa RADV DXVK sur Mesa Dozen
Direct3D 8 D3D8-to-D3D9 sur DXVK sur Mesa RADV D3D8-to-D3D9 sur DXVK sur Mesa RADV D3D8-to-D3D9 sur DXVK sur Mesa Dozen
OpenCL Mesa RustiCL avec Mesa RadeonSI Mesa RustiCL avec Mesa Zink sur Mesa RADV Microsoft OpenCLOn12 avec Mesa CLOn12Compiler

Et pour Vulkan sur macOS ?

Valve est d’abord une plate-forme de vente de jeux vidéo. Ce qui leur importe le plus, c’est que vous puissiez leur acheter des jeux (développés par eux ou par n’importe qui). À ce titre, il importe à Valve que le maximum de jeux fonctionne sur votre machine, quelle que soit votre machine. Valve peut donc, si nécessaire, décider de fournir à ses utilisateurs ses propres pilotes, distribués avec Steam.

En participant au développement de RADV sous Linux et Windows, Valve se donne le pouvoir de contrôler la qualité de la pile logicielle d’exécution des jeux qu’ils vendent, jusqu’au pilote graphique inclus.

Pour macOS, la solution n’est pas à voir du côté de RADV (les derniers macs n’ont plus de cartes graphiques AMD de toute façon), mais du côté de MolktenVK et KosmicKrisp, des pilotes libres convertissant les appels Vulkan vers l’API Metal de macOS.

Sur macOS Vulkan est déjà disponible grâce à MoltenVK, une implémentation propriétaire traduisant Vulkan pour l’API Metal de macOS. Valve a investi dans MoltenVK. Cela permet par exemple à Valve de faire tourner leur jeu Dota2 sur macOS et pouvoir continuer à le vendre aux utilisateurs de macOS sans se soucier de l’obsolétisation d’OpenGL sur macOS par Apple. Valve avait poussé à ce que MoltenVK soit libéré, ce qui fut fait en 2018 grâce à un travail conjoint de Valve, de The Brenwill Workshop (la société à l’origine de MoltenVK), LunarG et Khronos. LunarG est un autre sous-traitant spécialisé dans les solutions graphiques et Vulkan libres. Khronos est le consortium à but non lucratif définissant le standard Vulkan. Le code source de MoltenVK est hébergé par Khronos directement.

KosmicKrisp est lui un pilote Mesa qui fait de même (convertir Vulkan vers Metal) mais de façon intimement spécialisée pour les puces AGX que l’on trouve dans les ordinateurs Apple M1, M2, etc. (aussi appelé « Apple Silicon »).

Et pour Intel et Nvidia sous Linux et Windows ?

Pour les utilisateurs Linux utilisant une carte Intel ou Nvidia, il y a déjà chez Mesa le pilote Vulkan officiel ANV développé par Intel, et le pilote expérimental NVK pour Nvidia. Il y a des connexions : Faith Ekstrand avait initié NVK chez Collabora et Collabora est connu pour travailler avec Valve… RADV pour AMD avait été initié en réutilisant du code d’ANV d’Intel… Tout cet écosystème est tissé de liens profonds que ce soit en termes de relations personnelles ou de mutualisation de code.

Pour les utilisateurs Windows utilisant une carte Intel ou Nvidia, rien n’est à l’horizon du côté de chez Mesa, excepté Dozen. Il faut donc utiliser les pilotes graphiques propriétaires de chez Intel et Nvidia (que ce soit le pilote Vulkan propriétaire directement, ou le pilote DX12 propriétaire comme sous-couche à Dozen). La situation est donc pour le moment la même qu’avec AMD sous Windows jusqu’à ce que RADV devienne utilisable pour le grand public.

Mesa prend le contrôle des pilotes Vulkan

Si on se concentre uniquement sur l’API Vulkan, voici ce que pourrait proposer l’écosystème libre dans un futur proche :

Système Matériel AMD Matériel Intel Matériel Nvidia Matériel Apple
Linux Mesa RADV Mesa ANV Mesa NVK Mesa Asahi
Windows Mesa RADV Mesa Dozen Mesa Dozen
macOS Khronos MoltenVK Khronos MoltenVK Khronos MoltenVK Mesa KosmicKrisp

C’est une très bonne nouvelle. Vulkan avait été conçue pour devenir « l’API graphique universelle », sauf qu’au final le marché était resté très divisé : DX12 sur Windows, Metal sur macOS, Vulkan ailleurs (et ne parlons même pas des consoles…). La présence de Vulkan sous Windows dépendant entièrement du bon-vouloir des fabricants de carte graphiques, et ni Apple ni les fabricants de carte graphiques n’ont jamais développé un pilote Vulkan pour macOS…

Pour un distributeur de jeu vidéo comme Valve c’est excellent : ça signifie que si nécessaire, le jeu peut être distribué avec RADV sur Windows et Linux pour les utilisateurs de cartes graphiques AMD, et MoltenVK ou KosmicKrisp sur macOS afin de fournir une expérience Vulkan finement contrôlée, et autres combinaisons sus-mentionnées. Cela permet de contrôler et donc d’assurer au maximum la compatibilité d’un jeu.

Pour les développeurs et éditeurs de jeu, le bénéfice est le même. Si nécessaire, il devient possible d’indiquer au distributeur un pilote libre à intégrer avec le jeu.

Pour le joueur, il peut utiliser lui-même une autre option s’il la préfère ou en a besoin.

Ainsi, que ce soit avec des solutions propriétaires ou libre, Vulkan est déjà disponible quasiment partout, et le devient désormais encore plus souvent sous forme de pilote libre, grâce à Khronos et Mesa.

  • Dis Mesa, tu veux faire quoi cette nuit ?
  • La même chose que chaque nuit, Vulkan, tenter de conquérir le MONDE !

Commentaires : voir le flux Atom ouvrir dans le navigateur

  • ✇Korben
  • ffmpeg - Doubler le framerate d'une vidéo avec votre GeForce
    Depuis ce week-end, bonne nouvelle les zamis, puisque ce bon vieux ffmpeg sait maintenant fabriquer des images qui n'ont jamais été filmées. Oui oui ! Et ça c'est possible grâce à un filtre qui s'appelle fruc_vulkan, qui permet de calculer le mouvement entre deux images grâce au bloc dédié des GeForce RTX, pour ensuite synthétiser ce qui manque entre les deux. Grâce à ça, un 24 images par seconde ressort sans souci en version 60 images par seconde. La cadence de sortie se paramètre, donc vous po

ffmpeg - Doubler le framerate d'une vidéo avec votre GeForce

Par : Korben ✨
1 septembre 2026 à 14:00

Depuis ce week-end, bonne nouvelle les zamis, puisque ce bon vieux ffmpeg sait maintenant fabriquer des images qui n'ont jamais été filmées. Oui oui ! Et ça c'est possible grâce à un filtre qui s'appelle fruc_vulkan, qui permet de calculer le mouvement entre deux images grâce au bloc dédié des GeForce RTX, pour ensuite synthétiser ce qui manque entre les deux. Grâce à ça, un 24 images par seconde ressort sans souci en version 60 images par seconde.

La cadence de sortie se paramètre, donc vous pouvez aussi faire du 25 vers du 50, du 30 vers 60, ou n'importe quelle valeur intermédiaire. C'est donc beaucoup plus souple que le filtre équivalent côté AMD, frc_amf, qui ne sait que doubler la fréquence et ne fonctionner qu'en DirectX...

Fabriquer ce genre d'images intercalaires n'a rien de neuf, cela dit... L'outil RIFE convertissait déjà du 24 fps en 96 en 2020. Mais ce qui change ici, c'est qu'il n'y a plus de chaîne externe, plus d'aller-retour par des milliers de PNG, puisque tout tient dans le graphe de filtres, entre le décodage et l'encodage.

Le filtre logiciel historique de ffmpeg, minterpolate, existe pourtant depuis des années mais c'était loin d'être du temps réel. Alors que là, le vrai gain avec cette nouvelle feature, c'est qu'on passe en full temps réel. Ça veut dire que sur un catalogue à réencoder, l'interpolation cesse d'être l'élément qui bloque toute la chaîne de conversion.

Pour l'essayer il vous faut une RTX 30 ou plus récente. Il faut aussi compiler une version de développement car ce filtre est arrivé après la sortie de ffmpeg 9.0, ce qui veut dire que pour le moment, il n'est dans aucune release et ne sera dans aucun paquet avant la prochaine.

La commande suit ensuite le motif habituel des filtres Vulkan, qui veulent les images en mémoire GPU :

ffmpeg -init_hw_device vulkan=vk:0 -filter_hw_device vk -i entree.mp4 -vf "format=yuv420p,hwupload,fruc_vulkan=fps=60,hwdownload,format=yuv420p" sortie.mp4

L'auteur du filtre prévient quand même qu'en 2160p24, les réglages par défaut ne suivront pas en temps réel et qu'il faudra alors descendre la qualité d'estimation du mouvement. Ça s'écrit comme ceci :

fruc_vulkan=fps=60:perf=medium:grid=2

En traitement par lots maintenant, la question ne se pose pas, c'est juste plus lent.

Maintenant, les pros de l'encodage, redescendez de votre chaise parce que j'ai quand même quelques mauvaises nouvelles... Tout d'abord, on n'a aucune stat indépendante sur le débit ou la qualité. Et il y a aussi un défaut que l'auteur du patch documente lui-même... En fait, dans les zones sans texture, le moteur invente un mouvement faux mais cohérent, qui laisse des "fantômes" autour des objets. La parade existe heureusement, mais c'est une heuristique, qui demande quelques réglages à la main sur des échantillons.

Et il y a aussi un coût qu'on oublie... Car doubler la cadence, c'est donner deux fois plus d'images à avaler à l'encodeur, donc, il y a toujours une espèce de goulot d'étranglement. Et puis après il y a le rendu... un film de cinéma en 24 images par seconde qu'on monte à 60 prend immédiatement un aspect téléfilm que les cinéastes détestent !! Imaginez l'Odyssée de Nolan avec l'aspect visuel de Plus Belle La Vie... Ahahaha. Après sur de l'animation ou un ralenti, ça se défend bien sûr mais sur du cinéma, c'est un choix à prendre et pas une amélioration. En tout cas, c'est mon avis.

Ah et dernier point, parce que la confusion est déjà partout dans les commentaires sur le net : Tout ça se passe à l'encodage ! Je répète : A L'ENCODAGE ! Le fichier qui sort de ffmpeg est une vidéo NORMALE. Absolument personne n'aura besoin d'une carte graphique GeForce pour la regarder ! OK ? 😘

Source : Phoronix

  • ✇Korben
  • Wine 11.0 est là - NTSYNC, WoW64 et des perfs en hausse pour le jeu sous Linux
    Bon, les amis linuxiens (et ceux qui n'ont pas encore sauté le pas), asseyez-vous confortablement sur votre tabouret parce que Wine 11.0 vient de pointer le bout de son nez et c'est du lourd. Si vous pensiez que le projet s'essoufflait, détrompez-vous puisque après un un an de boulot, plus de 6 000 changements et 600 bugs corrigés, c'est pas juste une petite mise à jour de routine, c'est une sacrée étape ! Je commence direct, le gros morceau qui va faire plaisir aux gamers, c'est l'intégration d

Wine 11.0 est là - NTSYNC, WoW64 et des perfs en hausse pour le jeu sous Linux

Par : Korben
14 janvier 2026 à 07:45

Bon, les amis linuxiens (et ceux qui n'ont pas encore sauté le pas), asseyez-vous confortablement sur votre tabouret parce que Wine 11.0 vient de pointer le bout de son nez et c'est du lourd. Si vous pensiez que le projet s'essoufflait, détrompez-vous puisque après un un an de boulot, plus de 6 000 changements et 600 bugs corrigés, c'est pas juste une petite mise à jour de routine, c'est une sacrée étape !

Je commence direct, le gros morceau qui va faire plaisir aux gamers, c'est l'intégration de NTSYNC. Pour faire simple, c'est un module noyau Linux (qui devrait arriver avec le noyau 6.14) qui permet de gérer la synchronisation entre les processus de façon beaucoup plus efficace. Concrètement, ça veut dire que les jeux Windows qui tournent sur Linux vont arrêter de galérer sur les accès concurrents et gagner en fluidité. On est sur du gain de performance pur et dur.

L'autre révolution sous le capot, c'est la finalisation de l'architecture WoW64. Si vous vous souvenez, on en parlait déjà dans les versions précédentes comme d'une expérimentation, mais là c'est bon, c'est prêt. Ça permet de faire tourner des applications 32 bits (et même du 16 bits pour les nostalgiques) dans des préfixes 64 bits de manière totalement propre. Adieu le binaire wine64 séparé, maintenant on a un seul exécutable unifié qui gère tout. C'est plus propre, plus stable et ça simplifie vachement la vie.

Côté graphisme, Wine 11.0 passe à Vulkan 1.4.335 et apporte enfin le décodage matériel H.264 via les API Direct3D 11 sur Vulkan Video. En gros, vos vidéos et vos jeux vont moins pomper sur le CPU. Le pilote Wayland continue aussi de s'améliorer avec une meilleure gestion du presse-papier et des méthodes de saisie.

On sent que le futur sans X11 approche à grands pas...

Et pour ceux qui aiment brancher tout et n'importe quoi sur leur bécane, il y a du nouveau côté Bluetooth. On a maintenant un support initial pour le scan des appareils, la découverte et même l'appairage basique sur Linux via BlueZ. C'est encore le début, mais pouvoir connecter sa manette ou son casque sans bidouiller pendant trois heures, c'est ça l'objectif. Les joysticks et les volants à retour de force ont aussi eu droit à leur petit coup de polish pour une meilleure précision.

Ça me rappelle forcément la sortie de Wine 10.0 l'année dernière qui avait déjà posé de grosses bases, sans oublier que Win32 est devenu la couche de compatibilité la plus stable sur Linux !

On notera aussi que le support de TWAIN 2.0 pour le scan 64 bits est de la partie, tout comme des améliorations sur MSHTML pour le rendu web et même le support de Ping pour l'ICMPv6. Bref, c'est une version hyper complète qui prouve une fois de plus que le pont entre Windows et Linux est de plus en plus solide.

Voilà, si vous voulez tester tout ça, c'est dispo dès maintenant sur le site officiel. Comme d'hab, il faudra peut-être attendre quelques jours pour que ça arrive dans les dépôts de votre distrib préférée, mais ça vaut le coup d'œil.

Source

  • ✇Korben
  • Pour jouer à vos vieux jeux Windows, il faut quitter Windows
    Ça vous dirait de vous refaire le Counter-Strike original, Deus Ex, ou Hitman Codename 47 ? Oui, je suis un peu nostalgique aujourd’hui et c’est pour ça que je vous parle de ces classiques de l’an 2000. Mais bon, si on s’amuse à lancer ça comme ça, sur un Windows 11 flambant neuf, hop, ça risque de planter. Un écran noir, un erreur DirectX, une incompatibilité graphique… Snif… Tout ça parce que Windows 11 a abandonné la rétrocompatibilité avec DirectX 7… Alors si je vous disais qu’aujourd’hui, p

Pour jouer à vos vieux jeux Windows, il faut quitter Windows

Par : Korben
11 novembre 2025 à 09:00

Ça vous dirait de vous refaire le Counter-Strike original, Deus Ex, ou Hitman Codename 47 ?

Oui, je suis un peu nostalgique aujourd’hui et c’est pour ça que je vous parle de ces classiques de l’an 2000. Mais bon, si on s’amuse à lancer ça comme ça, sur un Windows 11 flambant neuf, hop, ça risque de planter. Un écran noir, un erreur DirectX, une incompatibilité graphique… Snif… Tout ça parce que Windows 11 a abandonné la rétrocompatibilité avec DirectX 7…

Alors si je vous disais qu’aujourd’hui, pour jouer à nos jeux Windows de l’ancien temps, il fallait quitter Windows ! Non, j’ai pas fumé la moquette de mes toilettes… A la place, je suis tombé sur D7VK , un projet qui vient de sortir et qui permet de faire tourner les vieux jeux Direct3D 7 sur Linux.

Comme je vous en parlais il y a quelques semaines, 90% des jeux Windows tournent maintenant sur Linux grâce à Proton et DXVK. Mais il restait un trou dans la raquette : les jeux Direct3D 7. Ces titres cultes sortis entre 2000 et 2004, quand l’API D3D7 dominait sur nos PC de gamers. Et je vous parle pas de quelques titres pourris non… je vous parle de plus de 400 jeux qui ont été mis au rebus à cause de ce problème. Counter-Strike original, FIFA 2001, Deus Ex, Unreal Tournament, Escape from Monkey Island, Arx Fatalis, Sacrifice, Disciples II. Toute une époque les amis !!

DXVK, c’est le projet open-source qui traduit DirectX vers Vulkan pour Linux. Il supporte D3D8, D3D9, D3D10, D3D11. Et Proton de Valve l’utilise pour faire tourner les jeux Windows sur le Steam Deck. Mais DXVK n’allait pas jusqu’à D3D7. C’est trop vieux, trop chiant à supporter, trop différent de D3D9. Donc ces jeux restaient coincés avec WineD3D, l’ancienne couche de compatibilité de Wine qui existe depuis 20 ans mais qui est lente de ouf.

Heureusement, WinterSnowfall, le dev derrière D7VK, a décidé de combler ce vide. Son projet est donc un spinoff de DXVK, spécialement conçu pour D3D7. Ainsi, au lieu de traduire directement D3D7 vers Vulkan, D7VK fait une traduction en deux étapes. D3D7 vers D3D9 (via le backend DXVK), puis D3D9 vers Vulkan. C’est une passe intermédiaire c’est vrai, mais ça permet de réutiliser tout le travail déjà fait sur DXVK.

L’auteur prévient d’ailleurs que c’est un bordel technique sans nom, car Direct3D 7 date d’une époque où les jeux mixaient plusieurs APIs graphiques. Certains utilisent D3D7 pour la 3D, mais DDraw ancien ou même GDI pour l’interface. Sachez que ces jeux-là ne marcheront jamais avec D7VK car c’est trop complexe. Et ne comptez pas non plus sur un support D3D6 ou plus ancien non plus car c’est pire !

Mais pour les jeux qui utilisent D3D7 proprement, ça marche très bien. Le dev mentionne même que depuis les derniers ajustements de perf, ça tourne bien. C’est pas parfait partout, mais ça marche bien quand même.

Et c’est pas juste une question de nostalgie, hein. C’est de la préservation ! Car dans 10 ans, si vous voulez rejouer à ces classiques, vous ferez quoi ? Vous installerez une VM Windows XP ? Vous croiserez les doigts pour que GOG ait patché le jeu pour les Windows moderne ? Ou vous bootez votre bon vieux Linux, vous installez D7VK, et hop, y’aura aucun problème ? La réponse, elle est vite répondue comme disait l’autre…

L’autre truc marrant, c’est que DXVK, sur certains jeux, performe MIEUX que DirectX natif sous Windows car la traduction vers Vulkan réduit l’overhead CPU dans des scénarios limités par le processeur. Donc non seulement Linux fait tourner vos vieux jeux Windows, mais parfois, il les fait tourner plus vite que Windows lui-même. C’est fou je sais.

Le PC Gaming Wiki liste les +400 titres D3D7. Beaucoup de truellewares sous licence , certes, mais y’a aussi des pépites comme Hitman Codename 47, le jeu qui a lancé la série ou encore Arx Fatalis, le dungeon crawler immersif d’Arkane Studios sorti bien avant Dishonored. Sans parler de Sacrifice, le RTS/action de Shiny Entertainment auquel personne n’a joué, je crois, mais qui est devenu culte.

Microsoft les a oubliés mais pas la communauté Linux qui les ressuscite ! Et ça c’est le seul miracle auquel je crois ! Et c’est pas fini car D7VK, c’est juste une brique. Proton continue d’évoluer, et le Steam Deck pousse le gaming Linux vers la démocratisation. Les développeurs commencent même à activer le support anti-cheat pour Linux. Bref, la compatibilité Linux grimpe en flèche, et les performances s’améliorent !

Pour installer D7VK, suffit de copier ddraw.dll à côté de l’executable du jeu, de configurer Wine pour override cette DLL, et c’est fini. Pas besoin de patcher le jeu, pas besoin de cracks, pas besoin d’autres bidouilles. Le jeu devrait tourner dans son état d’origine !

Source

❌
❌