CUDA’ya Meydan Okuyan ROCm: ‘Adım Adım İlerlemek’

 (eetimes.com)
2 puan yazan GN⁺ 16 일 전 | 2 yorum | WhatsApp'ta paylaş
  • AMD, Nvidia CUDA ekosistemine karşılık vermek için AI yazılım yığını ROCm etrafında veri merkezi GPU stratejisini güçlendiriyor
  • ROCm, başlangıçtaki basit bir ürün yazılımı paketinden tam kapsamlı bir yazılım platformuna dönüştü ve 6 haftalık sürüm döngüsü getirerek istikrarlı kullanılabilirlik sağlamaya çalışıyor
  • OneROCm ile CPU, GPU ve FPGA arasında AI yığını entegrasyonu ve taşınabilirlik sağlamayı hedefliyor, Triton·MLIR tabanlı kod yeniden kullanımıyla geliştirme verimliliğini artırıyor
  • ROCm, ürün yazılımı hariç tüm bileşenleri açık kaynak yaparak topluluğun yenilik hızını kendi bünyesine katıyor ve Strix Halo dizüstü bilgisayarlar ile Windows sürümünde de varsayılan olarak destekleniyor
  • AMD, geliştirici geri bildirimlerine yanıt vermeyi ve topluluk güvenini yeniden kazanmayı önemsiyor; ROCm’i önümüzdeki 10 yıl boyunca sürdürülebilir, geliştirici odaklı bir platforma dönüştürmeyi hedefliyor

AMD ROCm’in evrimi ve CUDA’ya karşı rekabet stratejisi

  • AMD, veri merkezi GPU pazarında Nvidia’nın CUDA ekosistemine karşılık vermek için AI yazılım yığını ROCm’i temel strateji olarak öne çıkarıyor
  • AI yazılım bölümünden sorumlu başkan yardımcısı Anush Elangovan, ROCm geliştirmesini “dağa tırmanmak gibi, adım adım ilerleyen bir süreç” olarak tanımlıyor ve sürekli iyileştirme ile entegrasyonun altını çiziyor
  • Elangovan, startup Nod.ai’nin satın alınması sonrasında AMD’ye katıldı; Nod ekibi daha önce Shark, Torch.MLIR, IREE gibi önemli açık kaynak projelerine katkıda bulundu
  • AMD, ROCm üzerinden CPU, GPU ve FPGA arasında AI yığını entegrasyonunu (OneROCm) ilerletiyor; yazılım geliştirme döngüsünü 6 haftaya indirerek “kullanıcının sürümü fark etmek zorunda kalmadığı bir seviye”yi hedefliyor
  • ROCm şu anda AI destekli mühendislik dönüşümüne hazırlanıyor ve açık kaynak ekosistemi ile geliştirici topluluğu merkezli büyümesini hızlandırıyor

ROCm’in gelişimi ve yazılım stratejisi

  • ROCm başlangıçta çeşitli ürün yazılımı parçalarının bir araya getirilmiş haliydi, ancak 2,5 yıllık yatırımın ardından tam teşekküllü bir yazılım platformuna dönüştü
    • Elangovan, Google Chrome ekibinin geliştirme kültürünü örnek alarak düzenli sürüm döngüsü ve istikrarlı kullanıcı deneyimi hedeflediklerini söylüyor
    • ROCm artık “sadece çalışan” bir yazılım haline geldi ve ileride 6 haftalık sürüm düzenine geçmesi planlanıyor
  • AMD, donanım odaklı bir şirketten yazılım odaklı bir şirkete dönüşüyor; bir sonraki kritik adım olarak AI destekli mühendisliği (AI-assisted engineering) görüyor

AI yığını entegrasyonu ve taşınabilirlik

  • AMD, OneROCm ile CPU, GPU, FPGA gibi farklı donanımlar arasında AI yığını entegrasyonunu hayata geçiriyor
    • Bazı bileşenler hâlâ donanıma bağımlı olsa da, tüm hızlandırma ROCm yığını üzerinden yapıldığı için taşınabilirlik (portability) korunuyor
  • Triton çerçevesinin yaygınlaşmasıyla GPU’lar arası uyumluluk sorunu hafifledi
    • Geçmişte CUDA çekirdekleri HIP çekirdeklerine dönüştürülüyordu; bugün ise Triton çekirdekleri yazılarak hem AMD hem Nvidia üzerinde çalıştırılabiliyor
    • AMD, Triton ve MLIR derleyici altyapısına aktif yatırım yapıyor; Torch.MLIR bakımını üstlenerek kodun farklı donanımlara yeniden hedeflenmesini destekliyor
  • Çıkarım müşterilerinin büyük bölümü vLLM, SGLang gibi LLM çerçevelerini kullanıyor; CUDA kodu dönüştürme talepleri azalıyor
    • Yeni bir attention algoritması ortaya çıktığında Triton tabanlı çekirdekler bir-iki gün içinde optimize edilebiliyor
    • HIPify hâlâ HPC müşterileri için sunuluyor; yeni çekirdek yazımında ise Claude AI doğrulama ve kod üretimi için kullanılıyor

Açık kaynak stratejisi

  • ROCm, ürün yazılımı hariç tüm bileşenlerini %100 açık kaynak olarak yayımlıyor
    • Açık kaynak yaklaşımı sayesinde hem geliştirici topluluğunun denetiminden geçiyor hem de AMD’den daha hızlı ilerleyen topluluk inovasyonundan yararlanabiliyor
    • Herkes derleyici, runtime ve benzeri istediği katmanda katkı verebiliyor; AMD’nin işbirliği hızına bağlı kalmak gerekmiyor
  • AMD, geliştirici topluluğunu büyütmek için aktif çaba gösteriyor; Strix Halo tabanlı dizüstü bilgisayarlarda ROCm varsayılan olarak destekleniyor
    • Instinct veri merkezi donanımıyla aynı gün Windows için ROCm güncellemeleri de yayımlanıyor

Geliştirici topluluğu ve geri bildirim kültürü

  • Elangovan, geliştiricilerle doğrudan iletişime önem veriyor ve X(Twitter) üzerinden gerçek zamanlı geri bildirim topluyor
    • “ROCm”, “ROCm sucks”, “AMD software not working” gibi anahtar kelimeleri takip ediyor ve tüm paylaşımlara bizzat yanıt veriyor
    • Sorunların çoğu eğitim ve destek eksikliğinden kaynaklanıyor; anonim geliştiricilere bile doğrudan tavsiye veriyor
  • AMD, GitHub’da ROCm ile ilgili 1.000’den fazla şikâyeti inceledi ve bunların tamamını 1 yıl içinde çözdü
    • Eski donanım desteği talepleri yoğundu; bunlar artık AMD veya topluluk tarafından bakım görüyor
    • Bu yaklaşım geliştirici güvenini yeniden tesis etti ve “AMD sorunları çözüyor” algısını güçlendirdi
  • Elangovan, MI450 GPU’ya (2026’nın ikinci yarısında çıkması planlanıyor) dair beklentisini dile getiriyor ve ROCm’i önümüzdeki 10 yıl için sürdürülebilir bir platform haline getireceklerini vurguluyor
    • Amaç, yeni donanımlar geldiğinde bile geliştiricilerin endişe etmesine gerek bırakmayan istikrarlı bir ekosistem kurmak

Gelecek yönü ve felsefe

  • Elangovan, Nod.ai dönemindeki deneyimine dayanarak derleyici teknolojisinin neredeyse tüm hızlandırıcı şirketleri tarafından benimsendiği örneğini veriyor
    • “Kararlılıkla adım adım ilerlemek gerekir” diyerek ROCm’in gelişimini sürekli uygulamanın bir sonucu olarak tanımlıyor
  • AMD, CUDA’yı yalnızca kopyalamakla yetinmeyip ROCm’e özgü farklılaştırılmış yetenekler geliştiriyor; uzun vadede geliştirici merkezli bir platform olarak konumlanmayı hedefliyor

İlgili okumalar

2 yorum

 
picopress 14 일 전

Önce sürücü tarafı biraz...
 
GN⁺ 16 일 전
Hacker News yorumları

  • Geçen hafta boyunca TheRock’ı stagex’e port ederken ROCm’u musl/mimalloc tabanlı bir araç zinciriyle derlemeyi denedim
    çünkü güvenlik ve gizliliğin kritik olduğu iş yüklerinde tek bir derleyiciyle oluşturulmuş ikili dosyalara güvenilemez
    30’dan fazla bağımlılığı ve özel bir LLVM’i paketlemek kabus gibiydi ama bu sabah sonunda çalışma zamanını derlemeyi başardım
    AMD donanımının tamamen açık bir ortamda çalışabilmesi sayesinde yüksek güvenlikli iş yükleri için umut görüyorum

    • Ben de özellikle Alpine Linux için ROCm’u musl üzerinde paketlemeye çalıştım
      özel LLVM fork’unu ve çeşitli paketleri geçtim ama sonunda bunun zaman kaybı olduğuna karar verip bıraktım
      şu anda Vulkan destekli llama.cpp kullanıyorum ve gayet memnunum
      Eğer derleme tariflerini paylaşabilirsen Alpine portunun son aşamasını geçmeme yardımcı olabilir
    • Bu durumu tekrar tekrar görmek üzücü
      Geçen yıl AMD’nin sözlerine güvenip hissedar kampanyasını durdurmuştum ama artık gerçekten harekete geçilmesi gerektiğini düşünüyorum
      unlockgpu.com/action-plan
    • sorun #3477’ye bakınca insanın içi acıyor
      Bu böyle olmamalı, bu çalışmanın açıkça kullanılabilir olması gerekiyor
    • Nvidia’ya güvenmemenizin sebebi sürücünün kapalı kaynaklı olması mı?
      Nvidia da açık kaynak sürücülerini iyileştirme sözü verdi
      Bana kalırsa Intel’in 32 GB VRAM’i 1000 dolar seviyesinde sunması daha cazip
    • “Tek bir derleyiciyle oluşturulmuş ikili dosyalara güvenilemez” sözü ilginç
      Farklı derleyicilerden gelen .o dosyalarını karıştırıp bağlamaktan mı bahsediyorsunuz?
      Yoksa gerçekten Reflections on Trusting Trust sorunundan kaçınmaya çalışan iş yükleri mi söz konusu, merak ettim

  • Şubattan beri AMD’den gfx1201 için ayarlanmış Tensile çekirdeklerini rcom-libs’e dahil etmesini istiyorum ama bununla kimin ilgilendiğini bilen yok
    Geliştirici Discord’unda da yanıt alamadım. Teknik sorunların ötesinde AMD’nin kurumsal darboğazlarını gösteren bir örnek gibi duruyor

  • AMD’nin ROCm konusunda hâlâ kapatması gereken yıllara yayılan bir fark var
    Yapay zeka işlemleri yapabilen kendi GPU’larının bile tamamını desteklemiyor, desteklediklerinde de çok fazla hata çıkıyor
    Linux için AMDGPU sürücüsü 6.6’dan beri sürekli kararsız

    • Yetenekli insan bulamamalarının sebebi basit. Dünyanın en iyi şirketleriyle yetenek rekabetine girmek zorundalar ama AMD bundan sadece 10 yıl önce bile varoluşsal kriz yaşıyordu
    • Sonuçta mesele yeterince maaş vermemeleri değil mi
    • ROCm’u çok uzun süre ihmal ettiler. 5 yıl önce arkadaşlarım içeride yatırımı artırmaları için bastırdı ama başarısız oldular
      Yapay zekanın önemli hale geleceğini görememeleri bariz bir hataydı
      AMD rekabetçi olursa tüm sektör kazanırdı ama bunu kendi kendilerine yaptılar
    • Bu kültürel bir sorun da olabilir
      Eski ATI günlerinden beri hatalarla dolu sürücüler yüzünden kötü bir şöhreti vardı ve AMD satın aldıktan sonra bile bu kültür değişmemiş gibi görünüyor

  • Geçen yıl AMD GitHub’da ROCm’la ilgili şikayetleri toplamış ve 1000 başlığın hepsini çözdüğünü açıklamıştı
    Ama gerçekte eski donanım desteği neredeyse hiç artmadı

    • Çeşitli vikileri kurcalayıp kart desteğini elle hacklemek gerekiyorsa buna “destek eklendi” denebilir mi, emin değilim

  • ROCm’un tüm AMD kartlarda çıktığı gün desteklendiği zamanı gördüğümde ancak o zaman pazarlamaya inanırım
    Eskiden 400 serisi gibi yeni kartları bile terk etmeleri büyük bir hataydı
    Umarım yönetim yazılım yığınına daha fazla yatırım yapar

    • CUDA da kusursuz değil. Örneğin GB10 piyasaya çıkalı epey oldu ama hâlâ uygulanmamış özellikler var

  • ROCm, RX 580 gibi genel tüketici GPU’larında desteklenmiyor
    Onun yerine Vulkan arka ucu gayet iyi çalışıyor

    • 2018’de bir RX 580 aldım, ama RDNA1 ve RDNA2 GPU’lara desteğin zayıf olması hayal kırıklığı yaratıyor
      GCN mimarisinin artık desteğinin kesilmesini normal karşılıyorum ama RDNA neslinde bile yetersiz destek sorun olmaya devam ediyor
    • ROCm genelde yalnızca iki nesil GPU’yu destekliyor
      Şu anda sadece RDNA3 ve RDNA4 mümkün, CUDA ise hâlâ Turing’e kadar destek veriyor
      resmi belgeler
    • RX 5700 kullanıyorum ve desteklenen ROCm sürümü o kadar eski ki Ollama çalıştıramıyorum
      Vulkan arka ucu iyi işliyor ama resmi desteğin gelmesi 1-2 yıl sürdü
    • Vulkan iyi çalışıyor ama C++/Fortran/Python JIT çekirdekleri, IDE entegrasyonu, hata ayıklama ve kütüphane desteği eksik
    • Eskiden RX580 ile ROCm kullandığımı sanıyordum, şimdi destek sonlandırıldı mı?

  • ROCm yığınını biraz temizlemelerini isterdim
    Basitçe git clone --recurse-submodules rocm deyip ardından configure/make ile derlenebilmeli ve eksik bağımlılıkları açıkça göstermeli
    Şu anda ortada bir yapı olmadan çeşitli bileşenler gelişigüzel atılmış gibi; tutarlı bir mimari görünmüyor

  • Ben OpenVINO ve SYCL ile CUDA’ya karşı duran ekipteyim
    Intel’in iGPU ve dGPU’ları son dönemde hem makul fiyatlı hem de yazılım desteği açısından daha iyi hale geldi
    Oyun için değil ama CV veya veri bilimi iş yüklerinde oldukça iyi ölçekleniyorlar

  • AMD yönetimine iletmek istediğim ROCm geri bildirimi şu
    (1) Yalnızca sunucu sınıfı GPU’ları destekleyip tüketici GPU/APU’larını görmezden gelmek stratejik bir hataydı
    Geliştiricilerin çoğu önce kişisel dizüstü bilgisayarlarında deneme yapıp sonra sunucuya ölçekleniyor
    CUDA gibi, performans düşük olsa bile tüketici GPU’larında çalışması gerekir
    (2) Yalnızca iki nesli destekleme politikası müşteri açısından mantıksız
    resmi belgeler
    CUDA güçlü bir geriye dönük uyumluluk sağlıyor
    (3) Sadece Triton’a odaklanıp HIP’e ikinci sınıf muamelesi yapmak yanlış bir yönelim
    Hâlâ çok sayıda C/C++ tabanlı HPC, simülasyon ve bilimsel kod var
    AMD GPU’larının güçlü yanı FP64 performansı ama bunu kendi elleriyle çöpe atıyorlar
    (4) Son olarak paketleme kalitesini artırmaları gerekiyor
    Dağıtım paketleyicileriyle iş birliği yapmak büyük maliyet gerektirmez ve Nvidia’ya karşı rekabet avantajı sağlayabilir

    • CUDA’nın gücü çok dilli destek
      Python, Julia ve başka dillerde çekirdekleri doğrudan yazabiliyorsunuz; IDE, hata ayıklayıcı ve kütüphane entegrasyonu da çok iyi
      GPGPU ekosisteminin geneline bakınca AMD ve Intel hâlâ CUDA’nın ekosistem olgunluğuna yetişemedi
    • Paketleme aslında kolay bir iş değil
      Çoğu şirket /opt/foo/ gibi üretici kurulum yöntemlerini seçiyor
      Böyle olunca dağıtımların sonradan kendi paketlerini hazırlaması da kolaylaşıyor
      Ama bunu anlamak için açık kaynak ekosisteminde deneyimli insanlara ihtiyaç var
    • NVIDIA da benzer hatalar yapıyor
      Yüksek VRAM’li tüketici GPU’larını geç çıkarıp sunucu pazarına odaklanıyor
      AMD bu boşluğu iyi değerlendirirse fırsata çevirebilir
    • Aslında ROCm resmi olarak desteklenmese bile gayriresmî olarak çalışıyor
      Örneğin 7900 XT’de sorunsuz çalışıyor
      Sadece AMD test kaynağı ayırmadığı için “resmi destek” diye işaretlemiyor

  • Eskiden compute shader ile uğraşmış biri olarak CUDA, ROCm ve OpenCV’nin kurulumunun aşırı zahmetli olduğunu düşünüyorum
    Bağımlılıkları da büyük, CUDA tek başına 11 GB
    Bence doğrudan Vulkan kullanmak daha iyi. Platforma bağımlı değil ve “sadece çalışıyor”

    • Vulkan’ı kurmak kolay ama kodu karmaşık
      Yalnızca shader derleme ve kaynak ayarlama bile yüzlerce satır gerektiriyor, GPU adresleriyle uğraşmak içinse eklentiler lazım
    • Windows’ta 3 GB’lık bir exe kuruyorsunuz, Linux’ta ise depo ekleyip kuruyorsunuz
      Bunun saatler süren bir iş olması garip geliyor
    • Vulkan düşük seviyeli bir API, bu yüzden basit işler bile 200 satırdan fazla kod istiyor
      Eskiden NVIDIA’da grafik moduna geçince performansın %20 artması gibi bir hata(?) bile vardı