NVIDIA y Linux en 2026

Hay una pregunta que lleva flotando en los foros desde hace años, y que cada nueva versión de driver resucita puntualmente: ¿cuándo va a tomarse NVIDIA en serio a los usuarios de Linux? La respuesta honesta, a julio de 2026, es más en serio que antes, pero no tanto como debería. Hay avances reales. También hay heridas sin cicatrizar y hardware que directamente se ha dado por muerto sin mucho aviso previo.

Este análisis no pretende ser ni un panfleto anti-NVIDIA ni una defensa corporativa. Lo que hay aquí son datos, contexto y alguna opinión sin filtrar sobre decisiones de diseño que, con toda la buena voluntad del mundo, siguen sin tener una justificación que convenza.

#De blob propietario a módulo abierto: la historia en dos actos

Durante décadas, el driver de NVIDIA en Linux fue el arquetipo del software de caja negra. Un binario enorme, opaco, que el kernel cargaba con la misma fe ciega con la que uno introduce una moneda en una máquina de refrescos: esperando que salga algo, sin garantías de nada.

El primer acto cambió en mayo de 2022, cuando NVIDIA publicó los módulos de kernel bajo licencia dual GPL/MIT con el lanzamiento del driver R515. El matiz es importante: lo que abrieron fue la capa que habla con el kernel Linux, no el driver completo. Las librerías de usuario, el stack de CUDA, el firmware del GPU… todo eso siguió siendo propietario.

El segundo acto llegó en julio de 2024, cuando NVIDIA anunció la transición completa hacia estos módulos abiertos como vía recomendada a partir del driver R560, para todas las arquitecturas desde Turing en adelante. A partir de ahí, si tienes una RTX 2060 o cualquier tarjeta más moderna, los paquetes nvidia-open son lo que deberías usar.

El resultado práctico es un modelo híbrido. Puedes leer el código que carga el módulo, puedes mandarte un parche al proyecto en GitHub si encuentras un bug. Lo que no puedes hacer es entender qué pasa exactamente dentro del firmware que corre en el GSP, porque eso sigue siendo territorio vedado. Una apertura real, pero acotada.

#Lo que ya no funciona: el golpe silencioso a Maxwell y Pascal

Si tienes una GTX 1080 en un servidor Linux que llevas años dejando correr con la filosofía del «si funciona, no lo toques», hay malas noticias. Con la llegada de la serie 590 de drivers, NVIDIA ha cortado formalmente el soporte activo para las arquitecturas Maxwell (GTX 700/900) y Pascal (GTX 10xx), además de Volta.

El branch 580.xx es el último que las mueve. A partir de ahí, nada.

Lo que NVIDIA ha prometido es un mantenimiento de seguridad trimestral hasta octubre de 2028. No nuevas funciones, no optimizaciones, no soporte para Wayland si no está ya implementado. Solo parches de seguridad. Para quien tenga una GTX 1080 Ti que sigue rindiendo perfectamente en su carga de trabajo, es una sentencia de obsolescencia programada que no tiene ninguna base técnica de rendimiento, sino puramente comercial.

El verdadero problema en Linux es que las distribuciones rolling-release como Arch o Manjaro empezaron a transicionar sus paquetes por defecto hacia los módulos abiertos (que no soportan Pascal). El usuario que no estaba al tanto se encontró con una actualización de sistema que dejó su entorno gráfico completamente inoperativo. Cualquier sysadmin que haya gestionado parques de máquinas con GPUs de esa generación sabe perfectamente de qué tipo de llamadas a las 3 de la tarde estoy hablando.

#El purgatorio de Wayland: suspend, hibernate y el GSP que no avisa

Aquí es donde la situación sigue siendo, eufemísticamente, «en proceso de maduración». La integración de NVIDIA con Wayland ha mejorado notablemente en los últimos dos años, y sería injusto no reconocerlo. Pero el suspend y el hibernate siguen siendo una ruleta rusa dependiendo del compositing manager que uses y del kernel que tengas cargado.

El culpable más documentado son los timeouts del firmware GSP durante los ciclos de suspend/resume. Lo que pasa es esto: cuando el sistema intenta entrar en suspend, el kernel manda una señal al driver, el driver intenta coordinar con el firmware del GSP, y si esa negociación no se resuelve dentro del timeout esperado, el sistema se queda colgado. Pantalla negra. Sin respuesta al teclado. Reset manual obligatorio.

KDE Plasma con KWin gestiona esto mejor que otros compositores porque reintenta la operación en lugar de abortar; con Sway o Hyprland la experiencia es bastante más dramática. El comportamiento varía también según el kernel: versiones específicas de la serie 7.x han introducido regresiones que estaban resueltas en LTS anteriores.

Los parámetros que mitigan el problema son conocidos y están bien documentados en la wiki de Arch, pero el hecho de que en 2026 haya que tocar /etc/modprobe.d/ manualmente para que el suspend funcione en un portátil es uno de esos recordatorios de que hay trabajo pendiente. En Windows, el equivalente ni siquiera existe como concepto: el driver gestiona el power management de forma transparente. En Linux, eres tú quien habilita los systemd services correspondientes:

Añadir en /etc/modprobe.d/nvidia-pm.conf:

# Preservar la VRAM durante suspend/hibernate.
# Sin esto, el resume falla con EIO al intentar restaurar el estado de la GPU.
options nvidia NVreg_PreserveVideoMemoryAllocations=1

Y habilitar los servicios de power management con privilegios de superusuario:

# Servicios necesarios para que suspend/hibernate funcionen con el driver NVIDIA.
# Si alguno de estos no está activo, el resume fallará silenciosamente o congelará el sistema.
sudo systemctl enable nvidia-suspend.service
sudo systemctl enable nvidia-resume.service
sudo systemctl enable nvidia-hibernate.service

#Nouveau: la alternativa que no termina de serlo

Vale la pena dedicarle un apartado a Nouveau, el driver de código abierto mantenido por la comunidad, porque hay una percepción popular de que NVIDIA «bloquea» activamente su desarrollo. La realidad es algo más matizada, y no precisamente más tranquilizadora.

Históricamente, NVIDIA no colaboraba con el proyecto Nouveau ni publicaba las especificaciones necesarias para un driver de alto rendimiento. La situación cambió en 2022 cuando, al abrir los módulos de kernel, también empezaron a liberar documentación de firmware del GSP que Nouveau puede usar. Es un avance real.

El problema es que la brecha de rendimiento acumulada durante años no se cierra de un día para otro. Nouveau en 2026 puede mover un escritorio de Wayland con decencia en tarjetas modernas, pero hablar de gaming competitivo o de cargas CUDA con Nouveau es, directamente, ciencia ficción. El reclocking —ajustar las frecuencias de la GPU a su punto de operación óptimo— lleva años siendo un asunto pendiente, y sin él, el rendimiento 3D se queda a una fracción de lo que el hardware puede ofrecer.

La ironía es que el usuario de Nouveau tiene exactamente lo contrario del usuario de Windows: código abierto pero rendimiento discreto, frente a una caja negra que simplemente funciona. Hay algo filosóficamente interesante en ese intercambio, aunque a quien le está ardiendo un deadline de render no le hace ninguna gracia.

#El elefante en la sala: AMD y los números que NVIDIA debería mirar

Los datos del Steam Hardware Survey cuentan una historia llamativa. NVIDIA domina el mercado general de Steam con aproximadamente el 73% de las tarjetas reportadas. En Linux, ese porcentaje se invierte: AMD copa cerca del 70% de las instalaciones Linux. Una parte importante de ese dato lo explica el Steam Deck (que usa hardware AMD), pero no toda.

Hay usuarios que eligen AMD precisamente por la experiencia de drivers en Linux: amdgpu está integrado en el kernel mainline, Wayland funciona sin ceremonias adicionales, y suspend/hibernate llevan años siendo transparentes. No hay parámetros de modprobe que recordar, no hay servicios de systemd que habilitar a mano, no hay binarios firmware que descargar por separado.

NVIDIA tiene una cuota de mercado masiva en Windows. El hecho de que en Linux esa cuota se evapore no es solo por las limitaciones técnicas del driver: hay un factor de confianza que se construye (o se destruye) con cada actualización que rompe algo inesperado.

«The open-source kernel modules have achieved performance parity with their closed-source predecessors, with some features now being exclusive to the open modules.»

La afirmación es técnicamente correcta para las métricas de rendimiento que NVIDIA eligió medir. Lo que no dice el comunicado es que «paridad de rendimiento» en el módulo de kernel no implica paridad en la experiencia completa de usuario en Linux.

#El día que una actualización de paquetes nos dejó sin servidor de render

Lo vi documentado en un hilo de los foros de EndeavourOS, y reconozco que me resultó demasiado familiar. Un equipo con tres nodos de render usando GTX 1080 Ti actualizó el sistema un lunes por la mañana. La distro, en su transición hacia los paquetes nvidia-open por defecto, tiró el driver antiguo. Al reiniciar, ninguno de los tres nodos arrancaba en entorno gráfico. Modo texto, sin GPU acelerada, trabajo parado.

Mi primera reacción habría sido reinstalar el driver propietario legacy sobre el paquete abierto. Error clásico: los dos no conviven bien si no limpias correctamente el estado anterior.

La solución real pasó por arrancar en modo recovery, desinstalar todo lo relacionado con NVIDIA, instalar explícitamente el paquete de la rama 580xx y bloquearlo con un hold en el gestor de paquetes para que no vuelva a actualizarse automáticamente. Dos horas de trabajo que podrían haberse evitado con una nota de release clara y visible. Hay decisiones de gestión de paquetes que, de tan convenientes para la mayoría, se vuelven una trampa para quien tiene hardware fuera del ciclo de soporte activo.

#¿Merece la pena elegir NVIDIA si tu sistema principal es Linux?

Depende, y ese «depende» tiene más matices ahora que hace tres años.

Si tienes hardware Turing o más moderno (RTX 2000 en adelante), la experiencia con los módulos abiertos es sólida para la mayoría de casos de uso. Gaming en Wayland funciona. CUDA funciona. Los problemas de suspend existen pero tienen solución documentada. No es ideal, pero tampoco es el desastre que fue hace cinco años.

Si tienes hardware Pascal (GTX 10xx) y Linux es tu sistema principal, estás en tierra de nadie. El branch 580xx seguirá recibiendo parches de seguridad hasta 2028, pero sin mejoras funcionales. Wayland en esa rama es limitado. Cada actualización mayor del kernel puede traer sorpresas. Es perfectamente usable hoy, pero la trayectoria no invita al optimismo.

Si estás eligiendo hardware nuevo y Linux es prioritario para ti, la experiencia de AMD es objetivamente más fluida en 2026. Sin firmware blobs separados, sin servicios de systemd manuales, sin gestionar ramas de driver legacy. El rendimiento en gaming puede variar según el título, pero la integración con el stack de Linux es más limpia.

NVIDIA no ha abandonado Linux. Pero tampoco ha llegado al punto donde la experiencia sea comparable a Windows sin conocimientos técnicos adicionales. Si sabes lo que haces, funciona bien. Si no los tienes, el margen de error sigue siendo demasiado amplio para una empresa con los recursos que tiene NVIDIA.

Esto lo escribo en julio de 2026 con drivers de la serie 595.xx. La situación de Wayland y suspend mejora en cada release importante, así que si llegaste aquí meses después, comprueba el changelog antes de asumir que los parámetros de modprobe que aparecen aquí siguen siendo necesarios.