ZLUDA, proyek open-source yang memungkinkan aplikasi CUDA berjalan di GPU AMD

 (cgchannel.com)
3 poin oleh GN⁺ 2024-03-06 | 1 komentar | Bagikan ke WhatsApp
  • ZLUDA 3 adalah teknologi open-source yang berupaya menjalankan aplikasi untuk GPU NVIDIA yang terikat pada CUDA di GPU AMD tanpa modifikasi
  • Awalnya dimulai sebagai implementasi pengganti CUDA untuk GPU Intel, tetapi setelah evaluasi oleh Intel dan AMD dihentikan, kali ini kode untuk GPU AMD telah dirilis
  • Pada Blender, ada kasus performa yang mirip dengan backend HIP native, tetapi 3DF Zephyr dan RealityCapture ditandai “much slower” di ZLUDA sehingga perbedaannya besar tergantung aplikasi
  • Kemungkinan menjalankan aplikasi CG khusus NVIDIA seperti RealityCapture dan Arnold telah dikonfirmasi, tetapi dukungan OptiX tetap pada tingkat minimal di Linux sehingga ada keterbatasan untuk alur kerja rendering
  • Tanpa dukungan dari Intel maupun AMD, proyek ini dinilai hampir “realistically now abandoned”, dan lisensi SDK NVIDIA juga membatasi pengembangan lapisan translasi untuk platform non-NVIDIA

Masalah ketergantungan CUDA yang ingin dipecahkan ZLUDA 3

  • ZLUDA 3 adalah proyek open-source yang memungkinkan aplikasi berbasis GPU yang dibuat untuk GPU NVIDIA berjalan di perangkat keras dari vendor lain
  • Dirancang agar aplikasi yang sudah ada dapat berjalan di perangkat keras baru tanpa modifikasi, sehingga tidak memerlukan pekerjaan porting tambahan dari pengembang aplikasi
  • ZLUDA pertama kali diperkenalkan pada 2020 sebagai implementasi pengganti CUDA yang bersifat drop-in untuk GPU Intel, dan setelah versi 2 pada 2021 pengembangannya menjadi sulit untuk dilanjutkan
  • Pada 2021, saat Andrzej Janik masih bekerja di Intel, Intel mengevaluasi ZLUDA sebagai kandidat teknologi resmi, tetapi menilai bahwa “tidak ada business case untuk menjalankan aplikasi CUDA di GPU Intel”
  • Setelah meninggalkan Intel pada 2022, Janik mendekati AMD, dan AMD juga mengevaluasi ZLUDA selama dua tahun tetapi memutuskan untuk tidak melanjutkannya
  • Setelah itu, kode yang telah diperbarui dirilis sebagai open source, dan latar belakang terkait dapat dibaca lebih rinci di artikel Phoronix

Cakupan operasi yang terkonfirmasi di aplikasi CG

  • ZLUDA 3 bertujuan menjalankan aplikasi GPU yang dikembangkan dengan API CUDA milik NVIDIA di GPU AMD
  • Di bidang VFX, motion graphics, dan visualisasi, ada beberapa aplikasi CG inti dan renderer yang berbasis CUDA sehingga pada praktiknya tetap eksklusif untuk NVIDIA
  • HIP milik AMD adalah teknologi untuk mem-porting aplikasi CUDA ke perangkat keras AMD, tetapi tetap membutuhkan pekerjaan dari pengembang perangkat lunak
    • HIP digunakan pada versi yang kompatibel dengan AMD dari Redshift dan Blender Cycles
    • ZLUDA 3 juga dibangun berbasis HIP, tetapi tujuannya adalah menjalankan aplikasi CUDA yang sudah ada tanpa modifikasi
  • Perangkat lunak khusus NVIDIA yang diuji Janik dengan ZLUDA mencakup 3DF Zephyr, RealityCapture, dan Autodesk Arnold
  • Dukungan untuk Arnold masih pada tingkat proof of concept, dan jumlah scene yang berhasil dirender dengan implementasi OptiX milik ZLUDA masih terbatas

Batasan realistis pada performa dan kompatibilitas

  • Janik menilai bahwa aplikasi CUDA berjalan di GPU AMD dengan “near-native performance”
  • Menurut benchmark Phoronix dan thread di forum Blender Artists, ada kasus di Blender di mana performa ZLUDA mirip dengan backend HIP native
  • Sebaliknya, repositori GitHub ZLUDA menandai 3DF Zephyr dan RealityCapture sebagai much slower di ZLUDA
  • Banyak renderer GPU juga menggunakan OptiX milik NVIDIA selain CUDA untuk akselerasi ray tracing
    • Dukungan OptiX di ZLUDA berada pada tingkat “minimum”
    • Dukungan OptiX hanya tersedia di Linux dan tidak ada di Windows
    • Status implementasinya adalah “buggy, unoptimized and incomplete”
    • ZLUDA-OptiX tidak disertakan dalam versi redistribusi sehingga harus dibangun sendiri
  • Sulit menilai kemungkinan aplikasi CG berbasis CUDA lain dapat dijalankan tanpa pengujian dari pengguna

Keberlanjutan proyek dan pembatasan lisensi

  • Janik menilai bahwa tanpa dukungan dari Intel atau AMD, ZLUDA secara realistis kini berada dalam kondisi “realistically now abandoned”
    • Ia tetap terbuka pada usulan untuk memajukan proyek ini
    • Jika tidak, kemungkinan besar ia hanya akan menambahkan dukungan untuk teknologi NVIDIA yang secara pribadi menarik baginya seperti DLSS
    • Kode saat ini juga dapat dimanfaatkan oleh pengembang perangkat lunak yang sedang melakukan porting bertahap dari CUDA ke HIP
  • Menurut pembaruan 14 Maret 2024, Tom’s Hardware menyoroti bahwa ketentuan lisensi SDK NVIDIA melarang penggunaan output SDK termasuk CUDA Toolkit untuk mengembangkan teknologi translasi yang ditujukan ke platform non-NVIDIA
  • Versi terkompilasi ZLUDA 3 tersedia untuk Windows dan Linux, sedangkan kode sumbernya tersedia di bawah Apache 2.0 atau MIT license
  • Unduh ZLUDA 3 tersedia di repositori GitHub proyek

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-06
Opini Hacker News

  • Ada diskusi terkait juga 22 hari sebelumnya: sebuah tulisan [0] tentang AMD yang mendanai implementasi drop-in CUDA berbasis ROCm lalu kemudian merilisnya sebagai open source mendapat 400 komentar
    Komentar tingkat teratas yang patut diperhatikan di thread itu mengatakan bahwa publikasinya sendiri adalah akibat AMD menghentikan pendanaan: “Setelah 2 tahun pengembangan dan peninjauan, AMD menilai bahwa menjalankan aplikasi CUDA di GPU AMD tidak memiliki kelayakan bisnis. Salah satu ketentuan kontrak dengan AMD adalah bahwa jika AMD menilai pengembangan lanjutan tidak sesuai, saya boleh mempublikasikannya. Jadi sampailah kita pada hari ini.” Sumber: https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq
    [0] https://news.ycombinator.com/item?id=39344815

  • AMD benar-benar tidak masuk akal menghentikan pendanaan proyek ini. Begitu dirilis sebagai open source, proyek ini langsung mulai menciptakan nilai bagi pengguna AMD
    Hal seperti ini rasanya semestinya menjadi prioritas utama AMD, tetapi mereka justru selama bertahun-tahun berkutat dengan dua, sekarang mungkin tiga, API alternatif yang dukungannya minim

    • Begitu ini menjadi opsi yang bisa dipercaya, Nvidia akan langsung mengirim perintah penghentian dan menggugat. Sebagai solusi serius, ini jalan buntu, jadi dalam konteks itu bisa dimengerti
    • Mungkin juga karena mereka ingin membuat orang memakai HIP
      “HIP sangat tipis sehingga dampak performanya hampir tidak ada atau tidak ada sama sekali dibandingkan coding langsung dalam mode CUDA”
      “Tool HIPIFY secara otomatis mengonversi source CUDA menjadi HIP”
      1. https://github.com/ROCm/HIP
    • Secara strategis, sulit melihat ini sebagai pilihan terbaik bagi AMD. Jika belum berada pada level produk dan belum teruji secara hukum, ini hanya akan menjadi tool yang memungkinkan developer membuat aplikasi di AMD lalu mendistribusikannya di Nvidia
      Untuk kartu grafis konsumen mungkin bisa memberi keuntungan jangka pendek, tetapi dalam jangka panjang ini lebih mirip langkah bunuh diri yang terus mengukuhkan posisi Nvidia di data center
    • Kemungkinan besar mereka mendapat informasi awal tentang pengumuman NVIDIA lalu melepas kontraktor ini. Berdasarkan ketentuan kontrak, proyeknya akan menjadi open source
    • Di sini ada asumsi bahwa AMD memilih menyerah. Bagaimana kalau mereka sebenarnya sedang membuat sesuatu yang lebih baik?

  • Dalam diskusi ini, tulisan “Nvidia melarang penggunaan lapisan translasi untuk menjalankan software CUDA di chip lain” juga tampak relevan [1]

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

    • Jika tidak memakai hardware Nvidia, tidak memakai driver Nvidia, dan tidak pernah menyetujui EULA Nvidia, saya tidak tahu kenapa harus peduli
      Emulasi dilindungi hukum, baik secara eksplisit maupun berdasarkan preseden. Peniruan API untuk tujuan kompatibilitas sudah sampai ke Mahkamah Agung AS dan diputuskan bukan objek hak cipta. Setidaknya saya rasa demikian dalam cakupan yang cukup luas
      Saya bukan pengacara, tetapi sulit melihat dasar hukum apa yang diharapkan Nvidia. Kalau individu atau perusahaan sama sekali tidak punya hardware Nvidia, ini terasa seperti isu yang tidak bermakna. Jika perusahaan sudah memiliki hardware Nvidia, mereka mungkin bisa mengajukan argumen sampai batas tertentu, tetapi bukankah itu justru masuk tepat ke ranah tindakan antipersaingan?
    • Saya tidak tahu apa bedanya ini dengan Wine/Proton. EULA Microsoft juga seharusnya punya ketentuan serupa; kalau bisa ditegakkan, bukankah Microsoft sudah mengirim perintah penghentian yang sama kepada para developer Wine?
    • Perlu ditekankan lagi bahwa, berbeda dari klaim artikel, klausul tersebut sudah ada di CUDA EULA sejak Januari 2022, dan berbeda dari pembaruan artikel, klausul itu juga disertakan dalam unduhan
    • Apakah itu ada artinya? Untuk mengimplementasikan sistem yang memiliki antarmuka kompatibel dengan sistem lain, seseorang tidak perlu izin siapa pun
      Memang melanggar EULA, tetapi selama tidak mengunduh software CUDA, tidak perlu menyetujui EULA, dan para pembuat ZLUDA mungkin bisa menghindari hal itu
    • NVIDIA tidak punya hak untuk melakukan itu. NVIDIA SDK tidak terlibat di sini

  • “Intel pun pada akhirnya menilai bahwa ‘menjalankan aplikasi CUDA di GPU Intel tidak memiliki kelayakan bisnis’,” ini benar-benar menyulitkan

    • Singkatnya, setiap perusahaan yang mencapai skala dan usia tertentu akhirnya lebih bermimpi menjadi monopolis daripada menjadi pesaing
    • Divisi grafis Intel sangat buruk sampai-sampai kesan buruk yang tertinggal di benak orang membuat mereka harus berhenti memakai nama Intel HD

  • Fakta yang diketahui siapa pun yang pernah menyentuh GPGPU AMD, bahkan sekali saja, akhirnya terkonfirmasi. Satu-satunya hal yang mencegah AMD menjadi perusahaan bernilai 2 triliun dolar benar-benar adalah software yang mengerikan
    Saya ingat pernah menemukan bug compiler OpenCL AMD [1], dan sangat mudah juga membuat compiler OpenCL itu mati dengan segmentation fault. Itu tidak pernah diperbaiki, jadi saya menyerah untuk melaporkannya
    Fakta bahwa AMD tidak mengembangkan pesaing CUDA adalah salah satu keputusan paling rabun yang pernah saya lihat. Saya tidak mengerti mengapa dewan direksinya tidak diganti dengan orang-orang yang paham bahwa sekalipun Anda membuat hardware terbaik, jika software yang memakainya—dengan kata-kata sehalus mungkin—buruk sekali, tidak ada yang akan membeli atau menggunakannya
    Kami sebagai pelanggan harus membeli kartu Nvidia yang mahal karena dewan direksi AMD rupanya terlalu kaya untuk peduli pada nilai sekitar 1 triliun dolar yang mereka biarkan tergeletak di atas meja. Kalau Anda punya saham AMD, Anda harus mulai bertanya. Dewan itu sebaiknya dibuang ke saluran pembuangan terdekat
    [1] https://github.com/msoos/amdmiscompile -- pada akhirnya ini diperbaiki

    • Bisa jelaskan apa itu GPGPU seolah-olah menjelaskannya kepada JavaScript?
      Pemahaman naif saya: kartu grafis adalah komputer aneh tempat kita bisa menaruh instruksi dan data, lalu membiarkannya menghitung sendiri
      Saya tidak mengerti mengapa CUDA begitu besar. Tidak bisakah AMD membuat GPU mereka bisa diakses langsung seperti array berisi 4096 board Arduino?
    • Betul. Sebaliknya, AMD umumnya lebih ramah open-source dibanding Nvidia. Nvidia selama beberapa waktu bersikap aktif bermusuhan; cukup lihat video “F* you!” dari Linus
      Perusahaan yang mengembangkan hardware pada umumnya buruk dalam software. Ada pengecualian, tetapi tidak banyak, dan perusahaan seperti itu memang mendapat imbalan lewat harga sahamnya. Saya tidak tahu budaya divisi software AMD, tetapi biasanya perlu perubahan yang cukup besar untuk memperbaiki hal seperti ini
      Mengganti dewan direksi saja kemungkinan tidak akan menyelesaikannya. Jika arahan eksekutif puncak bukan satu-satunya faktor yang menyeret perusahaan ke bawah, jauh lebih banyak lapisan manajemen harus diubah, dan cukup banyak manajer menengah juga harus diganti. Jika perekrutan software-nya tidak berjalan benar, kadang sampai kontributor individual pun harus diganti
    • Saya tidak mengerti mengapa AMD tidak bekerja sama dengan Intel untuk mendorong SYCL sebagai standar GPGPU dan cara pemrograman heterogen
      Intel bagus dalam software, dan SYCL adalah standar terbuka, jadi kedua perusahaan bisa mendapat manfaat dari kode yang sama, sementara pelanggan bisa menjalankan kode SYCL di Threadripper kalau mau. Beberapa Threadripper zaman sekarang bahkan secepat sebagian GPU
      Apakah AMD mencoba membuat ekosistem lock-in proprieter miliknya sendiri? Saya tidak mengerti mengapa mereka tidak berkomitmen pada standar terbuka lintas platform
    • Saya sendiri cukup suka AMD Software. Mudah untuk membatasi frame rate ke 60 agar GPU tidak berjalan maksimal saat game atau software tidak mendukungnya secara bawaan, dan seperti Shadowplay, kita juga bisa mengatur instant replay yang terus merekam beberapa menit terakhir ke sebuah hotkey
      Saat UPS saya kurang bagus, saya juga bisa membatasi daya GPU, dan saya bisa melakukan auto-overclock agar RX 580 bisa dipakai sekitar satu tahun lebih lama
      Namun software/driver setelah sekitar 2020 membuat judul VR crash dalam waktu kurang dari satu jam. Tidak ada paket software untuk Linux, dan CoreCtrl tidak sebagus itu. Instant replay juga kadang-kadang begitu saja tidak berfungsi. Saya tidak pernah berhasil memasangkan ROCm dengan LLM lokal, baik di Windows maupun Linux, dan DKMS suka melakukan banyak kompilasi sia-sia setiap kali apt upgrade
      Untuk GPU berikutnya, saya sedang mempertimbangkan apakah akan mencoba Intel Arc karena penasaran, atau kembali saja ke Nvidia. Kandidatnya kira-kira A580, RX 6600, RTX 3050, atau mungkin saya bertahan dulu sampai harga komponen lain turun

  • Apakah ada bahasa pemrograman yang dikompilasi ke berbagai bahasa kernel seperti Metal, CUDA, dan sesuatu dari sisi AMD? Kalau tidak ada, kenapa?
    Compiler C mengompilasi ke berbagai arsitektur CPU. Bukankah seharusnya ada juga compiler yang menargetkan arsitektur GPU? Mungkin saja hanya belum ada yang membuatnya

    • Apakah OpenCL juga bisa dihitung?
      https://www.khronos.org/api/opencl
    • OpenMP 5 telah menetapkan dukungan GPU. Dari pencarian sekilas, tampaknya sebagian compiler kini setidaknya mendukungnya sebagian

  • Ada yang pernah memakai ini untuk menjalankan alat fotogrametri open-source seperti Meshroom? Artikel menyebut beberapa alat proprieter, tetapi kebutuhan saya cukup kecil

  • Ini terlihat hampir persis seperti kasus Oracle vs Google seputar penggunaan bytecode JVM

    • Menurut saya tidak begitu. Isunya bukan transformasi bytecode, melainkan mengikat kekayaan intelektual library pada hardware di level yang lebih tinggi
      Ini mirip Google mengatakan, “aplikasi Android kami hanya boleh berjalan di ponsel yang disetujui Google.” Sejauh pemahaman saya, Google memang melakukan hal semacam itu untuk hal-hal seperti framework Play atau Maps

  • Baru-baru ini saya mendengar rumor menarik: orang yang menangani CUDA di NVIDIA selama bertahun-tahun harus berjuang mendapatkan sumber daya dan meyakinkan perusahaan agar menganggap proyek ini serius
    Tanpa CUDA, NVIDIA tidak mungkin menjadi perusahaan yang hari ini bernilai hampir 1 triliun dolar

  • geohot yang terus bergulat dengan GPU AMD mahal juga terkait: https://twitter.com/tinygrad/status/1764734675002810622