- Diferencias fundamentales entre el driver de código abierto Nouveau y los controladores propietarios de NVIDIA.
- Relación entre las arquitecturas de hardware (como Pascal, Ampere o Blackwell) y la versión del driver necesaria.
- Procedimientos de diagnóstico y configuración de variables de entorno para activar CUDA y OpenCL.
- Gestión de módulos de kernel abiertos y compatibilidad con Wayland en distribuciones modernas.
Instalar los controladores de NVIDIA en Linux puede parecer, a primera vista, una verdadera pesadilla. Entre nombres de arquitecturas que parecen sacados de una película de ciencia ficción y versiones de software que cambian cada dos por tres, es normal que cualquier usuario, desde el más novato hasta el más curtido, acabe con la cabeza hecha un lío. La realidad es que la comunicación entre las herramientas de instalación y el sistema operativo no siempre es la más fluida, lo que suele derivar en errores frustrantes al intentar ejecutar aplicaciones de alto rendimiento.
Sin embargo, una vez que entiendes cómo encajan las piezas, el panorama cambia totalmente. Ya no se trata solo de que la pantalla dé imagen, sino de aprovechar la potencia bruta de la tarjeta para tareas de inteligencia artificial, renderizado 3D o computación paralela. En este sentido, dominar la configuración de CUDA y OpenCL es la diferencia entre tener un pisapapeles caro o una estación de trabajo capaz de mover montañas de datos.
El dilema del driver: ¿Nouveau o Propietario?
Cuando instalas una distro como Ubuntu o Fedora, lo primero que te encuentras es Nouveau. Este es el controlador de código abierto desarrollado por la comunidad y su gran baza es que funciona directamente sin instalar nada. Pero ojo, que no todo es color de rosa: si buscas exprimir la GPU, Nouveau se queda corto. No tiene soporte real para CUDA, su gestión de frecuencias es limitada y, en tarjetas muy modernas, puede darte algún que otro susto como problemas de pantallas negras al arrancar.
Para quienes necesitamos potencia, la única opción sensata es el driver propietario de NVIDIA. Solo con este podemos acceder a Vulkan completo, Ray Tracing y, por supuesto, a las librerías de cómputo. Aunque NVIDIA ha empezado a abrir sus módulos de kernel desde la versión R515, es importante entender que el espacio de usuario sigue siendo privativo, lo que significa que OpenGL y CUDA no son precisamente software libre.
Entendiendo las Arquitecturas y sus Drivers
NVIDIA no lanza un driver único para todo, sino que segmenta el soporte según la arquitectura de la tarjeta. Aquí es donde mucha gente se pierde. Por ejemplo, si tienes una tarjeta muy antigua de la era Tesla o Fermi (series 200, 400 o 500), estarás condenada a usar el driver 340.x o 390.x, que ya están en modo legacy y apenas reciben mantenimiento.
- Maxwell y Pascal: Las famosas GTX 900 y 1000. Aunque el soporte empieza en versiones antiguas, hoy en día se recomienda saltar a la rama 550.x o incluso la 590.x para tener estabilidad.
- Turing y Ampere: Las series RTX 2000 y 3000. Aquí ya entramos en terreno moderno, donde los núcleos Tensor y el Ray Tracing son los protagonistas. El driver 560.x es ideal, ya que favorece los módulos de kernel abiertos.
- Ada Lovelace y Blackwell: Las RTX 4000 y las nuevas 5000. Para estas bestias necesitas, como mínimo, la versión 570.x, aunque la 590.x es la que marca el estado del arte actual en rendimiento y compatibilidad con Wayland.
Puesta a punto de CUDA y OpenCL
Si al lanzar una aplicación de OpenCL te dice que no encuentra el dispositivo, lo más probable es que el driver esté mal instalado o que el sistema no sepa dónde buscar las librerías. El primer paso es lanzar un nvidia-smi en la terminal. Si ves la tabla con tu GPU y la versión del driver (que debería empezar por 5 en sistemas modernos), vas por buen camino. Si no, toca reinstalar.
A veces, el compilador nvcc no responde aunque el driver esté ahí. Esto pasa porque las rutas de los ejecutables de CUDA no están en las variables de entorno. Para arreglarlo de forma permanente, debes editar el archivo /etc/environment y añadir las rutas a /bin y /lib64 de tu versión específica de CUDA (por ejemplo, la 12.6). Sin esto, el sistema simplemente no encuentra el kit de herramientas necesario para compilar el código.
Diagnóstico avanzado de OpenCL
Para saber si OpenCL está realmente operativo, la herramienta estrella es clinfo. Al ejecutarla, debes fijarte especialmente en el número de plataformas y dispositivos. Si el número de plataformas es 0, tienes un problema de drivers. Si todo está correcto, verás que el sistema reconoce tu GPU como un dispositivo de cómputo disponible. Si aun así falla, puede que falten las librerías básicas; en Ubuntu, esto se soluciona instalando ocl-icd-opencl-dev y los opencl-headers.
En casos muy concretos, especialmente con hardware antiguo como la Tesla V100 en Ubuntu 22.04, puede ocurrir que OpenCL sea inaccesible. En esos escenarios, la solución más drástica pero efectiva es hacer un downgrade del sistema operativo a Ubuntu 20.04 y bajar la versión de CUDA y el driver a combinaciones más estables, como el driver 535 y CUDA 12.2.
Configuraciones Especiales: Secure Boot y Wayland
Un dolor de cabeza habitual es el arranque seguro o Secure Boot. Si está activo, el kernel de Linux rechazará el driver de NVIDIA porque no está firmado digitalmente por una clave conocida. Para solucionar esto sin desactivar la seguridad de la BIOS, hay que importar la clave pública de NVIDIA mediante mokutil, reiniciar el equipo y, en la pantalla azul de gestión MOK, aceptar la inscripción de la clave. Si te saltas este paso, el driver jamás cargará.
En cuanto al entorno gráfico, la relación entre NVIDIA y Wayland ha sido tormentosa. Sin embargo, gracias a la implementación de GBM (Generic Buffer Manager) en versiones recientes, la experiencia en GNOME es ahora muy fluida. No obstante, si usas KDE Plasma y notas tirones o inestabilidad, lo más recomendable sigue siendo volver a X11 para garantizar una estabilidad absoluta.
Gestión de GPUs Híbridas con NVIDIA PRIME
Si usas un portátil con gráfica integrada y una dedicada, necesitas dominar NVIDIA PRIME. Tienes dos caminos: el modo Sync, donde la GPU NVIDIA hace todo el trabajo (más potencia, pero la batería vuela), y el modo Offload, que es el más inteligente. En este último, el sistema usa la integrada para el escritorio y solo activa la NVIDIA cuando tú se lo pides explícitamente mediante variables de entorno en la terminal.
Para evitar que el sistema se rompa cada vez que el kernel se actualiza, es vital que el driver esté instalado mediante DKMS (Dynamic Kernel Module Support). Esto hace que el módulo del driver se recompile automáticamente con el nuevo kernel, evitando que te despiertes un día y descubras que tu GPU ha dejado de funcionar misteriosamente.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.