basalt

Das Problem · Welche GPUs · Wie es funktioniert · Schnellstart · Gemessen, nicht angenommen · Erkenntnisse · API · Methode · Roadmap · Clean-Room

Das Problem

Eine NVIDIA-GPU-Instruktion ist 128 Bit lang, und 21 davon sind überhaupt nicht die Instruktion. Sie sind ein Scheduling-Steuerwort, von stall bis reuse: wie viele Zyklen vor der Ausgabe der nächsten Instruktion gewartet werden soll, welche Scoreboards signalisiert werden sollen, auf welche gewartet werden soll und welche Operanden aus dem Reuse-Cache bedient werden dürfen.

Die Hardware prüft nichts davon. Auf sm_120 gibt es keine Verriegelung bei Instruktionen mit fester Latenz. Das Silizium vertraut dem, was das Steuerwort erzeugt hat. Wenn eine Stall-Anzahl kürzer ist als die Latenz eines Werts, den die nächste Instruktion konsumiert, tritt kein Fehler auf, nichts wartet, und keine Warnung wird ausgegeben. Die Instruktion liest ein Register, das noch nicht geschrieben wurde, und rechnet jedes Mal mit veralteten Daten, mit voller Geschwindigkeit.

Das ist eine seltsame Art von Bug. Er stürzt nicht ab. Er taucht nicht im Debugger auf. Er erzeugt Zahlen, die lediglich falsch sind, was bei einer Matrixmultiplikation oder einem Attention-Kernel bedeutet, dass ein Modell leicht schlechter trainiert, statt sichtbar zu brechen.

Die drei billigsten Kodierungen sind die kaputten, und niemand irgendwo meldet es. Beachte außerdem, was der linke Balken tut: Ein Stall von null ist nicht null Zyklen, sondern eine eigene sichere Kodierung, die auf ausstehende Ergebnisse wartet und etwa neunmal so viel kostet wie eine schedulierte Instruktion. Ein Prüfer, der das als null lesen würde, würde korrekte Programme als defekt bezeichnen.

Werkzeuge, die Maschinencode für diese Architektur erzeugen, weisen diese Steuerbits anhand eines Latenzmodells zu. basalt ist das Werkzeug, das die Antwort prüft.

Die Prüfung, die NVIDIA nie ausgeliefert hat

NVIDIA gibt dir einen Compiler, der diese 21 Bits schreibt. Es gibt dir nichts, das sie zurückliest und dir sagt, dass sie sicher sind, und auch sonst niemand.

Assembler für NVIDIA-GPUs gibt es seit einem Jahrzehnt, die Blackwell-Kodierung wurde bereits früher per Reverse Engineering untersucht, es gibt veröffentlichte Charakterisierungen von sm_120 auf Zyklenebene, und ein öffentlicher Assembler für diese Architektur weist die Scheduling-Steuerbits bereits selbst zu und führt seine eigenen Kernel auf einer Karte aus, um zu sehen, dass die Antworten stimmen. Alles wahr, und nichts davon ist die Behauptung:

Nichts anderes kann ein cubin vorgelegt bekommen, das es nicht selbst erzeugt hat, und gefragt werden, ob seine Scheduling-Steuerbits sicher sind.

Dein Compiler hat dieses cubin erzeugt, oder eine Bibliothek hat es ausgeliefert, oder jemand hat es von Hand geschrieben, und bis jetzt gab es keine Möglichkeit zu fragen. Auf einer Architektur ohne Hardware-Verriegelung ist das der Unterschied zwischen „es lief“ und „es ist korrekt“, und der Unterschied ist unsichtbar: Ein Stall, der einen Zyklus zu kurz ist, liest ein veraltetes Register und liefert jedes Mal mit voller Geschwindigkeit eine falsche Zahl zurück, ohne Fehler und ohne Warnung.

Alles andere hier existiert, um diesen Satz testbar zu machen. Der Assembler ist das, was ein Programm mit einem absichtlich verkürzten Stall baut. Der Scheduler ist das, was das Modell zwingt, sich auf eine Antwort festzulegen, statt die eines anderen zu benoten. Und das Audit ist der Punkt, an dem der Satz aufhört, eine Abwesenheit zu sein, und zu einer Messung wird: basalt, gerichtet auf 2,473 sm_120-Cubins, die NVIDIA in cuBLAS, cuSOLVER, cuSPARSE, NPP und dem Rest ausliefert.

Warum es nicht existierte, in den eigenen Worten des Fachgebiets. Der am häufigsten verwendete SASS-Assembler sagt in seiner eigenen Dokumentation, dass „die rigorose Korrektheit des gesamten Programms … [ist] alles andere als möglich ohne offizielle Unterstützung. Es bleibt also dem Benutzer überlassen, die Korrektheit des Programms zu garantieren, mit sehr begrenzter Hilfe des Assemblers.“ SIP stellt zum Autotuning von SASS-Schedules fest, dass „Validierung für GPU-native Assembly-Codes unmöglich ist, weil die formale Semantik des sass closed-source ist.“

Beide betreffen die semantische Korrektheit: ob ein Kernel das berechnet, was er berechnen soll. basalt beantwortet das nicht, und nichts hier behauptet es. Es beantwortet eine streng kleinere Frage, und der Punkt ist, dass die kleinere Frage ohne die Semantik entscheidbar ist:

Decken die Steuerbits dieses Programms seine eigenen Datenabhängigkeiten ab?

Dazu braucht es die Abhängigkeitsstruktur, die die Kodierung preisgibt, und ein Latenzmodell, das das Silizium unter Messung preisgibt. Weder erfordert es zu wissen, was eine Instruktion berechnet. Ein Kernel kann diese Prüfung bestehen und trotzdem der falsche Algorithmus sein; was er nicht tun kann, ist, ein Register zu lesen, bevor der Wert ankommt.

Zweitens: Nichts anderes wird an den eigenen Bytes des Herstellers gemessen. Die Referenz von basalt ist die ptxas-Ausgabe, daher ist eine Abweichung basalts Bug, bis das Gegenteil bewiesen ist. Sein Assembler muss die exakten 128 Bits des Compilers reproduzieren. Sein Scheduler muss jedes Steuerbit, das der Compiler gewählt hat, verwerfen, neue berechnen und die GPU dieselbe Antwort berechnen lassen.

Ein Standard für alles: exakt mit dem Hersteller übereinstimmen – oder sagen, warum nicht.

Und der Teil, über den ein Scheduler normalerweise schweigt: was die Korrektheit kostet. Die Schedules von basalt verbrauchen das 1,05-fache der Issue-Zyklen des Herstellers, langsamer bei 111 der 1,323 Paare aus Kernels und Optimierungsstufen und billiger bei 842, wobei jeder vergleichbare Kernel auf der GPU weiterhin byte-identisch ist.

Die dritte Zeile ist diejenige, die die anderen drei verändert hat. Ein Prüfer, der auf einem Korpus kalibriert wurde, kann auf diesem Korpus nicht scheitern: Die engste Lücke, die der Compiler je hinterließ, ist per Konstruktion die Untergrenze, und zwar genau für den Code, an dem er gemessen wurde. Als dieser Prüfer zum ersten Mal Code von woanders sah, meldete er sechsundzwanzig Hazards pro Kernel in einem JPEG-Dekoder, der noch nie ein falsches Pixel geliefert hat, und alle 6.593 stammten von basalt. Das Beheben brachte ihn auf null, und null über eine Bibliothek war auch kein Beleg: Als die zurückgehaltene Menge auf drei Bibliotheken und 5,2 Millionen Instruktionen erweitert wurde, sprang sie direkt zurück auf 940 und fand zusätzlich zu den ersten acht fünf weitere Modellfehler. Dreizehn Korrekturen, keine davon von NVIDIA, und die aus 24.311 ausgelieferten Kernels neu gewonnene Anforderung setzte ein Guard-Prädikat bei 13 Zyklen über 229.567 Beobachtungen, was die Zahl ist, die Fehlerinjektion auf dieser Karte durch absichtliches Brechen eines Programms gemessen hatte. Siehe Erkenntnis 32.

Billiger als der Hersteller zu sein, ist kein Anlass zur Selbstzufriedenheit. basalt plant jede Abhängigkeit mit der engsten Lücke, die ptxas je für genau diese Paarung hinterließ, und ptxas balanciert Registerdruck und Speicher neben der Issue-Latenz, während dieses hier eine einzelne Zahl optimiert. Es wurde auch nicht auf den ersten Blick geglaubt: Als das Verhältnis zum ersten Mal unter 1,0 fiel, brach der Hardware-Roundtrip, und die Zahl stand erst, nachdem der dadurch aufgedeckte Bug behoben war. Aus diesem Grund ist das Verhältnis im Test-Suite von beiden Seiten festgenagelt.

Die mittlere Spalte ist der Punkt. Ein Prüfer und ein Scheduler, die sich ein Latenzmodell teilen, stimmen miteinander überein, während beide falsch liegen, also ist keiner ein Beleg für den anderen; nur das Silizium hat kein Interesse an dem Argument. Den Scheduler über sieben handgeschriebene Kernels laufen zu lassen, bestand lange Zeit sieben von sieben. Als er über dreihundert lief, fand er einundvierzig falsche, und jede Korrektur in den Erkenntnissen entstand dadurch, diese Zahl sich bewegen zu sehen.

Dasselbe gilt für die Eingaben. Ein veralteter Lesevorgang ändert die Antwort nur, wenn sich der veraltete Wert und der frische unterscheiden, also ist ein Byte-Muster eine Chance, es zu bemerken, und das Ausführen jedes Kernels gegen ein zweites, drittes und viertes Muster fand sofort ein Carry-out-Prädikat, das das Operandenmodell von Anfang an als Quelle gelesen hatte. Es hatte jede Kontrolle bis zu diesem Punkt überlebt, einschließlich des Roundtrips selbst.

Dieselbe Disziplin entscheidet, was der Assembler tun darf, und es lohnt sich, die beiden Zahlen, die er hat, zu trennen.

Die Abdeckung beträgt 99,9 % des Korpus und 87,5 % des ausgelieferten Bibliothekscodes. Die Korrektheit beträgt 100 %, und das ist die Zahl, die durch einen Test festgelegt ist. Die Lücke dazwischen sind Instruktionen, die basalt verweigert, jede mit Benennung des Feldes, das es nicht zuordnen konnte, denn ein Werkzeug, das raten würde, würde volle Abdeckung erreichen, indem es Wörter ausgibt, die zum richtigen Text zerlegt werden und etwas anderes berechnen. Es hat nie eines ausgegeben, über 59.760 Korpus-Instruktionen und 5.237.448 ausgelieferte hinweg.

Dorthin kam es erst nach acht getrennten Runden selbstsicheren Falschliegens:

• eine Registernummer in die Kodierung einer Immediate-Form zu schreiben,
• ein Uniform-Register als austauschbar mit einem normalen Register zu behandeln,
• das Sprungziel desjenigen Kernels beizubehalten, dem die Form entnommen war,
• die Ganzzahl 15 in ein Feld zu setzen, das eine Half-Precision-Float hält,
• einen Operanden in Bits zu schreiben, die sich als Reuse-Flag herausstellten,
• in ein Feld zu schreiben, das der Prober nur teilweise attribuiert hatte, sodass der Rest weiterhin den alten Wert kodierte,
• eine Registernummer über das Bit zu verteilen, das auswählt, in welcher Registerdatei sie liegt,
• und den Index eines register-indizierten Konstanten-Loads als Displacement zu lesen.

Jede einzelne davon erzeugte ein Wort, das assembliert, zurück zum exakt gleichen Text, aus dem es stammte, disassembliert und etwas anderes berechnet. Das ist derselbe Fehler, den der Rest dieses Repositoriums zu fangen existiert, weshalb alle acht jetzt mit einer Begründung verweigert werden, die benennt, was das Feld wirklich enthält, und weshalb die Zahl der Instruktionen, die zu den falschen Bytes assemblieren, ein Test ist, der bei null festgelegt ist, statt einer Zahl in einer Tabelle.

Ein neunter tauchte beim ersten Mal auf, als der Assembler auf Maschinencode gerichtet wurde, den er nicht erzeugt hatte, und er war anderer Art. c[0x0][UR4] indiziert seinen Offset über ein Register, wo die aufgezeichnete Form eine Zahl enthält, und der Encoder warf einen Fehler, statt zu verweigern. Ein Absturz bei fremder Eingabe ist schlimmer als ein falsches Urteil, weil der Aufrufer keins von beidem bekommt.

Welche GPUs

sm_120 ist keine Modellnummer. Es ist die Compute Capability, die die gesamte Consumer-Blackwell-Reihe gemeinsam hat, daher gelten die Instruktionskodierung, die Datenbank, der Assembler und der Prüfer für jede Karte darin:

ptxas zielt auch auf sm_121, einen anderen Chip derselben Familie. basalt ist nie auf einem gelaufen und behauptet nicht, es zu unterstützen. Was es sagen kann, ist gemessen: Der Compiler erzeugt byte-identischen Code, einschließlich der Steuerwörter, für alle sechs hier angebotenen Ziele, also ist der Schedule, den ein Kernel braucht, eine Eigenschaft der Architektur und nicht des Bauteils (Erkenntnis 28). Wenn das nicht wahr wäre, würde NVIDIAs eigener Compiler für eines davon einen unsicheren Schedule ausgeben.

Jede auf Silizium gemessene Zahl stammt von einer physischen Karte, die exakt benannt ist, weil „eine 5070 Ti“ nicht ausreicht, um einen Lauf zu reproduzieren:

Zitieren Sie die Konzept-DOI 10.5281/zenodo.22072811, anstelle einer Versions-DOI oder dieser URL. Sie verweist auf das neueste Release, bleibt also korrekt, ohne jemals erneut bearbeitet zu werden. CITATION.cff enthält sie, sodass sie bereits in beiden obigen Formen vorliegt.

Wenn Sie die gemessenen Tabellen (src/basalt/data/) wiederverwenden oder eine Abbildung reproduzieren, zitieren Sie das Release, aus dem sie stammen, anstelle von main: Die Zahlen werden von scripts/verify_all.py bei einem bestimmten Commit regeneriert, und ein Tag macht das reproduzierbar.

Namensnennung ist eine Lizenzbedingung, keine Höflichkeit. Apache-2.0 §4 verlangt, dass LICENSE und NOTICE bei jeder Weiterverbreitung oder abgeleiteten Arbeit mitgeführt werden, und NOTICE enthält die Autorenangabe und die Clean-Room-Erklärung. Forks, Vendor-Kopien und neu verpackte Wheels behalten beide Dateien.

Autor

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