NVIDIA ha empezado a mover ficha en un frente clave para el ecosistema Linux: la compatibilidad temprana de sus próximas GPU “post-Blackwell” a través de Nova, el nuevo controlador gráfico de kernel escrito en Rust que la compañía desarrolla de forma abierta y con vocación upstream. En un paquete de parches remitido a las listas de correo del kernel, los ingenieros de la firma introducen soporte para un cambio de bajo nivel pero de enorme calado: el tránsito desde el histórico NV_PMC_BOOT_0 al NV_PMC_BOOT_42 como registro de referencia para identificar arquitectura y revisión de los chips venideros. La implicación es directa: las generaciones futuras dejarán a cero el viejo BOOT_0 y usarán BOOT_42 como fuente de verdad para esa información.
La serie de parches —firmada por John Hubbard— no es una curiosidad técnica más. Es, en palabras del propio ingeniero, una adaptación necesaria para que Nova “reclame” de forma estable a Turing y posteriores y, al mismo tiempo, esté lista para las GPU siguientes a Blackwell, que en la rumorología de la industria se agrupan bajo el nombre clave Rubin. En términos prácticos, el cambio reescribe la lógica de selección del driver y documenta, en orden cronológico, cómo han evolucionado los registros de arranque de las GPU de NVIDIA y cómo debe comportarse el código según la era arquitectónica.
¿Qué es exactamente Nova y por qué importa?
Nova es el intento de NVIDIA de dar un salto generacional en su presencia open source en Linux. Se trata de un driver de kernel escrito en Rust, pensado para GPU con GSP (GPU System Processor) y llamado a convertirse en el sucesor de Nouveau en el árbol principal del kernel para las generaciones modernas (arrancando en Turing/RTX 20 y cubriendo Ampere, Ada y Blackwell). Su estrategia técnica combina dos objetivos: seguridad/robustez (apoyándose en las garantías de memoria y concurrencia de Rust) y alineación con la hoja de ruta de NVIDIA, que desde Turing exige la presencia del firmware GSP para ciertas funciones de bajo nivel.
Aunque todavía está en construcción, Nova representa una apuesta inédita de NVIDIA por desarrollar a la vista de la comunidad bloques críticos del soporte Linux, publicando parches en las listas del kernel e integrando comentarios upstream. En ese contexto se enmarca la adopción de BOOT42, un detalle aparentemente arcano que, sin embargo, resulta imprescindible para que el driver reconozca y configure correctamente las GPU que vendrán después de Blackwell.
De BOOT0 a BOOT42: un cambio de llave para la próxima era
Hasta ahora, el registro NV_PMC_BOOT_0 contenía información de arquitectura y revisión de la GPU. Nova —como cualquier otro software que necesite saber qué silicio tiene delante— consultaba ese registro para decidir rutas de inicialización y tablas específicas de cada familia (desde NV04 a Turing/Ampere/Ada/Blackwell). El paquete de parches divulgado por NVIDIA establece que los futuros chips no usarán ya BOOT_0 para ese cometido; en su lugar, la información vivirá en NV_PMC_BOOT_42, mientras BOOT_0 quedará en cero.
El cambio no es solo una sustitución de direcciones: obliga a simplificar y endurecer la lógica de detección para que funcione de Turing en adelante sin depender de ifs frágiles. De hecho, el diff que acompaña a la serie elimina tipos como Spec y Revision y recorta unas 33 líneas netas de código, reforzando la claridad del módulo que maneja la enumeración de GPU y su bring-up. La propia nota de portada de la serie explica que, con esta estrategia, Nova podrá reclamar Turing y posteriores “de forma predecible durante un buen tiempo” sin nuevos cambios en esa pieza.
Contexto industrial: el valor de llegar a tiempo al kernel
En los últimos años, el soporte gráfico de NVIDIA en Linux ha avanzado en dos planos: por un lado, el driver propietario (módulo binario) que la compañía libera para sus gamas GeForce/Quadro/Data Center; por otro, el ecosistema abierto (Nouveau), tradicionalmente limitado por la falta de documentación y por la dependencia de firmware. Nova busca puentear esa brecha en las GPU modernas con Rust, GSP y una colaboración upstream más fluida, reduciendo la distancia entre lo que llega al kernel principal y lo que los usuarios pueden ejecutar en distribuciones mainstream.
El hecho de que los primeros parches “post-Blackwell” aparezcan tan pronto es significativo por dos razones. Primero, sugiere que los equipos de Linux en NVIDIA trabajan con visibilidad suficiente de su siguiente arquitectura como para acondicionar hoy las capas comunes del driver. Segundo, implica una madurez en el proceso interno: cuando cambias la fuente de identidad de la GPU (de BOOT_0 a BOOT_42), tiene sentido ajustar cuanto antes todo el código que depende de esa señal para evitar “deuda” técnica cuando lleguen las primeras muestras de silicio.
Qué puede esperar el usuario de Linux (y qué no, todavía)
Conviene separar el titular de las expectativas. Estos parches no traen soporte funcional para Rubin ni activan mágicamente un rendimiento superior en tus GPU actuales. Son, más bien, obras de infraestructura: preparan el camino para que, cuando las primeras tarjetas de la siguiente generación aparezcan, el kernel sepa quiénes son y por dónde empezar a inicializarlas.
Para los usuarios finales, lo tangible a corto plazo será limitado. Sin embargo, para distribuidores, mantenedores y desarrolladores del ecosistema, el cambio es una señal útil:
- Distribuciones que siguen de cerca el mainline podrán integrar pronto estos cambios y validar que no rompen la detección en Turing/Ampere/Ada/Blackwell.
- Proyectos de userspace (Mesa, Wayland/GBM, window managers) pueden anticipar nombres y rutas que afecten a udev rules, identificación de dispositivos y quirks.
- Herramientas de diagnóstico y telemetría podrán incorporar la noción de
BOOT_42para sus informes en sistemas de próxima hornada.
En paralelo, sigue abierta la gran cuestión: cómo de rápido y completo será el soporte operativo de Nova para las nuevas GPU una vez estén en la calle. La historia del soporte abierto de NVIDIA ha sido gradual y, en ocasiones, conservadora en cuanto a aceleración 3D, gestión de energía o funciones avanzadas. Que Nova nazca en Rust y con enfoque upstream no garantiza milagros, pero sí mejores cimientos para iterar.
¿Qué hay de Blackwell… y de Rubin?
Aunque NVIDIA no entra a nombrar públicamente la arquitectura posterior a Blackwell, distintos observadores del código y medios especializados interpretan este “next-gen” como una referencia a Rubin, el nombre en clave que circularía internamente para la siguiente generación. En la propia documentación de los parches se habla de Turing a Blackwell como generaciones que se siguen apoyando en BOOT_0, y de las posteriores como las que pasarán a BOOT_42 con BOOT_0 a cero. Es, por tanto, una marca técnica de “más allá de Blackwell”.
Desde el punto de vista de compatibilidad, la modificación en Nova pretende que el driver reclame desde Turing en adelante, por lo que no afecta a series anteriores (NV4x, Tesla, Fermi, Kepler, Maxwell, Pascal), donde Nouveau seguirá siendo el camino natural. En las GPUs modernas con GSP (Turing+), la teoría es que Nova se convierta con el tiempo en el driver de referencia en el kernel principal.
Seguridad, Rust y limpieza de código
La decisión de escribir Nova en Rust no es cosmética. En el terreno de drivers de kernel, donde un desbordamiento, una doble liberación o una condición de carrera pueden convertirse en vulnerabilidades graves, las garantías del lenguaje —propiedad de memoria, préstamos, lifetimes— reducen superficies enteras de fallo. La serie de parches que acompaña la adopción de BOOT_42 elimina tipos y simplifica la lógica de selección, una señal de que el equipo está tratando de pagar deuda técnica y dejar el terreno preparado para un futuro en el que esa ruta no se toque en años.
Impacto en el desarrollo de software y herramientas
Las aplicaciones y toolchains que interactúan con la GPU a bajo nivel —desde sistemas de provisioning y monitoreo de flotas hasta diagnóstico de hardware— tendrán que actualizar su lógica si dependían del contenido de NV_PMC_BOOT_0. En entornos corporativos donde se automatizan inventarios y controles de cumplimiento por familia de GPU, convendrá añadir detección doble (BOOT0/BOOT42) hasta que la base instalada de Rubin y siguientes lo haga imprescindible.
Para los proyectos de terceros que aspiran a integrar con Nova, la recomendación evidente es seguir de cerca las listas de correo y el repositorio correspondiente, dado que las APIs internas y los nombres de constantes/registros están en pleno movimiento para acomodar este y otros cambios. La buena noticia es que el trabajo se está realizando a la vista de todos, lo que facilita comentar, proponer y evitar sorpresas.
¿Qué puede venir después?
Si NVIDIA mantiene el ritmo, veremos más parches que extiendan tablas, rutas de inicialización y capas de gestión de energía orientadas a los primeros samples de la siguiente generación. También es razonable esperar documentación adicional en el árbol de código de Nova que explique cómo se debe interpretar BOOT42, qué bits codifican familia/revisión y qué combinaciones distinguen arquitecturas. En paralelo, el trabajo para Blackwell seguirá su curso en Nova y en el driver propietario —con el horario que marquen los lanzamientos comerciales—.
Recomendaciones para usuarios y early adopters en Linux
- Sigue el mainline: si te gusta probar cosas nuevas, compila kernels recientes o usa una distro rolling para recibir pronto estos parches y verificar estabilidad en Turing/Ada/Blackwell.
- Observa el dmesg: cuando aterrices una build con Nova actualizado, revisa mensajes de detección e inicialización de GPU; ahí verás si el código “reclama” correctamente tu dispositivo.
- Mantén expectativas realistas: esto no es una mejora de rendimiento, sino un pilar para reconocer futuras GPU. El soporte funcional y 3D completo llegará con más iteraciones.
- Participa: si detectas regresiones en identificación, reporta con
lspci -nn, dmesg y versiones exactas del kernel; tu caso puede ayudar a pulir la transición.
Preguntas frecuentes
¿Qué es NV_PMC_BOOT_42 y por qué reemplaza a BOOT_0?NV_PMC_BOOT_42 es un registro de arranque que, en las próximas GPU de NVIDIA, almacenará los detalles de arquitectura y revisión del chip. Históricamente esa información residía en NV_PMC_BOOT_0, pero en las generaciones post-Blackwell BOOT_0 se quedará a cero. Nova actualiza su lógica para leer BOOT_42 y así identificar correctamente las GPU nuevas.
¿Qué diferencia hay entre Nova y Nouveau en Linux?
Nouveau es el driver abierto tradicional para GPU de NVIDIA y lleva años en el kernel mainline, con soporte amplio pero limitado por la ausencia de ciertos componentes propietarios. Nova es un driver nuevo escrito en Rust, orientado a GPU con GSP (Turing y posteriores), que NVIDIA desarrolla a la vista de la comunidad con la intención de sustituir progresivamente a Nouveau en las generaciones modernas.
¿Significa esto que mi GPU actual será más rápida o más compatible?
No de forma inmediata. Los parches anunciados preparan el driver para reconocer futuras GPU y simplifican la detección de arquitecturas en Turing→Blackwell. Las mejoras de rendimiento o nuevas funciones llegarán en series posteriores de parches que amplíen la aceleración, la gestión energética y el resto de la pila.
¿Se confirma el nombre “Rubin” y cuándo saldrán esas GPU?
El código habla de “next-gen GPUs” y de un cambio a BOOT_42 más allá de Blackwell. Varios analistas asocian esa referencia con la supuesta arquitectura “Rubin”, pero NVIDIA no ha anunciado públicamente detalles ni calendarios. Los parches son una señal técnica temprana, no un lanzamiento comercial.
Fuentes: Anuncio y parches en las listas de correo del kernel (serie “gpu: nova: add boot42 support for next-gen GPUs” firmada por John Hubbard) y cobertura de la novedad en Phoronix; documentación de Rust-for-Linux sobre el proyecto Nova.
vía: phoronix
