Blender 6.0 pourrait dire adieu à OpenGL : Vulkan est désormais assez mûr pour prendre toute la place

Blender 6.0 sans OpenGL : pour l’instant, c’est une proposition, pas une décision

L’information vient directement des notes de réunion du module Viewport & EEVEE de Blender publiées le 5 octobre. Les développeurs y mentionnent une proposition interne visant à supprimer OpenGL dans Blender 6.0, dont la sortie est actuellement planifiée pour novembre 2027. Le point important est écrit noir sur blanc : aucune décision définitive n’a encore été prise. Le principal blocage identifié est le virtual texturing, une technologie dont l’implémentation future doit encore être suffisamment avancée avant que l’ancien backend puisse réellement être retiré.

Cette nuance est essentielle, parce que « Blender réfléchit à supprimer OpenGL » et « Blender abandonne OpenGL l’année prochaine » ne racontent pas tout à fait la même histoire. Le projet fonctionne avec des cycles de développement assez stricts et une fonction jugée trop risquée peut parfaitement être repoussée à une version ultérieure. Mais la discussion existe désormais officiellement, ce qui aurait semblé nettement plus improbable quelques années auparavant, lorsque Vulkan était encore une expérimentation que l’on activait essentiellement pour découvrir quel morceau du viewport allait clignoter en premier.

Vulkan n’est plus le backend expérimental caché dans les préférences

La raison pour laquelle Blender peut aujourd’hui envisager ce changement est relativement simple : Vulkan a énormément progressé. Blender 4.5 LTS avait déjà introduit un support Vulkan complet, tandis que Blender 5.0 l’a encore renforcé avec, entre autres, des temps de compilation des matériaux sensiblement améliorés sur certaines configurations. Dans la future branche 5.3, les notes de développement officielles indiquent désormais Vulkan comme backend par défaut sur Windows et Linux , sauf Windows ARM. Les exigences minimales ont même été abaissées à Vulkan 1.1 dans cette branche afin de conserver la compatibilité avec davantage de matériel.

Blender 5.2 LTS permet encore de choisir manuellement entre OpenGL et Vulkan dans ses préférences système, et l’ API Python actuelle expose toujours les trois backends OpenGL, Vulkan et Metal . Mais le changement de valeur par défaut est symboliquement important : OpenGL passe progressivement du statut de moteur normal à celui de chemin de compatibilité. C’est généralement l’étape qui précède le moment où quelqu’un demande en réunion : « au fait, combien de développeurs passent encore du temps à maintenir ça ? ».

Pourquoi jeter OpenGL alors qu’il fonctionne encore ?

Parce qu’un vieux backend ne coûte pas seulement quelques lignes de code oubliées au fond d’un dépôt. Chaque nouvelle fonction graphique doit être pensée, testée et parfois contournée pour plusieurs API. Il faut vérifier les shaders, les formats de textures, la gestion mémoire, la synchronisation GPU, les drivers et les différences de comportement entre plateformes. Garder OpenGL, Vulkan et Metal en parallèle signifie donc multiplier les chemins à maintenir, même lorsque la majorité du développement intéressant se déplace déjà vers les deux derniers.

Le problème apparaît particulièrement clairement dans la documentation du Blender Shading Language . Historiquement, les shaders de Blender utilisaient GLSL et visaient essentiellement OpenGL. L’arrivée de Vulkan et Metal a obligé l’équipe à construire des outils capables d’utiliser la même base de shaders avec plusieurs API. À mesure que cette infrastructure s’est complexifiée, Blender a commencé à développer son propre langage, BSL, afin de mieux abstraire les différences entre plateformes et d’utiliser des fonctionnalités graphiques modernes sans rester prisonnier des limites historiques de GLSL.

En résumé : maintenir OpenGL n’est pas problématique parce qu’OpenGL aurait soudainement cessé de dessiner des triangles. C’est problématique parce que chaque triangle moderne doit continuer à penser à son arrière-grand-père.

Les nouvelles fonctions commencent déjà à préférer Vulkan et Metal

L’évolution la plus intéressante concerne ce que Blender souhaite faire ensuite. Pendant le workshop Geometry Nodes de septembre, les développeurs ont notamment discuté de l’exécution de certaines opérations de Geometry Nodes directement sur le GPU. Et dans les conclusions officielles du workshop Geometry Nodes , ils expliquent très clairement que se concentrer sur Vulkan et Metal simplifie certains problèmes de communication entre threads CPU et GPU, alors que le modèle de contexte OpenGL rend la même approche plus coûteuse et complexe.

Ce point permet de comprendre pourquoi l’éventuelle disparition d’OpenGL ne serait pas seulement du ménage technique. Elle pourrait permettre aux développeurs de concevoir de nouvelles fonctions directement autour des capacités des API graphiques modernes plutôt que de systématiquement vérifier si leur architecture peut également être pliée pour fonctionner avec OpenGL. GPU Geometry Nodes, ray tracing matériel dans davantage de parties du viewport, gestion plus fine de la mémoire ou futurs systèmes de textures : plus le logiciel pousse le GPU, plus maintenir le plus petit dénominateur commun devient pénalisant.

Le meilleur exemple arrive justement avec Blender 5.3 : Workbench commence à profiter de ray traced shadows matérielles sur Vulkan et Metal lorsque le GPU prend en charge les ray queries. L’aspect visuel reste comparable aux anciennes ombres stencil, mais le chemin d’exécution moderne peut offrir des performances nettement supérieures sur le matériel adapté.

Et les vieux GPU dans tout ça ?

C’est évidemment la première question qui vient à l’esprit. OpenGL fonctionne sur une quantité phénoménale de cartes graphiques anciennes, là où Vulkan possède un seuil matériel plus récent. Supprimer OpenGL signifie donc nécessairement exclure certains GPU qui arrivent encore aujourd’hui à démarrer Blender.

Il faut toutefois regarder les exigences matérielles actuelles de Blender . Sur Windows et Linux, Blender demande déjà des GPU relativement récents : GeForce série 900 ou ultérieures chez Nvidia, GCN de quatrième génération ou ultérieur chez AMD et architecture Kaby Lake ou plus récente chez Intel dans ses recommandations de compatibilité. Vulkan fait également déjà partie des exigences graphiques indiquées aux côtés d’OpenGL 4.3. Autrement dit, au moment où Blender 6.0 arrivera fin 2027, la quantité de matériel officiellement supporté capable d’exécuter OpenGL mais incapable de fournir un Vulkan suffisamment moderne devrait être nettement plus réduite qu’il y a cinq ans.

Cela ne veut pas dire que personne ne sera touché. Les vieux portables professionnels, certaines machines virtuelles, des pilotes exotiques ou des configurations Linux volontairement conservées pendant quinze ans peuvent parfaitement dépendre encore d’OpenGL. Mais Blender possède une réponse relativement élégante à ce problème : ses anciennes versions restent téléchargeables, et les versions LTS sont maintenues pendant deux ans. Blender 5.2 LTS, sorti en juillet 2026, restera ainsi supporté jusqu’en juillet 2028, couvrant même plusieurs mois après l’arrivée actuellement prévue de Blender 6.0.

Metal sur Mac, Vulkan partout ailleurs : Blender simplifie progressivement son monde graphique

macOS constitue un cas un peu différent. Apple a abandonné l’évolution d’OpenGL depuis longtemps et pousse Metal comme API graphique native. Blender a donc déjà investi massivement dans ce backend sur Apple Silicon. La situation vers laquelle le projet semble converger devient ainsi assez claire : Metal sur macOS, Vulkan sur Windows et Linux.

Ce n’est pas uniquement une simplification du tableau marketing. Les deux API offrent un contrôle nettement plus explicite sur la mémoire, la synchronisation et l’exécution des commandes GPU que le modèle historique d’OpenGL. Cela demande davantage de travail aux développeurs du moteur, mais ce travail peut ensuite être optimisé beaucoup plus précisément. Pour un logiciel comme Blender, capable d’aller du dessin d’une simple interface jusqu’au rendu interactif de scènes contenant des millions d’éléments, ce contrôle commence à valoir largement la complexité initiale.

La transition apparaît déjà dans des fonctions très concrètes. Pour afficher correctement du HDR et du wide gamut sous Linux, la documentation Blender 5.2 recommande Wayland et Vulkan ; Windows demande lui aussi Vulkan pour ces fonctions d’affichage avancées. OpenGL continue donc d’exister, mais certaines parties de l’avenir graphique de Blender ont déjà commencé à s’installer ailleurs.

Ce n’est surtout pas la même chose que CUDA, HIP ou Cycles

Petite précision utile parce que le vocabulaire GPU peut rapidement devenir une soupe de sigles : la disparition éventuelle d’OpenGL concerne principalement le backend utilisé pour afficher l’interface, le viewport et différents traitements graphiques internes. Elle ne signifie pas que Blender supprimerait CUDA, OptiX, HIP, oneAPI ou Metal pour le rendu Cycles.

Les préférences actuelles distinguent d’ailleurs explicitement ces deux familles. D’un côté, OpenGL/Vulkan/Metal servent au backend d’affichage. De l’autre, Cycles peut utiliser CUDA ou OptiX sur Nvidia, HIP sur AMD, oneAPI sur Intel et Metal sur les GPU Apple. Vous pourrez donc parfaitement avoir Blender affiché via Vulkan tout en faisant calculer votre rendu Cycles par OptiX sur une RTX. Aucun développeur ne vient retirer CUDA de votre ferme de rendu parce qu’OpenGL a quitté le bâtiment.

OpenGL ne disparaît pas du monde 3D, mais Blender commence à ne plus en avoir besoin

La trajectoire de Blender raconte finalement quelque chose de plus large sur l’évolution des logiciels graphiques. OpenGL a rempli un rôle extraordinaire : pendant des décennies, une application pouvait parler à des GPU radicalement différents derrière une API relativement universelle. Mais cette abstraction date d’une époque où l’on ne demandait pas aux cartes graphiques d’effectuer en temps réel du ray tracing, de la reconstruction d’image, des simulations massives, des traitements de données ou des pipelines extrêmement parallèles.

Blender est précisément devenu le genre d’application qui dépasse largement le simple affichage 3D. Il fait de la sculpture, de l’animation, du compositing, du montage vidéo, des simulations, du rendu temps réel, du ray tracing et bientôt probablement davantage de Geometry Nodes directement sur GPU. Garder une API ancienne uniquement parce qu’elle a toujours été là finit donc par devenir aussi étrange que maintenir une sortie VGA sur une RTX 6090 « au cas où ».

Pour l’instant, Blender 6.0 sans OpenGL reste seulement une proposition interne . Le virtual texturing pourrait repousser la décision et le plan peut encore évoluer d’ici novembre 2027. Phoronix, qui a repéré les notes de réunion, insiste d’ailleurs lui aussi sur le fait que rien n’est encore acté.

Mais lorsque Vulkan devient le backend par défaut, que les nouvelles fonctions GPU sont pensées pour Vulkan et Metal, que BSL cherche à dépasser les contraintes de GLSL et que les développeurs commencent officiellement à discuter de la suppression d’OpenGL, le message est assez clair.

OpenGL n’a pas encore reçu sa lettre de licenciement. Il vient simplement d’être invité à une réunion avec les RH.