- Proyek demo yang memperlihatkan satu codebase yang ditulis dengan Rust dapat berjalan di semua platform GPU dan CPU utama seperti CUDA, Vulkan(SPIR-V), Metal, DirectX 12, WebGPU, CPU telah dirilis
- Pemrograman GPU tradisional menimbulkan kompleksitas dan duplikasi karena harus memakai bahasa terpisah seperti GLSL dan HLSL, tetapi demo ini mendukung semua target GPU hanya dengan kode Rust murni
- Implementasi utamanya menggabungkan proyek Rust GPU(SPIR-V), Rust CUDA(NVVM IR), Naga(lapisan translasi bahasa GPU), dan algoritme bitonic sort yang sama berjalan di CPU maupun semua GPU. Fitur bahasa Rust seperti no_std, kompilasi kondisional, Newtype, Enum, Trait juga dapat diterapkan apa adanya pada kode GPU
- Masih ada tantangan perbaikan seperti integrasi resmi ke rustc, debugging, dan konsistensi API, tetapi ini merupakan upaya yang bisa menjadi titik balik bagi komputasi GPU lintas platform
Mewujudkan komputasi GPU lintas platform berbasis Rust
Pengenalan proyek dan maknanya
- Satu codebase Rust menjalankan kode kernel yang sama di CUDA(NVIDIA), Vulkan(SPIR-V), Metal(Apple), DirectX 12(Windows), WebGPU(browser), CPU, dan lainnya
- Tanpa memakai bahasa khusus shader atau kernel seperti GLSL atau HLSL, kode Rust murni dapat memproses komputasi yang sama di GPU maupun CPU
- Ini secara signifikan mengurangi duplikasi kode dan kompleksitas antara GPU dan CPU, sekaligus membawa keunggulan alat dan bahasa dalam ekosistem Rust seperti stabilitas tipe, testing, dokumentasi, dan manajemen build ke pemrograman GPU
Latar belakang
- Pemrograman GPU tradisional mengharuskan penggunaan bahasa shader yang terspesialisasi untuk tiap platform, seperti GLSL, HLSL, MSL, WGSL, dan lainnya
- Akibatnya, kode CPU dan GPU terpisah, memunculkan duplikasi logika dan peningkatan kompleksitas pengembangan
- Komunitas Rust menanggapi hal ini dengan mendorong pendekatan mengompilasi Rust umum untuk target GPU
- Rust GPU: mengompilasi kode Rust ke SPIR-V, berjalan di Vulkan dan GPU yang kompatibel dengan SPIR-V
- Rust CUDA: mengompilasi kode Rust ke IR CUDA NVIDIA (NVVM IR, PTX), lalu dijalankan di CUDA
- Naga: lapisan perantara yang mendukung konversi antar berbagai bahasa GPU (WGSL, SPIR-V, GLSL, MSL, HLSL), terutama digunakan dalam proyek wgpu. Bertanggung jawab atas portabilitas backend
- Masing-masing proyek awalnya berkembang secara terpisah dengan API dan struktur yang berbeda, tetapi melalui kolaborasi terbaru, eksekusi GPU dari codebase bersama akhirnya terwujud
Cara implementasi
- Dalam demo contoh, algoritme bitonic sort diimplementasikan sebagai satu kode Rust, dan kode yang sama dijalankan untuk semua target GPU dan CPU
- Istilah komponen utama
- Host: kode Rust yang berjalan di CPU (memulai pekerjaan)
- Device: GPU/CPU tempat kernel benar-benar dijalankan
- Driver API: API level rendah untuk berkomunikasi dengan perangkat, seperti CUDA, Vulkan, Metal, DX12
- Backend: abstraksi di Rust terhadap target Driver API, seperti cust, ash, wgpu
- Melalui kombinasi target dan feature flag Rust, pemilihan backend serta kontrol build dapat dilakukan
- Misalnya, tersedia opsi build terpisah untuk tiap backend seperti wgpu, ash, cuda
- Juga dimungkinkan membangun beberapa backend ke dalam satu biner dan memilihnya secara dinamis saat runtime
Alur kompilasi kernel
- Bergantung pada target dan feature, biner eksekusi GPU seperti SPIR-V atau PTX dibuat saat build dan di-embed ke dalam object file
- Saat runtime, kernel yang telah di-embed dimuat lalu dikonversi ke format yang dibutuhkan masing-masing platform melalui Naga dan lainnya sebelum dijalankan
- Contoh:
- macOS: SPIR-V dikonversi ke MSL → dijalankan lewat Metal
- Windows: SPIR-V dikonversi ke HLSL → dijalankan lewat DX12
- Linux/Android: SPIR-V → dijalankan lewat Vulkan
- CUDA: PTX dikompilasi ke SASS, diunggah ke GPU, lalu dijalankan
Teknik penulisan kode GPU yang ramah Rust
-
Dukungan no_std
- Karena GPU tidak memiliki dukungan OS, penggunaan
no_std di Rust adalah keharusan
- Karena ekosistem dasar Rust sejak awal mengasumsikan lingkungan tanpa OS seperti embedded, firmware, dan kernel, GPU pun dapat didukung dengan cara standar Rust tanpa "mode khusus" terpisah
-
Kompilasi kondisional
- Dengan kombinasi atribut cfg dan feature flag, kode yang membedakan platform maupun GPU/CPU dapat ditulis dengan jelas dan ringkas
- IDE dan compiler memahami semua jalur kode, sehingga keandalan kode dan produktivitas tetap tinggi
-
Pemanfaatan newtype
- Kesalahan implisit pada indeks atau pemetaan struct yang rawan terjadi di GPU dapat dicegah pada level tipe dengan memakai newtype
- Dengan atribut
#[repr(transparent)], abstraksi tipe ini bisa diterapkan tanpa overhead yang berarti
-
Enum dan representasi yang aman
- Alih-alih memakai magic number, Rust Enum digunakan, dengan
#[repr(u32)] untuk memastikan pemetaan ke integer native
- Pattern matching dan exhaustiveness (semua kemungkinan cabang ditangani) membantu membangun kode yang aman
- Namun, saat mengirim dan menerima nilai Enum di buffer bersama antara CPU dan GPU, perlu diperhatikan bahwa semua nilai harus valid sebagai Enum
-
Algoritme generik berbasis Trait
- Trait digunakan untuk menyediakan abstraksi operasi GPU seperti perbandingan, konversi, dan operasi umum pada berbagai tipe nilai
- Dengan mendefinisikan trait bound secara jelas pada algoritme generik, type safety dan optimasi bisa dicapai sekaligus
-
#[inline] dan optimasi performa
- Penggunaan
#[inline] mendorong agar lapisan abstraksi hilang dari hasil kompilasi nyata
- Ini dirancang agar abstraksi tidak menimbulkan biaya tambahan, mengingat karakteristik GPU seperti kebutuhan performa tinggi dan keterbatasan stack
-
Komposisi struct dan pengelompokan semantik
- Parameter GPU yang kompleks dapat dikelompokkan ke dalam struct berdasarkan makna, menjaga type safety dan mencegah ledakan jumlah parameter
- Pola smart constructor membantu memblokir status invalid sejak tahap kompilasi
-
Tata letak memori dan kontrol #[repr(C)]
- Untuk kompatibilitas data dengan GPU, layout struct ditentukan secara eksplisit dengan
#[repr(C)]
- Disebutkan pula perlunya dukungan bahasa tambahan ke depan, misalnya otomatisasi padding per GPU
-
Pattern matching
- Sebagai konsep yang lebih luas daripada switch/case, ini memungkinkan semua percabangan dan status dalam kode GPU ditangani dengan jelas
- Compiler juga dapat memeriksa jalur kode dan mengoptimalkan performa
-
Fungsi generik
- Logika yang sama dapat diimplementasikan untuk banyak tipe tanpa bergantung pada tipe data tertentu
- Trait bound, monomorphization, dan lainnya meningkatkan kemudahan pemeliharaan dan pengujian
-
Macro derive
- Trait yang cocok untuk GPU seperti Copy, Clone, Debug, PartialEq, Pod dapat diimplementasikan otomatis
- Ini membantu menjaga keamanan dan meminimalkan boilerplate
-
Sistem modul dan pengelolaan workspace
- Sistem paket/modul Rust memungkinkan penataan sumber untuk kode host, kernel, tipe, dan backend secara terstruktur
- Cargo workspace dan workspace dependency membantu menjaga konsistensi dependensi antar crate dan memudahkan pemeliharaan
-
Formatting, lint, dan dokumentasi
- Kode GPU dapat dikelola dengan cara yang sepenuhnya sama seperti alat standar Rust seperti rustfmt dan clippy, sehingga kualitas tetap konsisten
- Kode GPU juga dapat didokumentasikan dengan doc comment dan cargo doc
-
Build script
- Melalui
build.rs milik Cargo, build kernel berbasis feature flag dan embedding biner dapat diotomatisasi
-
Unit test dan produktivitas pengembangan
- Kode kernel GPU dapat diuji juga di CPU, sehingga pengembangan dan deteksi bug menjadi lebih mudah
- Alat tradisional seperti debug
println, gdb, dan lldb juga bisa digunakan
- Kernel Vulkan pun dapat diuji di CI dengan driver perangkat lunak seperti SwiftShader dan lavapipe
- Pengukuran testing, code coverage, property-based testing, dan alat pihak ketiga lainnya juga dapat terintegrasi dengan baik
Pengalaman pengembang yang belum matang dan tantangan
- Karena backend GPU belum terintegrasi ke compiler Rust resmi, masih perlu memakai backend codegen terpisah (
spirv, nvvm) dan mengunci ke versi nightly
- Target CUDA bergantung pada LLVM 7.1 milik NVIDIA, sehingga perlu build terpisah di distribusi Linux terbaru
- Pengalaman build dan debugging kernel masih kurang matang, dengan masalah seperti pelacakan error dan informasi debug yang belum memadai
- API antara Rust GPU dan Rust CUDA, termasuk penamaan standard library, masih berbeda dan menimbulkan kebingungan
- Dalam jangka panjang, perlu penguatan konsistensi dan integrasi berfokus GPU di bahasa Rust dan ekosistemnya secara menyeluruh
Partisipasi komunitas dan masa depan
- Menjalankan kode yang sama di semua platform GPU utama dengan Rust kini telah terwujud
- Ke depan, tantangan yang tersisa meliputi peningkatan build dan debugging, perluasan dukungan bahasa Rust dan API, serta tuning performa
- Pengembang yang ingin berpartisipasi dan berkontribusi dapat merujuk ke repositori GitHub rust-gpu dan rust-cuda
1 komentar
Komentar Hacker News
Sangat mengesankan bahwa teknologi ini memungkinkan.
Tapi use case saya adalah menjalankannya pada perangkat keras klien yang acak, jadi saya cenderung tidak mempercayai semua lapisan abstraksi yang dibangun di atas API GPU.
Tujuannya adalah memanfaatkan detail tingkat rendah GPU semaksimal mungkin, dan pendekatan yang menganggap detail seperti ini sebagai hal merepotkan biasanya berujung pada bug dan penurunan performa.
Karena setiap target berbeda secara signifikan.
Untuk mengatasinya, menurut saya sistem serupa harus disediakan langsung oleh vendor.
Namun karena posisi antarvendor masih belum selaras, tampaknya perbedaan antarpaltform masih besar.
Dalam kasus tertentu ada pengecualian seperti Angle, tetapi bahkan dalam kasus seperti itu stabilitas hanya dicapai lewat pembatasan fitur dan pada akhirnya ada kehilangan performa.
Meski begitu, jelas membantu bahwa pendekatan seperti kompilasi bersyarat memungkinkan.
Karena Rust adalah bahasa sistem, kita bisa memiliki tingkat kontrol sebanyak yang kita inginkan.
Kami berencana mencerminkan detail dan API GPU ke dalam bahasa serta pustaka core/std, dan mengekspos kemampuan GPU dan driver melalui sistem
cfg().(saya penulisnya)
Saya juga berpikir sama.
Saya selalu berhati-hati membangun sesuatu yang komersial di atas lapisan abstraksi, adaptor, dan layer translasi yang belum jelas apakah akan mendapat dukungan memadai ke depannya.
Sudah hampir 2025, tetapi saya masih merasa kita sangat membutuhkan standar terbuka yang didukung semua vendor dan memungkinkan penggunaan penuh fitur perangkat keras GPU terbaru.
Di tengah situasi seperti ini, terasa cukup bermakna bahwa Nvidia, yang menciptakan hambatan masuk perangkat lunak paling kuat, duduk sebagai perwakilan Khronos.
Sepertinya Anda sangat peduli dengan performa, jadi saya ingin bertanya karena penasaran.
Menurut saya kondisi dunia GPU saat ini sangat mirip dengan CPU di masa lalu.
Pada CPU, ada struktur compiler tiga tahap: optimisasi di lapisan tengah, lalu lapisan akhir mengeluarkan kode yang sesuai untuk tiap perangkat keras.
Kelebihan struktur ini adalah lapisan abstraksinya bisa bertahan lama, dan compiler menjadi makin cerdas seiring waktu.
Saya penasaran apakah struktur seperti ini juga memungkinkan di sisi GPU.
Atau apakah keberagaman GPU terlalu besar sehingga mustahil atau tidak ekonomis, atau memang itu arah yang jelas dituju tetapi teknologinya belum sampai ke sana.
Tepat sekali.
Saya kurang paham apa kelebihan menjalankan Rust di GPU Nvidia dibanding kode CUDA yang sudah ada.
Saya paham soal penambahan abstraksi, tapi hasil akhirnya terasa seperti “bisa melakukan segala macam hal secara umum”.
Sebenarnya semuanya adalah abstraksi.
CUDA pada akhirnya juga tidak lebih dari abstraksi yang menyatukan secara konseptual perangkat keras yang sebenarnya sangat berbeda.
Saya mengembangkan aplikasi audio native, dan di sini setiap siklus komputasi itu penting.
Saya juga membutuhkan compute API penuh, bukan shader grafis saja.
Saya penasaran apakah pipeline "Rust -> WebGPU -> SPIR-V -> MSL -> Metal" kokoh dari sisi performa.
Terlalu banyak tahap transformasi sehingga terlihat rapuh dan sulit diprediksi.
"... -> Vulkan -> MoltenVk -> ..." juga sama.
Sebaliknya, "Julia -> Metal" melewati MSL, dan bisa langsung memanfaatkan optimisasi khusus Apple Silicon seperti Unified Memory.
Inovasi di sini bukan bahasa shadernya, melainkan penggunaan bahasa pemrograman penuh seperti Rust.
Rust mendukung beragam fitur seperti newtype, trait, macro, dan lain-lain.
Saat memakai rust-gpu, Anda tidak harus melalui lapisan WebGPU.
Karena rust-gpu adalah backend code generation milik compiler.
Strukturnya memungkinkan Rust MIR dikompilasi langsung ke SPIRV.
Apakah pipeline "Rust -> WebGPU -> SPIR-V -> MSL -> Metal" kokoh dari sisi performa?
Pada dasarnya ini konsep yang mirip dengan cara optimisasi Apple Clang untuk GPU.
SPIR-V adalah representasi menengah seperti IR yang dipakai di LLVM, sehingga bisa dioptimalkan per sistem.
Secara teori, satu basis kode bisa menargetkan semua raster GPU yang didukung.
Sebaliknya, stack Julia -> Metal relatif kurang portabel.
Untuk pengembang yang hanya fokus pada satu platform seperti plugin audio mungkin itu tidak masalah, tetapi bagi perusahaan lintas platform seperti u-he atau Spectrasonics, pipeline berbasis SPIR-V yang lebih kompleks bisa jadi lebih menarik.
Untuk komputasi numerik dan optimisasi setelahnya, Julia jauh lebih cocok daripada Rust yang merupakan bahasa sistem.
Jika melihat matriks kompatibilitas Rust-CUDA, terlihat bahwa permintaan terhadap Rust untuk pemrograman CUDA sangat kecil.
Sebagian besar fitur CUDA yang disukai orang tidak ada, dan kalau memang ada permintaan nyata pasti perkembangannya sudah lebih besar, tetapi ternyata tidak.
Para programmer CUDA tampaknya tidak terlalu berniat memakai Rust.
https://github.com/Rust-GPU/Rust-CUDA/blob/main/guide/src/features.md
Meski saya punya kode yang ingin dijalankan di GPU, semua hal tentang pemrograman GPU begitu menyakitkan sampai akhirnya saya tidak jadi melakukannya.
Mungkin kegunaan sebenarnya rust-gpu adalah mengubah developer CPU menjadi developer GPU, meski harus menerima sedikit kerugian performa.
Jika Anda sudah terbiasa dengan dunia GPU dan hafal cuda/vulkan/metal/dx, mungkin alat seperti ini tidak akan terasa terlalu menarik.
Saya hanya web developer biasa jadi mungkin ini pertanyaan bodoh, tapi saya belum pernah melakukan pemrograman GPU.
Saya penasaran apakah WebGPU, sebagai satu API tunggal yang kompatibel dengan semua backend GPU, sebenarnya sudah menyelesaikan semua masalah ini.
Kelihatannya WebGPU juga hanya salah satu backend yang didukung, jadi kalau begitu bukankah artinya kita menumpuk abstraksi baru di atas abstraksi lama lalu akhirnya tetap memanggil backend GPU native?
Bukan begitu.
WebGPU adalah API yang memungkinkan CPU mengendalikan GPU untuk menjalankan shader dan berbagai tugas grafis lainnya, seperti D3D, Vulkan, atau SDL GPU.
Rust-GPU adalah bahasa untuk menulis kode shader yang benar-benar dijalankan di GPU, mirip dengan HLSL, GLSL, atau WGSL.
Saat Microsoft masih berpengaruh, ada DirectX.
Tapi sekarang saya tidak terlalu tahu sejauh mana produsen GPU mengimplementasikan API khusus untuk teknologi eksklusif mereka masing-masing.
Ada berbagai fitur unik seperti DLSS, MFG, RTX, dan sebagainya.
Kalau saya penjahat di film kartun, saya mungkin akan sengaja membuat API lama berjalan lambat, lalu hanya menyediakan API baru yang lebih cepat dan khusus vendor.
Sebagai catatan, saya juga web developer jadi tidak terlalu paham, tapi setidaknya LLM jadi belajar hal-hal seperti ini.
WebGPU lebih dekat ke API minimum bersama.
Misalnya editor Zed langsung menargetkan Metal pada versi Mac.
Dan soal apa yang dimaksud dengan “umum” pun tiap orang punya pendapat berbeda.
Seperti OpenGL vs Vulkan, perusahaan yang kuat cenderung mendorong ekosistem mereka sendiri seperti CUDA, Metal, atau DirectX menjadi standar pasar.
Kalau memang semudah itu, CUDA tidak akan menjadi moat Nvidia yang begitu kuat saat ini.
Upaya dalam proyek ini sangat bergantung pada implementasi WebGPU wgpu-rs.
WebGPU tidak optimal untuk aplikasi native.
Karena dirancang berdasarkan Vulkan versi lama (terutama pra-RTX), sementara API native yang sesungguhnya setelah itu berkembang jauh lebih maju.
Meski saat ini masih terasa kasar, saya benar-benar sulit percaya bahwa hal seperti ini bisa dilakukan.
Jika perkembangan seperti ini terus berlanjut, saya merasakan potensi untuk mematahkan kuatnya ketergantungan vendor di perangkat lunak GPU dan memungkinkan persaingan nyata antarprodusen perangkat keras.
Saya membayangkan suatu hari nanti kita bisa menulis model machine learning dalam Rust dan menjalankannya di Nvidia maupun AMD.
Tentu untuk performa terbaik kita tetap perlu menulis kode yang dioptimalkan khusus untuk tiap vendor, tetapi itu persoalan optimisasi.
Meski begitu, tetap mungkin memiliki kernel portabel yang berjalan lintas platform.
Ada framework machine learning Rust bernama https://burn.dev yang punya berbagai backend seperti CUDA dan ROCm.
Mungkin layak dilihat.
Masa depan di mana model machine learning ditulis dengan Rust lalu dijalankan di Nvidia dan AMD sepertinya sulit tercapai dalam sepuluh tahun ke depan.
Secara realistis, seluruh ekosistem seperti jax dan torch berbasis Python.
Rasanya hampir mustahil membayangkan semua developer profesional berpindah ke tool Rust.
Jika menghitung lapisan abstraksinya:
Jadi ada setidaknya 6 kompleksitas tersembunyi seperti ini.
Saya ragu apakah mungkin menembus semua lapisan ini dan tetap merefleksikan kekhasan platform ke performa tanpa kehilangan apa pun.
Yang dilakukan rust-gpu pada akhirnya adalah mengompilasi ke SPIRV (yakni IR milik Vulkan).
Jadi lapisan 2 dan 3 bisa dihilangkan atau dijadikan struktur paralel.
Tool seperti cargo, cargo test, cargo clippy, dan rust-analyzer dari ekosistem pengembangan Rust juga bisa dimanfaatkan apa adanya untuk pengembangan shader GPU.
Sebenarnya saya rasa pemrograman GPU bukan sulit karena arsitektur GPU terlalu alien, melainkan karena seluruh ekosistemnya terikat vendor dan tertahan oleh tool lama.
Demonya memang jelas lebih mirip mesin Rube Goldberg yang rumit, tetapi itu karena inilah pertama kalinya hal seperti ini memungkinkan.
Seiring waktu, ini akan berubah menjadi sesuatu yang lebih alami dan terintegrasi.
Dan kelebihan lain dari ekosistem Rust adalah Anda bisa mengabstraksikan atau mengembangkan serinci yang Anda mau.
Misalnya memakai fitur spesifik platform lewat
std::arch, atau bahkan menulis assembly.Mengganti allocator dan panic handler juga memungkinkan, dan ketika fitur externally implemented items yang akan datang diaktifkan, fleksibilitas untuk menangani lapisan abstraksi sesuai keinginan juga akan makin besar.
Poin yang bagus.
Tetapi lapisan tahap 4-6 selalu ada juga pada shader maupun kode CUDA.
Lapisan 1 dan 3 sebenarnya hanya diganti dengan lapisan lain (terutama jika lintas platform).
Bahkan jika proyek Rust ini menambah lapisan abstraksi, paling hanya satu tahap.
Dan sebagai orang yang bekerja langsung pada tahap 4-6, saya bisa pastikan kompleksitas tersembunyi di sana sangatlah besar.
Sejujurnya kadang malah ada lebih banyak lapisan lagi :P
Jika dilihat secara realistis, kebanyakan pengguna hanya akan berurusan sampai lapisan (3) atau (4) saja.
Praktiknya tidak menambah tahap ekstra sebesar itu.
Sebagai catatan, di atas lapisan 6 pun masih ada lapisan abstraksi lain.
Firmware dan mikroarsitektur mengimplementasikan instruction set yang kita pikir kita lihat.
Saya rasa ini tidak terlalu berbeda dengan mengelola compiler dan runtime berbeda untuk arsitektur CPU yang berbeda-beda.
Ada pula calling convention yang berbeda, perbedaan endianness, dan pada level perangkat keras ada firmware serta microcode.
Sungguh mengejutkan bahwa crate no_std + no alloc yang sudah ada bisa berjalan di GPU hampir tanpa modifikasi.
Rasanya ini benar-benar membuka banyak ide aplikasi yang beragam.
Benar-benar luar biasa.
Daftar proyek Rust GPU saja sudah sangat banyak sekarang.
Yang ini terasa lebih dekat ke abstraksi tingkat rendah dibanding burn, dan burn lebih rendah lagi dibanding candle.
Sekarang yang tersisa tampaknya adalah menambahkan backend seperti naga ke proyek-proyek di atas.
Memang terasa seperti semua orang membangun sesuatu di atas fondasi yang berbeda-beda, tetapi mungkin karena pekerjaan naga ini masih relatif baru.
Saya juga ingin menambahkan bahwa burn berfokus pada dukungan platform.
Tapi kalau dipikir-pikir, satu-satunya backend yang memakai naga adalah wgpu.
Jadi pada akhirnya apakah memakai wgpu saja sudah cukup?
Ringkasnya, pilihannya adalah wgpu/ash(vulkan, metal) atau cuda.
Tambahan singkat: ada satu crate lain yang dekat dengan upaya ini.
https://github.com/tracel-ai/cubecl
[0]: https://github.com/tracel-ai/burn
[1]: https://github.com/huggingface/candle/
Ada rangkuman soal CubeCL juga di sana.
Saya ragu ini benar-benar “Rust” yang berjalan di atas GPU.
Kalau melihat sekilas kodenya, strukturnya tampak seperti menaruh bahasa shader pada akhirnya di atas sintaks Rust yang penuh macro pemrograman.
Pemrograman GPU itu sangat berbeda sehingga menurut saya butuh perhatian khusus.
Memasukkan abstraksi seperti ini bisa membuat optimisasi tertentu menjadi tidak mungkin.
Saya sangat senang melihat proyek ini.
Rasanya ini sangat membantu para developer yang tidak ingin terjebak dalam perang platform.
Contoh seperti https://github.com/cogentcore/webgpu juga bagus.
Saya memakai golang dan yang saya butuhkan hanya agar GPU bisa dimanfaatkan dengan baik di semua platform, dan berkat hal-hal seperti ini GPU bisa dipakai di mana saja.
Terima kasih banyak untuk Rust.