basalt

समस्या · कौन से GPU · यह कैसे काम करता है · त्वरित आरंभ · मापा गया, अनुमानित नहीं · निष्कर्ष · API · विधि · रोडमैप · क्लीन-रूम

समस्या

NVIDIA GPU निर्देश 128 बिट का होता है, और उनमें से 21 बिट वास्तव में निर्देश बिल्कुल नहीं होते। वे एक शेड्यूलिंग नियंत्रण शब्द होते हैं, stall से reuse तक: अगला निर्देश जारी करने से पहले कितने चक्रों के लिए रुकना है, किन स्कोरबोर्ड को संकेत देना है, किनका इंतज़ार करना है, और कौन से ऑपरेंड reuse कैश से दिए जा सकते हैं।

हार्डवेयर इनमें से किसी की भी जाँच नहीं करता। sm_120 पर fixed-latency निर्देशों पर कोई interlock नहीं होता। सिलिकन उस पर भरोसा करता है जिसने भी नियंत्रण शब्द बनाया हो। यदि कोई stall count, अगले निर्देश द्वारा उपभोग किए जाने वाले मान की लैटेंसी से कम है, तो न कोई fault आता है, न कोई stall होता है, और न कोई चेतावनी जारी होती है। निर्देश एक ऐसे रजिस्टर को पढ़ता है जो अभी लिखा नहीं गया है, और पुराने डेटा पर पूरी गति से हर बार गणना करता है।

यह एक अजीब तरह का बग है। यह क्रैश नहीं करता। यह डीबगर में दिखाई नहीं देता। यह ऐसे नंबर पैदा करता है जो केवल गलत होते हैं, जिसका अर्थ है कि मैट्रिक्स गुणन या अटेंशन कर्नेल में, एक मॉडल जो स्पष्ट रूप से टूटने के बजाय थोड़ा खराब प्रशिक्षित होता है।

तीन सबसे सस्ते एन्कोडिंग ही टूटे हुए हैं, और कहीं भी कोई इसकी रिपोर्ट नहीं करता। यह भी ध्यान दें कि बायाँ बार क्या कर रहा है: शून्य का स्टॉल शून्य चक्र नहीं है, यह एक अलग सुरक्षित एन्कोडिंग है जो बकाया परिणामों का इंतज़ार करता है और एक शेड्यूल किए गए निर्देश से लगभग नौ गुना खर्च करता है। एक चेकर जो इसे शून्य के रूप में पढ़ता, सही प्रोग्राम को टूटा हुआ कहता।

इस आर्किटेक्चर के लिए मशीन कोड बनाने वाले उपकरण उन नियंत्रण बिट्स को लैटेंसी मॉडल से निर्धारित करते हैं। basalt वह चीज़ है जो उत्तर की जाँच करता है।

वह जाँच जो NVIDIA ने कभी शिप नहीं की

NVIDIA आपको एक कंपाइलर देता है जो उन 21 बिट्स को लिखता है। यह आपको ऐसा कुछ नहीं देता जो उन्हें वापस पढ़कर बताए कि वे सुरक्षित हैं, और न ही कोई और देता है।

NVIDIA GPU के लिए असेंबलर एक दशक से मौजूद हैं, Blackwell एन्कोडिंग का पहले भी रिवर्स इंजीनियरिंग किया जा चुका है, sm_120 के प्रकाशित चक्र-स्तरीय लक्षण वर्णन मौजूद हैं, और इस आर्किटेक्चर के लिए एक सार्वजनिक असेंबलर पहले से ही शेड्यूलिंग नियंत्रण बिट्स स्वयं निर्धारित करता है और यह देखने के लिए अपने कर्नेल को कार्ड पर चलाता है कि उत्तर सही निकलते हैं। यह सब सच है, और इनमें से कोई भी दावा नहीं है:

किसी और चीज़ को ऐसा cubin नहीं दिया जा सकता जो उसने उत्पन्न न किया हो, और यह बताने को नहीं कहा जा सकता कि क्या उसके शेड्यूलिंग नियंत्रण बिट्स सुरक्षित हैं।

आपका कंपाइलर उस cubin को निर्गत करता है, या किसी लाइब्रेरी ने उसे शिप किया, या किसी ने उसे हाथ से लिखा, और अब तक पूछने का कोई तरीका नहीं था। ऐसे आर्किटेक्चर पर जिसमें कोई hardware interlock नहीं है, यही "यह चला" और "यह सही है" के बीच का अंतर है, और अंतर अदृश्य है: एक चक्र कम वाला स्टॉल एक पुराना रजिस्टर पढ़ता है और पूरी गति से, बिना किसी फॉल्ट और बिना किसी चेतावनी के, हर बार गलत नंबर लौटाता है।

यहाँ बाकी सब कुछ उस वाक्य को परीक्षण योग्य बनाने के लिए मौजूद है। असेंबलर वह है जो जानबूझकर एक स्टॉल को छोटा करके एक प्रोग्राम बनाता है। शेड्यूलर वह है जो मॉडल को किसी और के उत्तर को रेट करने के बजाय एक उत्तर के लिए प्रतिबद्ध होने के लिए मजबूर करता है। और ऑडिट वह जगह है जहाँ वाक्य एक अनुपस्थिति नहीं रहकर माप बन जाता है: basalt को 2,473 sm_120 cubins की ओर इंगित किया गया, जिन्हें NVIDIA cuBLAS, cuSOLVER, cuSPARSE, NPP और बाकी में शिप करता है।

यह क्षेत्र के अपने शब्दों में क्यों मौजूद नहीं था। सबसे अधिक उपयोग किया जाने वाला SASS असेंबलर अपने दस्तावेज़ में कहता है कि "आधिकारिक समर्थन के बिना पूरे प्रोग्राम की कठोर शुद्धता की जाँच … [लगभग] असंभव है। इसलिए, असेंबलर की बहुत सीमित मदद के साथ, प्रोग्राम की शुद्धता की गारंटी देना उपयोगकर्ता पर छोड़ दिया गया है।" SIP, SASS शेड्यूल के ऑटोट्यूनिंग पर, कहता है कि "GPU नेटिव असेंबली कोड के लिए सत्यापन असंभव है क्योंकि sass की formal semantics बंद-स्रोत हैं।"

दोनों सिमेंटिक शुद्धता के बारे में हैं: क्या कोई कर्नेल वही गणना करता है जो उसे करनी चाहिए। basalt उसका उत्तर नहीं देता, और यहाँ कुछ भी वह दावा नहीं करता। यह एक कड़ाई से छोटे प्रश्न का उत्तर देता है, और बात यह है कि छोटा प्रश्न सिमेंटिक्स के बिना भी निर्णायक है:

क्या इस प्रोग्राम के नियंत्रण बिट्स उसकी अपनी डेटा निर्भरताओं को कवर करते हैं?

इसके लिए निर्भरता संरचना चाहिए, जो एन्कोडिंग से प्राप्त होती है, और एक लैटेंसी मॉडल चाहिए, जो माप के दौरान सिलिकन से प्राप्त होता है। किसी के लिए भी यह जानने की आवश्यकता नहीं है कि कोई निर्देश क्या गणना करता है। एक कर्नेल इस जाँच में पास हो सकता है और फिर भी गलत एल्गोरिदम हो सकता है; यह जो नहीं कर सकता वह है मान के पहुँचने से पहले रजिस्टर को पढ़ना।

दूसरी बात, किसी और चीज़ को विक्रेता के अपने बाइट्स के विरुद्ध मापा नहीं गया है। basalt का संदर्भ ptxas आउटपुट है, इसलिए जब तक अन्यथा सिद्ध न हो, असहमति basalt का बग है। उसके असेंबलर को कंपाइलर के सटीक 128 बिट्स को पुन: उत्पन्न करना होता है। उसके शेड्यूलर को कंपाइलर द्वारा चुने गए हर नियंत्रण बिट को फेंकना होता है, नए बिट्स की गणना करनी होती है, और GPU से वही उत्तर गणना करवाना होता है।

यह सब एक ही मानक पर चलता है: विक्रेता से बिल्कुल सहमत हो, या कहें कि क्यों नहीं।

और वह हिस्सा जिसके बारे में शेड्यूलर आमतौर पर चुप रहता है: शुद्धता की कीमत क्या है। basalt के शेड्यूल विक्रेता के issue cycles का 1.05x खर्च करते हैं, 1,323 कर्नेल और ऑप्टिमाइज़ेशन-स्तर जोड़ों में से 111 पर धीमे और 842 पर सस्ते, और हर तुलनीय कर्नेल GPU पर फिर भी बाइट-समान होता है।

तीसरी पंक्ति वह है जिसने बाकी तीनों को बदल दिया। एक चेकर जो कॉर्पस पर कैलिब्रेट किया गया है, उस कॉर्पस पर विफल नहीं हो सकता: कंपाइलर को छोड़ता हुआ देखा गया सबसे कड़ा अंतर, निर्माण के अनुसार, ठीक उसी कोड के लिए न्यूनतम सीमा है जिस पर उसे मापा गया था। पहली बार जब इसने कहीं और से कोड देखा, तो इसने एक JPEG डिकोडर के प्रत्येक कर्नेल में छब्बीस hazards की रिपोर्ट की, जिसने कभी एक गलत पिक्सेल नहीं लौटाया था, और सभी 6,593 basalt के थे। उन्हें ठीक करने से यह शून्य पर आ गया, और एक लाइब्रेरी पर शून्य भी सबूत नहीं था: अलग रखे गए सेट को तीन लाइब्रेरीज़ और 5.2 मिलियन निर्देशों तक विस्तारित करने से यह सीधे 940 पर वापस आ गया, और पहले आठ के अलावा पाँच और मॉडल त्रुटियाँ मिलीं। तेरह सुधार, जिनमें से कोई भी NVIDIA का नहीं था, और 24,311 शिप किए गए कर्नेल से पुनः प्राप्त आवश्यकता ने 229,567 अवलोकनों में 13 चक्रों पर एक गार्ड प्रेडिकेट रखा, जो कि इस कार्ड पर fault injection द्वारा जानबूझकर एक प्रोग्राम को तोड़कर मापी गई संख्या है। देखें निष्कर्ष 32।

विक्रेता से सस्ता होना कोई अकड़ने वाला दावा नहीं है। basalt हर निर्भरता को उस सबसे कड़े अंतर पर शेड्यूल करता है जिसे ptxas उस विशेष जोड़ी के लिए कभी छोड़ता हुआ देखा गया, और जहाँ यह एक संख्या को अनुकूलित करता है, वहीं ptxas रजिस्टर दबाव और मेमोरी को issue latency के साथ संतुलित कर रहा है। इस पर आँख बंद करके विश्वास भी नहीं किया गया: पहली बार जब अनुपात 1.0 से नीचे गया, हार्डवेयर राउंड ट्रिप टूट गई, और यह संख्या तभी खड़ी रही जब उसके द्वारा उजागर किया गया बग ठीक कर दिया गया। इसी कारण परीक्षण सूट में अनुपात दोनों ओर से स्थिर किया गया है।

बीच का कॉलम ही मुद्दा है। एक चेकर और एक शेड्यूलर जो एक ही लैटेंसी मॉडल साझा करते हैं, दोनों के गलत होने पर भी एक-दूसरे से सहमत होते हैं, इसलिए कोई भी दूसरे के लिए सबूत नहीं है; केवल सिलिकन का इस तर्क में कोई हित नहीं होता। शेड्यूलर को सात हाथ से लिखे कर्नेल पर चलाने से लंबे समय तक सात में से सात सफल होते रहे। इसे तीन सौ पर चलाने से इकतालीस गलत मिले, और निष्कर्षों में हर सुधार उस संख्या को हिलते देखने से निकला।

यही बात इनपुट पर भी लागू होती है। एक पुराना पठन उत्तर को तभी बदलता है जब पुराना मान और नया मान भिन्न होते हैं, इसलिए बाइट्स का एक पैटर्न नोटिस करने का एक अवसर है, और हर कर्नेल को दूसरे, तीसरे और चौथे पैटर्न के विरुद्ध चलाने से तुरंत एक carry-out प्रेडिकेट मिला, जिसे ऑपरेंड मॉडल शुरू से एक स्रोत के रूप में पढ़ रहा था। वह उस बिंदु तक हर नियंत्रण में बच गया था, जिसमें राउंड ट्रिप भी शामिल है।

वही अनुशासन यह तय करता है कि असेंबलर को क्या करने की अनुमति है, और उसके पास मौजूद दो संख्याओं को अलग करना उचित है।

कवरेज कॉर्पस का 99.9% और शिप किए गए लाइब्रेरी कोड का 87.5% है। शुद्धता 100% है, और यही वह संख्या है जिसे एक परीक्षण द्वारा स्थिर किया गया है। इनके बीच का अंतर वे निर्देश हैं जिन्हें basalt अस्वीकार करता है, जिनमें से प्रत्येक उस फ़ील्ड का नाम बताता है जिसे वह रख नहीं पाया, क्योंकि एक उपकरण जो अनुमान लगाता, सही टेक्स्ट में डिसअसेंबल होने वाले और कुछ और गणना करने वाले शब्दों को उत्सर्जित करके पूर्ण कवरेज तक पहुँच जाता। उसने 59,760 कॉर्पस निर्देशों और 5,237,448 शिप किए गए निर्देशों में कभी एक भी ऐसा उत्सर्जित नहीं किया है।

वह आत्मविश्वास से गलत होने के आठ अलग-अलग दौरों के बाद ही वहाँ पहुँचा:

• किसी immediate फ़ॉर्म के एन्कोडिंग में रजिस्टर संख्या लिखना,
• एक uniform रजिस्टर को सामान्य रजिस्टर के साथ विनिमेय मान लेना,
• उस कर्नेल की branch target को बनाए रखना जिससे फ़ॉर्म लिया गया था,
• integer 15 को ऐसे फ़ील्ड में डालना जो half-precision float रखता है,
• किसी ऑपरेंड को उन बिट्स में लिखना जो वास्तव में reuse फ़्लैग निकले,
• ऐसे फ़ील्ड में लिखना जिसका श्रेय prober ने केवल आंशिक रूप से दिया था, बाकी को अभी भी पुराना मान एन्कोड करते हुए छोड़ना,
• एक रजिस्टर संख्या को उस बिट में फैलाना जो चुनता है कि वह किस रजिस्टर फ़ाइल में है,
• और एक रजिस्टर-अनुक्रमित constant load के index को displacement के रूप में पढ़ना।

उनमें से प्रत्येक ने एक ऐसा शब्द उत्पन्न किया जो असेंबल होता है, ठीक उसी टेक्स्ट में डिसअसेंबल हो जाता है जिससे वह आया था, और कुछ और ही गणना करता है। यह वही विफलता है जिसे पकड़ने के लिए इस रिपॉज़िटरी का बाकी हिस्सा मौजूद है, यही कारण है कि अब सभी आठ को एक ऐसे कारण के साथ अस्वीकार कर दिया जाता है जो बताता है कि फ़ील्ड वास्तव में क्या रखता है, और यही कारण है कि गलत बाइट्स में असेंबल होने वाले निर्देशों की गिनती तालिका में एक संख्या के बजाय शून्य पर स्थिर किया गया परीक्षण है।

एक नौवीं समस्या पहली बार सामने आई जब असेंबलर को उस मशीन कोड की ओर इंगित किया गया जो उसने उत्पन्न नहीं किया था, और वह एक अलग तरह की थी। c[0x0][UR4] अपने ऑफ़सेट को एक रजिस्टर द्वारा अनुक्रमित करता है जहाँ रिकॉर्ड किया गया फ़ॉर्म एक संख्या रखता है, और एन्कोडर ने अस्वीकार करने के बजाय raise कर दिया। विदेशी इनपुट पर एक क्रैश गलत निर्णय से भी बदतर है, क्योंकि कॉलर को दोनों में से कुछ नहीं मिलता।

कौन से GPU

sm_120 कोई मॉडल नंबर नहीं है। यह पूरी कंज़्यूमर Blackwell श्रृंखला द्वारा साझा की गई compute capability है, इसलिए निर्देश एन्कोडिंग, डेटाबेस, असेंबलर और चेकर उसमें मौजूद हर कार्ड पर लागू होते हैं:

ptxas sm_121 को भी लक्षित करता है, जो उसी परिवार की एक अलग चिप है। basalt कभी उस पर नहीं चला है, और उसका समर्थन करने का दावा नहीं करता। यह जो कह सकता है वह मापा गया है: कंपाइलर यहाँ दिए गए सभी छह लक्ष्यों के लिए बाइट-समान कोड, नियंत्रण शब्दों सहित उत्सर्जित करता है, इसलिए एक कर्नेल को जिस शेड्यूल की आवश्यकता होती है, वह भाग-विशेष के बजाय आर्किटेक्चर का गुण है (निष्कर्ष 28)। यदि यह सच नहीं होता, तो NVIDIA का अपना कंपाइलर उनमें से किसी एक के लिए असुरक्षित शेड्यूल उत्सर्जित कर रहा होता।

सिलिकन पर मापी गई हर संख्या एक भौतिक कार्ड से आती है, जिसका नाम सटीक रूप से बताया गया है, क्योंकि "एक 5070 Ti" एक रन को पुन: उत्पन्न करने के लिए पर्याप्त नहीं है:

यह कैसे काम करता है

सब कुछ दो ओरेकल पर टिका है, दोनों ही स्टॉक NVIDIA बाइनरी हैं जिन्हें बाहरी प्रक्रियाओं के रूप में चलाया जाता है। कोई भी NVIDIA स्रोत, हेडर या लाइब्रेरी उपयोग या पुनर्वितरित नहीं की जाती है।

प्रोब ओरेकल ही वह है जो मायने रखता है। कंपाइलर आउटपुट तक सीमित कोई उपकरण केवल वही पुनः खोज सकता है जो कंपाइलर पहले से करता है। संश्लेषित 128-बिट शब्दों को सीधे डिकोडर तक पहुँचाने का अर्थ है कि निर्देश सेट को मापा जा सकता है।

किसी भी ओरेकल को GPU की आवश्यकता नहीं है, इसलिए संपूर्ण निर्देश डेटाबेस किसी भी मशीन पर CI में पुनर्निर्मित हो जाता है।

एन्कोडिंग को बदलकर व्युत्पन्न करना

basalt ऑपकोड की तालिका कहीं से नहीं पढ़ता। यह एक ऐसी एन्कोडिंग लेता है जो असेंबल हुई थी, एक बिट पलटता है, परिणाम को डिकोड करता है, और रिकॉर्ड करता है कि क्या बदला। जो बिट गंतव्य रजिस्टर को बदलता है वह डेस्टिनेशन बिट है; जो बिट मेमोनिक को बदलता है वह सेलेक्टर है; और जो बिट कोई अवलोकन योग्य परिवर्तन नहीं करता वह निष्क्रिय है।

IADD R5, R5, 0x2a के विरुद्ध चलाने पर, माप इस प्रकार सामने आती है:``` operand[0] bits 16:23 flip 16 -> R4, flip 17 -> R7 destination register operand[1] bits 24:31 plus bit 72, which negates it source register operand[2] bits 32:63 flip 32 -> 0x2b, flip 33 -> 0x28 32-bit immediate opcode bits 2, 4, 12:15 inert 36 bits no observable effect invalid 11 bits the decoder rejects the mutation

आठ-बिट रजिस्टर फ़ील्ड और एक 32-बिट इमीडिएट, जिन्हें अनुमान के बजाय प्रयोग द्वारा प्राप्त किया गया है।

### नियंत्रण शब्द

| फ़ील्ड | बिट्स | अर्थ |
| :--- | :--- | :--- |
| `stall` | 108:105 | अगला निर्देश जारी करने से पहले प्रतीक्षा करने के लिए साइकिल |
| `yield` | 109 | संकेत कि वार्प शेड्यूलर वार्प्स को स्विच कर सकता है |
| `write_barrier` | 112:110 | राइट-बैक पर संकेत देने के लिए स्कोरबोर्ड (7 = कोई नहीं) |
| `read_barrier` | 115:113 | ऑपरेंड रीड पर संकेत देने के लिए स्कोरबोर्ड (7 = कोई नहीं) |
| `wait_mask` | 121:116 | जारी करने से पहले स्पष्ट होने वाले स्कोरबोर्ड |
| `reuse` | 125:122 | ऑपरेंड रीयूज़-कैश फ़्लैग, प्रत्येक स्रोत स्लॉट के लिए एक |

<img src="https://raw.githubusercontent.com/sunnypatell/basalt/main/docs/assets/diagram-control-word.svg" alt="एक sm_120 निर्देश 128 बिट्स का होता है, जिसमें से बिट 105 से 125 शेड्यूलिंग नियंत्रण शब्द हैं: stall 108:105 पर, yield 109 पर, write_barrier 112:110 पर, read_barrier 115:113 पर, wait_mask 121:116 पर और reuse 125:122 पर।">

यह लेआउट संपर्क में आते ही स्वयं को मान्य करता है। एक साधारण कर्नेल में, `S2R` `write_barrier=0` सेट करता है और इसके परिणाम का उपभोग करने वाला `IMAD` `wait_mask=0x01` धारण करता है; `LDCU.64` `write_barrier=1` सेट करता है और आश्रित `STG.E` `wait_mask=0x02` धारण करता है। प्रत्येक उत्पादक और उपभोक्ता जोड़ी संरेखित होती है, और जिन निर्देशों को `nvdisasm` `.reuse` के रूप में चिह्नित करता है, उनमें संबंधित रीयूज़ बिट सेट होता है।

## त्वरित आरंभ

कोई CUDA इंस्टॉलेशन नहीं और कोई GPU नहीं। टूलचेन स्क्रिप्ट पिन की गई रिडिस्ट्रिब्यूटेबल्स लाती है, लगभग 45 MB, कोई व्यवस्थापक अधिकार नहीं, आपके PATH में कुछ भी नहीं जोड़ा जाता है।```bash
git clone https://github.com/sunnypatell/basalt.git
cd basalt
python -m venv .venv && source .venv/bin/activate   # Windows: .\.venv\Scripts\Activate.ps1
pip install -e ".[dev]"

python scripts/fetch_toolchain.py     # pinned ptxas + nvdisasm
python -m basalt.cli doctor           # verify both oracles end to end
python scripts/verify_all.py          # every control in this README, in order

I don't see any input text to translate. The INPUT section is empty — no Markdown content was provided for chunk 7 of 29. Please supply the source text, and I'll translate it into Hindi following all the formatting rules.```console $ python -m basalt.cli doctor ok toolchain V13.3.73 in third_party/cuda/13.3.1/bin ok ptxas assembled sm_120a ok cubin oracle 16 instructions with encodings ok probe oracle 16/16 mnemonics round-tripped

both oracles healthy. no GPU required for anything above.

### या एक पैकेज के रूप में

`pip install basalt-sass` CLI, लाइब्रेरी और तीनों माप तालिकाओं को स्थापित करता है, बिना
किसी रनटाइम निर्भरता के। यदि आपके मशीन पर पहले से CUDA है तो इसका उपयोग करें; यदि नहीं है,
या यदि आप मापों को दोहराना चाहते हैं, तो उपरोक्त checkout ही आपको चाहिए।```bash
pip install basalt-sass
basalt doctor
basalt verify kernel.cubin

यह ptxas और nvdisasm कहाँ खोजता है

basalt दोनों को बाहरी प्रक्रियाओं के रूप में चलाता है और किसी का भी पुनर्वितरण नहीं करता, इसलिए उसे एक प्रति ढूँढनी पड़ती है। यह सबसे पहले मिलने वाली प्रति लेता है, और कोई भी CUDA 13 इंस्टॉल काम करेगा: कुछ भी पिन किया हुआ पुनर्वितरण योग्य होना आवश्यक नहीं है।

basalt doctor बताता है कि उसने कौन सी प्रति चुनी है, और जब वह एक नहीं ढूँढ पाता तो गैर-शून्य कोड के साथ बाहर निकलता है, इसलिए यह केवल पढ़ने की वस्तु नहीं बल्कि बिल्ड-चरण की पूर्वशर्त के रूप में काम करता है।

इंस्ट्रक्शन डेटाबेस को क्वेरी करने के लिए किसी टूलचेन की आवश्यकता नहीं होती, क्योंकि डेटाबेस पहले से मापा जाता है और पैकेज के अंदर शामिल होता है:```bash basalt isa --stats basalt isa --opcode QMMA

निर्देश डेटाबेस को स्क्रैच से फिर से बनाएं, या कमिट किए गए डेटाबेस को क्वेरी करें:```bash
python -m basalt.cli build-isa          # harvest, probe, write src/basalt/data/isa/sm_120a.json
python -m basalt.cli isa --stats
python -m basalt.cli isa IMAD.WIDE.U32  # one form, with its measured field layout
python -m basalt.cli isa --opcode QMMA  # every form of one opcode

उस मशीन कोड की जाँच करें जो आपने नहीं लिखा

यह वह हिस्सा है जो और कोई नहीं करता, और इसे न GPU की आवश्यकता है और न तर्कों की। मापा गया विलंबता मॉडल और खनन की गई आवश्यकता तालिका दोनों प्रतिबद्ध हैं, इसलिए एक नया क्लोन सीधे किसी भी cubin की ओर इंगित किया जा सकता है, चाहे उसे किसी भी चीज़ ने उत्पन्न किया हो:```bash python -m basalt.cli verify kernel.cubin

I notice the input section is empty—no source text was provided for translation. Please share the chunk content so I can translate it into Hindi.```console
$ python -m basalt.cli verify nvjpeg.sm_120.cubin
  25 kernels, 0 with an error
  7984 instructions in 789 blocks, 11580 dependencies checked across blocks: 0 errors, 3 warnings
  pair data: 3957 pairings from 25634 kernels, 427 producers with enough observations to use
  latency model: measured on NVIDIA GeForce RTX 5070 Ti

एक लाइब्रेरी ELF में सैकड़ों कर्नेल होते हैं और प्रत्येक की अपने आप जाँच की जाती है, क्योंकि ऑफ़सेट शून्य से पुनः प्रारंभ होते हैं और एक से दूसरे में कुछ भी फ़ॉल-थ्रू नहीं होता है। बाहर निकलने के लिए --strict जोड़ें किसी हैज़र्ड पर नॉन-ज़ीरो, जो कि एक बिल्ड स्टेप के लिए आवश्यक है। यदि आपके पास sm_120 कार्ड है और चाहते हैं कि मॉडल को इस रिपॉज़िटरी में मौजूद सिलिकॉन के बजाय आपके अपने सिलिकॉन पर मापा जाए:```bash python -m basalt.cli measure -o my-card.json # needs a GPU, once python -m basalt.cli verify kernel.cubin --latencies my-card.json

<details>
<summary><b>हर कमांड, और किसे कार्ड की आवश्यकता है</b></summary>

<br/>

| कमांड | यह क्या करता है | GPU की आवश्यकता है |
| :--- | :--- | :--- |
| `doctor` | दोनों ओरेकल की एंड-टू-एंड जाँच करें | नहीं |
| `build-isa` | संग्रह और जाँच करें, निर्देश डेटाबेस लिखें | नहीं |
| `isa` | किसी फ़ॉर्म, ओपकोड या कवरेज को क्वेरी करें | नहीं |
| `validate-isa` | साबित करें कि मापे गए फ़ील्ड लिखे जा सकते हैं | नहीं |
| `mine-stalls` | कंपाइलर जो शेड्यूल करता है उससे प्रति-जोड़ी आवश्यकताएँ सीखें | नहीं |
| `verify` | डेटा खतरों के लिए cubin के नियंत्रण बिट्स की जाँच करें | नहीं |
| `schedule` | cubin के नियंत्रण बिट्स को शुरू से असाइन करें और परिणाम जाँचें | नहीं |
| `assemble` | SASS टेक्स्ट, या पूरे cubin को एनकोड करें और इसे साबित करने के लिए वापस पढ़ें | नहीं |
| `measure` | वास्तविक सिलिकॉन पर निर्देश विलंबता मापें | **हाँ** |
| `probe-stalls` | प्रोग्रामों को जानबूझकर तोड़कर आवश्यक स्टाल खोजें | **हाँ** |

</details>

CLI जो कुछ भी करता है वह इम्पोर्ट करने योग्य है, और रनने योग्य उदाहरणों सहित लाइब्रेरी इंटरफ़ेस
[`docs/API.md`](https://github.com/sunnypatell/basalt/blob/main/docs/API.md) में है।

और वे दो नियंत्रण जो बाकी को सही रखते हैं। पहले को एक कार्ड चाहिए; दूसरे को
शिप की गई लाइब्रेरीज़ चाहिए और बिल्कुल भी हार्डवेयर नहीं:```bash
python scripts/roundtrip_corpus.py    # reschedule all 441 corpus kernels, run both on the GPU

python scripts/fetch_toolchain.py --libs                  # ~1.2 GB, no admin, nothing on PATH
python scripts/audit_shipped.py --libs third_party/cuda/13.3.1/libs

No input content was provided to translate. The chunk text is missing after "INPUT:".```console $ python -m basalt.cli verify kernel.cubin --latencies src/basalt/data/latency/rtx-5070-ti.json kernel.cubin 32 instructions in 3 blocks, 23 dependencies checked: clean latency model: measured on NVIDIA GeForce RTX 5070 Ti

## मापा गया, अनुमानित नहीं

यहाँ की संख्याएँ टूलिंग द्वारा मुद्रित होती हैं और एक स्वच्छ चेकआउट से पुनः उत्पन्न होती हैं। ऊपर दिए गए कमांड सत्य के स्रोत हैं; ये तालिकाएँ स्नैपशॉट हैं।

**निर्देश डेटाबेस।** हर प्रविष्टि में वह एन्कोडिंग होती है जो वास्तव में असेंबल हुई और वह कंपाइलर बिल्ड जिसने इसे उत्पन्न किया।

| निर्देश डेटाबेस | संख्या |
| :--- | ---: |
| निर्देश प्रारूप | 345 |
| विशिष्ट ऑपकोड | 90 |
| पूर्ण ऑपरेंड मैप वाले प्रारूप | 339 |
| टेंसर-कोर प्रारूप | 46 |
| निर्मित | `ptxas` V13.3.73 |

टेंसर कवरेज वह जगह है जहाँ निम्न-परिशुद्धता हार्डवेयर रहता है: FP8, FP6 और FP4 प्रकारों में `HMMA` और `IMMA`, `QMMA`, जिसमें असममित ऑपरेंड युग्म शामिल हैं, स्केल-फैक्टर प्रारूप `QMMA.SF` और `OMMA.SF` जो प्रति-ब्लॉक घातांक रखते हैं, स्पार्स `IMMA.SP`, और मैट्रिक्स गति निर्देश `LDSM`, `STSM` और `MOVM` हर आकृति में, ट्रांसपोज़िंग वेरिएंट सहित।

**विलंबता, RTX 5070 Ti पर।** 70 SMs, हर फिट R² ≥ 0.9998। आश्रित श्रृंखलाओं का समय मापकर और ढलान लेकर मापा गया, जिसमें श्रृंखला की लंबाई संकलित SASS से वापस पढ़ी गई, अनुमानित नहीं।

| निर्देश | साइकिल |
| :--- | ---: |
| `IMAD` `IADD3` `FFMA` `FADD` `FMUL` `LOP3` `SHF` | 4 |
| `POPC` | 18 |
| `I2FP` + `F2I` एक साथ | 24 |
| `MUFU` | 44 |
| `DADD` `DFMA` | 64 |

इनमें से तीन उस अनुमानित मॉडल का खंडन करते हैं जिसके साथ basalt जारी किया गया था: `DADD` को 48 माना गया था, `POPC` को 4 माना गया था, और प्रत्येक रूपांतरण को 6 माना गया था, जबकि राउंड ट्रिप के लिए 24 मापा गया।

<img src="https://raw.githubusercontent.com/sunnypatell/basalt/main/docs/assets/chart-latency.svg" alt="तीन विलंबताएँ जिन्हें basalt ने सिलिकॉन की रिपोर्ट के विरुद्ध मापने से पहले अनुमानित किया था: fp64 जोड़ 48 अनुमानित और 64 मापा गया, POPC 4 अनुमानित और 18 मापा गया, और I2FP प्लस F2I रूपांतरण राउंड ट्रिप 12 अनुमानित और 24 मापा गया।">

एक अनुमानित विलंबता मॉडल, मापे गए मॉडल का छोटा सन्निकटन नहीं है, जो मापने का पूरा तर्क है।

**और शून्य स्टॉल शून्य साइकिल नहीं है।** यह एक अलग सुरक्षित एन्कोडिंग है जो बकाया परिणामों की प्रतीक्षा करती है, जिसकी लागत लगभग 37 साइकिल है जबकि एक निर्धारित निर्देश की लागत 4 है। यही कारण है कि `ptxas -O0` एक पूर्णतः शून्यित नियंत्रण शब्द उत्सर्जित करता है और कोड फिर भी सही ढंग से गणना करता है, लगभग नौ गुना धीमा।

| `stall` | साइकिल/निर्देश | परिणाम |
| ---: | ---: | :--- |
| **0** | **36.85** | **सही** |
| 1 | 4.88 | गलत |
| 2 | 4.88 | गलत |
| 3 | 5.88 | गलत |
| 4 | 6.88 | सही |

**यह कॉर्पस के हर कर्नेल पर विक्रेता कंपाइलर से सहमत है।** `ptxas` कॉर्पस से जो भी कर्नेल बनाता है, उसे उसके अपने शेड्यूलिंग के विरुद्ध सत्यापित किया जाता है, हर अनुकूलन स्तर पर जो शेड्यूल करता है: 30,421 निर्भरताएँ, शून्य त्रुटियाँ। यह स्वीप हर पुश पर CI में चलता है, और इस परियोजना द्वारा की गई हर मॉडलिंग त्रुटि तर्क से नहीं, बल्कि इसी से पकड़ी गई।

**निर्णय सिलिकॉन से मेल खाते हैं।** किसी आश्रित उत्पादक पर हर एन्कोड करने योग्य स्टॉल के लिए, basalt का स्थिर उत्तर और हार्डवेयर वास्तव में जो गणना करता है, वे सहमत हैं, शून्य स्थिति सहित। इसे एक परीक्षण के रूप में रखा गया है, यहाँ दावा नहीं किया गया। पूर्ण साक्ष्य, जिसमें आवश्यक स्टॉल के लिए तीन स्वतंत्र विधियाँ और रास्ते में किए गए सुधार शामिल हैं, [findings](https://github.com/sunnypatell/basalt/blob/main/docs/FINDINGS.md) में है।

**और जब यह कहता है कि कोई शेड्यूल असुरक्षित है, तो सिलिकॉन सहमत होता है।** 233 कर्नेल के लिए विक्रेता का अपना कार्यशील शेड्यूल लें, हर एक में एक वास्तविक निर्भरता छोटी करें, और basalt के निर्णय की तुलना GPU द्वारा गणना किए गए परिणाम से करें: 79 जिन्हें इसने टूटा हुआ कहा, टूटे हुए थे, और **जिन्हें इसने सुरक्षित कहा, उनमें से किसी ने भी गलत उत्तर नहीं निकाला**। यह संख्या शून्य के बजाय 34 छूटे हुए कर्नेल से शुरू हुई थी, और [findings](https://github.com/sunnypatell/basalt/blob/main/docs/FINDINGS.md) बताता है कि कारण क्या था और इसे ठीक करने की कीमत झूठे अलार्म में क्या थी, क्योंकि एक स्वीप जो केवल अपना अंतिम आँकड़ा रिपोर्ट करता है, उस स्वीप से कम मूल्यवान होगा जो अपना पहला आँकड़ा रिपोर्ट करता है।

## यह नियंत्रण बिट भी निर्धारित कर सकता है

सत्यापनकर्ता उत्तर देता है कि कोई शेड्यूल सुरक्षित है या नहीं। शेड्यूलर उत्तर देता है कि एक सुरक्षित शेड्यूल क्या होगा, उन्हीं मापों से: यह `ptxas` द्वारा उत्पन्न हर नियंत्रण बिट को त्याग देता है, अपना स्वयं का निकालता है, परिणाम वापस सत्यापनकर्ता को सौंपता है, और फिर उसे उसी कर्नेल के विक्रेता संस्करण के बगल में GPU पर चलाता है।

पूरे कॉर्पस को कार्ड पर चलाकर, हर अनुकूलन स्तर पर जो एक शेड्यूल उत्पन्न करता है, सभी 439 तुलनीय कर्नेल विक्रेता शेड्यूल के बाइट-समान परिणाम निकालते हैं, उन नियंत्रण बिटों से जिन्हें basalt ने स्वयं निकाला। जो 2 बाहर रखे गए हैं वे क्लॉक और ग्रिड आईडी पढ़ते हैं, इसलिए वे स्वयं से भी सहमत नहीं होते, और [findings](https://github.com/sunnypatell/basalt/blob/main/docs/FINDINGS.md) यह कहता है बजाय उन्हें प्रतिशत में मिलाने के।

वह नियंत्रण ही कारण है कि बाकी सब कुछ भरोसेमंद है। जाँचकर्ता और शेड्यूलर एक ही विलंबता मॉडल पढ़ते हैं, इसलिए उसमें एक गलत प्रविष्टि दोनों को एक साथ संतुष्ट कर देती है और वे एक-दूसरे से सहमत होते हैं जबकि दोनों गलत होते हैं। केवल सिलिकॉन का इस तर्क में कोई दाँव नहीं होता। शेड्यूलर को सात हाथ से लिखे कर्नेल पर चलाने से लंबे समय तक सात में से सात पास हुए; इसे तीन सौ पर चलाने से इकतालीस गलत मिले, और तब से हर मॉडल सुधार उस संख्या को हिलते देखने से आया।

वही लूप है जहाँ से वास्तविक बग आए। एक उत्पादक और उसके उपभोक्ता के बीच की खिड़की के बाहर बिताया गया स्टॉल किसी काम का नहीं होता, और वहाँ बिताने से खोज एक ऐसे प्रोग्राम के साथ समाप्त होती है जो अभी भी छोटा है। सुरक्षित एन्कोडिंग पर लगाया गया एक स्टॉल बाद के एक पास द्वारा अधिलेखित किया जा रहा था, एक गारंटी को एक छोटी संख्या से बदल दिया। fp64 ऑपरेंड रजिस्टर युग्मों पर कब्जा करते हैं, जिसमें मेमोनिक में कुछ भी ऐसा नहीं होता जो यह बताए, इसलिए हर fp64 निर्भरता का आधा हिस्सा जाँचकर्ता और शेड्यूलर दोनों के लिए अदृश्य था। किसी निर्देश के गार्ड के रूप में उपयोग किया गया एक प्रेडिकेट तेरह साइकिल चाहता है, जबकि डेटा के रूप में पढ़ा गया वही प्रेडिकेट पाँच चाहता है, क्योंकि गार्ड को निर्देश जारी होने से पहले ही हल किया जाना चाहिए। और स्कोरबोर्ड पर प्रतीक्षा करना किसी निर्भरता को पूरी तरह से नहीं सुलझाता: उत्पादक पर अभी भी अपना छोटा स्टॉल बकाया है, fp64 जोड़ के लिए दो साइकिल, और एक साइकिल कम चुपचाप गलत है। इनमें से कोई भी तर्क से नहीं मिला; हर एक आउटपुट चलाकर और गलत संख्या पाकर मिला।

> [!NOTE]
> **1.0, और इस बारे में विशिष्ट कि इसका क्या अर्थ है।** जो किया गया है: दोनों ओरेकल, निर्देश डेटाबेस जिसके फ़ील्ड लिखने योग्य सिद्ध हुए हैं, एक वास्तविक नियंत्रण-प्रवाह ग्राफ़ पर खतरा जाँचकर्ता, तीन स्वतंत्र विधियों द्वारा एक SKU पर मापी गई विलंबता, एक शेड्यूलर जो हर तुलनीय कॉर्पस कर्नेल को हार्डवेयर के माध्यम से बाइट-दर-बाइट राउंड-ट्रिप करता है, और 2,762 जारी किए गए कर्नेल का ऑडिट, जो जाँचकर्ता द्वारा पढ़ी जाने वाली हर तालिका से बाहर रखे गए हैं। जो नहीं किया गया: 12 कॉर्पस कर्नेल जो निर्माण से ही नहीं चलाए जा सकते और 2 जिनका विक्रेता आउटपुट नियतात्मक नहीं है, सभी findings में नामित हैं; दस ऑपकोड अभी भी मापी गई विलंबता के बजाय अनुमानित विलंबता रखते हैं, उनमें से कोई भी कभी भी किसी भी कोड निकाय में उत्पादक नहीं है; और केवल एक GPU मापा गया है, जिसके बारे में [finding 28](https://github.com/sunnypatell/basalt/blob/main/docs/FINDINGS.md) दर्शाता है कि यह जितना सुनाई देता है उससे कम मायने रखता है। जहाँ कुछ मापने के बजाय अनुमानित किया गया है, टूलिंग यह कहती है बजाय उसे एक तथ्य में बदल देने के। [रोडमैप](https://github.com/sunnypatell/basalt/blob/main/docs/ROADMAP.md) और [विधि](https://github.com/sunnypatell/basalt/blob/main/docs/METHOD.md) देखें।

## रिपॉजिटरी लेआउट

<details>
<summary><b>सब कुछ कहाँ रहता है</b></summary>

<br/>```
src/basalt/
  toolchain.py     Locating and driving ptxas / nvdisasm
  encoding.py      The 128-bit instruction word and its control fields
  disasm.py        Both oracles: cubin ground truth and raw-word probe
  harvest/         PTX corpus generation and encoding extraction
  probe/           Differential bit probing and field inference
  isa/             The generated instruction database and its builder
  asm/             The assembler, and the ELF reader that rewrites words in place
  sched/           Assigning the control bits, and costing the result
  verify/          Register def-use analysis, hazard model, latency checking
  gpu/             Driver-API bindings and the latency measurement harness
src/basalt/data/   The measured tables, inside the package so an installed copy
                   has them: the ISA database, the latency model and the mined
                   stall requirement
docs/              Findings, method, the Python API, roadmap, artwork sources
scripts/           Toolchain fetch, asset rendering, drift check, and the two
                   hardware controls: the corpus round trip and the agreement sweep
tests/             Unit tests, plus toolchain- and GPU-marked suites

क्लीन-रूम स्थिति

basalt एक स्वतंत्र, क्लीन-रूम इंटरऑपरेबिलिटी कार्य है। इसमें कोई NVIDIA स्रोत कोड, हेडर, लाइब्रेरी या दस्तावेज़ शामिल नहीं है, और यह किसी का पुनर्वितरण नहीं करता। यह सार्वजनिक रूप से वितरित एक्ज़ीक्यूटेबल के व्यवहार का अवलोकन करता है और उसे रिकॉर्ड करता है—यही वह आधार है जिस पर इस तरह का कार्य एक दशक से अधिक समय से खड़ा है।

NVIDIA, CUDA और Blackwell NVIDIA Corporation के ट्रेडमार्क हैं। यह प्रोजेक्ट NVIDIA से संबद्ध, समर्थित या प्रायोजित नहीं है।

Apache-2.0 के अंतर्गत लाइसेंस प्राप्त। जान-बूझकर किसी प्रतिबंधात्मक लाइसेंस के बजाय Apache: एक सहीपन(करेक्टनेस) टूल जिस पर किसी को निर्माण करने की अनुमति नहीं है, वह एक सहीपन टूल है जिसे कोई चलाता नहीं है, और पेटेंट अनुदान हार्डवेयर के इतने करीब के कार्य के लिए मायने रखता है।

योगदान

सबसे उच्च-मूल्य वाला योगदान वह एन्कोडिंग है जिसे basalt गलत समझता है। CONTRIBUTING.md और ISA गैप टेम्पलेट देखें, जो आपकी मशीन के बिना पुनरुत्पादन के लिए पर्याप्त जानकारी एकत्र करता है।

SUPPORT.md बताता है कि कोई प्रश्न कहाँ जाता है, GOVERNANCE.md बताता है कि किसी बदलाव को किन मानदंडों को पार करना होता है, RELEASING.md बताता है कि रिलीज़ कैसे कटती और सत्यापित होती है, और SECURITY.md बताता है कि निजी तौर पर रिपोर्ट कैसे करें।

basalt का उद्धरण

यदि basalt किसी पेपर, टूल, मॉडल या बग रिपोर्ट को सूचित करता है, तो कृपया इसे उद्धृत करें। GitHub CITATION.cff को मूल रूप से पढ़ता है, इसलिए साइडबार में Cite this repository आपको बिना किसी ट्रांसक्रिप्शन के APA और BibTeX देता है। यही फ़ाइल Zenodo और उद्धरण प्रबंधकों द्वारा पार्स की जाती है, और यह लेखकत्व का प्रामाणिक रिकॉर्ड है।

नीचे दी गई कुंजी वही है जो GitHub उत्पन्न करता है, इसलिए यहाँ से कॉपी करना और साइडबार से कॉपी करना एक ही प्रविष्टि देता है, न कि दो जो अलग-अलग कार्यों की तरह दिखते हैं:```bibtex @software{Patel_basalt_a_hazard_2026, author = {Patel, Sunny}, license = {Apache-2.0}, month = aug, title = {{basalt: a hazard checker, assembler and scheduler for NVIDIA consumer Blackwell (sm_120)}}, doi = {10.5281/zenodo.22072811}, url = {https://github.com/sunnypatell/basalt}, version = {1.0.0}, year = {2026} }

**कॉन्सेप्ट DOI** को उद्धृत करें, [`10.5281/zenodo.22072811`](https://doi.org/10.5281/zenodo.22072811), किसी
वर्शन DOI या इस URL के बजाय। यह नवीनतम रिलीज़ पर पहुँचता है, इसलिए यह बिना दोबारा संपादित
किए सदैव सही बना रहता है। `CITATION.cff` इसे धारण करता है, इसलिए यह पहले से ही उपरोक्त
दोनों रूपों में मौजूद है।

यदि आप मापी गई तालिकाओं (`src/basalt/data/`) का पुनः उपयोग करते हैं या कोई आकृति पुनः
प्रस्तुत करते हैं, तो `main` के बजाय उस रिलीज़ को उद्धृत करें जिससे वे आई हैं: संख्याएँ
`scripts/verify_all.py` द्वारा एक विशिष्ट कमिट पर पुनः उत्पन्न की जाती हैं, और एक टैग ही
उसे पुनरुत्पादनीय बनाता है।

**एट्रिब्यूशन लाइसेंस की शर्त है, सौजन्य नहीं।** Apache-2.0 §4 के अनुसार
[`LICENSE`](https://github.com/sunnypatell/basalt/blob/main/LICENSE) और [`NOTICE`](https://github.com/sunnypatell/basalt/blob/main/NOTICE) को किसी भी पुनर्वितरण या व्युत्पन्न कार्य
के साथ रखा जाना आवश्यक है, और `NOTICE` लेखकत्व तथा क्लीन-रूम विवरण धारण करता है।
फ़ोर्क, वेंडरड प्रतियाँ और पुनःपैकेज्ड व्हील्स — सभी दोनों फ़ाइलों को बनाए रखते हैं।

## लेखक

**Sunny Patel** · [sunnypatel.net](https://www.sunnypatel.net) · [github.com/sunnypatell](https://github.com/sunnypatell)