DevNews

Nouveau ouvre les canaux NVDEC et débloque Vulkan Video

Sur cette page
  1. Le trou que cela comble
  2. Ce que Vulkan Video apporte face aux solutions existantes
  3. Les attentes à garder mesurées
  4. Pourquoi cela compte quand même
  5. Sources et pour aller plus loin

Un petit correctif noyau pour Nouveau, signé David Airlie de Red Hat, est en attente dans drm-misc-next pour la fenêtre de fusion de Linux 7.3, et il fait une chose précise : il autorise l'allocation de canaux NVDEC via l'interface ABI16. C'est la pièce manquante dont le pilote NVK de Mesa avait besoin pour annoncer Vulkan Video, à commencer par le décodage H.264 sur les GPU Turing et plus récents. Trois lignes de description pour un changement qui comble un vrai trou dans la pile graphique NVIDIA entièrement libre, où le décodage vidéo matériel imposait jusqu'ici d'abandonner Mesa.

The short answer

Un correctif Nouveau de David Airlie, chez Red Hat, préparé dans drm-misc-next pour la fenêtre de fusion de Linux 7.3, autorise l'allocation de canaux NVDEC via l'interface ABI16. NVDEC est le moteur de décodage vidéo à fonction fixe des GPU NVIDIA, et ce chemin d'allocation est ce dont le pilote Vulkan NVK de Mesa a besoin pour exposer Vulkan Video. NVK annoncera d'abord le décodage H.264. Les travaux H.265 existent mais bloquent aujourd'hui le GSP. Le support exige un GPU de génération Turing ou plus récent, puisque l'implémentation dépend du firmware GSP.

Linux 7.3noyau visé, fenêtre de fusion fin août
Turing+couverture GPU, le chemin dépend du firmware GSP
H.264le codec que NVK annonce en premier en Vulkan Video
Carte réponse : un correctif Nouveau de David Airlie prévu pour Linux 7.3 autorise l'allocation de canaux NVDEC via ABI16, ce qui permet au pilote NVK de Mesa d'annoncer le décodage H.264 en Vulkan Video sur les GPU NVIDIA Turing et plus récents.
Le changement en une carte. Source : la couverture Phoronix du 31 juillet 2026 sur la préparation dans drm-misc-next. PNG

La plupart des correctifs noyau dont il vaut la peine de parler sont volumineux. Celui ci ne l'est pas, et c'est précisément ce qui le rend intéressant : un unique chemin d'allocation manquant bloquait toute une classe de fonctionnalités côté espace utilisateur.

Le trou que cela comble

La pile graphique NVIDIA libre sous Linux a deux moitiés. Nouveau vit dans le noyau et possède le matériel. NVK vit dans Mesa et implémente Vulkan par dessus. Ces dernières années, ce duo est passé du statut de curiosité à celui de solution réellement utilisée, aidé énormément par le firmware GSP, qui permet à Nouveau de déléguer l'initialisation et la gestion des fréquences au microcontrôleur livré sur la carte plutôt que de le rétroconcevoir.

Le décodage vidéo était resté à l'écart de cette progression. NVDEC, le bloc de décodage à fonction fixe, dormait sur la puce du point de vue du pilote libre, faute d'un moyen supporté pour un pilote Vulkan d'obtenir un canal de soumission de commandes pointant dessus. Vous pouvez implémenter autant de la spécification Vulkan Video que vous voulez dans Mesa, cela ne sert à rien si le noyau refuse de vous donner un canal.

Le correctif d'Airlie fournit exactement cela, via ABI16, l'interface espace utilisateur la plus ancienne et la plus simple de Nouveau. Une fois en place, NVK peut allouer ce dont il a besoin et commencer à annoncer les extensions.

Figure terminal montrant des commandes d'exemple pour vérifier la prise en charge du décodage Vulkan Video sous Linux, avec vulkaninfo listant les extensions VK_KHR_video et annonçant NVK comme nom de pilote.
Commandes d'exemple pour vérifier si une file de décodage Vulkan Video est exposée. Sortie illustrative, pas une capture sur une machine équipée du nouveau correctif. PNG

Ce que Vulkan Video apporte face aux solutions existantes

Le décodage vidéo matériel sous Linux a longtemps signifié VA-API ou VDPAU, deux API distinctes avec leurs implémentations propres à chaque fabricant et leur travail d'intégration dans chaque lecteur et chaque navigateur. Vulkan Video place le décodage dans la même API, sur le même modèle de périphérique et de files que le rendu.

Pour qui écrit un compositeur, un lecteur multimédia ou un pipeline de rendu, cela supprime toute une couche d'interopérabilité. L'image décodée est déjà une image Vulkan sur le périphérique avec lequel vous dessinez, donc pas d'export, pas d'import, pas de négociation de format entre deux piles fabricant qui ne s'entendent pas sur le pavage. C'est ce point qui compte davantage que la liste des codecs. Le même argument pousse l'adoption de Vulkan Video dans les autres pilotes Mesa, sur la période même où RADV s'étend bien au delà de sa plateforme d'origine.

Les attentes à garder mesurées

Trois points méritent d'être clairs.

Le support de codecs est précoce. NVK annoncera du H.264. Le H.265 est en chantier et bloque actuellement le GSP, c'est à dire que le firmware cesse de répondre sur certaines charges de décodage et que la reprise exige une réinitialisation. C'est un problème d'interaction avec le firmware, pas une implémentation à terminer, et ce genre de sujet prend du temps.

La frontière matérielle est réelle. GSP signifie Turing et plus récent. Les cartes Pascal et antérieures n'y auront pas droit, et aucune mise à jour de noyau n'y changera rien.

Le calendrier est le classique calendrier en deux temps. Le côté noyau vise Linux 7.3, dont la fenêtre de fusion s'ouvre dans la seconde moitié d'août 2026, ce qui place la publication à l'automne. Le côté Mesa arrive à son propre rythme, et Mesa 26.2 intègre déjà des corrections Vulkan Video et des travaux de performance NVK dans ses versions candidates. Obtenir les deux moitiés en même temps suppose une distribution en publication continue ou une compilation maison, les autres attendront la prochaine mise à jour stable de distribution. C'est le schéma que suit chaque fonctionnalité arrivant dans le cycle 7.3.

Pourquoi cela compte quand même

Il existe une version de l'histoire NVIDIA libre qui est vraie depuis longtemps : cela fonctionne pour le bureau, cela fonctionne pour le jeu moyennant un coût, puis vous tombez sur quelque chose que seul le pilote propriétaire sait faire et vous installez le pilote propriétaire. Le décodage vidéo matériel faisait partie de ces murs, et c'est un mur particulièrement agaçant parce qu'il frappe l'autonomie et la chauffe d'un portable plutôt que le nombre d'images par seconde, c'est à dire ce que l'on remarque sur les machines qui ne servent pas à jouer.

Un correctif ne supprime pas le mur. Il supprime la raison pour laquelle on ne pouvait pas travailler dessus. C'est en général ainsi que les choses avancent dans Nouveau, et cela vaut la peine d'être noté quand cela arrive.

Sources et pour aller plus loin

Questions fréquentes

Qu'ajoute réellement ce correctif ?

Il ajoute la possibilité d'allouer des canaux NVDEC via l'interface ABI16 de Nouveau. NVDEC est le moteur de décodage vidéo à fonction fixe des GPU NVIDIA, et un canal est le contexte de soumission de commandes dont un client a besoin pour lui envoyer du travail. Sans ce chemin d'allocation, l'espace utilisateur n'avait aucun moyen supporté de piloter le moteur de décodage via Nouveau, ce qui empêchait le pilote Vulkan NVK de Mesa d'exposer Vulkan Video, quelle que soit la complétude de sa propre implémentation. Le correctif est signé David Airlie, de Red Hat, et figure dans les patchs drm-misc-next préparés pour la fenêtre de fusion de Linux 7.3.

Quand cela arrive t il, et dans quel noyau ?

Dans Linux 7.3. Le correctif est dans drm-misc-next, la branche de préparation qui alimente la demande de fusion du sous système DRM, et la fenêtre de fusion de Linux 7.3 s'ouvre dans la seconde moitié d'août 2026. L'inclusion n'est jamais garantie tant que la demande n'est pas acceptée, mais drm-misc-next est le chemin habituel et ce qui y est préparé arrive en général à destination. Concrètement, cela place un noyau 7.3 publié à l'automne, et les noyaux de distribution qui l'embarquent plus tard encore, sauf distribution en publication continue ou compilation maison.

Quels GPU sont couverts ?

Turing et plus récents, parce que l'implémentation dépend du firmware GSP de NVIDIA. Le GPU System Processor est le microcontrôleur embarqué que les GPU NVIDIA utilisent depuis Turing pour gérer une large part de l'initialisation et de la gestion du matériel, et le chemin de support moderne de Nouveau est bâti autour du dialogue avec lui. Les cartes plus anciennes, Pascal et antérieures, n'ont pas de GSP et ne sont pas concernées par ces travaux. C'est la même frontière que pour le reclocking automatique dans Nouveau, donc quiconque a suivi cet épisode sait déjà de quel côté se trouve sa carte.

Que pourra décoder NVK une fois en place ?

Du H.264 pour commencer. Phoronix indique que NVK annoncera d'abord le décodage vidéo H.264 en Vulkan Video, les travaux H.265 étant en cours mais bloquant actuellement le GSP, formule polie pour dire que le firmware cesse de répondre et que le GPU doit être réinitialisé. C'est un état normal pour des travaux d'accélération vidéo débutants, et non une raison d'espérer une correction rapide. L'attente réaliste est H.264 d'abord, H.265 ensuite, AV1 plus loin encore, sur un calendrier fixé par les versions de Mesa plutôt que par le noyau.

Est ce utile si nous utilisons déjà le pilote propriétaire ?

Non. La pile propriétaire de NVIDIA expose le décodage matériel depuis des années via ses propres interfaces, et rien ne change pour ces installations. Le public de ces travaux est celui du chemin entièrement libre : Nouveau côté noyau et NVK côté Mesa, c'est à dire le comportement par défaut des distributions qui n'embarquent pas de modules hors arbre, et la seule option pour qui a besoin d'un noyau librement recompilable. Sur ce chemin, le décodage vidéo matériel était un vrai manque, et le combler retire l'une des dernières raisons pratiques d'installer le pilote propriétaire sur un poste qui sert surtout à lire des vidéos.