12 पॉइंट द्वारा GN⁺ 2024-07-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SCALE एक GPGPU प्रोग्रामिंग टूलकिट है जो CUDA applications को AMD GPU के लिए native compile करने में सक्षम बनाता है
  • CUDA प्रोग्राम या build system में बदलाव करने की ज़रूरत नहीं है, और अधिक GPU vendors तथा CUDA API support पर काम चल रहा है

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

  • अन्य cross-platform GPGPU solutions की तुलना में SCALE में कुछ प्रमुख innovations हैं
    • यह CUDA प्रोग्राम्स को ज्यों का त्यों स्वीकार करता है। उन्हें किसी दूसरी language में port करने की ज़रूरत नहीं होती। यह उन मामलों में भी सही है जहाँ प्रोग्राम inline PTX asm का उपयोग करते हैं
    • SCALE compiler nvcc जैसी ही command-line options और CUDA dialect को स्वीकार करता है, इसलिए यह drop-in replacement की तरह काम करता है
    • यह NVIDIA CUDA Toolkit installation का "रूप धारण" करता है ताकि मौजूदा build tools और scripts बिना बदलाव के काम करें

किन projects का परीक्षण किया गया है?

  • SCALE को validate करने के लिए open source CUDA projects को compile किया गया और tests चलाए गए
  • फिलहाल निम्न open source projects nightly automated testing में शामिल हैं और पूरी तरह pass हुए हैं
    • NVIDIA Thrust, Blender Cycles, AMGX, llama-cpp, faiss, xgboost, GOMC, stdgpu, hashcat

कौन से GPU supported हैं?

  • निम्न GPU targets supported हैं और Nightly tests में शामिल हैं
    • AMD gfx1030 (Navi 21, RDNA 2.0)
    • AMD gfx1100 (Navi 31, RDNA 3.0)
  • निम्न GPU targets का अस्थायी manual testing किया गया है और वे "काम करते हुए लगते हैं"
    • AMD gfx1010
    • AMD gfx1101
  • निम्न GPU support पर काम चल रहा है
    • AMD gfx900 (Vega 10, GCN 5.0)
  • यदि आप किसी विशेष AMD GPU architecture के लिए जल्दी support चाहते हैं, तो संपर्क करें

SCALE के components

  • AMD GPU के लिए nvcc dialect CUDA को compile कर सकने वाला nvcc-compatible compiler, जिसमें PTX asm शामिल है
  • AMD GPU के लिए CUDA runtime और driver API implementation
  • एक open source wrapper library जो ROCm libraries को delegate करके "CUDA-X" API उपलब्ध कराती है। cuBLAS और cuSOLVER जैसी libraries को इसी तरह संभाला जाता है

SCALE और अन्य solutions में अंतर

  • नया GPGPU software लिखने का तरीका देने के बजाय, SCALE व्यापक रूप से उपयोग की जाने वाली CUDA language में लिखे गए programs को AMD GPU के लिए सीधे compile करने में सक्षम बनाता है
  • SCALE का लक्ष्य NVIDIA CUDA के साथ पूरी compatibility है। इसका मानना है कि users को कई codebases बनाए बिना या performance से समझौता किए बिना कई GPU vendors को support कर पाना चाहिए
  • SCALE की language, NVIDIA CUDA का एक superset है, जो nvcc से आगे बढ़ना चाहने वाले users के लिए GPU code लिखना अधिक आसान और कुशल बनाने वाले optional language extensions देती है
  • SCALE अभी development में है। यदि कोई API missing है जो आपके उपयोग में बाधा बन रही है, तो संपर्क करें। development priorities को समायोजित किया जाएगा

GN⁺ का सार

  • SCALE एक महत्वपूर्ण टूलकिट है जो CUDA applications को AMD GPU के लिए native compile करने में सक्षम बनाता है
  • मौजूदा CUDA programs में बदलाव किए बिना उन्हें AMD GPU पर चलाया जा सकता है, जो developers के लिए बड़ा लाभ है
  • NVIDIA CUDA के साथ पूर्ण compatibility का लक्ष्य होने के कारण, यह कई GPU vendors को support करने में फायदेमंद है
  • यह एक ongoing project है, और यदि ज़रूरी API missing हों तो development team से संपर्क कर priority समायोजित कराई जा सकती है
  • समान कार्यक्षमता वाले projects में ROCm और HIP शामिल हैं

1 टिप्पणियां

 
GN⁺ 2024-07-16
Hacker News की राय
  • कई लोगों का मानना है कि AMD को translation layer सपोर्ट करनी चाहिए, लेकिन एक राय यह है कि यह बुरा विचार है

    • CUDA को vendor-neutral तरीके से डिज़ाइन नहीं किया गया है, और Nvidia तकनीकी व कानूनी रूप से मुश्किलें पैदा कर सकता है
    • उदाहरण के लिए, इसके ऊपर cuDNN या cuBLAS चलाना license agreement का उल्लंघन हो सकता है
    • ये Nvidia libraries उस API boundary का हिस्सा बन जाएँगी जिन्हें AMD को फिर से implement और support करना होगा
  • एक राय यह है कि bug compatibility का पीछा करना मूर्खता है

    • महत्वपूर्ण CUDA users open source हैं
    • AMD, pytorch या llama.cpp जैसे upstream projects में सीधे support implement कर सकता है
    • support होने पर community उसका maintenance कर सकती है
  • एक राय यह है कि यह समझना मुश्किल है कि hardware पर बहुत निर्भर code AMD पर "बस चल" कैसे सकता है

    • ज़्यादातर गंभीर CUDA code को register file, shared memory size, wgmma instruction, optimal tensor core memory और register layout, tensor memory accelerator instructions आदि की जानकारी होती है
  • अगर यह सच है तो प्रभावशाली है, लेकिन एक राय यह है कि यह open source नहीं है और यह कैसे काम करता है इस पर सटीक जानकारी भी कम है

    • समझ नहीं आता कि आजकल यह उम्मीद क्यों की जाती है कि कोई project open source हो या कम से कम source-available हो
  • एक राय यह है कि Nvidia के ऊँचे valuation का मुख्य कारण यह है कि AMD ने GPU को ML के लिए उपयोगी बनाने में निवेश नहीं किया

    • हो सकता है AMD anti-trust कार्रवाई से डरता हो, या उसके hardware approach में कुछ ऐसा हो जो प्रतिस्पर्धात्मकता को सीमित करता हो
    • लगता है कंपनी ने crypto mining GPU demand surge और मौजूदा AI boom demand surge, दोनों के दौरान अरबों डॉलर का मौका गंवा दिया
  • एक राय यह है कि AMD ने इतनी गलतियाँ की हैं कि ऐसे project की सराहना करने का मन होता है

    • खासकर Linux में यह बहुत निराशाजनक है कि laptop की capabilities hardware में मौजूद हैं, लेकिन उनका इस्तेमाल नहीं किया जा सकता
  • मैंने कुछ साल पहले Spectral Compute में काम किया था

    • वहाँ की technical team बहुत ही होशियार और सक्षम थी
    • उस समय वे सिर्फ AMD को target नहीं कर रहे थे, बल्कि base LLVM ptx backend और NVCC से भी बेहतर प्रदर्शन कर रहे थे
  • मैंने थोड़ा CUDA लिखा है

    • जिज्ञासा है कि AMD cards के लिए code लिखने का बुनियादी setup क्या है
  • एक राय यह है कि यह project शानदार है

    • उम्मीद है कि AMD, Nvidia के साथ सीधे प्रतिस्पर्धा करेगा
  • अभी की limitations के लिए एक page होना अच्छा है, लेकिन एक राय यह है कि ज़्यादातर लोग जिस चीज़ को "CUDA" कहते हैं, वह असली CUDA functionality का सिर्फ छोटा हिस्सा है

    • warp shuffle, atomic operations, DPX, TMA, MMA जैसी advanced features की comparison table हो तो अच्छा होगा
    • आदर्श रूप से, PTX instructions को RDNA के समकक्ष instructions या उन्हें emulate करने वाली instruction list से map करने वाली table होनी चाहिए
  • एक राय यह है कि तकनीकी रूप से संभव होने के कारण यह वास्तविक हो सकता है

    • inline PTX को parse करके AMDGPU पर map करना बहुत बड़ी परेशानी होगी
    • ऐसे CUDA source पर AMDGPU target करना जो inline PTX इस्तेमाल नहीं करता, HIP से replace करने जैसा है
    • कुछ details संदिग्ध हो सकती हैं, जैसे atomic model का मेल न खाना या Volta का अलग instruction pointer model होना
    • फिर भी इसे सही तरीके से किया जा सकता है
    • AMD यह नहीं करेगा
    • CUDA आम तौर पर कोई बहुत अच्छी चीज़ नहीं है, और legal team समस्या खड़ी करेगी
    • लेकिन दूसरे लोग इसे पर्याप्त रूप से कर सकते हैं