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

 (collabora.com)
3 पॉइंट द्वारा GN⁺ 2025-08-08 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • यह लेख 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 पर चर्चा की जाएगी

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.