ROCm Menantang CUDA: ‘Melangkah Maju Selangkah demi Selangkah’

 (eetimes.com)
2 poin oleh GN⁺ 5 hari lalu | 2 komentar | Bagikan ke WhatsApp
  • AMD memperkuat strategi GPU pusat data dengan berfokus pada stack perangkat lunak AI ROCm untuk menghadapi ekosistem Nvidia CUDA
  • ROCm telah berkembang dari sekadar kumpulan firmware awal menjadi platform perangkat lunak yang lengkap, dan kini mengadopsi siklus rilis 6 mingguan untuk memastikan kegunaan yang stabil
  • Melalui OneROCm, AMD mendorong integrasi stack AI dan portabilitas di antara CPU, GPU, dan FPGA, serta meningkatkan efisiensi pengembangan lewat penggunaan ulang kode berbasis Triton·MLIR
  • ROCm menjadikan seluruh komponennya kecuali firmware sebagai open source, menyerap kecepatan inovasi komunitas, dan juga didukung secara bawaan pada laptop Strix Halo dan versi Windows
  • AMD menekankan respons terhadap masukan pengembang dan pemulihan kepercayaan komunitas, dengan tujuan mengembangkan ROCm menjadi platform berfokus pada pengembang yang berkelanjutan untuk 10 tahun ke depan

Evolusi AMD ROCm dan strategi bersaing dengan CUDA

  • AMD tengah mendorong stack perangkat lunak AI ROCm sebagai strategi inti untuk menghadapi ekosistem CUDA milik Nvidia di pasar GPU pusat data
  • Wakil presiden divisi perangkat lunak AI Anush Elangovan menggambarkan pengembangan ROCm sebagai “proses mendaki gunung, maju selangkah demi selangkah,” sambil menekankan pentingnya peningkatan dan integrasi yang berkelanjutan
  • Ia bergabung dengan AMD melalui akuisisi startup Nod.ai, dan tim Nod memiliki rekam jejak kontribusi pada proyek open source utama seperti Shark, Torch.MLIR, dan IREE
  • Melalui ROCm, AMD mendorong integrasi stack AI lintas CPU, GPU, dan FPGA (OneROCm), serta memperpendek siklus pengembangan perangkat lunak menjadi 6 minggu dengan target “mencapai tingkat di mana pengguna tidak perlu sadar versi yang mereka gunakan”
  • ROCm saat ini sedang bersiap untuk transisi ke rekayasa berbantuan AI, sambil mempercepat ekspansi yang berpusat pada ekosistem open source dan komunitas pengembang

Perkembangan ROCm dan strategi perangkat lunak

  • Pada awalnya ROCm hanyalah gabungan beberapa bagian firmware, tetapi setelah investasi selama dua setengah tahun, ia berkembang menjadi platform perangkat lunak yang lengkap
    • Elangovan mencontoh budaya pengembangan tim Google Chrome untuk menargetkan siklus rilis reguler dan pengalaman pengguna yang stabil
    • ROCm kini telah menjadi perangkat lunak yang “langsung bekerja”, dan ke depan akan beralih ke sistem rilis setiap 6 minggu
  • AMD sedang bertransformasi dari perusahaan yang berfokus pada perangkat keras menjadi perusahaan yang berfokus pada perangkat lunak, dengan rekayasa berbantuan AI (AI-assisted engineering) sebagai titik balik utama berikutnya

Integrasi stack AI dan portabilitas

  • Melalui OneROCm, AMD mewujudkan integrasi stack AI di berbagai jenis perangkat keras seperti CPU, GPU, dan FPGA
    • Beberapa komponen masih bergantung pada perangkat keras, tetapi seluruh akselerasi dijalankan melalui stack ROCm sehingga portabilitas dapat dijaga
  • Penyebaran framework Triton mengurangi masalah kompatibilitas antar-GPU
    • Di masa lalu, kernel CUDA diubah menjadi kernel HIP, tetapi sekarang kernel Triton dapat ditulis agar berjalan baik di AMD maupun Nvidia
    • AMD berinvestasi aktif pada Triton dan infrastruktur kompilator MLIR, serta mendukung penargetan ulang kode ke berbagai perangkat keras melalui pemeliharaan Torch.MLIR
  • Sebagian besar pelanggan inferensi menggunakan framework LLM seperti vLLM dan SGLang, sehingga permintaan konversi kode CUDA menurun
    • Saat algoritme attention baru muncul, kernel berbasis Triton dapat dioptimalkan dalam satu hingga dua hari
    • HIPify masih disediakan untuk pelanggan HPC, sementara penulisan kernel baru memanfaatkan Claude AI untuk verifikasi dan pembuatan kode

Strategi open source

  • ROCm membuka 100% seluruh komponennya kecuali firmware sebagai open source
    • Dengan open source, ROCm dapat diverifikasi oleh komunitas pengembang sekaligus memanfaatkan kecepatan inovasi komunitas yang lebih cepat daripada AMD
    • Siapa pun bisa berkontribusi pada titik yang mereka inginkan, seperti kompilator atau runtime, tanpa dibatasi oleh kecepatan kolaborasi AMD
  • AMD juga aktif memperluas komunitas pengembang, dan ROCm didukung secara bawaan pada laptop berbasis Strix Halo
    • AMD juga merilis pembaruan ROCm versi Windows pada hari yang sama dengan perangkat keras pusat data Instinct

Komunitas pengembang dan budaya umpan balik

  • Elangovan menaruh perhatian besar pada komunikasi langsung dengan pengembang dan mengumpulkan umpan balik secara real time melalui X(Twitter)
    • Ia memantau kata kunci seperti “ROCm”, “ROCm sucks”, dan “AMD software not working”, lalu merespons semua unggahan secara langsung
    • Sebagian besar masalah berasal dari kurangnya edukasi dan dukungan, dan ia bahkan memberi saran langsung kepada pengembang anonim
  • AMD menyelidiki lebih dari 1.000 keluhan terkait ROCm di GitHub dan menyelesaikan semuanya dalam waktu satu tahun
    • Banyak permintaan terkait dukungan perangkat keras lama, yang kini dipelihara oleh AMD atau komunitas
    • Respons seperti ini memulihkan kepercayaan pengembang dan memperkuat persepsi bahwa “AMD menyelesaikan masalah”
  • Elangovan menyatakan antusiasmenya terhadap GPU MI450 yang direncanakan rilis pada paruh kedua 2026, dan menegaskan bahwa ROCm akan dikembangkan menjadi platform berkelanjutan untuk 10 tahun ke depan
    • Tujuannya adalah membangun ekosistem yang stabil sehingga pengembang tidak perlu khawatir ketika perangkat keras baru hadir

Arah masa depan dan filosofi

  • Berdasarkan pengalamannya di Nod.ai, Elangovan menyebutkan bahwa teknologi kompilator telah diadopsi oleh hampir semua perusahaan akselerator
    • Ia menegaskan bahwa “kita harus melangkah maju selangkah demi selangkah dengan keyakinan,” dan mendefinisikan perkembangan ROCm sebagai hasil dari eksekusi yang berkelanjutan
  • AMD tidak hanya berupaya meniru CUDA, tetapi juga sedang mengembangkan fitur ROCm yang terdiferensiasi, dengan tujuan jangka panjang untuk menjadi platform yang berpusat pada pengembang

Bacaan terkait

2 komentar

 
picopress 3 hari lalu

Mulai dari driver dulu...
 
GN⁺ 5 hari lalu
Opini Hacker News

  • Selama seminggu terakhir saya mem-porting TheRock ke stagex sambil mencoba membangun ROCm dengan toolchain berbasis musl/mimalloc
    Karena untuk workload yang sensitif terhadap keamanan dan privasi, biner yang dibangun hanya dengan satu compiler tidak bisa sepenuhnya dipercaya
    Mengemas lebih dari 30 dependensi dan LLVM kustom adalah mimpi buruk, tetapi pagi ini akhirnya saya berhasil membangun runtime-nya
    Fakta bahwa hardware AMD bisa berjalan dalam lingkungan yang sepenuhnya terbuka memberi harapan untuk workload dengan keamanan tinggi

    • Saya juga pernah mencoba mengemas ROCm di atas musl, khususnya untuk Alpine Linux
      Saya sudah melewati LLVM fork kustom dan berbagai paket, tetapi akhirnya menyerah karena terasa buang-buang waktu
      Sekarang saya memakai llama.cpp dengan dukungan Vulkan dan cukup puas
      Kalau Anda bisa membagikan recipe build-nya, itu sepertinya akan membantu melewati tahap terakhir porting Alpine
    • Menyedihkan melihat situasi seperti ini terus berulang
      Tahun lalu saya menghentikan kampanye pemegang saham karena percaya pada janji AMD, tetapi sekarang rasanya memang perlu tindakan nyata
      unlockgpu.com/action-plan
    • Melihat issue #3477 itu rasanya menyakitkan
      Seharusnya tidak begini, pekerjaan ini jelas harus bisa dipakai
    • Apakah alasan Anda tidak mempercayai Nvidia itu karena driver-nya tertutup?
      Nvidia juga sudah berjanji akan memperbaiki driver open-source mereka
      Secara pribadi, saya lebih tertarik pada Intel yang menawarkan 32GB VRAM di kisaran 1000 dolar
    • Pernyataan “biner yang dibangun hanya dengan satu compiler tidak bisa dipercaya” itu menarik
      Apakah maksudnya menghubungkan file .o yang dicampur dari compiler berbeda?
      Saya penasaran apakah ini memang workload yang berusaha benar-benar menghindari masalah Reflections on Trusting Trust

  • Sejak Februari saya meminta AMD agar kernel Tensile yang sudah dituning untuk gfx1201 dimasukkan ke rcom-libs, tetapi tidak ada yang tahu siapa penanggung jawabnya
    Bahkan di Discord developer pun tidak ada jawaban, jadi sangat membuat frustrasi. Ini tampak seperti contoh hambatan organisasi di AMD selain masalah teknis

  • AMD masih harus mengejar kesenjangan bertahun-tahun untuk ROCm
    Bahkan tidak semua GPU mereka sendiri yang mampu menjalankan AI didukung, dan kalau pun didukung bug-nya banyak
    Driver AMDGPU untuk Linux juga terus tidak stabil sejak 6.6

    • Alasan mereka sulit mendapatkan talenta itu sederhana. Mereka harus bersaing memperebutkan talenta dengan perusahaan terbaik di dunia, sementara AMD bahkan sampai sekitar 10 tahun lalu masih berada di ambang kelangsungan hidup
    • Pada akhirnya bukankah ini karena mereka tidak membayar cukup tinggi
    • ROCm terlalu lama dibiarkan begitu saja. Lima tahun lalu teman-teman saya di internal mencoba meyakinkan perusahaan agar meningkatkan investasi, tetapi gagal
      Jelas ini kesalahan karena tidak melihat bahwa AI akan menjadi penting
      Kalau AMD lebih kompetitif, seluruh industri akan diuntungkan, tetapi ini memang akibat ulah mereka sendiri
    • Ini mungkin juga masalah budaya
      Sejak era ATI dulu sudah terkenal dengan driver yang penuh bug, dan tampaknya budaya itu tidak berubah setelah diakuisisi AMD

  • Tahun lalu AMD mengumpulkan keluhan terkait ROCm di GitHub dan mengumumkan bahwa semua 1000 kasus sudah diselesaikan
    Tetapi kenyataannya dukungan untuk hardware lama hampir tidak bertambah

    • Kalau orang harus membongkar berbagai wiki lalu meretas dukungan kartu secara manual, sulit rasanya menyebut itu sebagai “penambahan dukungan”

  • Saat ROCm mendukung semua kartu AMD sejak hari peluncuran, barulah saya merasa bisa mempercayai promosinya
    Dulu membuang kartu yang masih relatif baru seperti seri 400 adalah kesalahan besar
    Saya berharap manajemen berinvestasi lebih besar pada software stack

    • CUDA juga tidak sempurna. Misalnya, GB10 sudah cukup lama dirilis tetapi masih punya banyak fitur yang belum diimplementasikan

  • ROCm tidak didukung pada GPU konsumen biasa, misalnya kartu seperti RX 580
    Sebaliknya, backend Vulkan bekerja dengan baik

    • Saya membeli RX 580 pada 2018, dan kurangnya dukungan untuk GPU RDNA1 dan RDNA2 terasa disayangkan
      Saya menganggap wajar kalau arsitektur GCN sekarang sudah dihentikan dukungannya, tetapi pada generasi RDNA masalahnya masih kurang dukungan
    • ROCm biasanya hanya mendukung dua generasi GPU
      Saat ini hanya RDNA3 dan RDNA4 yang bisa, sementara CUDA masih mendukung sampai Turing
      Lihat dokumentasi resmi
    • Saya memakai RX 5700, tetapi versi ROCm yang didukung sudah terlalu tua sehingga tidak bisa menjalankan Ollama
      Backend Vulkan berjalan baik, tetapi butuh 1-2 tahun sampai dukungan resmi hadir
    • Vulkan bekerja baik, tetapi dukungan untuk kernel JIT C++·Fortran·Python, integrasi IDE, debugging, dan library masih kurang
    • Dulu sepertinya saya pernah memakai ROCm dengan RX580, apakah sekarang dukungannya sudah dihentikan?

  • Saya berharap stack ROCm dirapikan (clean-up)
    Cukup buat bisa dibangun hanya dengan git clone --recurse-submodules rocm lalu configure/make, dan tampilkan dependensi yang hilang dengan jelas
    Saat ini rasanya seperti banyak komponen dilempar begitu saja tanpa struktur, sehingga tidak terlihat arsitektur yang konsisten

  • Saya berada di tim OpenVINO dan SYCL untuk menantang CUDA
    iGPU dan dGPU Intel belakangan ini cukup masuk akal dari sisi harga dan dukungan software juga membaik
    Untuk workload CV atau data science, bukan gaming, skalanya cukup baik

  • Ini umpan balik terkait ROCm yang ingin saya sampaikan ke manajemen AMD
    (1) Hanya mendukung GPU kelas server dan mengabaikan GPU/APU konsumen adalah kesalahan strategis
    Kebanyakan developer bereksperimen di laptop pribadi dulu lalu nanti berkembang ke server
    Seperti CUDA, seharusnya bisa berjalan di GPU konsumen meski performanya lebih rendah
    (2) Kebijakan hanya mendukung dua generasi itu tidak masuk akal dari sudut pandang pelanggan
    Lihat dokumentasi resmi
    CUDA menjaga kompatibilitas mundur dengan kuat
    (3) Terlalu fokus pada Triton dan memperlakukan HIP sebagai kelas dua adalah arah yang salah
    Masih banyak kode HPC, simulasi, dan ilmiah berbasis C/C++
    GPU AMD unggul dalam performa FP64, jadi ini seperti membuang keunggulan sendiri
    (4) Terakhir, kualitas packaging juga harus ditingkatkan
    Bekerja sama dengan package maintainer distro tidak memerlukan biaya besar, dan bisa menjadi keunggulan kompetitif dibanding Nvidia

    • Kekuatan CUDA ada pada dukungan polyglot
      Dari Python, Julia, dan berbagai bahasa lain, orang bisa langsung menulis kernel, dan integrasi IDE, debugger, serta library-nya juga sangat bagus
      Jika melihat seluruh ekosistem GPGPU, AMD dan Intel masih belum menyamai kematangan ekosistem CUDA
    • Packaging sebenarnya bukan hal yang mudah
      Kebanyakan perusahaan memilih metode instalasi vendor seperti /opt/foo/
      Dengan begitu distro juga lebih mudah membuat packaging sendiri nanti
      Tetapi untuk memahami ini dibutuhkan orang yang punya pengalaman dalam ekosistem open-source
    • NVIDIA juga membuat kesalahan serupa
      Mereka menunda peluncuran GPU konsumen dengan VRAM besar sambil fokus pada pasar server
      Kalau AMD bisa memanfaatkan celah ini dengan baik, itu bisa menjadi peluang
    • Sebenarnya ROCm berjalan secara tidak resmi meski tidak didukung resmi
      Misalnya pada 7900 XT juga berjalan baik
      Hanya saja AMD tidak menginvestasikan sumber daya pengujian sehingga tidak diberi label “dukungan resmi”

  • Dari pengalaman saya dulu menangani compute shader, CUDA, ROCm, dan OpenCV semuanya terlalu merepotkan untuk dipasang
    Dependensinya juga besar, CUDA bahkan 11GB
    Menurut saya lebih baik pakai Vulkan saja. Tidak tergantung platform dan “tinggal jalan”

    • Vulkan memang mudah dipasang, tetapi kodenya rumit
      Hanya untuk kompilasi shader dan pengaturan resource saja sudah butuh ratusan baris, dan untuk menangani alamat GPU perlu extension
    • Di Windows tinggal pasang exe 3GB, di Linux cukup tambah repositori lalu instal
      Rasanya itu bukan sesuatu yang seharusnya memakan waktu berjam-jam
    • Vulkan adalah API level rendah, jadi pekerjaan sederhana pun butuh lebih dari 200 baris
      Dulu di NVIDIA bahkan pernah ada bug(?) bahwa beralih ke mode grafis bisa meningkatkan performa 20%