CUDA को चुनौती देता ROCm: ‘एक-एक कदम आगे बढ़ना’

 (eetimes.com)
2 पॉइंट द्वारा GN⁺ 2026-04-15 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • AMD, Nvidia CUDA ecosystem का मुकाबला करने के लिए AI software stack ROCm को केंद्र में रखकर अपनी datacenter GPU रणनीति को मजबूत कर रहा है
  • ROCm शुरुआती साधारण firmware bundle से विकसित होकर एक पूर्ण software platform बन चुका है, और 6-सप्ताह release cycle अपनाकर स्थिर usability सुनिश्चित कर रहा है
  • OneROCm के जरिए CPU, GPU, FPGA के बीच AI stack integration और portability को आगे बढ़ाया जा रहा है, और Triton·MLIR आधारित code reuse से development efficiency बढ़ाई जा रही है
  • ROCm में firmware को छोड़कर सभी components को open source किया गया है, ताकि community innovation की गति का लाभ लिया जा सके, और Strix Halo laptop और Windows version में भी यह default support के साथ आता है
  • AMD developer feedback पर प्रतिक्रिया और community trust की बहाली को महत्व देता है, और ROCm को आने वाले 10 वर्षों तक टिकाऊ, developer-centric platform के रूप में विकसित करने का लक्ष्य रखता है

AMD ROCm का विकास और CUDA से प्रतिस्पर्धा की रणनीति

  • AMD, datacenter GPU market में Nvidia के CUDA ecosystem का मुकाबला करने के लिए AI software stack ROCm को अपनी प्रमुख रणनीति के रूप में आगे बढ़ा रहा है
  • AI software division के vice president Anush Elangovan ने ROCm के विकास को “पहाड़ पर चढ़ने की तरह एक-एक कदम आगे बढ़ने की प्रक्रिया” बताया, और लगातार सुधार व integration पर जोर दिया
  • वे startup Nod.ai के acquisition के जरिए AMD में शामिल हुए, और Nod टीम ने Shark, Torch.MLIR, IREE जैसे प्रमुख open source projects में योगदान दिया है
  • AMD, ROCm के जरिए CPU, GPU, FPGA के बीच AI stack integration (OneROCm) को आगे बढ़ा रहा है, और software development cycle को 6 सप्ताह तक घटाकर “ऐसे स्तर” पर ले जाना चाहता है जहाँ “यूज़र को version के बारे में सोचना न पड़े”
  • ROCm अभी AI-supported engineering transition की तैयारी में है, और open source ecosystem व developer community केंद्रित विस्तार को तेज कर रहा है

ROCm की प्रगति और software रणनीति

  • ROCm शुरुआती दौर में कई firmware टुकड़ों के bundle जैसा था, लेकिन ढाई साल के निवेश के बाद यह एक पूर्ण software platform में विकसित हो गया
    • Elangovan ने Google Chrome टीम की development culture को benchmark बनाकर नियमित release cycle और स्थिर user experience को लक्ष्य बनाया
    • ROCm अब ऐसे software के रूप में स्थापित हो चुका है जो “बस काम करता है”, और आगे 6-सप्ताह release system में बदलने वाला है
  • AMD hardware-centric company से software-centric company में बदल रही है, और अगले चरण में AI-assisted engineering को प्रमुख turning point मान रही है

AI stack integration और portability

  • AMD, OneROCm के जरिए CPU, GPU, FPGA जैसे विभिन्न hardware के बीच AI stack integration को साकार कर रहा है
    • कुछ components अभी भी hardware-dependent हैं, लेकिन सभी acceleration ROCm stack के जरिए होने से portability सुनिश्चित होती है
  • Triton framework के प्रसार से GPUs के बीच compatibility issues कम हुए हैं
    • पहले CUDA kernel को HIP kernel में बदला जाता था, लेकिन अब Triton kernel लिखकर उसे AMD और Nvidia दोनों पर चलाया जा सकता है
    • AMD, Triton और MLIR compiler infrastructure में सक्रिय निवेश कर रहा है, और Torch.MLIR maintenance के जरिए विभिन्न hardware targets पर code retargeting को support करता है
  • अधिकांश inference customers vLLM, SGLang जैसे LLM frameworks का उपयोग करते हैं, इसलिए CUDA code conversion की मांग कम हुई है
    • जब नए attention algorithms आते हैं, तो Triton-based kernels को एक-दो दिन में optimize किया जा सकता है
    • HIPify अभी भी HPC customers के लिए उपलब्ध है, और नए kernels लिखने में Claude AI का उपयोग verification और code generation के लिए किया जाता है

open source रणनीति

  • ROCm में firmware को छोड़कर सभी components 100% open source के रूप में उपलब्ध हैं
    • open source होने से developer community द्वारा verification मिलता है, साथ ही AMD से भी तेज community innovation की गति का लाभ उठाया जा सकता है
    • कोई भी compiler, runtime या किसी भी इच्छित स्तर पर योगदान दे सकता है, और AMD की collaboration speed तक सीमित नहीं रहता
  • AMD developer community expansion को सक्रिय रूप से आगे बढ़ा रहा है, और Strix Halo वाले laptops में ROCm default support के साथ आता है
    • Instinct datacenter hardware के उसी दिन Windows version ROCm update भी जारी किया जाता है

developer community और feedback संस्कृति

  • Elangovan developers के साथ सीधे संवाद को महत्व देते हैं, और X(Twitter) के जरिए real-time feedback इकट्ठा करते हैं
    • वे “ROCm”, “ROCm sucks”, “AMD software not working” जैसे keywords को monitor करते हैं, और हर post का सीधे जवाब देते हैं
    • अधिकांश समस्याएँ शिक्षा और support की कमी से आती हैं, और वे anonymous developers को भी सीधे सलाह देते हैं
  • AMD ने GitHub पर ROCm से जुड़ी 1,000 से अधिक शिकायतों की जांच की, और एक साल के भीतर सभी को हल कर दिया
    • पुराने hardware support की मांग काफी थी, और अब उसका maintenance AMD या community द्वारा किया जा रहा है
    • इस तरह की प्रतिक्रिया से developers का भरोसा लौटा, और “AMD समस्याएँ हल करता है” जैसी धारणा फैलने लगी
  • Elangovan ने MI450 GPU (2026 की दूसरी छमाही में अपेक्षित रिलीज़) को लेकर उम्मीद जताई, और जोर दिया कि ROCm को आने वाले 10 वर्षों के लिए टिकाऊ platform बनाया जाएगा
    • लक्ष्य यह है कि नया hardware आने पर भी developers को चिंता न करनी पड़े, ऐसा स्थिर ecosystem बनाया जाए

भविष्य की दिशा और दर्शन

  • Elangovan ने Nod.ai के दौर के अनुभव के आधार पर कहा कि compiler technology को लगभग सभी accelerator कंपनियों ने अपनाया है
    • उनका कहना है, “आत्मविश्वास के साथ एक-एक कदम आगे बढ़ना चाहिए”, और वे ROCm की प्रगति को लगातार execution का परिणाम मानते हैं
  • AMD, CUDA की केवल नकल करने से आगे बढ़कर, ROCm की अलग पहचान वाली क्षमताएँ विकसित कर रहा है, और लंबे समय में इसे developer-centric platform के रूप में स्थापित करना चाहता है

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

2 टिप्पणियां

 
picopress 2026-04-18

ड्राइवर से ही थोड़ा...
 
GN⁺ 2026-04-15
Hacker News की राय

  • पिछले हफ़्ते TheRock को stagex पर पोर्ट करते हुए ROCm को musl/mimalloc-आधारित toolchain से build करने की कोशिश की
    क्योंकि security·privacy-संवेदनशील workloads में सिर्फ़ एक compiler से बने binaries पर भरोसा नहीं किया जा सकता
    30 से ज़्यादा dependencies और custom LLVM को package करने में बुरे सपने जैसा समय लगा, लेकिन आज सुबह आख़िरकार runtime build करने में सफलता मिली
    AMD hardware का पूरी तरह open environment में चलना उच्च-सुरक्षा workloads के लिए उम्मीद देता है

    • मैंने भी ROCm को musl पर package करने की कोशिश की थी, ख़ासकर Alpine Linux के लिए
      custom LLVM fork और कई packages को पार कर लिया था, लेकिन आख़िर में इसे समय की बर्बादी मानकर छोड़ दिया
      अभी Vulkan support वाला llama.cpp इस्तेमाल कर रहा हूँ, और उससे काफ़ी संतुष्ट हूँ
      अगर build recipe साझा कर सकें, तो शायद Alpine porting के आख़िरी चरण को पार करने में मदद मिले
    • ऐसी स्थिति बार-बार देखना दुखद है
      पिछले साल AMD के वादों पर भरोसा करके shareholder campaign रोक दी थी, लेकिन अब सच में कार्रवाई की ज़रूरत महसूस होती है
      unlockgpu.com/action-plan
    • issue #3477 को देखकर दिल टूटता है
      यह ऐसे नहीं होना चाहिए, यह काम साफ़ तौर पर उपयोग योग्य होना चाहिए
    • क्या Nvidia पर भरोसा न करने की वजह closed-source driver है?
      Nvidia ने भी open-source drivers को बेहतर करने का वादा किया है
      व्यक्तिगत रूप से मुझे Intel का 32GB VRAM लगभग 1000 डॉलर में देना ज़्यादा आकर्षक लगता है
    • “सिर्फ़ एक compiler से बने binaries पर भरोसा नहीं किया जा सकता” वाली बात दिलचस्प है
      क्या इसका मतलब अलग-अलग compilers से बने .o files को मिलाकर link करना है?
      क्या यह सच में Reflections on Trusting Trust समस्या से बचने की कोशिश करने वाला workload है, यह जानने की जिज्ञासा है

  • फ़रवरी से AMD से gfx1201 के लिए tuned Tensile kernels को rcom-libs में शामिल करने का अनुरोध कर रहा हूँ, लेकिन किसी को नहीं पता कि ज़िम्मेदार कौन है
    developer Discord पर भी कोई जवाब नहीं मिला, इसलिए निराशा होती है। तकनीकी समस्या से आगे बढ़कर यह AMD की संगठनात्मक bottleneck का उदाहरण लगता है

    • क्या आपने GitHub पर issue उठाया है?
      zichguan-amd या harkgill-amd शायद संबंधित लोग हों

  • ROCm के मामले में AMD को अभी भी कई वर्षों का फ़ासला पाटना है
    AI compute करने में सक्षम अपनी सभी GPUs को भी यह support नहीं करता, और जहाँ support है वहाँ भी bugs बहुत हैं
    Linux के लिए AMDGPU driver 6.6 के बाद से लगातार unstable है

    • talent न मिल पाने की वजह सीधी है। दुनिया की सबसे बड़ी कंपनियों के साथ talent competition करनी पड़ती है, और AMD सिर्फ़ 10 साल पहले तक कंपनी के अस्तित्व के संकट में थी
    • आख़िरकार क्या बात सिर्फ़ काफ़ी salary न देने की नहीं है
    • ROCm को बहुत लंबे समय तक यूँ ही छोड़ दिया गया। 5 साल पहले मेरे दोस्तों ने अंदर से investment बढ़ाने के लिए समझाने की कोशिश की थी, लेकिन असफल रहे
      AI के महत्वपूर्ण होने को न देख पाना साफ़ ग़लती थी
      अगर AMD competitive बने, तो पूरे industry के लिए अच्छा होगा, लेकिन यह स्थिति उसने ख़ुद बनाई है
    • यह सांस्कृतिक समस्या भी हो सकती है
      पुराने ATI दौर से ही buggy drivers के लिए बदनामी थी, और AMD के अधिग्रहण के बाद भी वह संस्कृति बदली नहीं लगती

  • पिछले साल AMD ने GitHub पर ROCm से जुड़ी शिकायतें इकट्ठा कीं और कहा कि सभी 1000 मामले हल कर दिए गए
    लेकिन हक़ीक़त में पुराने hardware का support लगभग बढ़ा ही नहीं

    • अगर कई wikis खंगालकर manually card support hack करना पड़े, तो क्या उसे “support जोड़ा गया” कहना सही होगा, इस पर संदेह है

  • जिस दिन ROCm सभी AMD cards पर launch के साथ ही support देगा, तभी शायद उसके प्रचार पर भरोसा कर पाऊँगा
    पहले 400 series जैसी नई cards को छोड़ देना बड़ी ग़लती थी
    उम्मीद है management software stack में ज़्यादा निवेश करे

    • CUDA भी परफ़ेक्ट नहीं है। उदाहरण के लिए GB10 आए काफ़ी समय हो गया, लेकिन अब भी उसमें कई unimplemented features हैं

  • ROCm आम consumer GPUs, जैसे RX 580, पर support नहीं करता
    उसकी जगह Vulkan backend अच्छी तरह काम करता है

    • मैंने 2018 में RX 580 खरीदा था, और RDNA1·RDNA2 GPU support की कमी अफ़सोसजनक है
      मुझे लगता है GCN architecture का अब support खत्म होना स्वाभाविक है, लेकिन RDNA पीढ़ी में भी support की कमी समस्या बनी हुई है
    • ROCm आम तौर पर सिर्फ़ दो पीढ़ियों की GPUs support करता है
      अभी RDNA3·RDNA4 ही संभव हैं, जबकि CUDA अब भी Turing तक support करता है
      आधिकारिक दस्तावेज़ देखें
    • मैं RX 5700 इस्तेमाल करता हूँ, लेकिन supported ROCm version इतना पुराना है कि Ollama नहीं चला सकता
      Vulkan backend ठीक चलता है, लेकिन official support आने में 1–2 साल लग गए
    • Vulkan अच्छी तरह काम करता है, लेकिन C++·Fortran·Python JIT kernels, IDE integration, debugging और libraries का support कमज़ोर है
    • मुझे याद है कि पहले RX580 पर ROCm इस्तेमाल किया था, तो क्या अब उसका support खत्म हो गया है?

  • काश ROCm stack की clean-up हो जाए
    बस git clone --recurse-submodules rocm के बाद configure/make से build हो सके, और missing dependencies साफ़-साफ़ दिखा दे
    अभी हाल यह है कि बिना किसी ढाँचे के कई components बस इकट्ठा कर दिए गए हैं, इसलिए सुसंगत architecture दिखता ही नहीं

  • मैं OpenVINO और SYCL के साथ CUDA को चुनौती देने वाली टीम में हूँ
    Intel के iGPU·dGPU हाल में क़ीमत के लिहाज़ से भी ठीक हैं और software support भी बेहतर हुआ है
    gaming नहीं बल्कि CV या data science workloads में ये काफ़ी अच्छी तरह scale करते हैं

  • AMD management को ROCm पर देना चाहूँगा यह feedback
    (1) सिर्फ़ server-grade GPUs support करना और consumer GPUs/APUs को नज़रअंदाज़ करना रणनीतिक ग़लती थी
    ज़्यादातर developers पहले अपने निजी laptop पर प्रयोग करते हैं और बाद में server तक scale करते हैं
    CUDA की तरह, performance कम हो तब भी consumer GPUs पर चलना चाहिए
    (2) सिर्फ़ दो पीढ़ियों को support करने की नीति ग्राहक के नज़रिए से अतार्किक है
    आधिकारिक दस्तावेज़ देखें
    CUDA मज़बूत backward compatibility बनाए रखता है
    (3) सिर्फ़ Triton पर ध्यान देना और HIP को second-class मानना ग़लत दिशा है
    अब भी C/C++-आधारित HPC·simulation·scientific code बहुत हैं
    AMD GPU की FP64 performance उसकी ताक़त है, और इस तरह वह ख़ुद ही उसे छोड़ रहा है
    (4) आख़िर में packaging quality बेहतर करनी चाहिए
    distro packagers के साथ सहयोग करना कोई बहुत महँगा काम नहीं है, और यह Nvidia पर competitive advantage दे सकता है

    • CUDA की ताक़त polyglot support है
      Python, Julia जैसी कई languages में kernels सीधे लिखे जा सकते हैं, और IDE·debugger·library integration भी शानदार है
      पूरे GPGPU ecosystem को देखें तो AMD और Intel अभी भी CUDA की ecosystem completeness तक नहीं पहुँचे हैं
    • packaging असल में आसान काम नहीं है
      ज़्यादातर कंपनियाँ /opt/foo/ जैसे vendor install model को चुनती हैं
      इससे बाद में distros के लिए अपना packaging करना आसान हो जाता है
      लेकिन इसे समझने के लिए open-source ecosystem का अनुभव रखने वाले लोगों की ज़रूरत होती है
    • NVIDIA भी ऐसी ही ग़लती कर रहा है
      वह high-VRAM consumer GPUs के launch को टालते हुए server market पर ध्यान दे रहा है
      अगर AMD इस मौके का सही इस्तेमाल करे, तो यह अवसर बन सकता है
    • सच तो यह है कि ROCm official support न होने पर भी अनौपचारिक रूप से काम करता है
      उदाहरण के लिए 7900 XT पर यह अच्छी तरह चलता है
      बस AMD testing resources नहीं लगाता, इसलिए उसे “official support” के रूप में नहीं लिखता

  • पहले compute shaders के साथ काम करने के अनुभव से कहूँ तो CUDA, ROCm, OpenCV सभी की installation बहुत झंझटभरी है
    dependencies भी भारी हैं, और CUDA तो 11GB का है
    मुझे लगता है सीधे Vulkan इस्तेमाल करना बेहतर है। platform lock-in भी नहीं है और “बस काम करता है”

    • Vulkan install करना आसान है, लेकिन code जटिल है
      सिर्फ़ shader compilation और resource setup में ही सैकड़ों lines लगती हैं, और GPU addresses संभालने के लिए extensions चाहिए
    • Windows पर 3GB का exe install, Linux पर repository जोड़कर install करना काफ़ी है
      समझ नहीं आता कि इसमें घंटों क्यों लगें
    • Vulkan एक low-level API है, इसलिए साधारण काम में भी 200 से ज़्यादा lines लगती हैं
      पहले NVIDIA में graphics mode पर स्विच करने से performance 20% बढ़ जाने वाला bug(?) भी था