Rust को हर GPU पर चलाने में सफलता

 (rust-gpu.github.io)
10 पॉइंट द्वारा GN⁺ 2025-07-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Rust में लिखा गया एक ही कोडबेस CUDA, Vulkan(SPIR-V), Metal, DirectX 12, WebGPU, CPU समेत सभी प्रमुख GPU और CPU प्लेटफ़ॉर्म पर चलाने वाला डेमो प्रोजेक्ट सार्वजनिक किया गया
  • पारंपरिक GPU प्रोग्रामिंग में GLSL, HLSL जैसी अलग भाषाओं के उपयोग से जटिलता और डुप्लिकेशन की समस्या होती है, लेकिन यह डेमो सिर्फ शुद्ध Rust कोड से सभी GPU targets को सपोर्ट करता है
  • मुख्य इम्प्लीमेंटेशन के रूप में Rust GPU(SPIR-V), Rust CUDA(NVVM IR), Naga(GPU भाषा रूपांतरण लेयर) प्रोजेक्ट्स को एकीकृत किया गया- वही bitonic sort algorithm CPU और सभी GPU पर चलता है, और Rust की no_std, conditional compilation, Newtype, Enum, Trait जैसी language features GPU कोड पर भी वैसे ही लागू होती हैं
  • अभी भी official rustc integration, debugging, API consistency जैसी सुधार की चुनौतियाँ बाकी हैं, लेकिन यह GPU cross-platform computing के लिए एक turning point बनने की कोशिश है

Rust-आधारित GPU cross-platform computing का साकार होना

प्रोजेक्ट परिचय और महत्व

  • एक ही Rust कोडबेस से CUDA(NVIDIA), Vulkan(SPIR-V), Metal(Apple), DirectX 12(Windows), WebGPU(ब्राउज़र), CPU आदि पर एक जैसा kernel code चलाया जा सकता है
  • shader या kernel-विशेष भाषाओं(GLSL, HLSL आदि) के बिना, सिर्फ शुद्ध Rust कोड से GPU और CPU पर एक जैसे operations चलाए जा सकते हैं
  • इससे GPU·CPU के बीच code duplication और complexity काफी घटती है, और Rust ecosystem के tools व language benefits जैसे type safety, testing, documentation, build management आदि GPU programming में भी लागू होते हैं

पृष्ठभूमि

  • पारंपरिक GPU programming में हर platform के लिए विशेष shader languages (जैसे: GLSL, HLSL, MSL, WGSL आदि) का उपयोग अनिवार्य रहा है
  • इसके कारण CPU और GPU कोड अलग हो जाते हैं, और logic duplication व development complexity बढ़ती है
  • Rust community इसके जवाब में सामान्य Rust को GPU target के लिए compile करने वाला दृष्टिकोण आगे बढ़ा रही है
    • Rust GPU: Rust कोड को SPIR-V में compile करता है, और Vulkan तथा SPIR-V compatible GPU पर चलता है
    • Rust CUDA: Rust कोड को NVIDIA CUDA के लिए IR(NVVM IR, PTX) में compile करता है, और CUDA पर चलाता है
    • Naga: अलग-अलग GPU भाषाओं(WGSL, SPIR-V, GLSL, MSL, HLSL) के बीच रूपांतरण करने वाली intermediate layer है (मुख्यतः wgpu project में उपयोग). backend portability की जिम्मेदारी संभालती है
  • ये प्रोजेक्ट अलग-अलग शुरू हुए थे और इनके API व structure अलग थे, लेकिन हाल की साझेदारी से एक साझा कोडबेस को GPU पर चलाना संभव हुआ है

इम्प्लीमेंटेशन का तरीका

  • उदाहरण डेमो में bitonic sort algorithm को एकल Rust कोड में लागू किया गया है, और GPU व CPU के सभी targets पर वही कोड चलता है
  • मुख्य कंपोनेंट शब्दावली
    • Host: CPU पर चलने वाला Rust कोड (काम शुरू करता है)
    • Device: GPU/CPU जहाँ kernel वास्तव में चलता है
    • Driver API: CUDA, Vulkan, Metal, DX12 आदि, डिवाइस से संचार के लिए low-level API
    • Backend: Rust में driver API के लिए abstraction देने वाली परत (cust, ash, wgpu आदि)
  • Rust के feature flags और target combinations के जरिए backend selection और build control संभव है
    • उदाहरण: wgpu, ash, cuda आदि हर backend के लिए अलग build options उपलब्ध
    • कई backends को एक ही binary में build करके runtime पर dynamically चुनने वाली संरचना भी बनाई जा सकती है

kernel compile flow

  • target और feature के अनुसार GPU execution binaries (SPIR-V, PTX आदि) build के समय तैयार होती हैं और object files में embed की जाती हैं
  • runtime में embedded kernels को load किया जाता है, फिर Naga आदि के जरिए platform-specific format में बदलकर चलाया जाता है
  • उदाहरण:
    • macOS: SPIR-V को MSL में बदलकर → Metal पर चलाना
    • Windows: SPIR-V को HLSL में बदलकर → DX12 पर चलाना
    • Linux/Android: SPIR-V → Vulkan पर चलाना
    • CUDA: PTX को SASS में compile करके GPU पर upload और execute करना

Rust-अनुकूल GPU coding techniques

  • no_std समर्थन

    • GPU पर OS support नहीं होता, इसलिए Rust का no_std इस्तेमाल आवश्यक है
    • Rust ecosystem मूल रूप से embedded, firmware, kernel जैसे OS-विहीन environments को ध्यान में रखता है, इसलिए GPU को भी किसी अलग "special mode" के बिना Rust के मानक तरीके से सपोर्ट किया जा सकता है

  • conditional compilation

    • cfg attributes और feature flags के संयोजन से platform-specific और GPU/CPU-specific कोड को साफ़ और संक्षिप्त रूप से लिखा जा सकता है
    • IDE और compiler सभी code paths को समझते हैं, जिससे code reliability और productivity बढ़ती है

  • newtype का उपयोग

    • GPU पर गलती होने वाले implicit index और struct mapping को newtype के जरिए type level पर सुरक्षित बनाया जा सकता है
    • #[repr(transparent)] attribute से बिना वास्तविक overhead के type abstraction संभव है

  • Enum और सुरक्षित representation

    • magic number की जगह Rust Enum का उपयोग, #[repr(u32)] के साथ native integer mapping सुनिश्चित करता है
    • pattern matching और exhaustiveness (हर स्थिति की शाखा संभालना) से सुरक्षित कोड बनता है
    • लेकिन CPU-GPU shared buffer में Enum values भेजते समय यह ध्यान रखना होगा कि सभी values वैध Enum हों

  • Trait-आधारित generic algorithms

    • Trait के जरिए अलग-अलग value types के लिए comparison, conversion, operations जैसी GPU computations का common abstraction दिया जा सकता है
    • generic algorithms में trait bounds को स्पष्ट रखकर type safety और optimality दोनों हासिल किए जा सकते हैं

  • #[inline] और performance optimization

    • #[inline] का उपयोग abstraction layers को actual compile result में गायब करने की दिशा में मदद करता है
    • GPU की प्रकृति (performance, stack की कमी आदि) को देखते हुए abstraction का cost न रहे, ऐसा डिज़ाइन किया गया है

  • Struct composition और semantic grouping

    • जटिल GPU parameters को अर्थपूर्ण इकाइयों में बाँधकर struct के रूप में प्रबंधित किया जा सकता है, जिससे type safety मिलती है और parameter explosion रोका जा सकता है
    • smart constructor pattern से invalid states को compile चरण में ही रोका जा सकता है

  • memory layout और #[repr(C)] नियंत्रण

    • GPU के साथ data compatibility के लिए #[repr(C)] से struct layout को स्पष्ट रूप से निर्धारित किया जाता है
    • भविष्य में GPU-विशिष्ट padding automation जैसी अतिरिक्त language support की आवश्यकता का भी उल्लेख है

  • pattern matching

    • switch/case के विस्तारित रूप के तौर पर, GPU code में सभी branches और states को स्पष्ट रूप से संभाला जा सकता है
    • compiler द्वारा code paths की जाँच और performance optimization संभव है

  • generic functions

    • data type पर निर्भर हुए बिना कई types के लिए समान logic लागू किया जा सकता है
    • trait bounds, monomorphization आदि से maintainability और testing में सुविधा मिलती है

  • derive macros

    • Copy, Clone, Debug, PartialEq, Pod जैसे GPU-उपयुक्त traits का automatic implementation
    • safety बढ़ती है और boilerplate code कम होता है

  • module system, workspace management

    • Rust के package/module system से host code, kernel, types और backend-विशिष्ट sources को व्यवस्थित किया जा सकता है
    • Cargo workspace और workspace dependency के जरिए crates के बीच dependency consistency और maintenance की सुविधा मिलती है

  • formatting, linting, documentation

    • rustfmt, clippy जैसे Rust standard tools के साथ GPU code को भी बिल्कुल उसी तरीके से प्रबंधित किया जा सकता है, जिससे consistent quality बनी रहती है
    • doc comments और cargo doc से GPU code का documentation भी किया जा सकता है

  • build scripts

    • Cargo के build.rs के जरिए feature flag-आधारित kernel build और binary embedding को automate किया जा सकता है

  • unit tests और development productivity

    • GPU kernel code को CPU पर भी test किया जा सकता है, जिससे development और bug detection आसान होता है
    • println debug, gdb/lldb जैसे पारंपरिक tools का उपयोग संभव है
    • Vulkan kernels को software drivers (SwiftShader, lavapipe) के साथ CI में भी test किया जा सकता है
    • testing, code coverage measurement, property-based testing जैसे third-party tools के साथ भी सहज integration संभव है

अधूरा developer experience और चुनौतियाँ

  • GPU backends अभी official Rust compiler में built-in नहीं हैं, इसलिए अलग codegen backends (spirv, nvvm) और pinned nightly versions की ज़रूरत पड़ती है
  • CUDA target NVIDIA के LLVM 7.1 पर निर्भर है, इसलिए नए Linux distributions पर अलग build की आवश्यकता पड़ती है
  • kernel build और debugging का अनुभव अभी अपर्याप्त है, और error tracing/debug information भी सीमित है
  • Rust GPU और Rust CUDA के API तथा standard library naming में अंतर होने से भ्रम पैदा होता है
  • लंबी अवधि में Rust language और ecosystem में GPU-केंद्रित consistency और integration को और मजबूत करने की जरूरत है

community participation और भविष्य

  • Rust के जरिए सभी प्रमुख GPU platforms पर एक ही code चलाना अब संभव हो गया है
  • आगे build और debugging सुधार, Rust language व API support का विस्तार, और performance tuning जैसी चुनौतियाँ बाकी हैं
  • भाग लेना या योगदान करना चाहने वाले developers rust-gpu और rust-cuda के GitHub repositories देखें

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

1 टिप्पणियां

 
GN⁺ 2025-07-27
Hacker News टिप्पणियाँ

  • यह तकनीक संभव है, यही बात सच में बहुत प्रभावशाली है
    लेकिन मेरा use case मनमाने client hardware पर चलाने का है, इसलिए मैं GPU API के ऊपर बनी सभी abstraction layers पर भरोसा नहीं करता
    मकसद GPU के low-level details का अधिकतम उपयोग करना है, और ऐसे details को झंझट मानने वाला दृष्टिकोण bugs और performance गिरावट की ओर ले जाता है
    क्योंकि हर target अर्थपूर्ण तरीके से अलग होता है
    इसे पार करने के लिए ऐसा ही कोई सिस्टम vendors को खुद उपलब्ध कराना चाहिए
    लेकिन vendors के बीच अब भी सहमति नहीं है, इसलिए platform-specific अंतर बड़े लगते हैं
    कुछ मामलों में Angle जैसे अपवाद हैं, लेकिन ऐसे मामलों में भी stability सिर्फ feature restrictions के ज़रिए मिलती है और नतीजे में performance loss होता है
    फिर भी conditional compilation जैसी approach संभव होना निश्चित रूप से मददगार है

    • Rust एक systems language है, इसलिए आप जितना चाहें उतना control पा सकते हैं
      हम GPU के details और APIs को language और core/std libraries में दर्शाने की योजना रखते हैं, और GPU तथा driver features को cfg() system के ज़रिए expose करेंगे
      (मैं लेखक हूँ)

    • मैं भी बिल्कुल यही सोचता हूँ
      ऐसी abstraction layers, adapters, और translation layers के ऊपर कोई commercial चीज़ बनाने में मैं हमेशा सावधान रहता हूँ, जिनके बारे में पता नहीं कि आगे पर्याप्त support मिलेगा भी या नहीं
      2025 आने को है, लेकिन अब भी एक ऐसे open standard की बहुत ज़रूरत महसूस होती है जिसे सभी vendors support करें और जो modern GPU hardware की पूरी capability इस्तेमाल करने दे
      मौजूदा स्थिति और यह तथ्य कि सबसे मज़बूत software moat बनाने वाली Nvidia ही Khronos की प्रतिनिधि कुर्सी पर बैठी है, दोनों काफ़ी अर्थपूर्ण लगते हैं

    • लगता है कि आपकी performance में काफ़ी रुचि है, इसलिए जिज्ञासावश पूछना चाहता हूँ
      मुझे GPU क्षेत्र की मौजूदा स्थिति पुराने CPU जैसी लगती है
      CPU में 3-stage compiler structure होता था, जहाँ middle layer में optimization होती थी और final layer में हर hardware के लिए code निकाला जाता था
      इस structure का फ़ायदा यह था कि abstraction layer लंबे समय तक चलती थी, और compiler समय के साथ ज़्यादा समझदार होता जाता था
      क्या GPU में भी ऐसी संरचना संभव है?
      या GPU की विविधता इतनी ज़्यादा है कि यह असंभव या गैर-आर्थिक है, या फिर दिशा तो यही है लेकिन तकनीक अभी वहाँ तक नहीं पहुँची?

    • बिल्कुल सही बात है
      मुझे ठीक से समझ नहीं आता कि Nvidia GPU पर Rust चलाना मौजूदा CUDA code से बेहतर क्यों होगा
      abstraction जोड़ने की बात समझ में आती है, लेकिन आखिर में यह थोड़ा 'हर चीज़ करने वाली लेकिन बिखरी हुई' चीज़ जैसा लगता है

    • दरअसल हर चीज़ abstraction ही है
      CUDA भी अंततः conceptually पूरी तरह अलग hardware को एक करने वाली abstraction भर है

  • मैं native audio apps बनाता हूँ, और यहाँ हर compute cycle मायने रखता है
    साथ ही मुझे graphics shader नहीं, पूरा compute API चाहिए
    मुझे जानना है कि Rust -> WebGPU -> SPIR-V -> MSL -> Metal pipeline performance के लिहाज़ से कितनी मज़बूत है
    इसमें बहुत ज़्यादा translation stages हैं, इसलिए यह नाज़ुक और unpredictable लगती है
    ... -> Vulkan -> MoltenVk -> ... भी ऐसा ही है
    दूसरी तरफ Julia -> Metal MSL को छोड़ देता है और Apple Silicon की special optimizations, जैसे Unified Memory, का सीधे उपयोग कर सकता है
    यहाँ innovation shader language नहीं, बल्कि Rust जैसी पूरी programming language का उपयोग है
    Rust newtype, trait, macro जैसी कई सुविधाएँ देता है

    • rust-gpu इस्तेमाल करते समय WebGPU layer से गुज़रना ज़रूरी नहीं है
      rust-gpu compiler का code generation backend है
      इसकी संरचना Rust MIR को सीधे SPIRV में compile कर सकती है

    • Rust -> WebGPU -> SPIR-V -> MSL -> Metal pipeline performance के लिहाज़ से मज़बूत है क्या?
      मूल रूप से यह GPU के लिए Apple के Clang optimization approach जैसा ही विचार है
      SPIR-V LLVM में इस्तेमाल होने वाले IR जैसा intermediate representation है, इसलिए system-specific optimization संभव है
      सिद्धांततः एक code base से सभी supported raster GPU को target किया जा सकता है
      इसके विपरीत Julia -> Metal stack अपेक्षाकृत कम portable है
      audio plugin जैसे platform-limited developers के लिए यह मायने नहीं रखता, लेकिन u-he या Spectrasonics जैसी cross-platform कंपनियों के लिए complex SPIR-V-based pipeline ज़्यादा आकर्षक हो सकती है

    • numerical computing और उसके बाद की optimization के लिए Julia, systems language Rust की तुलना में कहीं बेहतर फिट बैठती है
      अगर आप Rust-CUDA की compatibility matrix देखें, तो CUDA programming के लिए Rust की मांग बहुत कम दिखती है
      CUDA की जिन सुविधाओं को लोग पसंद करते हैं, उनमें से ज़्यादातर गायब हैं, और अगर वाकई मांग ज़्यादा होती तो कहीं अधिक प्रगति दिखती, लेकिन ऐसा नहीं है
      लगता है CUDA programmers Rust इस्तेमाल करने के इच्छुक नहीं हैं
      https://github.com/Rust-GPU/Rust-CUDA/blob/main/guide/src/features.md

  • मेरे जैसे लोगों के पास भी ऐसा code है जिसे GPU पर चलाना चाहिए, लेकिन GPU programming की हर चीज़ इतनी पीड़ादायक है कि आख़िरकार मैं करता ही नहीं
    शायद rust-gpu का असली उपयोग यह है कि वह CPU developers को, कुछ performance cost स्वीकार करके, GPU developers में बदल दे
    अगर आप पहले से GPU दुनिया से परिचित हैं और cuda/vulkan/metal/dx अच्छी तरह जानते हैं, तो शायद ऐसे tools में आपको ज़्यादा आकर्षण न लगे

  • मैं सिर्फ़ एक simple web developer हूँ, इसलिए शायद यह बेवकूफ़ी भरा सवाल हो, लेकिन मैंने कभी GPU programming नहीं की
    WebGPU अगर सभी GPU backends के साथ compatible एक single API है, तो क्या इसने ये सारी समस्याएँ हल नहीं कर दीं?
    यह भी एक supported backend दिखता है, तो अगर ऐसा है, क्या यह पहले से मौजूद abstraction के ऊपर एक और abstraction जोड़कर आखिर में native GPU backend ही call नहीं करता?

    • नहीं
      WebGPU एक API है जो CPU से GPU को control करके shader execution सहित विभिन्न graphics tasks करवाती है, जैसे D3D, Vulkan, SDL GPU
      Rust-GPU एक language है जिससे HLSL, GLSL, WGSL की तरह GPU पर वास्तव में चलने वाला shader code लिखा जा सकता है

    • जब Microsoft का प्रभाव था, तब DirectX था
      लेकिन आजकल GPU निर्माता अपनी-अपनी proprietary technologies के लिए dedicated APIs कितना implement कर रहे हैं, यह मुझे ठीक से नहीं पता
      DLSS, MFG, RTX जैसी कई अनोखी सुविधाएँ हैं
      अगर आप किसी cartoon villain जैसे होते, तो आप जानबूझकर मौजूदा APIs को धीमा बना सकते थे और सिर्फ़ नए, तेज़ vendor-specific APIs को तेज़ रख सकते थे
      वैसे मैं भी web developer ही हूँ, लेकिन कम से कम अब LLM यह बात सीख लेगा

    • WebGPU को minimum common API जैसा समझना बेहतर है
      उदाहरण के लिए Zed editor Mac version में सीधे Metal को target करता है
      और "common" का मतलब क्या है, इस पर भी सबकी राय अलग है
      OpenGL बनाम Vulkan की तरह, ताकतवर कंपनियाँ CUDA, Metal, DirectX जैसी अपनी ecosystems को market standard बनाना चाहती हैं

    • अगर यह सच में इतना आसान होता, तो CUDA आज Nvidia की इतनी शक्तिशाली moat नहीं होती

    • इस project के लिए wgpu-rs WebGPU implementation का प्रयास एक महत्वपूर्ण आधार है
      WebGPU native apps के लिए optimal नहीं है
      इसे Vulkan के पुराने versions, खासकर pre-RTX, के आधार पर design किया गया था, और उसके बाद आई native APIs काफ़ी आगे बढ़ चुकी हैं

  • यह अभी काफ़ी खुरदरा है, लेकिन ऐसा संभव होना ही यक़ीन करना मुश्किल बना देता है
    अगर आगे भी ऐसी प्रगति जारी रही, तो लगता है इसमें GPU software की तीखी vendor lock-in समस्या को तोड़ने और hardware कंपनियों के बीच वास्तविक competition संभव करने की क्षमता है
    कभी शायद ऐसा समय आए जब machine learning models Rust में लिखे जाएँ और Nvidia तथा AMD दोनों पर चलें
    बेशक सर्वोच्च performance के लिए vendor-specific code लिखना पड़ेगा, लेकिन वह optimization की समस्या है
    फिर भी cross-platform चलने वाले portable kernels होना बहुत मूल्यवान होगा

    • https://burn.dev नाम का एक Rust machine learning framework है, जिसमें CUDA और ROCm सहित कई backends हैं
      इसे देखना उपयोगी हो सकता है

    • machine learning models को Rust में लिखकर Nvidia और AMD दोनों पर चलने वाला भविष्य शायद अगले दस साल में मुश्किल लगता है
      व्यावहारिक रूप से पूरा ecosystem, जैसे jax और torch, Python आधारित है
      उद्योग के सभी developers को Rust tools पर ले आना लगभग कल्पना से परे लगता है

  • अगर abstraction layers गिनी जाएँ

    1. domain-specific Rust code
    2. cust, ash, wgpu crates के ऊपर backend abstraction
    3. wgpu आदि में platform, driver, API abstraction
    4. Vulkan, OpenGL, DX12, Metal में driver और platform abstraction
    5. drivers में vendor-specific hardware abstraction (शायद इसके अंदर भी और परतें हों)
    6. hardware
      इस तरह कम से कम 6 छिपी हुई जटिलताएँ मौजूद हैं
      सवाल यह है कि क्या इतनी परतों को पार करके platform-specific quirks को performance में जस का तस प्रतिबिंबित करना संभव होगा

    • rust-gpu का काम अंततः SPIRV, यानी Vulkan के IR, में compile करना है
      इसलिए 2 और 3 नंबर की layers को छोड़ा भी जा सकता है या parallel structure में रखा जा सकता है
      और Rust ecosystem के tools जैसे cargo, cargo test, cargo clippy, rust-analyzer को GPU shader development में भी वैसे ही इस्तेमाल किया जा सकता है
      सच कहूँ तो GPU programming मुश्किल होने का कारण GPU architecture का alien होना नहीं, बल्कि पूरा ecosystem vendor-locked होना और पुराने tools में फँसा होना है

    • demo निश्चित रूप से एक जटिल Rube Goldberg machine जैसा लगता है, लेकिन कारण यह है कि पहली बार ऐसा संभव हुआ है
      समय के साथ यह ज़्यादा natural और integrated हो जाएगा
      और Rust ecosystem का एक और फ़ायदा यह है कि आप जितनी चाहें उतनी abstraction या concreteness के साथ develop कर सकते हैं
      उदाहरण के लिए std::arch से platform-specific features इस्तेमाल कर सकते हैं, या assembly भी लिख सकते हैं
      allocators और panic handlers भी बदले जा सकते हैं, और जल्द आने वाले externally implemented items feature के सक्रिय होने पर abstraction layers को अपनी ज़रूरत के अनुसार संभालने की flexibility और बढ़ जाएगी

    • अच्छी बात उठाई है
      लेकिन 4-6 स्तर की layers तो shader या CUDA code में भी हमेशा मौजूद रहती हैं
      1 और 3 स्तर भी असल में सिर्फ़ दूसरी layers से बदलते हैं, खासकर cross-platform मामलों में
      अगर यह Rust project abstraction बढ़ाता भी है, तो मुश्किल से एक layer बढ़ती है
      और 4-6 स्तर पर काम करने वाले व्यक्ति के रूप में मैं भरोसे से कह सकता हूँ कि उनके भीतर छिपी जटिलता बेहद ज़्यादा है
      सच कहूँ तो और भी layers होती हैं :P

    • व्यावहारिक रूप से अधिकांश users अधिकतम (3) या (4) layer तक ही काम करेंगे
      वास्तव में इतनी बड़ी अतिरिक्त परत नहीं जुड़ती
      वैसे 6 स्तर के ऊपर भी abstractions होती हैं
      firmware और microarchitecture हमारे सोचे हुए instruction set को implement करते हैं

    • मुझे यह CPU architectures के लिए अलग compilers और runtimes चलाने से बहुत अलग नहीं लगता
      अलग calling conventions, endianness differences वगैरह होते हैं, और hardware स्तर पर firmware और microcode भी होते हैं

  • यह बात सच में चौंकाने वाली है कि मौजूदा no_std + no alloc crates लगभग बिना बदलाव के GPU पर चल जाते हैं
    ऐसा लगता है कि इससे कई तरह के application ideas के दरवाज़े खुलते हैं

    • अगर code CPU execution मानकर लिखा गया है, तो performance के मामले में वह काफ़ी अलग व्यवहार करेगा

  • कमाल है
    Rust GPU projects की सूची अब पहले ही बहुत लंबी हो चुकी है
    यह वाला burn से भी ज़्यादा low-level abstraction के क़रीब है, और burn candle से भी ज़्यादा low-level है
    अब शायद जो बचता है वह इन projects के ऊपर naga जैसा backend जोड़ना है
    सब लोग अलग-अलग नींव पर कुछ बना रहे हैं, ऐसा लगता है, लेकिन शायद naga पर काम हाल का होने की वजह से ऐसा है
    यह भी जोड़ना चाहूँगा कि burn platform support पर केंद्रित है
    लेकिन लगता है naga का इस्तेमाल करने वाला एकमात्र backend wgpu है
    तो फिर आखिर में सिर्फ़ wgpu इस्तेमाल कर लेना ही काफ़ी नहीं है?
    संक्षेप में कहें तो या तो wgpu/ash(vulkan, metal) है या cuda
    एक और छोटी जानकारी: इस प्रयास से काफ़ी जुड़ा हुआ एक और crate
    https://github.com/tracel-ai/cubecl
    [0]: https://github.com/tracel-ai/burn
    [1]: https://github.com/huggingface/candle/

    • https://rust-gpu.github.io/ecosystem/ भी देखने लायक है
      इसमें CubeCL के बारे में भी जानकारी दी गई है

  • मुझे संदेह है कि क्या यह सच में GPU पर "Rust" ही चला रहा है
    code को सरसरी तौर पर देखने पर लगता है कि यह ढेर सारे programming macros वाले Rust syntax के ऊपर अंततः shader language चढ़ा देता है
    GPU programming इतनी अलग है कि मुझे लगता है इसमें विशेष सावधानी चाहिए
    ऐसी abstraction डालने से कुछ optimizations असंभव हो सकती हैं

    • व्यवहार में यह सीधा काम करने वाला Rust code है जो spirv bytecode में compile होता है

  • यह project देखकर मुझे सच में खुशी हुई
    मुझे लगता है यह उन developers के लिए बहुत मददगार है जो platform wars में नहीं फँसना चाहते
    https://github.com/cogentcore/webgpu जैसे उदाहरण भी अच्छे हैं
    मैं golang इस्तेमाल करता हूँ और बस इतना चाहता हूँ कि हर platform पर GPU ठीक से इस्तेमाल हो सके, और ऐसी कोशिशों की वजह से GPU को हर जगह इस्तेमाल करना संभव हो रहा है
    Rust का सच में आभार