हैक किए गए Nvidia 4090 GPU ड्राइवर में P2P सक्रिय

 (github.com/tinygrad)
1 पॉइंट द्वारा GN⁺ 2024-04-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह repository NVIDIA Linux open GPU kernel modules का source release है, और README के अनुसार इसका version 565.57.01 है
  • बनाए गए kernel modules को उसी 565.57.01 driver release के GSP firmware और user-space NVIDIA GPU driver components के साथ इस्तेमाल करना होगा
  • समर्थित targets x86_64 और aarch64 हैं, और Linux kernel support proprietary NVIDIA kernel modules जैसी ही range को कवर करता है, जो वर्तमान में 4.15 या उससे ऊपर है
  • kernel modules को operating-system-independent components और Linux kernel interface layer में बांटा गया है, और target kernel के अनुसार kernel interface layer को build करना होगा
  • compatible GPU में Turing के बाद के GPU शामिल हैं, और तालिका में NVIDIA GeForce RTX 4090 सहित कई GeForce, RTX, A/H/L series products और PCI ID सूचीबद्ध हैं

रिलीज़ और build शर्तें

  • यह repository NVIDIA Linux open GPU kernel modules का source release है और इसका version 565.57.01 है
  • मूल build command इस प्रकार है
    • make modules -j$(nproc)
  • install करने से पहले मौजूदा NVIDIA kernel modules को हटाना होगा, और root अधिकारों के साथ निम्न चलाना होगा
    • make modules_install -j$(nproc)
  • यहां बनाए गए kernel modules के लिए संबंधित 565.57.01 driver release का GSP firmware और user-space NVIDIA GPU driver components आवश्यक हैं
    • उदाहरण के तौर पर NVIDIA GPU driver .run फ़ाइल को --no-kernel-modules विकल्प के साथ install करने का तरीका दिया गया है

समर्थित architecture और toolchain

  • kernel modules को फिलहाल x86_64 या aarch64 के लिए build किया जा सकता है
  • cross compilation के समय TARGET_ARCH=aarch64|x86_64 के साथ CC, LD, AR, CXX, OBJCOPY को make command line में निर्दिष्ट किया जाता है
  • इसे GCC या Clang के अपेक्षाकृत नए versions से build किया जा सकता है
  • kernel modules की kernel interface layer को उसी toolchain से build करना होगा जिसका उपयोग target kernel को build करने में किया गया था
  • समर्थित Linux kernel versions वही range हैं जिन्हें proprietary NVIDIA kernel modules support करते हैं, और वर्तमान में यह Linux kernel 4.15 या उससे ऊपर है

build options

  • NV_VERBOSE=1 चलाए जाने वाले पूरे commands को print करता है
    • default setting में केवल संक्षिप्त CC lines दिखाई जाती हैं
  • DEBUG=1 kernel modules को debug build के रूप में compile करता है
    • default build debugging information के बिना compile होता है
    • यह option kernel modules के कई debug log messages को भी सक्षम करता है

kernel module संरचना

  • अधिकतर NVIDIA kernel modules दो components में विभाजित होते हैं
    • OS-agnostic component: operating system से स्वतंत्र हिस्सा
    • kernel interface layer: Linux kernel version और configuration के लिए विशेष हिस्सा
  • NVIDIA .run install package में OS-agnostic component binary रूप में दिया जाता है
    • यह component बड़ा है और compile होने में समय लेता है, इसलिए हर driver install पर users को दोबारा compile न करना पड़े, इसके लिए prebuilt version दिया जाता है
    • nvidia.ko में इस component का नाम nv-kernel.o_binary है
    • nvidia-modeset.ko में इस component का नाम nv-modeset-kernel.o_binary है
    • nvidia-drm.ko और nvidia-uvm.ko में OS-agnostic component नहीं है
  • हर kernel module की kernel interface layer को target kernel के अनुसार build करना होता है

directory संरचना और Nouveau integration

  • मुख्य directories की भूमिकाएं इस प्रकार हैं
    • kernel-open/: kernel interface layer
    • kernel-open/nvidia/: nvidia.ko के लिए kernel interface layer
    • kernel-open/nvidia-drm/: nvidia-drm.ko के लिए kernel interface layer
    • kernel-open/nvidia-modeset/: nvidia-modeset.ko के लिए kernel interface layer
    • kernel-open/nvidia-uvm/: nvidia-uvm.ko के लिए kernel interface layer
    • src/: OS-agnostic code
    • src/nvidia/: nvidia.ko के लिए OS-agnostic code
    • src/nvidia-modeset/: nvidia-modeset.ko के लिए OS-agnostic code
    • src/common/: utility code जो nvidia.ko और nvidia-modeset.ko में से एक या अधिक में उपयोग होता है
    • nouveau/: Nouveau device driver integration tools
  • nouveau directory की Python scripts source code में encoded कुछ firmware binary images और संबंधित data को extract करके अलग files में सहेजती हैं
  • इन files का उपयोग Nouveau device driver द्वारा GSP firmware को load करने और उससे communication करने में किया जाता है
  • binary file layout का विवरण nouveau_firmware_layout.ods में दिया गया है, और यह फ़ाइल OpenDocument Spreadsheet format में है

योगदान और issue handling

  • योगदान NVIDIA की open-gpu-kernel-modules repository में pull request बनाकर किया जाता है
  • pull request submit करते समय Contributor License Agreement स्वीकार करना आवश्यक है
  • यह codebase NVIDIA proprietary driver के साथ साझा किया जाता है, और public source साझा code पर कई processing steps के बाद तैयार होता है
    • GitHub repository मुख्य रूप से हर driver release के snapshot की तरह काम करती है
    • NVIDIA shared codebase में किए गए individual changes की revision history मिलने की अपेक्षा करना कठिन है
    • हर driver release में केवल एक git commit होने की संभावना अधिक है
    • individual contributions GitHub repository में अलग git commit के रूप में शामिल न हो पाएं, ऐसा हो सकता है
    • public release से पहले होने वाली processing के कारण shared codebase में contribution लागू करने के लिए manual merge की आवश्यकता होती है
    • बड़े refactoring को merge करना और स्वीकार करना कठिन हो सकता है, इसलिए पहले से संपर्क और समन्वय आवश्यक है
  • Open GPU Kernel Modules से जुड़े issues को NVIDIA repository के Issues, NVIDIA developer forums, या linux-bugs@nvidia.com पर भेजा जा सकता है
  • यदि कोई security vulnerability मिलती है, तो अलग SECURITY.md document देखना चाहिए

compatible GPU range

  • NVIDIA open kernel modules का उपयोग Turing के बाद के GPU पर किया जा सकता है
  • feature support और limitations का विस्तृत विवरण NVIDIA GPU driver end user README के kernel_open.html document में देखने को कहा गया है
  • vGPU support के लिए vGPU Host Package में शामिल README.vgpu को देखना चाहिए
  • compatible GPU तालिका product names और PCI ID को साथ में सूचीबद्ध करती है
    • यदि तीन IDs हों, तो पहली PCI Device ID, दूसरी PCI Subsystem Vendor ID, और तीसरी PCI Subsystem Device ID होती है
    • तालिका में NVIDIA GeForce RTX 4090, NVIDIA GeForce RTX 4090 D, NVIDIA GeForce RTX 4080 SUPER, NVIDIA GeForce RTX 4070 Ti SUPER, NVIDIA H100, NVIDIA H200, NVIDIA GH200, NVIDIA L40S सहित कई products शामिल हैं

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

1 टिप्पणियां

 
GN⁺ 2024-04-13
Hacker News की राय

  • शानदार। मैं सोच रहा था कि क्या यह संभव है; अब local LLM के लिए 4x4090 मशीन को रोकने वाली चीज़ बस उसे बनाने में लगने वाला समय है
    tensor parallelization होने पर inference में यह H100 SXM से कहीं सस्ता और तेज़ लग सकता है। हालांकि अभी भी समझ नहीं आता कि tinybox ने 6 GPU वाला configuration क्यों चुना। कई workloads 4 या 8 पर ही अच्छे से चलते हैं; अभी तो ऐसा लगता है कि आप 6 का दाम देकर सिर्फ 4 इस्तेमाल कर रहे हैं, या 8 न होने वाला बीच का अजीब configuration ले रहे हैं

    • tinygrad असमान splitting को support करता है। 4 या 8 ही होने की कोई बुनियादी वजह नहीं है, और software अच्छा हो तो किसी भी GPU count पर workload लगभग पूरी तरह parallelize हो सकता है
      6 चुनने की वजह यह है कि PCIe lanes 128 हैं, यानी x16 ports 8 हैं। NVMe के लिए 1 और network के लिए 1 इस्तेमाल करें तो 6 GPU को full fabric से जोड़ा जा सकता है। 4 ही इस्तेमाल करें तो PCIe waste होता है, और 8 इस्तेमाल करें तो USB3 के कुछ ports छोड़कर external connectivity की गुंजाइश नहीं बचती
    • 6 GPU इसलिए हैं क्योंकि fast storage चाहिए, और वह PCIe lanes इस्तेमाल करता है
      लक्ष्य भी 70B FP16 model चलाना था, जिसके लिए लगभग 140GB VRAM चाहिए। 6*24GB = 144GB, इसलिए यह ठीक बैठता है
    • 6 समझदारी भरा लगता है। ThreadRipper की 128 lanes में से कुछ network और NVMe के लिए इस्तेमाल करनी ही पड़ेंगी
      उदाहरण के लिए 4 NVMe हों तो x16 lanes, और 10G network हो तो फिर x4 lanes चाहिए
    • कुछ समय पहले जारी किए गए NVIDIA SXM2 materials देखे थे, और SXM2/NVLink 2.0 भी 6-way system जैसा दिखता था
      NVIDIA SXM बाद में version 3 और 4 में update हुआ और यह configuration उसका आधार भी नहीं है, लेकिन शायद 6-way के sensible होने की कोई और वजह भी हो सकती है
    • अगर आप जिस build के बारे में सोच रहे हैं उसकी details share कर सकें तो अच्छा होगा। हमें lab server चाहिए, लेकिन options इतने ज़्यादा हैं कि समझ नहीं आ रहा

  • यह वाकई अच्छी खबर है। academia में होने के कारण, मैं कई labs को जानता हूँ जिन्होंने कई 4090 cards से मशीन बनाई और उन्हें पता ही नहीं था कि Nvidia ने cards के बीच P2P communication बंद कर रखा है
    मेरे काम के लिए 4090 काफी सस्ता पड़ता, लेकिन उसे न खरीदने की एक वजह यही थी। यह NVLink नहीं है, लेकिन Nvidia ने top-end cards को छोड़कर NVLink को लगभग हटा ही दिया है, इसलिए न होने से तो बेहतर है। पिछले साल के अंत में 4 NVLink H100 cards का quote लिया था, delivery time 13 महीने था; non-NVLink products 4 महीने में मिल सकते थे। अभी lab को चलाए रखने के लिए 4 L40S खरीदे हैं, लेकिन supply chain issues और भारी price hikes की वजह से research बहुत मुश्किल हो गई है। 6 PhD students और कई undergraduates को support करने के लिए यह बिल्कुल नाकाफी है
    2015–2018 में पिछली university में हम 2 GPU और NVLink वाली machines प्रति unit 5 हजार डॉलर में बना सकते थे और हर student की desk के नीचे एक रख सकते थे; तब सब कुछ बहुत आसान था

    • उससे पहले भी Nvidia ने server में लगाए जा सकने वाले consumer cards के blower-style design को धीरे-धीरे हटाकर हमारी जिंदगी और मुश्किल कर दी थी
      labs के लिहाज़ से, MTBF आधा भी हो तो कीमत 1/4 वाले card को वे कभी भी चुनेंगे
    • GPU cloud providers की तुलना में cost कैसी पड़ती है?

  • यहाँ P2P का मतलब क्या है? Search करने पर peer to peer जैसा लग रहा है, लेकिन graphics card के context में इसका मतलब क्या है?

    • मतलब, एक GPU की memory से दूसरे GPU में data भेजते समय system RAM से होकर जाने की जरूरत नहीं पड़ती। https://xilinx.github.io/XRT/master/html/p2p.html
    • Nvidia GPUs के बीच shared memory access की बात है
      https://developer.nvidia.com/gpudirect
    • सटीक term, और पहले ज्यादातर लोग इसे जिस नाम से बुलाते, वह bus mastering है
    • यह बेवकूफी भरा term है। यह तो RS-232 link को भी peer to peer कहने जैसा है

  • काश और hardware companies documentation खोल दें और बाकी चीजें community को पता लगाने दें
    यह शुरुआती IBM VGA में हुई चीज़ों जैसा है। "Mode X" या BIOS के बजाय hardware के असली modes, यहाँ तक कि 800x600x16 भी खोजे जा सकते हैं। अफसोस है कि ज्यादातर companies product usage के हर पहलू पर कसकर control रखना पसंद करती दिखती हैं, ताकि user base से और पैसा निकाला जा सके। निजी तौर पर मुझे लगता है कि PC का सबसे productive दौर वही था जब वह सबसे open भी था

    • तब आप same hardware के लिए अलग-अलग customers से अलग price नहीं ले पाएंगे। यह सबके फायदे की बात नहीं है
    • अगर मैं hardware manufacturer होता और product features की software locking काम न करती, तो उसकी जगह hardware locking कर देता
      तब product की कीमत बस और महंगी हो जाती
    • openness वाकई शानदार थी, लेकिन असल में अनिवार्य नहीं थी। लोग closed systems से निपटने का तरीका भी खोज सकते हैं
      adversarial interoperability आम थी, और manufacturer चाहे या न चाहे, reverse engineering से software चलाया जाता था। पहले जो rare था लेकिन अब आम हो गया है, वह software और hardware locking है। cryptography ऐसी technology होनी चाहिए थी जो हमें ताकत दे, लेकिन आखिरकार इसे हमारी अपनी machines से हमें बाहर रखने में इस्तेमाल किया जाने लगा। अब हम driver seat में नहीं हैं। operating system तक अब system को operate नहीं कर पाता। एक free Linux system भी manufacturer के अनजान proprietary firmware और silicon से बने ढेर के अंदर बस "user OS" ही है, और असली operation से sandbox किया गया छोटा-सा हिस्सा भर है
    • Nvidia का software ही उनकी moat है

  • Nvidia ने consumer lineup से NVLink हटाते समय जो मूल justification दिया था, वह यह था कि PCIe 5 काफी तेज़ होगा
    लेकिन 40xx series PCIe 5 और P2P support, दोनों के बिना launch हुई। अब उसका आधा भी मिलना अच्छा है, लेकिन कल्पना करना मुश्किल है कि अगली generation के firmware में भी वे इसे allow करेंगे

  • क्या यह consumer cards में market segmentation के लिए disable किए गए features में से एक है?

    • कुछ हद तक सही है
      पूरी तरह सही analogy नहीं है, लेकिन मान लें कि करीब 15 घरों वाली एक छोटी colony में construction चल रहा है। आम तौर पर corner पर 200kVA transformer रखा जाता है और grid से उचित बिजली supply की जाती है। लेकिन transformer की कमी के कारण contractor commercial 1250kVA transformer लगा देता है। यह जरूरत से कहीं ज्यादा घरों को power दे सकता है, इसलिए काफी capacity बची रहती है। एक दिन कोई resident बड़े पैमाने पर grow operation शुरू करना चाहता है और अपने ही घर के लिए उस extra transformer capacity को activate करने का तरीका खोज लेता है। geohot ने जो पाया, वह ठीक उसी “activation” जैसा है
    • शायद बहुत downvotes मिलेंगे, लेकिन मेरी इच्छा है कि consumer devices में ऐसी practices पर ban लगे या उन पर बहुत भारी tax लगे
    • consumer GPU में इस feature को implement और test करने का कोई incentive नहीं है। Gaming के लिए multi-GPU configurations लगभग कभी भी ढंग से अच्छी तरह नहीं चलीं

  • मैं लंबे समय से George Hotz की hacking ability से हमेशा प्रभावित रहा हूँ। मेरे personal projects के लिए भी वह बड़ी inspiration रहे हैं

    • उनका development process देखना वाकई दिलचस्प है। इतनी उदारता से उसे share करना भी उल्लेखनीय है
      वे अक्सर ऐसे सतही और मनमाने issues पर अटक जाते हैं जो ज्यादा knowledgeable engineer को कम कठिन लगेंगे। उन्हें बहुत खराब code, कभी-कभी तो गलत code लिखते हुए भी अक्सर देखा जा सकता है। Twitter से जुड़े scenes इसका अच्छा example हैं। फिर भी वे अकेले लगातार iterate करते रहते हैं और उतनी ही बार चौंकाने वाली improvements भी कर देते हैं। सीखने लायक अच्छा example है
    • उनकी streams से मुझे बहुत प्रेरणा मिली। Focus और मेहनत अच्छे results की कुंजी हैं, और उसमें clear vision और strategy जोड़ दें तो success भी हासिल की जा सकती है
      geohot और tinygrad/comma contributors, सभी को बधाई
    • उनमें long-distance flight पर मौजूद military pilot जैसी concentration है
    • उनका Xbox360 laptop मेरी teenage motivation का मुख्य हिस्सा था

  • README पर नजर डालकर, जो लोग curious हैं उनके लिए: यह NVLink नहीं, बल्कि PCIe पर P2P है

    • RTX 40 के PCB पर NVLink नहीं है, लेकिन उसी family के कुछ cards इसे support करते हैं, इसलिए silicon में यह मौजूद होगा। मेरा अनुमान है कि शायद इसे fuse से बंद कर दिया गया है
    • मेरी जानकारी में 4090 PCIe 5.0 support नहीं करता, इसलिए यह PCIe 4.0 speed तक सीमित है। फिर भी यह improvement है

  • Future architectures में वे इसे firmware में lock करना शुरू कर देंगे, इसलिए जब तक यह चलता है, अच्छा रहेगा

    • सही है, लेकिन यह वैसे भी कभी न कभी होना ही था
      इसलिए बिल्कुल न होने से बेहतर है कि कम से कम एक generation तक इसे इस्तेमाल किया जा सके

  • उत्सुकता है कि यह George ने खुद किया है या tinycorp द्वारा रखे गए bounty को पाने की कोशिश में किसी और ने किया है
    और PCI subsystem को अच्छी तरह जानने वाले किसी व्यक्ति से पूछना चाहता हूँ: क्या यह ऐसा नहीं लगता कि NVIDIA ने इसे सक्रिय रूप से रोकने की कोशिश करने के बजाय बस इस पर ध्यान नहीं दिया?

    • PCI devices हमेशा shared address space को read और write कर सकते थे। IOMMU की constraints होती हैं, लेकिन आम तौर पर इसका सबसे ज्यादा उपयोग system RAM में DMA के लिए होता था; यह उसी तक सीमित नहीं है
      इसलिए device में बदलाव करके पूरे VRAM को address space में डालने के लिए configure करना तार्किक है। resizable BAR support हो, या fixed-size BAR पर्याप्त बड़ा हो तो काम हो सकता है। साथ ही एक card को दूसरे card के VRAM में mapped address को read/write करने का निर्देश देना भी तार्किक है। जिज्ञासा है कि bottleneck PCIe switching capacity बनेगी या point-to-point link और VRAM। किसी भी तरह, system RAM के जरिए round trip कम करना मददगार होगा
    • commit geohot के नाम से है, इसलिए लगता है कि George ने खुद किया है
    • tinygrad Discord पर भी progress दर्ज की गई थी