ZLUDA, AMD GPU पर CUDA ऐप्स चलाने वाला ओपन सोर्स प्रोजेक्ट

 (cgchannel.com)
3 पॉइंट द्वारा GN⁺ 2024-03-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ZLUDA 3 एक ओपन सोर्स तकनीक है जिसका लक्ष्य CUDA पर निर्भर NVIDIA GPU एप्लिकेशनों को AMD GPU पर बिना किसी बदलाव के चलाना है
  • इसकी शुरुआत Intel GPU के लिए CUDA के विकल्प के रूप में हुई थी, लेकिन Intel और AMD दोनों द्वारा मूल्यांकन रोक दिए जाने के बाद अब AMD GPU के लिए कोड सार्वजनिक किया गया है
  • Blender में नेटिव HIP बैकएंड के समान प्रदर्शन के उदाहरण हैं, लेकिन 3DF Zephyr और RealityCapture को ZLUDA पर “much slower” बताया गया है, इसलिए ऐप के अनुसार अंतर काफी बड़ा है
  • RealityCapture और Arnold जैसे NVIDIA-विशेष CG ऐप्स के चलने की संभावना दिखी है, लेकिन OptiX support Linux पर न्यूनतम स्तर तक सीमित है, इसलिए rendering workflow में बाधाएँ हैं
  • Intel और AMD के समर्थन के बिना यह प्रोजेक्ट “realistically now abandoned” के करीब माना जा रहा है, और NVIDIA SDK लाइसेंस भी non-NVIDIA platforms के लिए translation layer के विकास को सीमित करता है

ZLUDA 3 किस CUDA निर्भरता समस्या को हल करना चाहता है

  • ZLUDA 3 एक ओपन सोर्स प्रोजेक्ट है जो NVIDIA GPU के लिए बने GPU-आधारित एप्लिकेशनों को दूसरे निर्माताओं के हार्डवेयर पर चलाने का प्रयास करता है
  • इसे इस तरह डिज़ाइन किया गया है कि मौजूदा एप्लिकेशन बिना किसी संशोधन के नए हार्डवेयर पर चल सकें, यानी ऐप डेवलपर को अलग से porting का काम न करना पड़े
  • ZLUDA को पहली बार 2020 में Intel GPU के लिए CUDA drop-in replacement implementation के रूप में पेश किया गया था, लेकिन 2021 में version 2 के बाद विकास जारी रखना कठिन हो गया
  • 2021 में जब Andrzej Janik Intel में कार्यरत थे, तब Intel ने ZLUDA को एक आधिकारिक तकनीकी उम्मीदवार के रूप में परखा, लेकिन यह निष्कर्ष निकाला कि “Intel GPU पर CUDA एप्लिकेशन चलाने का कोई व्यावसायिक मामला नहीं है”
  • Janik ने 2022 में Intel छोड़ने के बाद AMD से संपर्क किया, और AMD ने भी 2 साल तक ZLUDA का मूल्यांकन किया, लेकिन आगे नहीं बढ़ने का फैसला किया
  • इसके बाद अपडेट किया गया कोड ओपन सोर्स के रूप में जारी किया गया, और संबंधित पृष्ठभूमि Phoronix लेख में विस्तार से देखी जा सकती है

CG ऐप्स में पुष्टि हुई काम करने की सीमा

  • ZLUDA 3 का लक्ष्य NVIDIA के CUDA API से विकसित GPU ऐप्स को AMD GPU पर चलाना है
  • VFX, motion graphics और visualization के क्षेत्र में कुछ प्रमुख CG ऐप्स और renderers CUDA-आधारित होने के कारण व्यवहार में NVIDIA-विशेष बने हुए हैं
  • AMD का HIP CUDA ऐप्स को AMD हार्डवेयर पर port करने की तकनीक है, लेकिन इसमें software developer के काम की जरूरत होती है
    • HIP का उपयोग Redshift और Blender Cycles के AMD-compatible versions में किया गया है
    • ZLUDA 3 भी HIP पर आधारित है, लेकिन इसका लक्ष्य मौजूदा CUDA ऐप्स को बिना संशोधन चलाना है
  • Janik ने ZLUDA पर जिन NVIDIA-विशेष सॉफ्टवेयरों का परीक्षण किया उनमें 3DF Zephyr, RealityCapture, और Autodesk Arnold शामिल हैं
  • Arnold support अभी proof of concept स्तर पर है, और ZLUDA की OptiX implementation के साथ सफलतापूर्वक render किए गए scenes सीमित हैं

प्रदर्शन और compatibility की वास्तविक सीमाएँ

  • Janik का आकलन है कि CUDA ऐप्स AMD GPU पर “near-native performance” के साथ चल सकते हैं
  • Phoronix benchmarks और Blender Artists फ़ोरम के thread के अनुसार, Blender में ZLUDA का प्रदर्शन कुछ मामलों में नेटिव HIP backend जैसा है
  • दूसरी ओर ZLUDA GitHub repository में 3DF Zephyr और RealityCapture को ZLUDA पर much slower बताया गया है
  • कई GPU renderers ray tracing acceleration के लिए CUDA के साथ NVIDIA OptiX का भी उपयोग करते हैं
    • ZLUDA की OptiX support “minimum” स्तर की है
    • OptiX support केवल Linux पर है, Windows पर नहीं
    • implementation की स्थिति “buggy, unoptimized and incomplete” है
    • ZLUDA-OptiX redistributable version में शामिल नहीं है, इसलिए इसे खुद build करना पड़ता है
  • अन्य CUDA-आधारित CG ऐप्स चल पाएँगे या नहीं, यह बिना user testing के तय करना कठिन है
    • known issues अब भी मौजूद हैं
    • V-Ray benchmark कुछ “lucky” पुराने ZLUDA और HIP combinations में चलता है
    • OctaneBench बिल्कुल नहीं चलता

प्रोजेक्ट की निरंतरता और लाइसेंस संबंधी सीमाएँ

  • Janik का मानना है कि Intel या AMD के समर्थन के बिना ZLUDA अब “realistically now abandoned” स्थिति में है
    • वे प्रोजेक्ट को आगे बढ़ाने वाले प्रस्तावों के लिए खुले हैं
    • अन्यथा, संभव है कि वे केवल DLSS जैसी उन NVIDIA तकनीकों का support जोड़ें जिनमें उनकी व्यक्तिगत रुचि है
    • मौजूदा कोड उन software developers के लिए भी उपयोगी हो सकता है जो CUDA से HIP में क्रमिक porting कर रहे हैं
  • 14 मार्च 2024 के अपडेट के अनुसार, Tom’s Hardware ने बताया कि NVIDIA SDK लाइसेंस शर्तें CUDA Toolkit सहित SDK outputs का उपयोग non-NVIDIA platforms के लिए conversion technology विकसित करने में प्रतिबंधित करती हैं
  • ZLUDA 3 के compiled versions Windows और Linux के लिए उपलब्ध हैं, और source code Apache 2.0 या MIT license के तहत उपलब्ध है
  • ZLUDA 3 डाउनलोड प्रोजेक्ट के GitHub repository से किया जा सकता है

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

1 टिप्पणियां

 
GN⁺ 2024-03-06
Hacker News की राय

  • 22 दिन पहले भी इस पर चर्चा हुई थी: AMD ने ROCm-आधारित CUDA drop-in implementation को फंड किया था, और बाद में उसे open source के रूप में जारी किया गया—उस पोस्ट [0] पर 400 टिप्पणियाँ आई थीं
    उस थ्रेड की एक उल्लेखनीय top-level टिप्पणी में कहा गया था कि यह रिलीज़ खुद AMD द्वारा फंडिंग रोकने का नतीजा थी: “2 साल के विकास और समीक्षा के बाद AMD ने तय किया कि AMD GPU पर CUDA applications चलाने का कोई व्यावसायिक औचित्य नहीं है। AMD के साथ मेरे कॉन्ट्रैक्ट की एक शर्त यह थी कि अगर AMD को लगे कि यह आगे के विकास के लिए उपयुक्त नहीं है, तो मैं इसे सार्वजनिक कर सकता हूँ। इसलिए आज हम यहाँ हैं।” स्रोत: https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq
    [0] https://news.ycombinator.com/item?id=39344815

    • संबंधित पोस्टों को फैलाकर देखें तो यह मिलता है: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source - https://news.ycombinator.com/item?id=39344815 - फ़रवरी 2024, 410 टिप्पणियाँ
      Zluda: Run CUDA code on Intel GPUs, unmodified - https://news.ycombinator.com/item?id=36341211 - जून 2023, 90 टिप्पणियाँ
      Zluda: CUDA on Intel GPUs - https://news.ycombinator.com/item?id=26262038 - फ़रवरी 2021, 77 टिप्पणियाँ
      हाल की संबंधित पोस्टों में Nvidia bans using translation layers for CUDA software to run on other chips - https://news.ycombinator.com/item?id=39592689 - मार्च 2024, 155 टिप्पणियाँ भी शामिल है
    • “अगर AMD को लगे कि यह आगे के विकास के लिए उपयुक्त नहीं है, तो मैं इसे सार्वजनिक कर सकता हूँ” जैसी कॉन्ट्रैक्ट शर्त देखकर लगता है कि इसे आगे चलकर हर नौकरी के हर कॉन्ट्रैक्ट में होना चाहिए

  • AMD का इस प्रोजेक्ट की फंडिंग रोकना सच में बेतुका था। open source होते ही इसने AMD users के लिए value बनानी शुरू कर दी
    ऐसा लगता है कि यही AMD की सबसे ऊँची प्राथमिकता होनी चाहिए थी, लेकिन वह इसके बजाय सालों से मामूली सपोर्ट वाले दो, या अब शायद तीन, वैकल्पिक API के पीछे भटक रहा था

    • जैसे ही यह एक भरोसेमंद विकल्प बनता, Nvidia तुरंत cease-and-desist भेजकर मुकदमा कर देती। एक गंभीर समाधान के रूप में यह dead end है, इसलिए उस संदर्भ में बात समझ आती है
    • हो सकता है वे चाहते हों कि लोग HIP इस्तेमाल करें
      “HIP बहुत thin है, इसलिए सीधे CUDA mode में कोडिंग करने की तुलना में performance impact बहुत कम या बिल्कुल नहीं होता”
      “HIPIFY tool CUDA source को अपने-आप HIP में बदल देता है”
      1. https://github.com/ROCm/HIP
    • रणनीतिक नज़रिए से देखें तो यह AMD के लिए सबसे अच्छा कदम नहीं लगता। जब तक यह product-grade और कानूनी रूप से परखा हुआ न हो, यह बस डेवलपर्स को AMD पर application बनाने और deployment Nvidia पर करने देने वाला tool बन जाता
      consumer graphics card बाज़ार में यह अल्पकालिक फ़ायदा दे सकता है, लेकिन लंबी अवधि में यह data center में Nvidia की स्थिति को और मजबूत करने वाली आत्मघाती चाल के करीब है
    • काफ़ी संभावना है कि उन्हें NVIDIA की घोषणा की पहले से जानकारी थी और उन्होंने इस contractor को मुक्त कर दिया। कॉन्ट्रैक्ट की शर्तों के तहत प्रोजेक्ट open source बन ही जाता
    • यहाँ यह मान लिया गया है कि AMD ने हार मानने का फैसला किया। क्या यह भी संभव नहीं कि वे कुछ बेहतर बना रहे हों?

  • इस चर्चा से “Nvidia ने CUDA software को दूसरे chips पर चलाने के लिए translation layers के इस्तेमाल पर रोक लगा दी” वाली पोस्ट भी जुड़ी हुई लगती है [1]

    [1] https://news.ycombinator.com/item?id=39592689

    • अगर आप Nvidia hardware इस्तेमाल नहीं कर रहे, Nvidia driver इस्तेमाल नहीं कर रहे, और आपने कभी Nvidia की EULA से सहमति नहीं दी, तो फिर इसकी परवाह क्यों करनी चाहिए, समझ नहीं आता
      emulation को स्पष्ट रूप से भी और case law के तहत भी कानूनी सुरक्षा मिली हुई है। compatibility के उद्देश्य से API की नकल का मामला अमेरिका के सर्वोच्च न्यायालय तक गया था, और यह तय हुआ था कि वह copyright के दायरे में नहीं आता। कम-से-कम काफ़ी व्यापक सीमा तक तो यही माना जाता है
      मैं वकील नहीं हूँ, लेकिन समझ नहीं आता कि Nvidia किस कानूनी आधार की उम्मीद कर रही है। अगर किसी व्यक्ति या कंपनी के पास Nvidia hardware है ही नहीं, तो यह मुद्दा लगभग निरर्थक लगता है। और अगर किसी कंपनी के पास पहले से Nvidia hardware है, तो शायद Nvidia कुछ दावा कर सके, लेकिन क्या वह सीधा anti-competitive conduct के दायरे में नहीं आएगा?
    • समझ नहीं आता कि यह Wine/Proton से कैसे अलग है। Microsoft EULA में भी शायद ऐसी ही शर्तें होंगी; अगर वे लागू की जा सकतीं, तो क्या Microsoft ने Wine developers को भी ऐसा ही cease-and-desist नहीं भेजा होता?
    • यह फिर से ज़ोर देकर कहना चाहिए कि, लेख के दावे के विपरीत, वह क्लॉज़ जनवरी 2022 से CUDA EULA में मौजूद था, और लेख के अपडेट के उलट, downloads में भी शामिल था
    • क्या उससे कोई फ़र्क पड़ता है? किसी सिस्टम जैसा compatible interface रखने वाला सिस्टम लागू करने के लिए किसी की अनुमति की ज़रूरत नहीं होती
      CUDA software डाउनलोड किए बिना आपको EULA मानने की भी ज़रूरत नहीं, इसलिए ZLUDA के लेखक शायद उससे बच पाए होंगे
    • NVIDIA के पास ऐसा करने का अधिकार नहीं है। इसमें NVIDIA SDK शामिल नहीं है

  • “Intel ने भी आख़िरकार तय किया कि ‘Intel GPU पर CUDA applications चलाने का कोई व्यावसायिक औचित्य नहीं है’”, यह वाकई असहज करने वाला है

    • संक्षेप में कहें तो, हर कंपनी जब एक खास आकार और उम्र तक पहुँचती है, तो प्रतिस्पर्धी बनने का सपना देखने के बजाय monopolist बनने का सपना देखने लगती है
    • Intel का graphics division इतना खराब था कि लोगों के मन में बनी बुरी छवि की वजह से उन्हें Intel HD नाम का इस्तेमाल बंद करना पड़ा

  • AMD GPGPU को एक बार भी इस्तेमाल कर चुके लोग जिस बात को जानते हैं, वही यहाँ पक्की हुई। AMD को 2 ट्रिलियन डॉलर की कंपनी बनने से रोकने वाली एकमात्र चीज़ सचमुच बेहद भयानक software है
    मुझे याद है कि मैंने AMD के OpenCL compiler में bug ढूँढे थे [1], और segmentation fault से OpenCL compiler को क्रैश कराना भी बहुत आसान था। वह आखिर तक ठीक नहीं हुआ, इसलिए मैंने report करना ही छोड़ दिया
    AMD ने CUDA का competitor नहीं बनाया — यह मेरे देखे सबसे short-sighted फ़ैसलों में से एक है। अगर आप बेहतरीन hardware भी बना लें, लेकिन उसे इस्तेमाल करने वाला software बहुत ही नरमी से कहें तो भी घटिया हो, तो कोई उसे खरीदेगा या इस्तेमाल नहीं करेगा; यह समझने वाले लोगों से board को क्यों नहीं बदला गया, समझ नहीं आता
    हम ग्राहक इतने अमीर नहीं हैं कि AMD board ने मेज़ पर छोड़ी हुई लगभग 1 ट्रिलियन डॉलर की value की चिंता न करें, इसलिए हमें महंगे Nvidia कार्ड खरीदने पड़ते हैं। अगर आपके पास AMD के shares हैं, तो आपको सवाल पूछने चाहिए। वह board सबसे नज़दीकी नाले में बहा दिया जाना चाहिए
    [1] https://github.com/msoos/amdmiscompile -- आखिरकार यह ठीक कर दिया गया

    • क्या कोई GPGPU को ऐसे समझा सकता है जैसे JavaScript को समझा रहे हों?
      मेरी भोली समझ के मुताबिक, graphics card एक अजीब-सा computer है जिसमें आप instructions और data चढ़ा देते हैं और फिर वह खुद हिसाब-किताब कर लेता है
      मुझे समझ नहीं आता कि CUDA इतनी बड़ी बात क्यों है। AMD अपने GPU तक सीधी पहुँच ऐसे क्यों नहीं दे सकता जैसे वह 4096 Arduino boards की array हो?
    • सही है। दूसरी तरफ AMD आम तौर पर Nvidia से ज़्यादा open-source friendly है। Nvidia काफ़ी समय तक खुलकर hostile रहा है, Linus वाला “F* you!” वीडियो देख लीजिए
      hardware बनाने वाली कंपनियाँ आम तौर पर software में अच्छी नहीं होतीं। exceptions हैं, लेकिन ज़्यादा नहीं, और ऐसी कंपनियों को सच में stock price में इनाम मिला है। AMD के software division की culture मुझे नहीं पता, लेकिन आम तौर पर इसे ठीक करने के लिए काफ़ी बड़ा बदलाव चाहिए होता है
      सिर्फ board बदल देने से शायद बात नहीं बनेगी। अगर ऊपर से आने वाले executive निर्देश ही कंपनी को नीचे खींचने वाली अकेली वजह नहीं हैं, तो management की बहुत ज़्यादा layers बदलनी पड़ेंगी और middle managers का भी बड़ा हिस्सा हटाना पड़ेगा। अगर software hiring ही ठीक से नहीं हुई, तो कभी-कभी individual contributors तक बदलने पड़ते हैं
    • समझ नहीं आता कि AMD, Intel के साथ मिलकर SYCL को standard GPGPU और heterogeneous programming तरीके के रूप में push क्यों नहीं करता
      Intel software में अच्छा है, SYCL एक open standard है, इसलिए दोनों कंपनियाँ एक ही codebase से फ़ायदा उठा सकती हैं, और ग्राहक चाहें तो Threadripper पर भी SYCL code चला सकते हैं। आजकल कुछ Threadripper कुछ GPUs जितने तेज़ भी हैं
      क्या AMD अपना खुद का proprietary lock-in ecosystem बनाना चाहता है? समझ नहीं आता कि वह cross-platform open standards के लिए committed क्यों नहीं है
    • मुझे खुद AMD Software काफ़ी पसंद आया था। game या software जब by default support नहीं करते थे, तब GPU को बेवजह पूरी क्षमता पर चलने से रोकने के लिए frame rate को 60 पर limit करना आसान था, और Shadowplay की तरह पिछले कुछ मिनट लगातार रिकॉर्ड रखने वाला instant replay भी hotkey पर set किया जा सकता था
      जब मेरा UPS अच्छा नहीं था, तब GPU power limit भी लगाई जा सकती थी, और RX 580 को लगभग एक साल और चलाने के लिए auto overclock भी किया जा सकता था
      लेकिन 2020 के आसपास के बाद का software/driver VR titles को एक घंटे के अंदर ही crash करा देता है। Linux के लिए software package भी नहीं है और CoreCtrl उतना अच्छा नहीं है। instant replay भी कभी-कभी बस काम ही नहीं करता। Windows और Linux दोनों पर मैं local LLM के साथ ROCm को एक बार भी ठीक से नहीं चला पाया, और DKMS को apt upgrade के हर बार ढेर सारी बेकार compilation चलाने का शौक था
      अगला GPU लेते समय जिज्ञासा में Intel Arc लूँ या बस Nvidia पर लौट जाऊँ, यही सोच रहा हूँ। options लगभग A580, RX 6600, RTX 3050 जैसे हैं, या फिर बाकी parts की कीमतें गिरने तक इंतज़ार भी कर सकता हूँ

  • क्या कोई ऐसी programming language है जो Metal, CUDA, AMD वाली किसी चीज़ जैसे कई kernel languages में compile हो जाती हो? अगर नहीं है, तो क्यों नहीं?
    C compiler कई CPU architectures के लिए compile करते हैं। तो GPU architectures के लिए compiler भी होने चाहिए, है न? हो सकता है अभी तक किसी ने बनाया ही न हो

    • क्या इसमें OpenCL को भी गिन सकते हैं?
      https://www.khronos.org/api/opencl
    • OpenMP 5 ने GPU support को explicitly specify किया है। मैंने जल्दी से खोजा तो लगा कि कुछ compilers अब कम-से-कम आंशिक रूप से इसे support करते हैं

  • क्या किसी ने Meshroom जैसे open-source photogrammetry tools चलाने के लिए इसे आज़माया है? लेख में कुछ proprietary tools का ज़िक्र है, लेकिन मेरी ज़रूरतें काफ़ी छोटी हैं

  • यह JVM bytecode के इस्तेमाल को लेकर हुए Oracle बनाम Google मामले जैसा लगभग एक जैसा लगता है

    • मुझे ऐसा नहीं लगता। मुद्दा bytecode translation नहीं, बल्कि hardware से बँधी हुई, उससे ऊँचे स्तर की library intellectual property का है
      यह कुछ वैसा है जैसे Google कहे, “हमारे Android applications सिर्फ Google-approved phones पर ही चल सकते हैं।” मेरी समझ से Google वास्तव में Play framework या Maps जैसी चीज़ों के साथ ऐसा करता भी है

  • मैंने हाल ही में एक दिलचस्प अफ़वाह सुनी कि NVIDIA में CUDA के ज़िम्मेदार व्यक्ति ने कई साल तक resources हासिल करने और कंपनी को मनाने के लिए लड़ाई लड़ी, ताकि इस project को गंभीरता से लिया जाए
    अगर CUDA न होता, तो NVIDIA आज लगभग 1 ट्रिलियन डॉलर की कंपनी कभी नहीं बनती

  • geohot का महंगे AMD GPU के साथ लगातार जूझना भी इससे जुड़ा है: https://twitter.com/tinygrad/status/1764734675002810622