- NVIDIA ha mejorado mucho en Linux con módulos de kernel abiertos, PRIME y Wayland, pero aún conserva partes privativas y menor paridad con Windows en algunos escenarios.
- AMD e Intel ofrecen una integración más fluida con la pila abierta, mientras NVIDIA mantiene ventaja en CUDA, DLSS, gama alta y disponibilidad en portátiles.
- Elegir bien la arquitectura y la rama de driver, desde legacy 340.x hasta 590.x, evita gran parte de los problemas y confusiones habituales.
Si estás pensando en dejar atrás tu RX 580 y dar el salto a una tarjeta NVIDIA, es normal que te asalten dudas sobre Linux. Durante años se ha repetido que NVIDIA es un dolor de cabeza en este sistema, que sus drivers cerrados rompen todo y que AMD o Intel son la única opción sensata. Esa fama tiene fundamento histórico, pero también mucho de cliché antiguo. La situación ha cambiado y conviene mirarla con datos actuales, no con titulares de hace una década.
En este artículo vamos a desmenuzar todo el ecosistema: desde las ramas de controladores que ofrece NVIDIA hasta las arquitecturas Tesla, Fermi, Kepler, Maxwell, Pascal, Volta, Turing, Ampere, Ada Lovelace y Blackwell. También veremos Nouveau, Vulkan, OpenCL, OpenGL, PRIME, los módulos abiertos del kernel, DKMS, GSP, Wayland, el rendimiento en juegos e inteligencia artificial y por qué los fabricantes siguen montando NVIDIA incluso en equipos con Linux. No es una cuestión de blanco o negro, sino de entender qué hay debajo.
De dónde viene la mala fama de NVIDIA en Linux
El origen del recelo está en la política de controladores privativos que NVIDIA mantuvo durante muchísimos años. La compañía ofrecía documentación limitada, colaboraba poco con los desarrolladores del kernel y dificultaba la integración con la pila gráfica abierta. Para una comunidad acostumbrada al desarrollo abierto, ese enfoque chocaba de frente. Incluso Android, que se apoya en el kernel Linux, recibió durante mucho tiempo pocas contribuciones directas de NVIDIA dentro del ecosistema del kernel.
La frase más recordada de esa tensión es la de Linus Torvalds criticando públicamente la actitud de NVIDIA. Aquello se convirtió en un símbolo: el responsable del kernel expresaba una frustración compartida por muchos usuarios y desarrolladores. A partir de ahí se consolidó la idea de que NVIDIA era casi inservible en Linux, aunque la realidad nunca fue tan extrema como el meme.
Frente a eso, AMD e Intel representan una alternativa más alineada con el desarrollo abierto. Sus controladores y buena parte de la pila gráfica están integrados en el kernel y en Mesa, lo que suele traducirse en una experiencia de encender y que todo funcione. Por eso gozan de mejor aceptación entre los usuarios de Linux. Sin embargo, cuando toca comprar hardware dedicado, la teoría se topa con la disponibilidad real del mercado.
NVIDIA sigue siendo referencia en rendimiento, disponibilidad y soporte de aplicaciones especializadas. Marcas de ordenadores con Linux, incluidos portátiles, recurren mayoritariamente a sus GPU. Es una contradicción solo aparente: AMD encaja mejor con la filosofía de Linux, pero NVIDIA domina la oferta en gamas medias y altas, sobre todo en portátiles. TUXEDO Computers, especialista en hardware para Linux, lo resume como una mezcla de estructura de mercado, disponibilidad de GPU y demanda del cliente.
Qué ha mejorado y qué sigue pendiente
En los últimos años NVIDIA ha dado pasos apreciables. El más comentado es la publicación de módulos abiertos del kernel para GPU Turing y posteriores, que la compañía recomienda usar por defecto en esas generaciones. Esto ordena el apartado de licencias, reduce zonas grises y mejora la capacidad de depuración dentro del kernel. Ya no es solo una promesa: es una opción real en drivers modernos.
También ha mejorado mucho el terreno de las GPU híbridas. Durante años, la conmutación entre gráficos integrados y dedicados fue problemática porque NVIDIA no ofrecía soporte oficial completo en Linux. Hoy el modo bajo demanda funciona de forma fiable en la mayoría de distribuciones, con PRIME como mecanismo estándar. Eso permite usar la iGPU para el escritorio y activar la dGPU solo cuando hace falta, con un consumo más contenido.
El avance en Wayland ha sido otro punto clave. Desde el driver 495 se añadió soporte GBM, fundamental para Wayland, y versiones posteriores como 525, 550 y 590 han ido puliendo la integración. GNOME con Wayland y driver NVIDIA 550 o superior funciona de forma muy estable en gran parte del hardware. KDE Plasma con Wayland todavía puede dar algún problema ocasional, así que quien busque estabilidad absoluta a veces prefiere X11.
Lo que sigue pendiente es la parte en espacio de usuario y buena parte de la pila gráfica, que continúan siendo privativas. Eso mantiene fricciones en la integración y en la experiencia desde el primer arranque. En comparación directa, el rendimiento del driver NVIDIA en Linux suele quedar por detrás de su equivalente en Windows en varios escenarios. AMD e Intel, en cambio, tienden a un rendimiento más equilibrado entre ambos sistemas gracias a su integración más profunda en la pila abierta.
Las opciones de controlador que ofrece NVIDIA

Cuando descargas un driver desde la web de NVIDIA, te encuentras con etiquetas que marean: Todo, WHQL, GRD, NSD, PB/ODE, NFB/QNF, PB/LLB, NFB/SLB, Beta y Recomendado por NVIDIA. Cada una responde a un perfil distinto. No son caprichos: indican el ciclo de vida, el tipo de certificación y el público objetivo. Entenderlas evita instalar la rama equivocada.
- Todo: muestra todas las opciones de controlador disponibles para el producto seleccionado, sin filtrar por rama ni certificación.
- WHQL: son las pruebas de los Laboratorios de Calidad de Hardware de Windows. Se ejecutan baterías de pruebas sobre hardware o software de terceros y se envían los registros a Microsoft para su revisión. El proceso también puede incluir pruebas propias de Microsoft en distintos equipos y ediciones de Windows.
- GRD: Controlador Game Ready. Está pensado para jugadores que priorizan compatibilidad con los últimos juegos, parches y DLC desde el día de lanzamiento.
- NSD: Controladores de Studio. Apuntan a creadores de contenido que valoran estabilidad y calidad en flujos como edición de vídeo, animación, fotografía, diseño gráfico o streaming.
- PB/ODE: Controlador de Rama de Producción o Studio. Ofrece estabilidad y rendimiento óptimos, certificación ISV, soporte de ciclo de vida largo y acceso a las mismas funciones que los Studio equivalentes. Antes se conocía como Controlador Óptimo Quadro para Empresas.
- NFB/QNF: Controlador de la Rama de Nuevas Características. Da acceso temprano a nuevas funciones, correcciones, compatibilidad con nuevos sistemas operativos y mejoras entre versiones de producción. Su soporte dura menos y se prueba en entornos de estación de trabajo con soporte reducido. Antes era Nueva Función de Quadro.
- PB/LLB: Controlador de Rama de Producción para Unix. Proporciona certificación ISV y estabilidad y rendimiento óptimos para clientes Unix. Se usa mucho en empresas y mantiene corrección de errores y actualizaciones de seguridad. Antes era Rama de Larga Duración de Linux.
- NFB/SLB: Controlador de la Rama de Nuevas Características para Unix. Está dirigido a primeros usuarios y desarrolladores que quieren las últimas funciones antes de que lleguen a producción. Antes era Rama de Corta Duración de Linux.
- Versión Beta: versiones preliminares para corregir errores rápido y probar novedades. Pasan por pruebas de cualificación y pueden tener fallos importantes. NVIDIA recomienda hacer copia de seguridad y comprobar antes si hay controladores recomendados o certificados más recientes. No ofrecen garantía ni soporte.
- Recomendado por NVIDIA: cumple niveles de calidad aplicados a los controladores de Windows que superan las pruebas WHQL, aportando fiabilidad, robustez y rendimiento también en sistemas no Windows, como Linux.
Arquitecturas: Tesla, Fermi, Kepler, Maxwell, Pascal, Volta, Turing, Ampere, Ada Lovelace y Blackwell
NVIDIA bautiza cada generación con un nombre en clave. Esos nombres no son versiones de software, sino arquitecturas de hardware. Marcan cómo está construida la GPU y, por tanto, qué driver necesitas y qué tecnologías soporta. Conocerlos es la base para no perderte entre números.
- Tesla (2006-2010): primera arquitectura con soporte unificado de shaders. Incluye GeForce 8, 9 y 200. En Linux solo tiene el driver 340.x, en mantenimiento.
- Fermi (2010-2012): mejoró el rendimiento en cómputo. GeForce 400 y 500. Soporte hasta el driver 390.x, hoy sin soporte activo.
- Kepler (2012-2014): mejoras de eficiencia energética. GeForce 600 y algunas 700. Soporte oficial hasta 390.x, con parches de comunidad para kernels modernos.
- Maxwell (2014-2016): gran salto en eficiencia. GeForce 900 y algunas 700. Driver recomendado desde 390.x, aunque hoy se aconseja 470.x o 550.x.
- Pascal (2016-2018): muy popular en Linux. GTX 1000 y Titan X Pascal. Soporte desde 390.x y hoy se recomienda 550.x o superior.
- Volta (2017-2018): sobre todo centros de datos. Titan V. Soporte completo desde 390.x.
- Turing (2018-2020): introdujo ray tracing por hardware y núcleos Tensor para IA. RTX 2000. Primera generación con ray tracing en Linux vía Vulkan. Driver mínimo recomendado 470.x.
- Ampere (2020-2022): mejoró ray tracing y rendimiento general. RTX 3000. Mínimo 470.x, recomendado 525.x o superior.
- Ada Lovelace (2022-2024): RTX 4000. Mejoras en DLSS 3 y Frame Generation. Requiere 525.x o superior; hoy se recomienda 550.x o 590.x.
- Blackwell (2024-presente): RTX 5000. Avances en IA y rendimiento. En Linux necesita driver 570.x o superior para un soporte adecuado.
Versiones de driver en Linux: de la 340 a la 590
NVIDIA publica varias ramas simultáneas. Cada una cubre GPUs distintas y tiene un ciclo de vida diferente. Aquí está el mapa de las versiones más relevantes.
- 340.x: rama legacy para tarjetas muy antiguas Tesla y Fermi antiguo. Ya no tiene mantenimiento oficial, aunque algunas distribuciones como Debian la parchean. GeForce 8, 9, 100M, 200 y 300.
- 390.x: amplía soporte a Fermi y Kepler. Fue la rama estable para gama media antigua. Hoy es legacy. GeForce 400, 500, 600 y 700.
- 470.x: fue la rama de soporte a largo plazo para Kepler tardío, Maxwell y Pascal antiguo. Entró en fase legacy, pero sigue siendo válida en muchos equipos con GTX 900. Actualizaciones de seguridad ocasionales.
- 525.x y 535.x: transición al soporte moderno. Mejoraron compatibilidad con kernels recientes y Wayland. Compatibles con Maxwell, Pascal, Volta, Turing, Ampere y Ada Lovelace. Hoy están superadas por versiones nuevas.
- 550.x: una de las ramas más recomendadas para uso cotidiano. Mejoras para Wayland, GSP firmware y kernel moderno. Es la opción por defecto en muchas distribuciones como Ubuntu 24.04. Ideal para Pascal en adelante.
- 560.x: introdujo los módulos de kernel abiertos como opción recomendada por defecto en Turing y superiores. Cambio histórico: NVIDIA empezó a favorecer sus módulos abiertos frente a los privativos clásicos. Recomendado para GPUs modernas.
- 570.x y 575.x: añaden soporte completo para Blackwell, RTX 5000. Mejoran Vulkan, compositores Wayland y PRIME para portátiles híbridos. Blackwell requiere esta rama como mínimo.
- 580.x y 590.x: estado del arte actual. La 590 consolida los módulos de kernel abiertos como estándar y mejora notablemente Vulkan y Wayland. Para GPU moderna y distribución actualizada, es la mejor elección disponible. Compatibilidad plena desde Pascal; Maxwell con soporte parcial.
Tabla resumen: qué driver necesita tu GPU
| Arquitectura | Ejemplo de GPU | Driver recomendado | Estado |
|---|---|---|---|
| Tesla antiguo | GeForce 8, 9 | 340.x | Legacy |
| Fermi | GeForce 400, 500 | 390.x | Legacy |
| Kepler | GTX 600, 700 | 470.x | Legacy |
| Maxwell | GTX 900 | 470.x / 550.x | Activo |
| Pascal | GTX 1000 | 550.x / 590.x | Activo |
| Volta | Titan V | 550.x / 590.x | Activo |
| Turing | RTX 2000 | 560.x / 590.x | Activo |
| Ampere | RTX 3000 | 560.x / 590.x | Activo |
| Ada Lovelace | RTX 4000 | 570.x / 590.x | Activo |
| Blackwell | RTX 5000 | 570.x / 590.x | Activo |
Nouveau: el driver libre que viene por defecto
Nouveau es el controlador de código abierto desarrollado por la comunidad. Viene instalado por defecto en la mayoría de distribuciones como Ubuntu, Fedora o Debian. Su gran ventaja es que funciona sin instalar nada: arrancas Linux y la tarjeta da imagen. Para uso de escritorio básico puede ser suficiente.
Sus limitaciones son importantes. No accede a la gestión completa de frecuencias, así que el rendimiento en juegos o cargas pesadas es muy inferior al driver oficial. No soporta CUDA, por lo que no sirve para IA, ciencia o diseño que dependan de esa plataforma. Tampoco ofrece Vulkan completo y estable, y con tarjetas muy recientes puede dar pantallas negras al arrancar. Si quieres exprimir una GPU NVIDIA, necesitas el driver propietario.
Vulkan, OpenCL y OpenGL en el ecosistema Linux
Vulkan es una API gráfica de bajo nivel del Khronos Group. Ofrece control más directo sobre la GPU que OpenGL y permite mejor rendimiento en juegos y aplicaciones compatibles. En Linux es clave porque sostiene DXVK, la capa que traduce DirectX 11 y 12 a Vulkan para ejecutar juegos mediante Proton. Si juegas en Linux, necesitas Vulkan funcionando bien. Los drivers NVIDIA incluyen soporte completo desde 390.x, pero para Vulkan 1.3 y ray tracing avanzado hacen falta Turing o superior y driver 525.x o más reciente.
OpenCL es un estándar para cómputo paralelo en GPU. Se usa en edición de vídeo, renderizado 3D, ciencia de datos e IA. Con los drivers propietarios de NVIDIA funciona automáticamente. En Ubuntu puedes instalar las librerías con sudo apt install nvidia-opencl-dev. No hay que confundirlo con CUDA, que es la plataforma propietaria de NVIDIA, rinde más en su hardware, pero OpenCL es multiplataforma y funciona también en AMD e Intel.
OpenGL sigue siendo relevante aunque Vulkan lo esté reemplazando poco a poco. Muchas aplicaciones profesionales como Blender en parte, FreeCAD o AutoCAD para Linux usan OpenGL. Los drivers NVIDIA ofrecen soporte completo de OpenGL 4.6, la versión más reciente. Nouveau también soporta OpenGL, pero limitado a versiones anteriores y con menos rendimiento.
PRIME y portátiles híbridos
Si tienes un portátil con gráficos integrados Intel o AMD y una GPU NVIDIA dedicada, PRIME es el sistema que gestiona la conmutación. Permite elegir qué GPU usa cada aplicación. Existen dos modos principales: PRIME Sync y PRIME Offload.
PRIME Sync hace que la GPU NVIDIA renderice directamente en la pantalla. Elimina el tearing y mejora el rendimiento, pero consume más batería. PRIME Offload deja que la GPU integrada gestione el escritorio y activa la NVIDIA solo cuando se necesita. Es ideal para conservar autonomía mientras trabajas con aplicaciones ligeras. Para lanzar una aplicación con la dGPU se puede usar __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia aplicacion.
Desde el driver 435 en adelante, NVIDIA mejoró mucho PRIME en Linux. La integración con GNOME y KDE es actualmente bastante fluida. Aun así, el reto principal está en la experiencia de usuario: a menudo no es transparente qué GPU está usando una aplicación, no hay una interfaz gráfica central y unificada para controlarlo y algunas opciones solo están en línea de comandos. Los motores modernos, Wine y Proton detectan varias GPU y eligen la más potente, lo que ayuda, pero la gestión manual sigue siendo mejorable.
Módulos de kernel abiertos, DKMS y GSP
Desde la versión 515.x, NVIDIA publicó los módulos de kernel abiertos. Es un hito, pero conviene aclarar que solo son abiertos esos módulos; el resto del driver, incluidas las librerías de espacio de usuario, sigue siendo propietario. Desde el driver 560.x, NVIDIA recomienda usarlos por defecto en GPU Turing y superiores. Esto mejora la integración con el kernel y facilita la distribución en repositorios. Puedes comprobar la versión con cat /proc/driver/nvidia/version.
DKMS es el sistema que recompila automáticamente los módulos del driver al actualizar el kernel. Es crucial con NVIDIA: sin DKMS, cada actualización de kernel podría dejarte sin GPU hasta recompilar a mano. Al instalar desde repositorios de la distribución, DKMS se configura solo. Si usas el instalador .run oficial, debes asegurarte de incluirlo manualmente.
GSP es el GPU System Processor que NVIDIA incluye desde Turing. Puede ejecutar parte del firmware del driver de forma autónoma y reduce la carga en la CPU. Los drivers modernos, desde aproximadamente 510.x, pueden usar GSP firmware para mejorar rendimiento y estabilidad, sobre todo en virtualización y servidores. Se puede verificar con nvidia-smi -q | grep GSP.
Wayland y NVIDIA: una relación que ha mejorado
Durante años, Wayland y NVIDIA no se llevaron bien. Los usuarios de GNOME en Fedora con drivers NVIDIA sufrían problemas. La situación cambió radicalmente desde el driver 495, cuando se añadió soporte GBM, pieza fundamental para Wayland. Las versiones 525, 550 y 590 han seguido perfeccionando esa integración. Hoy GNOME con Wayland y driver NVIDIA 550 o superior funciona de forma muy estable en la mayoría del hardware.
KDE Plasma con Wayland y NVIDIA todavía puede presentar pequeños problemas ocasionales. Por eso algunos usuarios prefieren KDE con X11 si su prioridad es la estabilidad absoluta. La documentación de NVIDIA sobre la serie 595 explica que las diferencias arquitectónicas entre X11 y Wayland afectan al conjunto de funciones que el driver puede ofrecer, por qué se ven impactadas y si podrán soportarse en el futuro. Es un recordatorio de que la transición a Wayland sigue viva y no está cerrada del todo.
Rendimiento, inteligencia artificial y juegos

En rendimiento bruto, NVIDIA suele ir sobrada tanto en juegos como en cargas profesionales. Pero su punto débil histórico no ha sido la potencia, sino la experiencia de escritorio y la integración con el sistema. En Linux, el driver de NVIDIA queda por detrás de su versión para Windows en muchos escenarios. Con AMD e Intel el panorama es más equilibrado: el rendimiento gráfico en Linux y Windows suele ser comparable gracias a su integración en la pila abierta.
CUDA sigue siendo el argumento más fuerte de NVIDIA. Es el estándar de facto para muchos frameworks de IA y modelos de lenguaje. AMD ha avanzado con ROCm y hoy muchas cargas populares pueden ejecutarse en su hardware con poco esfuerzo extra. Aun así, ROCm todavía tiene dificultades de instalación, soporte por distribución y disponibilidad de paquetes actualizados. La distancia se reduce, pero CUDA mantiene un ecosistema mayor, más soporte de software y una experiencia más madura.
Si el objetivo es jugar exclusivamente en Linux, AMD se ha consolidado como opción muy equilibrada. Sus drivers abiertos en kernel y Mesa hacen que buena parte funcione directamente, con rendimiento comparable o incluso mejor que en Windows. Tiene dos limitaciones prácticas: no hay equivalente directo a NVIDIA en la gama más alta y sus GPU para portátil son difíciles de encontrar. NVIDIA sigue sumando puntos por presencia en gama alta y disponibilidad en portátiles.
Intel Arc ha avanzado técnicamente y está bien integrada en Linux gracias a su alineación con la pila abierta. La calidad del driver ha mejorado y la arquitectura es competitiva. Pero su papel en mercado de usuario final sigue siendo menor: apenas está en portátiles y AMD y NVIDIA dominan la percepción. Es interesante, pero todavía no una opción asentada para la mayoría.
En juegos, la valoración se desplaza del rendimiento bruto a la madurez del driver y las tecnologías de reescalado. NVIDIA destaca en trazado de rayos y DLSS, con gran calidad de imagen y eficiencia. AMD apuesta por FSR como solución más abierta y disponible, aunque depende de la implementación de cada juego. Pero la calidad del driver en Linux, sus actualizaciones y su integración limpia importan tanto o más que las siglas comerciales.
Por qué los fabricantes siguen eligiendo NVIDIA

Los fabricantes de portátiles recurren de forma abrumadora a NVIDIA en gamas media y alta. También muchos proveedores centrados en Linux, pese a las reservas de la comunidad. La razón principal es una combinación de estructura de mercado y disponibilidad de hardware. NVIDIA tiene una posición muy fuerte en el segmento OEM, mientras AMD mantiene una oferta más limitada en móvil e Intel Arc no juega apenas en portátiles.
Encima de esa base entran la demanda de los clientes y el ecosistema. NVIDIA se elige a menudo porque su rendimiento y pila de software convencen, y porque muchos equipos también se usan con Windows, donde los drivers abiertos no son el criterio principal. Parte de la responsabilidad también recae en AMD: sería deseable más iniciativa en portátiles para traducir sus ventajas técnicas en Linux a una oferta de hardware más amplia.
AMD ha mejorado mucho en portátiles. Las Radeon actuales ofrecen rendimiento comparable o superior en algunas categorías, sobre todo en Linux con drivers abiertos. Las plataformas Strix Halo, que combinan CPU y gráficos integrados potentes, son un ejemplo interesante como alternativa a la GPU dedicada tradicional. La elección depende del caso de uso, requisitos y presupuesto, porque ambos ecosistemas han alcanzado un nivel técnico alto.
En gráficos integrados para portátiles y mini PC, AMD tiene ventajas estructurales: CPU y GPU nacen de un diseño unificado y están optimizadas para eficiencia y latencia. NVIDIA todavía está desarrollando su presencia en ese segmento y colabora con Intel en futuras combinaciones. La cuestión de fondo es que gran parte de los recursos de desarrollo se dirige a infraestructura de IA y centros de datos, donde los márgenes son mayores. El mercado de escritorio y portátil para usuario final pesa cada vez menos, lo que afecta al ritmo de innovación.
TUXEDO tuvo en catálogo el Sirius, un portátil con gráfica dedicada AMD, algo poco habitual. La compañía sigue considerando interesantes los portátiles con Radeon dedicada, pero las decisiones dependen de disponibilidad de plataformas, suministro a largo plazo, objetivos de rendimiento y demanda. Evalúan continuamente hardware de AMD y NVIDIA, porque existe un grupo de usuarios que prefiere un sistema íntegramente AMD por motivos técnicos, ideológicos o de ecosistema.
Listado histórico de GPU compatibles
Las tablas antiguas de NVIDIA y los repositorios de drivers incluyen un inventario enorme de identificadores PCI para modelos legacy. Aparecen desde GeForce2 Go 0x0112, GeForce2 Integrated GPU 0x01A0, GeForce2 MX 100/200 0x0111 y GeForce2 MX/MX 400 0x0110, hasta GeForce3 0x0200, GeForce3 Ti 200 0x0201 y GeForce3 Ti 500 0x0202. También GeForce4 Go 410 0x017D, GeForce4 4200 Go 0x0286, GeForce4 420 Go 0x0175, GeForce4 440 Go 0x0174, GeForce4 MX 4000 0x0185, GeForce4 Ti 4200 0x0253 y muchos más.
La familia GeForce 6xxx y 7xxx ocupa un bloque extenso: GeForce 6100 0x0242, 6150 0x0240, 6200 0x00F3, 6600 0x00F2, 6600 GT 0x0140, 6800 0x0041, 6800 Ultra 0x0040, 7300 GS 0x01DF, 7600 GS 0x02E1, 7800 GTX 0x0090, 7900 GTX 0x0290. Las FX también tienen su hueco: FX 5100 0x0327, FX 5200 0x0320, FX 5500 0x0326, FX 5600 0x0312, FX 5700 0x0342, FX 5800 0x0302, FX 5900 0x0331 y FX 5950 Ultra 0x0333. Las versiones Go y PCX completan el cuadro: GeForce Go 6200 0x0164, Go 6600 0x0144, Go 7300 0x01D7, Go 7800 GTX 0x0099, PCX 4300 0x00FF, PCX 5750 0x00FA, PCX 5900 0x00FB.
En el lado profesional, el listado incluye Quadro2, Quadro4, Quadro FX y Quadro NVS: Quadro2 MXR/EX/Go 0x0113, Quadro4 380 XGL 0x018B, Quadro4 550 XGL 0x0178, Quadro4 900 XGL 0x0258, Quadro DCC 0x0203, Quadro FX 1000 0x0309, FX 1100 0x034E, FX 2000 0x0308, FX 3400 0x00F8, FX 4400 0x00F8, FX 4500 X2 0x029F, FX 5500 0x029C, FX Go1000 0x034C, FX Go700 0x031C, Quadro NVS 0x017A, NVS 110M 0x01D7, NVS 280 PCI 0x032A, NVS 285 0x0165, NVS 440 0x014A y NVS 50 PCI 0x018C. Son modelos que hoy solo tienen sentido con drivers legacy como 340.x o 390.x.
Cómo instalar y comprobar el driver

Antes de tocar nada, conviene saber qué driver tienes. El comando nvidia-smi muestra la versión instalada, información de la GPU y uso de recursos. También puedes usar modinfo nvidia | grep ^version. En Ubuntu existe el Administrador de controladores adicionales, que detecta la GPU y sugiere la versión adecuada. En la mayoría de casos basados en Debian o Ubuntu, sudo ubuntu-drivers autoinstall selecciona automáticamente el driver más adecuado. Si prefieres una versión concreta, puedes usar sudo apt install nvidia-driver-590.
En Fedora y derivadas de Red Hat, el método recomendado es el repositorio RPM Fusion con sudo dnf install akmod-nvidia. En Arch Linux y derivadas como Manjaro, se instala con sudo pacman -S nvidia nvidia-utils. El instalador oficial .run de NVIDIA existe, pero no se recomienda salvo casos especiales porque puede generar conflictos con el gestor de paquetes de la distribución. Si lo usas, asegúrate de gestionar DKMS correctamente para no quedarte sin gráficos al actualizar el kernel.
La forma más segura suele ser confiar en los repositorios de tu distribución y en las herramientas automáticas. Así recibes actualizaciones integradas, parches de seguridad y compatibilidad con el kernel. Para GPUs modernas, la rama 590 es la más actual; para Maxwell o Pascal, una 550 puede ser más que suficiente. Para tarjetas Kepler o Fermi, toca aceptar ramas legacy y asumir que no habrá milagros de rendimiento.
Después de todo este repaso, queda claro que NVIDIA en Linux ya no es aquel desierto intratable que muchos recuerdan. Los módulos abiertos del kernel, la mejora de Wayland, PRIME y la disponibilidad de drivers en repositorios han convertido la experiencia en algo bastante decente para la mayoría. Sigue habiendo diferencias frente a AMD e Intel en integración y paridad de rendimiento con Windows, y las partes privativas mantienen cierta fricción. Pero si necesitas CUDA, DLSS, máximo rendimiento o un portátil con GPU potente, NVIDIA es una opción viable y no un suicidio técnico. La clave está en elegir la arquitectura y la rama correctas, instalar desde el canal adecuado y asumir que Linux no es Windows: a cambio, tienes un ecosistema que ha aprendido a convivir con NVIDIA mucho mejor que antes.