basalt

Il problema · Quali GPU · Come funziona · Avvio rapido · Misurato, non presunto · Scoperte · API · Metodo · Roadmap · Clean-room

Il problema

Un'istruzione GPU NVIDIA è di 128 bit, e 21 di essi non sono affatto l'istruzione. Sono una parola di controllo dello scheduling, da stall a reuse: quanti cicli attendere prima di emettere l'istruzione successiva, quali scoreboard segnalare, su quali attendere e quali operandi possono essere serviti dalla reuse cache.

L'hardware non verifica nulla di tutto ciò. Su sm_120 non c'è interlock sulle istruzioni a latenza fissa. Il silicio si fida di qualunque cosa abbia prodotto la parola di controllo. Se un conteggio di stall è più breve della latenza di un valore consumato dall'istruzione successiva, non si verifica alcun fault, nessuno stall e nessun avviso viene emesso. L'istruzione legge un registro non ancora scritto e calcola su dati obsoleti, a piena velocità, ogni singola volta.

È un tipo strano di bug. Non va in crash. Non appare in un debugger. Produce numeri semplicemente sbagliati, il che in una moltiplicazione di matrici o in un kernel di attenzione significa un modello che si addestra leggermente male, non uno che si rompe in modo visibile.

Le tre codifiche più economiche sono quelle rotte, e nulla ovunque lo segnala. Si noti anche cosa fa la barra di sinistra: uno stall di zero non sono zero cicli, è una codifica sicura distinta che attende i risultati pendenti e costa circa nove volte un'istruzione schedulata. Un checker che la leggesse come zero definirebbe rotti programmi corretti.

Gli strumenti che generano codice macchina per questa architettura assegnano quei bit di controllo a partire da un modello di latenza. basalt è ciò che verifica la risposta.

Il controllo che NVIDIA non ha mai distribuito

NVIDIA ti dà un compilatore che scrive quei 21 bit. Non ti dà nulla che li rilegga e ti dica che sono sicuri, e nessun altro lo fa.

Gli assembler per GPU NVIDIA esistono da un decennio, l'encoding Blackwell è stato già fatto di reverse engineering, esistono caratterizzazioni pubblicate a livello di cicli di sm_120, e un assembler pubblico per questa architettura assegna già da solo i bit di controllo dello scheduling ed esegue i propri kernel su una scheda per vedere che le risposte siano giuste. Tutto vero, e nessuna di queste cose è l'affermazione:

Nessun altro strumento può ricevere un cubin che non ha prodotto e gli si può chiedere di dire se i suoi bit di controllo dello scheduling sono sicuri.

Il tuo compilatore ha emesso quel cubin, o una libreria lo ha distribuito, o qualcuno lo ha scritto a mano, e fino ad ora non c'era modo di chiederlo. Su un'architettura senza interlock hardware, questa è la differenza tra "è girato" e "è corretto", e la differenza è invisibile: uno stall in difetto di un ciclo legge un registro obsoleto e restituisce un numero sbagliato a piena velocità, senza fault e senza avvisi, ogni singola volta.

Tutto il resto qui esiste per rendere verificabile quella frase. L'assembler è ciò che costruisce un programma con uno stall deliberatamente accorciato. Lo scheduler è ciò che costringe il modello a impegnarsi su una risposta invece di valutare quella di qualcun altro. E l'audit è il punto in cui la frase smette di essere un'assenza e diventa una misurazione: basalt puntato su 2.473 cubin sm_120 che NVIDIA distribuisce in cuBLAS, cuSOLVER, cuSPARSE, NPP e il resto.

Perché non esisteva, parole del settore. L'assembler SASS più usato dice nella propria documentazione che "verificare il rigore della correttezza dell'intero programma … [è] lontano dall'essere possibile senza supporto ufficiale. Quindi, è lasciato all'utente garantire la correttezza del programma, con un aiuto molto limitato dall'assembler." SIP, sull'autotuning degli schedule SASS, afferma che "la validazione è impossibile per i codici assembly nativi della GPU perché la semantica formale del sass è closed-source."

Entrambe riguardano la correttezza semantica: cioè se un kernel calcola ciò che dovrebbe. basalt non risponde a questo, e nulla qui lo sostiene. Risponde a una domanda strettamente più piccola, e il punto è che la domanda più piccola è decidibile senza la semantica:

I bit di controllo di questo programma coprono le sue stesse dipendenze dai dati?

Questo richiede la struttura delle dipendenze, che l'encoding rivela, e un modello di latenza, che il silicio rivela sotto misurazione. Nessuno dei due richiede di sapere cosa calcola un'istruzione. Un kernel può superare questo controllo ed essere comunque l'algoritmo sbagliato; ciò che non può fare è leggere un registro prima che il valore arrivi.

In secondo luogo, nient'altro viene misurato contro i byte del fornitore stesso. Il riferimento di basalt è l'output di ptxas, quindi un disaccordo è un bug di basalt fino a prova contraria. Il suo assembler deve riprodurre gli esatti 128 bit del compilatore. Il suo scheduler deve buttare via ogni bit di controllo scelto dal compilatore, calcolarne di nuovi e far sì che la GPU calcoli la stessa risposta.

Un unico standard per tutto: concordare esattamente con il fornitore, o spiegare perché no.

E la parte su cui uno scheduler di solito tace: quanto costa la correttezza. Gli schedule di basalt spendono 1,05x i cicli di issue del fornitore, più lenti su 111 delle 1.323 coppie kernel-livello di ottimizzazione e più economici su 842, con ogni kernel comparabile ancora byte-identico sulla GPU.

La terza riga è quella che ha cambiato le altre tre. Un checker calibrato su un corpus non può fallire su quel corpus: il divario più stretto che il compilatore è stato visto lasciare è il minimo, per costruzione, esattamente per il codice su cui è stato misurato. La prima volta che questo ha visto codice da qualche altra parte, ha segnalato ventisei hazard per kernel in un decoder JPEG che non ha mai restituito un pixel sbagliato, e tutti i 6.593 erano di basalt. Correggerli lo ha portato a zero, e zero su una sola libreria non era comunque una prova: ampliando il set di esclusione a tre librerie e 5,2 milioni di istruzioni è tornato direttamente a 940, e ha trovato altri cinque errori del modello oltre ai primi otto. Tredici correzioni, nessuna di NVIDIA, e il requisito ri-estratto da 24.311 kernel distribuiti ha posto un predicato di guardia a 13 cicli su 229.567 osservazioni, che è il numero che l'iniezione di guasti aveva misurato su questa scheda rompendo un programma apposta. Vedi finding 32.

Essere più economici del fornitore non è un'affermazione di cui vantarsi. basalt scheduler ogni dipendenza al divario più stretto mai osservato in ptxas per quella esatta coppia, e ptxas sta bilanciando pressione dei registri e memoria oltre alla latenza di issue mentre questo ottimizza un solo numero. Inoltre non è stato creduto a prima vista: la prima volta che il rapporto è sceso sotto 1,0 il round trip hardware si è rotto, e il numero ha retto solo dopo aver corretto il bug che aveva esposto. Il rapporto è fissato da entrambi i lati nella suite di test per questo motivo.

La colonna centrale è il punto. Un checker e uno scheduler che condividono un modello di latenza concordano tra loro pur essendo entrambi sbagliati, quindi nessuno dei due è una prova per l'altro; solo il silicio non ha interessi in gioco nell'argomento. Eseguire lo scheduler su sette kernel scritti a mano ha passato sette su sette per molto tempo. Eseguirlo su trecento ne ha trovati quarantuno sbagliati, e ogni correzione in scoperte è venuta osservando quel numero muoversi.

Lo stesso vale per gli input. Una lettura obsoleta cambia la risposta solo quando il valore obsoleto e quello nuovo differiscono, quindi un pattern di byte è una sola occasione per accorgersene, ed eseguire ogni kernel contro un secondo, terzo e quarto pattern ha subito trovato un predicato di carry-out che il modello degli operandi leggeva come sorgente fin dall'inizio. Era sopravvissuto a ogni controllo fino a quel punto, incluso il round trip stesso.

La stessa disciplina decide cosa è permesso fare all'assembler, e vale la pena separare i due numeri che ha.

La copertura è del 99,9% del corpus e dell'87,5% del codice di libreria distribuito. La correttezza è del 100%, ed è quel numero a essere fissato da un test. Il divario tra loro sono istruzioni che basalt rifiuta, ciascuna con il nome del campo che non è riuscito a collocare, perché uno strumento che tirasse a indovinare raggiungerebbe la copertura totale emettendo parole che si disassemblano nel testo giusto e calcolano qualcos'altro. Non ne ha mai emessa una, su 59.760 istruzioni del corpus e 5.237.448 distribuite.

Ci è arrivato solo dopo otto turni distinti di sicurezza errata:

• scrivere un numero di registro nell'encoding di una forma immediata,
• trattare un registro uniform come interscambiabile con uno normale,
• mantenere il target del branch del kernel da cui la forma era stata prelevata,
• inserire l'intero 15 in un campo che contiene un float a mezza precisione,
• scrivere un operando in bit che si sono rivelati essere un flag di reuse,
• scrivere in un campo che la sonda aveva attribuito solo in parte, lasciando il resto ancora codificare il vecchio valore,
• spalmare un numero di registro attraverso il bit che seleziona in quale register file si trova,
• e leggere l'indice di un caricamento costante indicizzato da registro come se fosse uno spiazzamento.

Ognuno di questi ha prodotto una parola che si assembla, si disassembla di nuovo esattamente nel testo da cui proveniva, e calcola qualcos'altro. È lo stesso fallimento che il resto di questo repository esiste per intercettare, motivo per cui tutti e otto sono ora rifiutati con un motivo che indica cosa contiene davvero il campo, e per cui il conteggio delle istruzioni che si assemblano nei byte sbagliati è un test fissato a zero piuttosto che un numero in una tabella.

Un nono è saltato fuori la prima volta che l'assembler è stato puntato su codice macchina che non aveva prodotto, ed era di tipo diverso. c[0x0][UR4] indicizza il suo offset tramite un registro dove la forma registrata contiene un numero, e l'encoder ha sollevato un'eccezione piuttosto che rifiutare. Un crash su input estraneo è peggio di un verdetto sbagliato, perché il chiamante non ottiene né l'uno né l'altro.

Quali GPU

sm_120 non è un numero di modello. È la compute capability condivisa da tutta la linea Blackwell consumer, quindi l'encoding delle istruzioni, il database, l'assembler e il checker si applicano a ogni scheda della linea:

ptxas ha anche come target sm_121, un chip diverso della stessa famiglia. basalt non è mai stato eseguito su uno e non sostiene di supportarlo. Ciò che può dire è misurato: il compilatore emette codice byte-identico, parole di controllo incluse, per tutti e sei i target che offre qui, quindi lo schedule di cui un kernel ha bisogno è una proprietà dell'architettura piuttosto che del componente (finding 28). Se non fosse vero, il compilatore di NVIDIA stesso emetterebbe uno schedule non sicuro per uno di essi.

Ogni numero misurato sul silicio proviene da una scheda fisica, nominata esattamente, perché "una 5070 Ti" non basta a riprodurre un'esecuzione:

Cita il DOI concettuale, 10.5281/zenodo.22072811, piuttosto che un DOI di versione o questo URL. Si risolve nella release più recente, quindi rimane corretto senza dover essere modificato di nuovo. CITATION.cff lo contiene, quindi è già in entrambe le forme sopra.

Se riutilizzi le tabelle misurate (src/basalt/data/) o riproduci una figura, cita la release da cui provengono piuttosto che main: i numeri sono rigenerati da scripts/verify_all.py a un commit specifico, e un tag è ciò che rende riproducibile il tutto.

L'attribuzione è un termine della licenza, non una cortesia. Apache-2.0 §4 richiede che LICENSE e NOTICE accompagnino qualsiasi ridistribuzione o opera derivata, e NOTICE riporta la paternità e la dichiarazione di clean-room. Fork, copie vendorizzate e wheel riconfezionate mantengono entrambi i file.

Autore

Sunny Patel · sunnypatel.net · github.com/sunnypatell