Blender podría estar preparándose para uno de los cambios tecnológicos más importantes de toda su historia reciente: abandonar definitivamente OpenGL y convertir Vulkan en la base gráfica de referencia para Linux y Windows.
Los desarrolladores del proyecto están evaluando internamente eliminar el backend OpenGL con la llegada de Blender 6.0, una decisión que cerraría décadas de dependencia de la API gráfica creada originalmente por Silicon Graphics y consolidaría la transición hacia tecnologías modernas de GPU.
La decisión todavía no está tomada.
Las notas oficiales de la reunión del módulo EEVEE & Viewport del 5 de octubre de 2026 son muy claras:
Internal proposal to remove OpenGL support in Blender 6.0 It hasn't been decided yet.
Es decir:
existe una propuesta interna para eliminar OpenGL, pero todavía no existe una decisión definitiva.
El principal obstáculo técnico señalado por los desarrolladores es actualmente:
Virtual TexturingSi ese trabajo queda resuelto a tiempo, Blender 6.0 podría convertirse en la primera gran versión de Blender completamente liberada de su antiguo backend OpenGL.
Blender lleva años preparándose para este momento
La posible eliminación de OpenGL no apareció de repente.
Es el resultado de una transición tecnológica que Blender lleva preparando durante años.
Durante muchísimo tiempo la arquitectura gráfica de Blender podía representarse aproximadamente así:
Blender | v OpenGL | v Driver GPU | v NVIDIA / AMD / Intel
OpenGL proporcionaba una interfaz común para dibujar:
- La interfaz de Blender.
- El Viewport 3D.
- EEVEE.
- Overlays.
- Herramientas de modelado.
- Editores.
Pero el mercado gráfico cambió.
Las APIs modernas tomaron el control
En los últimos años aparecieron APIs de bajo nivel mucho más modernas:
Vulkan Direct3D 12 Metal
Su filosofía es diferente a la de OpenGL.
En lugar de ocultar gran parte de la gestión de la GPU dentro del controlador, permiten que la aplicación tenga un control mucho más explícito sobre:
- Memoria.
- Sincronización.
- Colas.
- Command buffers.
- Recursos.
- Paralelismo.
Eso aumenta la complejidad para los desarrolladores.
Pero también permite construir motores gráficos más previsibles y eficientes.
Vulkan es especialmente importante para Linux
En Windows existe Direct3D.
Apple tiene Metal.
Linux necesitaba una API moderna y multiplataforma que pudiera convertirse en sucesora tecnológica de OpenGL.
Vulkan terminó ocupando ese espacio.
Linux | +-- OpenGL | +-- Vulkan
Hoy Vulkan está presente en:
- Motores de videojuegos.
- Proton.
- DXVK.
- VKD3D-Proton.
- Emuladores.
- Aplicaciones profesionales.
- Motores gráficos.
Y Blender lleva años preparando su propia migración.
El objetivo de abandonar OpenGL ya existía desde la era Blender 3.x
En la hoja de ruta de Blender 3.x, publicada en 2021, los desarrolladores ya afirmaban que uno de los grandes objetivos era:
mover Blender para utilizar APIs modernas como Vulkan y Metal.
En aquel momento incluso se esperaba que los nuevos backends pudieran reemplazar OpenGL mucho antes.
Pero reescribir una aplicación gráfica tan grande como Blender resultó mucho más complejo de lo previsto.
No se trata simplemente de cambiar una biblioteca
Blender posee millones de líneas de código y muchos sistemas interactúan directamente con la GPU.
Entre ellos:
UI | Viewport | EEVEE | Workbench | Compositor | Grease Pencil | Overlays | Image Editor
Cambiar el backend significa garantizar que todos esos componentes produzcan resultados correctos en distintas combinaciones de:
- GPU NVIDIA.
- GPU AMD.
- GPU Intel.
- Windows.
- Linux.
- macOS.
Eso requiere años de desarrollo, pruebas y correcciones.
Blender 4.3 fue uno de los primeros grandes pasos
En Blender 4.3, Vulkan apareció públicamente como:
experimentalen Linux y Windows.
Los usuarios podían activarlo desde las preferencias de Blender.
En aquel momento existían limitaciones importantes.
Entre ellas:
- GPU subdivision sin soporte completo.
- OpenXR no disponible.
- Problemas gráficos específicos.
- Rendimiento inferior en determinadas tareas.
El objetivo todavía no era superar OpenGL.
Era alcanzar:
paridad funcional y estabilidad.
Blender 4.5 LTS cambió completamente la situación
Con Blender 4.5 LTS, publicado en julio de 2025, el propio proyecto anunció:
“Vulkan is here!”
La documentación oficial afirmó que el nuevo backend ya estaba:
on par with OpenGLes decir, a la par de OpenGL.
Vulkan obtuvo soporte para componentes que anteriormente faltaban, incluyendo:
- OpenXR.
- GPU Subdivision.
- USD/Hydra.
- Más funciones de Viewport.
Además, el rendimiento había mejorado considerablemente.
OpenGL continuó siendo el backend predeterminado
A pesar del avance, Blender 4.5 LTS mantuvo:
OpenGL = defaultmientras recomendaba a los usuarios comenzar a probar Vulkan.
Era una transición prudente.
OpenGL
|
| estable
|
+-------------------+
|
Vulkan
|
maduración
En lugar de cambiar abruptamente millones de instalaciones, Blender permitió que Vulkan acumulara pruebas en hardware real.
Blender 5.x está convirtiendo Vulkan en una plataforma madura
La serie Blender 5.x ha continuado mejorando el backend.
Durante Blender 5.0 y versiones posteriores se corrigieron:
- Problemas gráficos.
- Fugas de memoria.
- Errores específicos de drivers.
- Incompatibilidades con determinados dispositivos.
Al mismo tiempo, Vulkan empezó a ofrecer ventajas que ya no se limitan únicamente a compatibilidad futura.
En algunas escenas Vulkan ya es claramente más rápido
Los datos oficiales publicados para Blender 5.3 muestran resultados interesantes.
Las pruebas fueron realizadas sobre:
AMD Ryzen 9 7950X + NVIDIA RTX 6000 Ada + Linux
Comparando OpenGL y Vulkan.
| Escena | OpenGL Blender 5.3 | Vulkan Blender 5.3 |
|---|---|---|
| barbershop_interior | 42,2 FPS | 45,6 FPS |
| autumn | 192,7 FPS | 282,1 FPS |
| hatching | 597,1 FPS | 902,7 FPS |
| shader_balls | 141,3 FPS | 225,7 FPS |
| sponza | 416,8 FPS | 493,2 FPS |
Estos resultados no significan que Vulkan sea siempre más rápido en cualquier GPU o proyecto.
Pero muestran que el backend ya no existe únicamente como una alternativa experimental.
En determinados workloads proporciona ventajas considerables.
La compilación de materiales también ha mejorado
Blender lleva varias versiones trabajando en la compilación paralela de shaders y pipelines.
En pruebas oficiales de Blender 5.1, por ejemplo, una compilación fría sobre la escena Barbershop Interior pasó aproximadamente de:
OpenGL: 30,39 segundos
a:
Vulkan: 11,67 segundos
en el hardware utilizado por Blender para esa prueba.
De nuevo, no debe entenderse como una garantía universal de rendimiento.
Pero revela las posibilidades de una arquitectura moderna.
Blender 5.3 reduce todavía más la barrera de entrada
Otro cambio especialmente importante está llegando con Blender 5.3.
Los desarrolladores han reducido el requisito mínimo del backend a:
Vulkan 1.1y diferentes características que antes eran obligatorias se han convertido en opcionales.
El objetivo es:
hacer que Vulkan funcione sobre una gama mayor de GPUs.
Esto es fundamental antes de eliminar OpenGL
Mientras Blender mantenga dos backends, una incompatibilidad Vulkan puede resolverse temporalmente haciendo:
Vulkan falla
|
v
usar OpenGL
Pero si OpenGL desaparece:
Vulkan falla
|
v
Blender no puede iniciar
correctamente con esa GPU
Por eso ampliar la compatibilidad es un requisito fundamental antes de retirar el backend anterior.
El gran obstáculo actualmente se llama Virtual Texturing
Las notas de la reunión de EEVEE & Viewport del 5 de octubre revelan el problema que todavía impide tomar la decisión definitiva.
Los desarrolladores escribieron:
OpenGL deprecation Internal proposal to remove OpenGL support in Blender 6.0. It hasn't been decided yet as virtual texturing would be a blocker for this.
Por tanto:
Virtual Texturing es actualmente una de las piezas que debe resolverse antes de que Blender pueda prescindir completamente de OpenGL.
¿Qué es Virtual Texturing?
En una escena 3D profesional podemos tener texturas enormes.
Imagine:
8K + 8K + 16K + UDIM + cientos de materiales
Cargar absolutamente todas esas imágenes simultáneamente dentro de la VRAM puede resultar extremadamente costoso.
Virtual Texturing permite trabajar de otra manera.
Textura enorme
|
v
dividir en bloques
|
v
cargar solamente
lo necesario
|
v
GPU
La idea recuerda conceptualmente a la memoria virtual.
La GPU no necesita necesariamente tener toda la textura residente
Puede cargar las regiones necesarias según:
- Cámara.
- Resolución.
- Visibilidad.
- Nivel de detalle.
Esto resulta especialmente interesante para:
- Escenas cinematográficas.
- Entornos enormes.
- Assets de alta resolución.
- Producción profesional.
Eliminar OpenGL antes de solucionar este punto podría crear una regresión
Blender no quiere realizar:
OpenGL eliminado
|
v
función importante
ya no disponible
La transición necesita preservar las capacidades utilizadas en producción.
Por eso la decisión sobre Blender 6.0 todavía no está cerrada.
¿Qué significa realmente “eliminar OpenGL”?
No significa que Blender vaya a dejar de funcionar con tarjetas NVIDIA o AMD.
Tampoco significa:
OpenGL desaparece del sistema operativo
Significa que Blender dejaría de mantener:
su propio backend de renderizado de interfaz y Viewport basado en OpenGL.
La arquitectura quedaría aproximadamente así
Actualmente:
Blender GPU API
/ | \
/ | \
OpenGL Vulkan Metal
Windows/ Windows/ macOS
Linux Linux
Si la propuesta se aprueba:
Blender GPU API
/ \
/ \
Vulkan Metal
Windows/Linux macOS
Esto es importante porque Blender 6.0 no sería literalmente:
“Vulkan en todas las plataformas”.
macOS seguirá utilizando Metal
Apple lleva años orientando su plataforma hacia:
Metaly Blender ya utiliza este backend nativamente en macOS.
Desde Blender 3.5, Metal ha sido utilizado para la interfaz y el Viewport en Mac.
Por tanto, el posible futuro sería:
| Plataforma | Backend principal |
|---|---|
| Linux | Vulkan |
| Windows | Vulkan |
| macOS | Metal |
Éste es realmente el cambio histórico
Durante décadas OpenGL fue el denominador común.
En el nuevo modelo Blender utiliza una capa propia que puede traducirse hacia APIs modernas según la plataforma.
Código Blender
|
v
GPU abstraction
|
+---+---+
| |
Vulkan Metal
Eso reduce la dependencia directa de una API gráfica diseñada originalmente en otra era informática.
La transición también afecta a los shaders
Históricamente los shaders de Blender estaban escritos utilizando:
GLSLporque el único objetivo importante era OpenGL.
Pero Vulkan y Metal necesitan gestionar shaders de forma diferente.
Esto obligó al proyecto a crear capas de compatibilidad cada vez más complejas.
Blender está desarrollando su propio Blender Shading Language
La documentación de desarrollo actual describe un nuevo proyecto denominado:
BSL
Blender Shading LanguageNo pretende convertirse en otro lenguaje gráfico universal.
Su función es permitir que Blender exprese shaders en una forma común y pueda transformarlos posteriormente hacia los lenguajes necesarios para cada backend.
La vieja dependencia de GLSL se estaba convirtiendo en una carga
Los desarrolladores explican que mantener shaders históricos compatibles con diferentes APIs estaba complicando cada vez más:
- El código.
- Las herramientas.
- El mantenimiento.
- La incorporación de nuevas características.
Eliminar finalmente OpenGL podría permitir simplificar parte de esa infraestructura.
Mantener OpenGL tiene un coste real
Cada vez que Blender desarrolla una nueva función GPU puede necesitar:
implementar Vulkan
+
implementar OpenGL
+
implementar Metal
+
probar todo
Eso significa:
- Más código.
- Más bugs.
- Más pruebas.
- Más mantenimiento.
Si uno de los backends existe fundamentalmente para hardware antiguo, llega un momento donde mantenerlo puede impedir avanzar más rápidamente.
Eliminar OpenGL permitiría concentrar recursos
El nuevo escenario sería:
Linux / Windows
|
v
Vulkan
macOS
|
v
Metal
Eso puede permitir que el equipo dedique más tiempo a:
- Optimización.
- Ray tracing.
- Memory management.
- Virtual Texturing.
- Shader compilation.
- Nuevas funciones EEVEE.
La reducción de deuda técnica puede ser incluso más importante que el rendimiento
Cuando se habla de cambiar OpenGL por Vulkan se suele pensar inmediatamente en:
más FPS
Pero para los desarrolladores, una de las ventajas mayores puede ser:
dejar de mantener rutas de código antiguas.
Una aplicación con décadas de evolución acumula compatibilidad histórica.
Cada capa tiene un coste.
Vulkan tampoco es automáticamente más rápido
Éste es otro mito importante.
Vulkan proporciona más control.
Eso puede permitir más rendimiento.
Pero:
Vulkan ≠ automáticamente más FPS
Una implementación OpenGL altamente optimizada puede superar a una implementación Vulkan deficiente.
La ventaja aparece cuando los desarrolladores aprovechan adecuadamente las capacidades modernas.
Los propios benchmarks de Blender lo demuestran
En algunas escenas la diferencia entre ambos backends es enorme.
En otras:
OpenGL ≈ Vulkan
Eso es completamente normal.
El beneficio depende de:
- Escena.
- Driver.
- GPU.
- CPU.
- Carga de shaders.
Vulkan puede reducir cuellos de botella de CPU
En determinadas escenas Blender necesita enviar enormes cantidades de instrucciones gráficas.
Una API moderna puede facilitar:
- Preparación paralela.
- Menor overhead del driver.
- Gestión más explícita.
- Planificación de comandos.
El backend Vulkan de Blender utiliza incluso un:
Render Graphpara organizar operaciones enviadas hacia la GPU.
El Render Graph puede reordenar determinadas operaciones
La documentación técnica explica que diferentes threads pueden generar comandos GPU.
El Render Graph organiza:
- Transferencias.
- Compute.
- Draw commands.
- Barreras de sincronización.
para enviarlos adecuadamente al dispositivo.
Es un modelo mucho más explícito que buena parte del diseño histórico basado en OpenGL.
Vulkan también abre más puertas para ray tracing moderno
Blender 5.3 ya incorpora trabajo relacionado con:
hardware ray-traced shadows
en Workbench para Metal y Vulkan.
Estas capacidades aprovechan extensiones modernas de hardware que encajan mejor con APIs contemporáneas.
Eso puede beneficiar en el futuro:
- EEVEE.
- Viewport.
- Sombras.
- Iluminación.
- Previsualización.
EEVEE puede ser uno de los grandes beneficiados
EEVEE depende profundamente de la GPU.
Su evolución necesita capacidades como:
- Ray queries.
- Shaders modernos.
- Compute.
- Mejor gestión de memoria.
- Compilación eficiente.
Mantenerse atado indefinidamente a las limitaciones de OpenGL puede dificultar la incorporación de algunas de esas tecnologías.
¿Qué pasará con las tarjetas gráficas antiguas?
Ésta es probablemente la principal preocupación para usuarios.
Mientras OpenGL siga disponible, determinados equipos antiguos pueden continuar ejecutando Blender aunque su soporte Vulkan sea limitado.
Si OpenGL desaparece, una GPU tendrá que disponer de un backend moderno compatible.
Blender está intentando reducir el requisito Vulkan precisamente por eso
La decisión de bajar el mínimo hacia:
Vulkan 1.1es especialmente relevante.
Permite incluir hardware que podría quedar excluido si Blender exigiera únicamente características muy recientes.
Linux puede tener una ventaja interesante con Mesa
El ecosistema gráfico Linux cuenta con:
Mesa
que proporciona drivers Vulkan open source para diferentes GPUs.
Entre ellos encontramos proyectos como:
- RADV para AMD.
- ANV para Intel.
- NVK para NVIDIA.
- Turnip para Qualcomm.
Esto significa que incluso hardware relativamente antiguo puede recibir mejoras de Vulkan mucho después de que el fabricante original reduzca soporte.
En Blender 4.5 ya aparecía una diferencia interesante entre Linux y Windows
Por ejemplo, determinadas generaciones antiguas de AMD e Intel que no estaban soportadas mediante Vulkan en Windows podían funcionar en Linux gracias a Mesa.
Esto demuestra una de las fortalezas del stack gráfico abierto.
Pero no todo hardware sobrevivirá eternamente
Una GPU suficientemente antigua puede carecer de:
- Vulkan.
- Extensiones requeridas.
- Drivers funcionales.
En ese caso, una futura versión de Blender sin OpenGL podría dejarla atrás.
Eso forma parte inevitablemente de la evolución tecnológica.
Blender 6.0 no llegará inmediatamente
Otro detalle que conviene aclarar es la fecha.
Las notas internas de octubre todavía mencionaban:
Blender 6.0 — November 2027pero la documentación oficial de compatibilidad más reciente sitúa actualmente Blender 6.0 en:
March 2028Por tanto, el calendario todavía puede evolucionar.
Lo importante es que estamos hablando de una decisión para la siguiente gran generación del programa, no de un cambio que llegará en unas semanas.
Eso ofrece mucho tiempo para probar Vulkan
Los usuarios profesionales deberían aprovechar ese periodo.
En lugar de esperar a Blender 6.0 y descubrir problemas el día de la actualización:
Blender actual
|
v
probar Vulkan
|
v
validar drivers
|
v
probar proyectos
|
v
reportar errores
Esto ayuda tanto al usuario como al propio proyecto.
Los estudios deberían comenzar a validar sus pipelines
Una productora o estudio puede tener:
- Decenas de estaciones.
- Add-ons propios.
- Herramientas Python.
- Drivers certificados.
- Escenas enormes.
Para ellos un cambio de backend gráfico necesita evaluación anticipada.
¿Qué debería probar un estudio?
| Área | Prueba |
|---|---|
| Viewport | Escenas reales de producción |
| EEVEE | Materiales y luces complejas |
| Drivers | NVIDIA, AMD o Intel utilizados |
| Add-ons | Funciones gráficas personalizadas |
| XR | Workflows OpenXR |
| Performance | FPS y compilación de shaders |
| Memoria | Escenas de gran tamaño |
Los desarrolladores de add-ons ya recibieron años de advertencia
Blender tenía antiguamente un módulo Python denominado:
bglque proporcionaba acceso directo a OpenGL.
Ese módulo comenzó a ser desaconsejado hace años.
La documentación advertía explícitamente que sería eliminado cuando Blender migrara hacia:
Metal + Vulkan
Blender 5.0 terminó eliminando la API BGL obsoleta
La documentación de Blender 5.0 confirma:
Remove deprecated BGL APILos desarrolladores de extensiones deben utilizar ahora:
gpula abstracción gráfica de Blender.
Ésta es otra señal de que OpenGL está dejando de ser parte del contrato público
Antes un add-on podía asumir:
Blender = OpenGL
Hoy debería asumir:
Blender = GPU abstraction
y dejar que Blender decida si detrás funciona:
OpenGL Vulkan Metal
Los add-ons modernos deberían ser independientes del backend
Ésta es la dirección correcta porque evita que una extensión quede atada a una API determinada.
Por ejemplo:
gpu.shader
gpu.state
gpu.texture
gpu.typespermiten interactuar con la GPU utilizando la capa proporcionada por Blender.
La eliminación de OpenGL podría simplificar también las pruebas
Actualmente una función gráfica puede necesitar verificarse en diferentes combinaciones:
Linux + OpenGL Linux + Vulkan Windows + OpenGL Windows + Vulkan macOS + Metal
El futuro podría reducirlo a:
Linux + Vulkan Windows + Vulkan macOS + Metal
Sigue siendo una matriz considerable.
Pero elimina una dimensión completa de mantenimiento.
¿Por qué OpenGL sobrevivió tantos años?
Porque tiene algunas ventajas enormes.
OpenGL es:
- Maduro.
- Conocido.
- Disponible en muchísimo hardware.
- Relativamente sencillo de utilizar.
- Soportado por décadas de drivers.
Para una aplicación multiplataforma como Blender fue durante años una elección excelente.
El problema es que el hardware evolucionó mucho más rápido que OpenGL
Las GPUs modernas funcionan con enormes niveles de paralelismo.
La industria necesitaba interfaces capaces de expresar ese hardware de manera más directa.
OpenGL fue construido originalmente bajo supuestos muy diferentes.
Aunque recibió muchas extensiones y mejoras, su arquitectura conserva décadas de compatibilidad histórica.
Vulkan nació precisamente para romper con ese modelo
Khronos diseñó Vulkan alrededor de:
- Bajo overhead.
- Control explícito.
- Multithreading.
- Gestión explícita de recursos.
- Portabilidad.
Eso lo hace atractivo para aplicaciones de alta demanda como Blender.
Pero Vulkan también exige mucho más trabajo a Blender
Con OpenGL, el driver realizaba muchas decisiones automáticamente.
Con Vulkan:
Aplicación | v debe gestionar mucho más
Por eso el backend ha necesitado años para madurar.
La complejidad no desaparece.
Se mueve desde el driver hacia el motor gráfico de Blender.
El beneficio es tener más control
Una vez construida correctamente esa infraestructura, Blender puede optimizar específicamente para sus necesidades.
Esto puede mejorar:
- Previsibilidad.
- Paralelismo.
- Uso de memoria.
- Compilación de pipelines.
- Sincronización.
El cambio tiene también una dimensión open source
Vulkan es un estándar abierto mantenido por Khronos Group.
Esto resulta especialmente importante para Linux.
El stack puede combinar:
Blender | v Vulkan | v Mesa | v driver open source | v GPU
permitiendo una pila gráfica ampliamente auditable y desarrollada públicamente.
Blender y Mesa pueden evolucionar juntos
Cuando Blender encuentra problemas específicos sobre Linux puede trabajar con desarrolladores de:
- Mesa.
- RADV.
- ANV.
- NVK.
para resolver errores y mejorar comportamiento.
Eso fortalece todo el ecosistema gráfico Linux.
La transición beneficiará también al desarrollo multiplataforma
La capa GPU de Blender busca evitar que EEVEE o la interfaz tengan que conocer en detalle cada API.
Conceptualmente:
EEVEE | v Blender GPU API | +--> Vulkan | +--> Metal
Eso permite que las funciones de alto nivel compartan una base común.
Blender 6.0 puede marcar una ruptura generacional
El número mayor:
6.0es precisamente un buen momento para realizar cambios que resulten demasiado disruptivos para versiones menores.
Blender ya ha utilizado saltos importantes para introducir cambios profundos.
Eliminar OpenGL encajaría perfectamente dentro de esa filosofía.
Pero todavía puede no ocurrir en 6.0
Esto debe mantenerse muy claro.
La información disponible actualmente dice:
PROPUESTA
no:
DECISIÓN FINAL
Si Virtual Texturing o cualquier otro componente crítico no está preparado, los desarrolladores podrían mantener OpenGL durante más tiempo.
La estabilidad suele ganar frente al calendario
Blender es utilizado profesionalmente para:
- Cine.
- Animación.
- Videojuegos.
- Arquitectura.
- Diseño.
- VFX.
Romper esos workflows únicamente para cumplir una fecha sería mucho más perjudicial que conservar OpenGL otra versión.
Por eso la prudencia de los desarrolladores tiene sentido.
¿Deberían preocuparse los usuarios actuales?
No.
No hay ninguna necesidad de reemplazar una GPU inmediatamente.
Blender 6.0 todavía está lejos y la decisión no está cerrada.
Lo más útil ahora es comprobar:
- Si tu GPU soporta Vulkan.
- Qué versión Vulkan proporciona el driver.
- Cómo funciona Blender actualmente con Vulkan.
- Si tus add-ons presentan problemas.
Cómo comprobar Vulkan en Linux
Si tienes las herramientas Vulkan instaladas puedes ejecutar:
vulkaninfo --summaryTambién:
vulkaninfo | lessEn sistemas con Mesa:
glxinfo -Bcontinúa siendo útil para identificar la GPU y el driver OpenGL, pero para la nueva etapa la información Vulkan será cada vez más importante.
En Linux, actualizar Mesa puede cambiar completamente la experiencia
Una GPU puede ser compatible físicamente con Vulkan pero estar limitada por un driver antiguo.
Por eso conviene mantener actualizado:
- Kernel.
- Mesa.
- Firmware.
- Drivers NVIDIA cuando corresponda.
especialmente al probar versiones recientes de Blender.
NVIDIA en Linux tiene requisitos propios
Blender 4.5 recomendaba para Vulkan sobre NVIDIA en Linux drivers:
550 o posterioresLa documentación actual también mantiene una lista de drivers problemáticos que pueden bloquearse cuando se conocen fallos graves.
Por tanto, Vulkan no depende únicamente del hardware.
También depende de la calidad del controlador.
AMD tiene una situación particularmente interesante en Linux
Los usuarios pueden trabajar con:
- Drivers oficiales.
- Mesa RADV.
RADV ha evolucionado rápidamente y constituye una de las implementaciones Vulkan open source más importantes del ecosistema Linux.
Intel también depende fuertemente de Mesa
Las GPU Intel modernas disponen de soporte Vulkan a través de ANV.
Blender 5.3 está trabajando precisamente para reducir requisitos y mejorar soporte de generaciones más antiguas.
¿Qué pasa con Cycles?
Otro punto donde puede existir confusión.
Eliminar OpenGL como backend de interfaz y Viewport no significa que Cycles vaya a renderizar únicamente mediante Vulkan.
Cycles utiliza tecnologías específicas como:
- CUDA.
- OptiX.
- HIP.
- oneAPI.
- Metal.
- CPU.
Por tanto:
Viewport backend ≠ Cycles compute backend
Vulkan afecta principalmente a la infraestructura gráfica interactiva
Cuando Blender habla de backend Vulkan está hablando principalmente de:
- Interfaz.
- Viewport.
- EEVEE.
- Workbench.
- Overlays.
- Editores gráficos.
No significa que toda la arquitectura de renderizado offline abandone sus APIs de cómputo actuales.
Es una distinción especialmente importante para usuarios NVIDIA
Alguien puede utilizar:
Vulkan para Viewport
y simultáneamente:
OptiX para Cycles
No existe contradicción.
Son capas diferentes.
El futuro de Blender puede utilizar varias APIs especializadas
Por ejemplo:
Blender | +-- Vulkan -> Viewport Linux/Windows | +-- Metal -> Viewport macOS | +-- OptiX -> Cycles NVIDIA | +-- HIP -> Cycles AMD | +-- oneAPI -> Cycles Intel
La eliminación de OpenGL simplificaría una parte de esa arquitectura, no toda.
¿Qué ganaría un usuario Linux normal?
Potencialmente:
- Mejor rendimiento de Viewport.
- Compilación de shaders más rápida.
- Acceso a características modernas.
- Menor dependencia de rutas gráficas antiguas.
- Mejor evolución futura de EEVEE.
Pero el beneficio exacto dependerá del hardware.
Los equipos antiguos son quienes asumirían el coste
Un usuario con una GPU que funciona correctamente mediante OpenGL pero no dispone de Vulkan suficiente podría encontrarse con:
Blender 5.x | funciona Blender 6.x | GPU incompatible
si finalmente se aprueba la eliminación.
Una versión LTS puede convertirse en refugio temporal
Cuando Blender realiza cambios importantes, las versiones LTS permiten que estudios y usuarios profesionales permanezcan durante más tiempo sobre una base conocida.
Por eso no todos necesitarían adoptar Blender 6.0 el día de lanzamiento.
Una migración profesional razonable puede ser:
LTS estable
|
v
probar Blender 6.0
|
v
validar proyectos
|
v
migrar
El gran cambio no será visible en la interfaz
Ésta es quizá la parte más curiosa.
Si Blender realiza bien la transición, el usuario podría abrir 6.0 y pensar:
“se ve exactamente igual”.
Y eso sería una buena señal.
Porque el cambio está debajo.
Botón Viewport Material Objeto
seguirán siendo familiares.
Lo que habrá cambiado será la infraestructura que envía millones de operaciones hacia la GPU.
Es una transformación comparable a cambiar el motor de un automóvil sin cambiar el volante
El usuario continúa utilizando:
- Las mismas herramientas.
- Los mismos atajos.
- Los mismos archivos.
Pero debajo puede existir una arquitectura gráfica completamente distinta.
El abandono de OpenGL sería también simbólico
Blender ha acompañado prácticamente toda la historia moderna de OpenGL.
Durante décadas ambas tecnologías crecieron juntas.
Cuando Blender necesitó una interfaz multiplataforma acelerada por GPU, OpenGL era la elección natural.
Que el proyecto considere hoy eliminarlo demuestra hasta qué punto ha cambiado el panorama gráfico.
OpenGL no desaparecerá del mundo
Seguirá utilizándose durante años en:
- Aplicaciones existentes.
- Educación.
- Software científico.
- Hardware antiguo.
- Sistemas embebidos.
Pero aplicaciones de alto rendimiento están migrando progresivamente hacia APIs modernas.
Blender sería otra señal de esa transición
Si uno de los proyectos gráficos open source más importantes abandona OpenGL, el mensaje para el ecosistema es significativo.
OpenGL | | mantenimiento / legado | v Vulkan | | desarrollo moderno | v futuro
No porque OpenGL deje de funcionar.
Sino porque muchas de las nuevas inversiones se concentran en otra capa tecnológica.
Linux puede beneficiarse especialmente
La combinación:
Blender + Vulkan + Mesa + Wayland
representa una pila gráfica moderna en la que gran parte de la infraestructura puede desarrollarse abiertamente.
Eso habría sido difícil de imaginar hace una década.
Blender 6.0 podría cerrar un ciclo de más de 30 años
Blender nació en una época donde OpenGL representaba el futuro del gráficos 3D multiplataforma.
Ahora el propio programa se prepara para una generación tecnológica diferente.
La transición puede representarse de esta manera:
OpenGL | v GPU abstraction | v Vulkan + Metal
Es una evolución técnica.
Pero también histórica.
¿Qué deberían hacer ahora los usuarios?
- No entrar en pánico: OpenGL todavía no ha sido eliminado.
- Mantener actualizado Blender.
- Comprobar el soporte Vulkan de la GPU.
- Actualizar drivers.
- Probar Vulkan en proyectos reales.
- Reportar fallos al proyecto.
- Revisar add-ons antiguos.
- No comprar hardware nuevo únicamente por una propuesta todavía no aprobada.
¿Qué deberían hacer los desarrolladores de add-ons?
Especialmente:
NO depender de OpenGL directamente
y utilizar:
gpuy las APIs públicas actuales de Blender.
El antiguo módulo BGL ya fue retirado en Blender 5.0.
La migración tecnológica ya comenzó.
¿Qué deben hacer los estudios?
Empezar pruebas mucho antes de Blender 6.0.
Especialmente si mantienen:
- Workstations antiguas.
- Drivers congelados.
- Plugins internos.
- Pipelines personalizados.
La eliminación de OpenGL, si finalmente ocurre, será mucho menos problemática para quienes hayan probado Vulkan previamente.
Un posible cronograma tecnológico
Blender 4.3 | Vulkan experimental | v Blender 4.5 LTS | paridad con OpenGL | v Blender 5.x | optimización compatibilidad Vulkan 1.1 | v Blender 6.0 | ¿OpenGL eliminado?
El último paso continúa acompañado por un signo de interrogación.
Ese signo de interrogación es importante
Los titulares pueden decir:
Blender abandona OpenGL
Pero hoy eso sería adelantarse a los hechos.
La descripción correcta es:
Blender está evaluando seriamente eliminar OpenGL en 6.0 porque Vulkan ya ha alcanzado suficiente madurez, pero el proyecto todavía no ha tomado una decisión definitiva.
Recomendamos
- 10 herramientas poderosas de Software Libre para transformar su empresa
- ¿Cuáles deben ser los criterios para seleccionar una distribución Linux?
En resumen
Los desarrolladores de Blender están considerando eliminar el backend OpenGL con Blender 6.0 y concentrar el futuro gráfico de Linux y Windows alrededor de Vulkan.
La propuesta apareció oficialmente en las notas de la reunión del módulo EEVEE & Viewport del 5 de octubre de 2026.
Sin embargo, todavía no existe una decisión final.
El principal bloqueo mencionado actualmente es Virtual Texturing, una tecnología importante para trabajar eficientemente con grandes cantidades de texturas y memoria GPU.
La migración lleva años preparándose. Vulkan apareció como opción experimental en Blender 4.3 y alcanzó paridad funcional con OpenGL en Blender 4.5 LTS.
Durante la serie 5.x, Blender ha seguido mejorando estabilidad, rendimiento y compatibilidad. Blender 5.3 reduce incluso el requisito mínimo hacia Vulkan 1.1 y hace opcionales determinadas capacidades para soportar más hardware.
Las pruebas oficiales muestran que Vulkan puede superar significativamente a OpenGL en determinadas escenas, aunque la ventaja no es uniforme para todos los workloads.
Si OpenGL finalmente desaparece, Vulkan sería la principal API gráfica de Blender en Linux y Windows, mientras macOS continuaría utilizando Metal.
Conclusión editorial
Si Blender 6.0 termina eliminando OpenGL, no estaremos simplemente ante otra opción que desaparece del menú de preferencias.
Será el cierre de una etapa tecnológica que acompañó a Blender prácticamente desde sus orígenes.
OpenGL permitió que una aplicación 3D compleja pudiera ejecutarse durante décadas sobre Linux, Windows y macOS utilizando una interfaz gráfica común.
Fue una de las tecnologías que hizo posible que Blender se convirtiera en una herramienta verdaderamente multiplataforma.
Pero precisamente porque Blender continúa evolucionando, llega un momento donde mantener compatibilidad con el pasado puede comenzar a limitar lo que es posible construir para el futuro.
Vulkan ofrece a los desarrolladores un control mucho mayor de las GPU modernas.
También exige muchísimo más trabajo.
Los años que Blender ha necesitado para llegar desde un backend experimental hasta una implementación comparable —y en algunos escenarios claramente superior— a OpenGL demuestran que esta migración nunca fue sencilla.
Pero la dirección parece cada vez más difícil de revertir.
Vulkan ya no es únicamente una prueba.
Ya soporta buena parte del Viewport.
Ya funciona con EEVEE.
Ya trabaja con OpenXR.
Ya soporta GPU subdivision.
Y en determinados benchmarks oficiales ya supera ampliamente a OpenGL.
Al mismo tiempo, Blender está desarrollando nuevas abstracciones de GPU, un nuevo lenguaje de shaders y tecnologías pensadas para una generación gráfica donde OpenGL deja progresivamente de ser el denominador común.
El gran reto será realizar la transición sin abandonar innecesariamente hardware que todavía puede ejecutar Blender perfectamente.
Por eso reducir los requisitos hasta Vulkan 1.1, mejorar Mesa y resolver Virtual Texturing son tareas mucho más importantes que simplemente borrar el código OpenGL.
La Blender Foundation tiene todavía tiempo.
La documentación actual sitúa Blender 6.0 en 2028 y la decisión no está cerrada.
Pero si finalmente ocurre, el cambio tendrá un significado especial para Linux.
Una de las aplicaciones gráficas open source más importantes del mundo podría dejar atrás OpenGL y apostar su futuro sobre Vulkan, Mesa y una infraestructura gráfica moderna diseñada para aprovechar las GPU de la próxima década.
Y eso marcaría no solamente una nueva etapa para Blender.
También sería otra señal de que el relevo generacional de OpenGL dentro del escritorio y las aplicaciones profesionales Linux ya está en marcha.
Fuentes: Blender Developer Forum — EEVEE & Viewport Meeting, 5 de octubre de 2026, Blender Developer Documentation — Vulkan en Blender 4.5 LTS, Blender Developer Documentation — EEVEE & Viewport en Blender 5.3, Blender Developer Documentation — Vulkan Device Management, Blender Developer Documentation — Blender Shading Language, Blender — Compatibility and Upcoming Releases y Phoronix — Blender 6.0 May End Up Removing OpenGL Support.
