Rust से GPU kernel ड्राइवर लिखना: GPU ड्राइवर के काम करने के तरीके का संक्षिप्त परिचय

• यह लेख Linux kernel के लिए Rust में विकसित आधुनिक GPU driver Tyr की विकास प्रक्रिया और GPU ड्राइवर के काम करने के सिद्धांतों पर केंद्रित है
• GPU ड्राइवर डेवलपमेंट में UMD (यूसर मोड ड्राइवर) और KMD (कर्नेल मोड ड्राइवर) की भूमिका विभाजन तथा उनकी परस्पर क्रिया को VkCube उदाहरण के माध्यम से समझाया गया है
• UMD उच्च-स्तरीय API को GPU द्वारा समझे जा सकने वाले लो-लेवल कमांड में बदलता है, जबकि KMD मेमोरी एलोकेशन, जॉब शेड्यूलिंग, डिवाइस इनिशियलाइज़ेशन जैसी मुख्य ज़िम्मेदारियाँ संभालता है
• Tyr ड्राइवर द्वारा दी गई API Panthor के समान है और इसमें डिवाइस क्वेरी, मेमोरी मैनेजमेंट, ग्रुप मैनेजमेंट, जॉब सबमिशन, Tiler heap मैनेजमेंट आदि शामिल हैं
• अगले लेख में Arm CSF हार्डवेयर आर्किटेक्चर और उसके मुख्य घटकों (जैसे MCU) तथा बूट प्रक्रिया पर चर्चा की जाएगी

---

परिचय: Rust आधारित आधुनिक GPU kernel ड्राइवर विकास

• यह लेख Linux kernel पर Arm Mali CSF आधारित GPU का समर्थन करने वाले आधुनिक Rust GPU kernel driver Tyr की विकास श्रृंखला का दूसरा लेख है
• वास्तविक उदाहरण के रूप में हमने Vulkan API का उपयोग करके घूमता हुआ cube render करने वाले सरल 3D प्रोग्राम VkCube को चुना है, ताकि GPU ड्राइवर के अंदरूनी काम करने के तरीके को समझाया जा सके
• VkCube की सरल संरचना GPU ड्राइवर के ऑपरेशन मॉडल को सीखने के लिए उपयुक्त केस स्टडी साबित होती है

GPU ड्राइवर की बुनियाद: UMD और KMD की भूमिका तथा संरचना

• इसमें User Mode Driver(UMD) और Kernel Mode Driver(KMD) शामिल होते हैं
  • UMD: panvk (Mesa के Vulkan ड्राइवर आदि) की तरह सामान्य ऐप्स के API (Vulkan, OpenGL आदि) को implement करता है
  • KMD: Tyr आदि, Linux kernel में रन होने वाला privileged kernel-level हार्डवेयर ड्राइवर
• kernel mode GPU ड्राइवर, UMD और वास्तविक GPU के बीच सेतु का काम करता है, जबकि UMD API कमांड की व्याख्या करके उन्हें GPU-readable command sequence में बदलता है
• UMD दृश्य निर्माण के लिए ज़रूरी geometry, texture, shader आदि डेटा तैयार करता है और execution से पहले उसे GPU memory में allocate करने के लिए KMD से अनुरोध करता है
• शेडर GPU पर चलने वाले स्वतंत्र प्रोग्राम होते हैं; VkCube में वे cube placement, coloring और rotation logic संभालते हैं। शेडर रन होने के लिए अतिरिक्त data (geometry, color, rotation matrix आदि) की आवश्यकता होती है
• UMD तैयार कमांड (जैसे VkCommandBuffers) को KMD को भेजकर रन कराता है; काम पूरा होने पर completion notification मिलते ही परिणाम memory में लिख सकता है

KMD (कर्नेल मोड ड्राइवर) की मुख्य ज़िम्मेदारियाँ

• GPU मेमोरी की allocation और mapping (हर ऐप्लिकेशन के लिए अलग isolation उपलब्ध कराना)
• हार्डवेयर queue में जॉब सबमिशन और completion के समय उपयोगकर्ता को notification भेजना
• asynchronous और parallel hardware वातावरण में jओब निर्भरता प्रबंधन अनिवार्य होता है; सही परिणाम सुनिश्चित करने के लिए KMD scheduling और dependency validation का काम करता है
• डिवाइस इनिशियलाइज़ेशन, clock/voltage regulator control, startup code execution, कई क्लाइंट्स को hardware fair तरीके से share करने के लिए access rotation management आदि भी इसमें शामिल हैं

जटिलता कहाँ केंद्रित है: UMD और KMD का विभाजन

• GPU ड्राइवर की बड़ी हिस्सेदारी की जटिलता सामान्यतः UMD में होती है
  • UMD: हाई-लेवल API commands को hardware commands में बदलता है
  • KMD: UMD सही तरीके से काम कर सके, इसके लिए memory isolation, साझा उपयोग, fair access जैसी core सुविधाएँ देता है

Tyr की ड्राइवर इंटरफ़ेस (API) संरचना

• Tyr ड्राइवर API (Panthor के समान) को कुल मिलाकर 5 समूहों में समझा जा सकता है
  1. डिवाइस info query: DEV_QUERY (IOCTL द्वारा GPU हार्डवेयर info देखना, ROM क्षेत्र का उपयोग)
  2. मेमोरी allocation और isolation: VM_CREATE, VM_BIND, VM_DESTROY, VM_GET_STATE, BO_CREATE, BO_MMAP_OFFSET आदि
  3. शेड्यूलिंग group management: GROUP_CREATE, GROUP_DESTROY, GROUP_GET_STATE (विस्तृत विवरण अगले लेख में)
  4. जॉब सबमिशन: GROUP_SUBMIT (device command buffers के माध्यम से GPU पर execute request भेजना)
  5. Tiler heap management: TILER_HEAP_CREATE, TILER_HEAP_DESTROY (tiled rendering GPU की memory requirements पूरी करने के लिए)
• ये APIs वास्तव में सीधे pixels draw करने के काम से दूरी पर होती हैं, लेकिन UMD वास्तविक commands execute करता है और KMD केवल hardware access के लिए ऊपर का interface उपलब्ध कराता है

निष्कर्ष और आगे की योजना

• इस लेख में हमने GPU ड्राइवर का समग्र ढांचा और आंतरिक flow, तथा Tyr के core APIs पर एक नजर डाली
• इसी आधार पर श्रृंखला के अगले लेख में Arm CSF हार्डवेयर आर्किटेक्चर, माइक्रोकंट्रोलर यूनिट (MCU) जैसे मुख्य घटकों और ड्राइवर initialization process पर चर्चा की जाएगी

[GN⁺]

Hacker News राय

• बहुत बढ़िया लेख था, लेकिन कंटेंट बहुत छोटा लगा; अभी जब ये दिलचस्प बनना शुरू ही हुआ था वहीँ खत्म हो गया लगता है, इसलिए अगले हिस्से का इंतज़ार है
  • अगला हफ्ता भी एक और रोमांचक episode लेकर आएगा—जहाँ आप देखेंगे कि GPU में queued commands queue से निकलकर कैसे execute होते हैं। इस लेख में जो abstraction level बताया गया है वह user-space/kernel boundary पर data पास करने वाला हिस्सा है। इसलिए इसमें ज्यादातर queue और buffer management ही कवर होता है, इसलिए गणनाएँ/compute बहुत ज्यादा नहीं हैं। असली काम तो तब होता है जब queue में डाले गए commands रन होते हैं। GPU से उल्टी दिशा में भी एक और command-completion signal जाता है—वह भी देखना दिलचस्प रहेगा। ये लगभग सारा asynchronous handling driver में नहीं, user code में ही होता है; driver सिर्फ completion signal आगे भेजता है
• मैं RK3588 के एक डिवाइस को desktop की तरह इस्तेमाल कर रहा हूँ और इसमें panfrost चला रहा हूँ, लेकिन कभी-कभी Firefox में स्क्रीन ब्लैक हो जाती है या transparent area बन जाते हैं—यह एक odd behavior है
  • RK3588 में दरअसल panfrost नहीं, इसी पोस्ट का विषय panthor driver इस्तेमाल होता है
• क्या uring_cmd को ioctls की जगह लेने पर किसी ने सोचा था? क्योंकि यह project पूरी तरह नया build किया गया है, इसलिए यह लागू हो सकता लगता था; पर मुझे समझ नहीं आया कि इसे लगभग कोई फायदा क्यों नहीं माना गया
  • GPU पहले से ही अपना async command queue रखता है, इसलिए ioctl का काम मूलतः उस command queue पर लिखने तक ही रहता है और वही पहले से ही relatively cheap है। इसलिए CPU side पर एक और async queue बनाकर उस write को schedule करना एक limited-use विकल्प है। अगर proposal यह था कि GPU का खुद का command queue ही uring बनाकर userspace में map किया जाए, तो io_uring API spec को ठीक से support करने के लिए firmware में काफी बड़ा बदलाव करना पड़ेगा, और शायद hardware constraints की वजह से यह संभव ही न हो
  • जिस driver का लेख में जिक्र है, वह userspace Mesa library जो API मांगती है, वही API सीधे follow करता है
• यह वाकई दिलचस्प था, इसलिए सोच रहा था कि क्या कोई follow-up part है या कोई logical continuation आने वाला है
  • यह आज पहली बार public हुई post है, इसलिए उम्मीद है आगे और updates आएँगी
• "Rust GPU driver" शीर्षक निश्चित ही क्लिक बढ़ाने वाला लगा, लेकिन क्या यह वास्तव में Arm Mali CSF based GPU driver नहीं है? सच कहूँ तो मेरा focus meta-tool पर चला गया था जो tool development के लिए लगता है—व्यक्तिगत तौर पर मुझे यह पसंद नहीं; लगा कि actual intent Rust में कुछ बनाने का है। आर्टिकल में इसे "arm mali based gpu driver kernel" लिखा गया है, फिर भी इसे arm mali driver नहीं कहा गया। किसी ड्राइवर को बनाना बस OS API और hardware vendor API को connect करने का काम होता है; उसके ऊपर किसी अतिरिक्त abstraction-layer framework को build करना नहीं। शायद भाषा थोड़ी सीधेपन की है, उसके लिए समझने की कोशिश करें
  • इस case में Rust शब्द का महत्व इसलिए है क्योंकि Linux में यह Rust-based GPU driver के शुरुआती (या शुरुआती प्रयासों में से एक) उदाहरणों में है
  • मैं आपके blunt शब्दों को बुरा नहीं मानता; आपकी बोलचाल से लगता है कि आपको modern GPU driver की current reality का ज्यादा पता नहीं है। मैं भी लगभग 15 साल पहले तक इन्हें इस्तेमाल करता था, और सिर्फ इतना जानता हूँ कि तब से यह काफी complex हो गया है। Linux kernel source code देखें तो GPU drivers code lines के हिसाब से सबसे बड़ा हिस्सा occupy करते हैं। लगभग सभी drivers कई graphics cards को support करते हैं। हर GPU card के लिए पूरी तरह अलग और independent driver अलग से बनाना कितना irrational है, यह सवाल है। GPU driver काम दो APIs को बस 'लाइन से लाइन जोड़ने' जैसा नहीं होता; असल में यह कहीं ज्यादा अलग है। अगर आप सच में इसे चुनौती दे सकते हैं तो अपना लिखा हुआ GPU driver दिखाइए—मैं सच में देखना चाहूँगा कि क्या आपने वाकई सिर्फ कुछ लाइनें जोड़कर काम खत्म कर दिया
  • Rust महत्वपूर्ण इसलिए है क्योंकि यह शायद पहला (या पहले कुछ मामलों में से एक) प्रयास है जहाँ Rust infrastructure को GPU driver में use किया गया है