8 Minuter
NVIDIA har tyst börjat lägga grunden för sina nästa generations GPU:er. Nya patcher till Nova-drivrutinen visar att företaget skiftar från den länge använda Boot0-registreringen till en ny Boot42‑identifierare — en förändring som pekar mot Rubin som serverarkitektur och en större moderniseringsinsats för Linux‑grafik.
Why Boot42 matters for GPUs and Linux
Under många år använde NVIDIA registret NV_PMC_BOOT_0 för att identifiera GPU‑arkitekturer och revisioner. De nya uppdateringarna i Nova‑drivrutinen ersätter den logiken med NV_PMC_BOOT_42, vilket i praktiken nollställer Boot0 för framtida kretsar. Det kan låta som en intern detalj, men det förenklar detektionslogiken, minskar beroendet av gamla specialfall och gör drivrutinskoden renare samt mer framåtriktad vad gäller kompatibilitet.
För Linux‑gemenskapen och öppen källkod för grafikdrivrutiner är detta en viktig signal. Ett mer konsekvent registerformat förenklar upstream‑arbete, gör det lättare att integrera förändringar i Linux‑kärnan och minskar behovet av ad hoc‑patchar som bara gäller för specifika chipgenerationer. Genom att använda NV_PMC_BOOT_42 som en kanonisk källa för arkitektur‑ och revisionsidentifiering blir det enklare för både kärn‑ och användarrumsutvecklare att bygga robust stöd för nya NVIDIA‑GPU:er.
Det är också viktigt att notera hur dessa förändringar har implementerats. Nova‑patcherna är en del av det öppna Nova‑drivrutinsprojektet och utvecklas i Rust, vilket signalerar ett modernare angreppssätt för grafikdrivrutiner. Rusts typ‑ och minnessäkerhet kan förbättra stabilitet och minska risk för vanliga minnesproblem som historiskt har varit svåra att hantera i C‑kodbaser. För organisationer och utvecklare som arbetar med Linux‑GPU‑drivrutiner innebär detta bättre möjlighet till långsiktigt underhåll, snabbare upstreamning och enklare felsökning.
What the Nova patches reveal
- Boot0 är under avveckling och kommer att nollställas för kommande GPU:er.
- NV_PMC_BOOT_42 blir det kanoniska registret som Nova använder för att identifiera arkitekturer och revisioner.
- Valningslogiken i drivrutinen uppdateras så att Nova korrekt kommer att påstå stöd för Turing och senare GPU:er utan ytterligare patchning.
- Ändringen tar bort ungefär 33 rader kod, vilket förbättrar läsbarheten och underlättar underhåll.
- Nova‑utvecklingen går framåt i Rust, vilket indikerar ett modernt förhållningssätt till drivrutinsutveckling.
Var och en av dessa punkter har tekniska följdverkningar. Att Boot0 nollställs innebär att gammal detektionslogik som förlitade sig på specifika bitmönster inte längre kan användas, vilket i sin tur tvingar fram en mer generell och arkitekturagnostisk metod för identifiering. NV_PMC_BOOT_42 fungerar som en entydig källa för metadata om GPU:n, inklusive familjetillhörighet och revision, vilket underlättar automatisk val av rätt kodvägar i drivrutinen.
Att drivrutinsvalet uppdateras så att Nova automatiskt kan ta ansvar för Turing‑ och senare‑GPUs betyder mindre fragmentering inom Linux‑ekosystemet. I praktiken kan detta minska tiden mellan att en ny GPU lanseras och att stöd för den finns i upstream‑kärnan eller i den öppna drivrutinskoden. För projekt som bygger på upstream‑drivrutiner — exempelvis vissa containeriserade AI‑plattformar, HPC‑kluster och molntjänster — är snabb och stabil integration av nya GPU:er en konkurrensfördel.
De cirka 33 rader kod som tas bort är symboliska för en större inriktning: att minska legacy‑specialfall och göra koden lättare att läsa och revidera. I stora kodbaser ackumuleras snabbt små specialfall som ökar komplexiteten och risken för regressionsfel vid framtida ändringar. Varje förenkling är därför värdefull för både säkerhet och utvecklingstempo, särskilt i en kritisk komponent som en GPU‑drivrutin.
Dessutom betyder övergången till Rust att projektet drar nytta av språkets säkerhetsgarantier och moderna verktyg för pakethantering, testning och formell verifiering. För organisationer som prioriterar code quality, säkerhet och långsiktigt underhåll är detta en positiv utveckling som även kan påverka hur hårdvarupartners och datacenterkunder planerar sina portföljer.
Rubin on the horizon — what to expect
Dessa förändringar ligger i linje med tidigare rapporter som pekar på Rubin som NVIDIAs nästa serverklassade arkitektur. Enligt flera källor och analyser har volymproduktion för Rubin planerats till andra halvan av 2026. Det innebär att förberedelserna i mjukvarustacken pågår i god tid för att säkerställa kompatibilitet och stabilitet i moln‑ och datacenter‑miljöer.
Det finns även indikationer på att en högpresterande variant, ofta refererad till som Rubin Ultra, kan komma att använda microchannel cover plates för förbättrad termisk prestanda. Microchannel‑kylning ger högre värmeavgivning per ytenhet och möjliggör effektivare temperaturkontroll i tätt packade GPU‑racks. För hyperscale‑datacenter och OEM‑leverantörer av kylsystem kan detta kräva anpassningar i både mekanisk design och kylinfrastruktur.
Rubin förväntas fokusera på förbättrad energieffektivitet och högre prestanda per watt, vilket är centralt för storskaliga AI‑träningskluster och HPC‑installationer. Kombinationen av uppdaterad hårdvara och en mer strömlinjeformad, upstream‑fokuserad drivrutinsstack kan leda till snabbare adoption i molnleverantörers erbjudanden och ökade möjligheter för företag att optimera sina beräkningsflöden.
Från ett tekniskt perspektiv innebär en ny serverarkitektur som Rubin flera utvecklingsområden: stöd för nya minnesteknologier, ändringar i interconnect (t.ex. NVLink/PCIe‑konfigurationer), samt optimeringar i firmware och strömkontroller. Dessa aspekter påverkar inte bara prestandan utan även testprocedurer, kvalitetssäkring och certifieringsprocesser som OEM‑partner måste genomgå innan lansering.
So, what does this mean for users and partners?
För Linux‑användare och kärnutvecklare förenklar Boot42 hur framtida GPU:er identifieras och stöds, vilket minskar behovet av snabba, temporära patchar som annars kan leda till splittrade lösningar. Ett tydligare, upstream‑vänligt registerformat innebär att förändringar är lättare att granska, testa och acceptera in i kärnans och drivrutinens huvudgren.
För NVIDIA‑partners och korttillverkare innebär Rubin‑indikatorerna — tillsammans med potentiella kylförändringar — att planera för nya SKU:er och termiska lösningar blir nödvändigt. Designteam måste utvärdera huruvida befintliga flänsar, kylplattor och rackkonfigurationer klarar de termiska krav som Rubin och Rubin Ultra ställer, eller om investering i specialiserade microchannel‑lösningar krävs.
För datacenterkunder kan Rubin innebära stegvisa förbättringar i både prestanda och energieffektivitet, understödda av en renare och mer underhållbar upstream‑drivrutinsstack. Det ger operatörer bättre förutsättningar för långsiktig drift, enklare uppgraderingsvägar och potentiellt lägre totalkostnad per beräkningsenhet. Samtidigt kräver övergången noggrann planering av firmwareuppdateringar, validering i befintliga arbetsflöden och koordination med molnleverantörer för att undvika driftsstörningar.
Ur ett ekosystemperspektiv stärker detta också möjligheten för tredjepartsutvecklare och distributionsprojekt att integrera och stödja NVIDIA‑hårdvara snabbare. När drivrutinslogiken blir mer förutsägbar och väl definierad minskar entry‑barriären för att göra optimeringar i middleware, containerplattformar och AI‑stacks.
Sammanfattningsvis är Boot42‑skiftet mindre en ändring av en enskild registeradress och mer en signal om ett modernt, upstream‑vänligt synsätt på GPU‑stöd. Det visar att NVIDIA investerar i att göra sin hårdvara lättare att stödja i öppna ekosystem som Linux, vilket i sin tur förbereder företagets programvarustack för Rubin och framtida arkitekturer.
För utvecklare som arbetar med drivrutiner är detta ett bra tillfälle att fördjupa tester mot NV_PMC_BOOT_42, uppdatera CI‑jobb och utvärdera hur Rust‑baserade komponenter kan integreras i befintliga verktygskedjor. För driftsteam betyder det att planera för firmware‑ och BIOS‑uppdateringar, verifiera termisk kapacitet och säkerställa att övervakningslösningar fångar nya telemetrisignaler från Rubin‑baserade system.
Slutligen öppnar den här typen av upstream‑vänliga förändringar upp för bredare samarbete mellan hårdvarutillverkare, datacenteroperatörer och öppen källkodsprojekt. När registerdefinitioner, revisioner och identifieringsmetoder standardiseras blir det lättare att bygga gemensamma testsviter, dela erfarenheter och accelerera innovation inom områden som AI‑infrastruktur, grafisk acceleration och högpresterande beräkningar.
Genom att förstå tekniska detaljer som NV_PMC_BOOT_42 och hur de påverkar drivrutinslogik, termisk design och upstream‑arbete kan beslutsfattare och tekniker dra konkreta slutsatser: planera uppgraderingar i god tid, investera i kompatibla kylsystem om Rubin Ultra kräver det, och utnyttja Rust‑drivna förbättringar för bättre kvalitetssäkring. Det är dessa praktiska implikationer som gör skiftet från Boot0 till Boot42 viktigare än vad enbart en registerändring antyder.
Källa: wccftech
Kommentarer
Tomas
Är detta säkert? nollställa Boot0 låter bra men risk för regressionsfel, hur testar man microchannel kylning i riktiga rack? nyfiken..
datapuls
Oj, det här känns som ett stort steg! Rust + Boot42 kan verkligen rena kodbasen, men undrar hur snabbt det kommer upstreama… spännande men lite oro också
Lämna en kommentar