3 puan yazan GN⁺ 2024-03-06 | 1 yorum | WhatsApp'ta paylaş
  • ZLUDA 3, CUDA’ya bağlı kalmış NVIDIA GPU uygulamalarını AMD GPU’larda değişiklik yapmadan çalıştırmayı amaçlayan açık kaynak bir teknoloji
  • Intel GPU’lar için CUDA’nın alternatif bir uygulaması olarak başlamıştı; ancak Intel ve AMD’nin değerlendirmeleri durdurmasının ardından bu kez AMD GPU hedefli kod yayımlandı
  • Blender’da yerel HIP arka ucuyla benzer performans örnekleri olsa da 3DF Zephyr ve RealityCapture, ZLUDA’da “much slower” olarak işaretleniyor; uygulamaya göre farklar büyük
  • RealityCapture ve Arnold gibi NVIDIA’ya özel CG uygulamalarını çalıştırma olasılığı doğrulandı; ancak OptiX desteği Linux’ta asgari düzeyde kaldığından render iş akışlarında kısıtlamalar var
  • Intel ve AMD desteği olmadan proje “realistically now abandoned” durumuna yakın; NVIDIA SDK lisansı da NVIDIA dışı platformlara yönelik dönüştürme katmanlarının geliştirilmesini kısıtlıyor

ZLUDA 3’ün çözmeye çalıştığı CUDA bağımlılığı sorunu

  • ZLUDA 3, NVIDIA GPU’lar için yapılmış GPU tabanlı uygulamaları başka üreticilerin donanımlarında çalıştırmayı sağlayan açık kaynak bir proje
  • Mevcut uygulamaları değişiklik yapmadan yeni donanımda çalıştırmak üzere tasarlandığı için uygulama geliştiricilerinden ek portlama işi gerektirmiyor
  • ZLUDA ilk olarak 2020’de Intel GPU’lar için CUDA’nın drop-in alternatif uygulaması olarak yayımlandı; 2021’deki sürüm 2’den sonra geliştirmeyi sürdürmek zorlaştı
  • Andrzej Janik’in Intel’de çalıştığı 2021’de Intel, ZLUDA’yı resmi bir teknoloji adayı olarak değerlendirdi; ancak “Intel GPU’larda CUDA uygulamalarını çalıştırmak için bir iş gerekçesi yok” sonucuna vardı
  • Janik, 2022’de Intel’den ayrıldıktan sonra AMD’ye başvurdu; AMD de ZLUDA’yı 2 yıl boyunca değerlendirdi ancak devam etmeme kararı aldı
  • Daha sonra güncellenmiş kod açık kaynak olarak yayımlandı; ilgili arka plan Phoronix makalesinde daha ayrıntılı görülebilir

CG uygulamalarında doğrulanan çalışma kapsamı

  • ZLUDA 3, NVIDIA’nın CUDA API’siyle geliştirilmiş GPU uygulamalarını AMD GPU’larda çalıştırmayı hedefliyor
  • VFX, motion graphics ve görselleştirme alanlarında bazı temel CG uygulamaları ve renderer’lar CUDA tabanlı olduğu için fiilen NVIDIA’ya özel kalmış olabiliyor
  • AMD’nin HIP teknolojisi, CUDA uygulamalarını AMD donanımına portlamak için kullanılıyor; ancak yazılım geliştiricisinin çalışmasını gerektiriyor
    • HIP, Redshift ve Blender Cycles için AMD uyumlu sürümlerde kullanılıyor
    • ZLUDA 3 de HIP temelinde yapılmış olsa da hedefi mevcut CUDA uygulamalarının değişiklik yapılmadan çalıştırılması
  • Janik’in ZLUDA ile test ettiği NVIDIA’ya özel yazılımlar arasında 3DF Zephyr, RealityCapture ve Autodesk Arnold yer alıyor
  • Arnold desteği kavram kanıtı düzeyinde; ZLUDA’nın OptiX uygulamasıyla başarıyla render edilen sahneler sınırlı

Performans ve uyumluluğun pratik sınırları

  • Janik, CUDA uygulamalarının AMD GPU’larda “near-native performance” ile çalıştığını değerlendiriyor
  • Phoronix benchmark’larına ve Blender Artists forumundaki başlığa göre Blender’da ZLUDA performansının yerel HIP arka ucuna benzer olduğu örnekler var
  • Buna karşılık ZLUDA GitHub deposu, 3DF Zephyr ve RealityCapture’ı ZLUDA’da much slower olarak işaretliyor
  • Birçok GPU renderer, ray tracing hızlandırması için CUDA’nın yanında NVIDIA OptiX de kullanıyor
    • ZLUDA’nın OptiX desteği “minimum” düzeyinde
    • OptiX desteği yalnızca Linux’ta var, Windows’ta yok
    • Uygulama durumu “buggy, unoptimized and incomplete”
    • ZLUDA-OptiX yeniden dağıtılan sürüme dahil değil; doğrudan derlemek gerekiyor
  • Diğer CUDA tabanlı CG uygulamalarının çalışıp çalışmayacağını kullanıcı testleri olmadan değerlendirmek zor

Projenin sürdürülebilirliği ve lisans kısıtları

  • Janik, Intel veya AMD desteği olmadığında ZLUDA’nın “realistically now abandoned” durumda olduğunu düşünüyor
    • Projeyi ilerletecek tekliflere açık
    • Aksi halde DLSS gibi kişisel olarak ilgi duyduğu NVIDIA teknolojileri için destek ekleme olasılığı daha yüksek
    • Mevcut kod da CUDA’dan HIP’ye kademeli portlama yapan yazılım geliştiriciler için kullanılabilir
  • 14 Mart 2024 tarihli güncellemeye göre Tom’s Hardware, NVIDIA SDK lisans koşullarının CUDA Toolkit dahil SDK çıktılarının NVIDIA dışı platformlara yönelik dönüştürme teknolojileri geliştirmek için kullanılmasını yasakladığına dikkat çekiyor
  • ZLUDA 3’ün derlenmiş sürümleri Windows ve Linux için sunuluyor; kaynak kodu Apache 2.0 veya MIT license ile sağlanıyor
  • ZLUDA 3 indirme, projenin GitHub deposundan yapılabiliyor

1 yorum

 
GN⁺ 2024-03-06
Hacker News yorumları
  • 22 gün önce de bununla ilgili bir tartışma vardı: AMD’nin ROCm tabanlı bir CUDA drop-in uygulamasını finanse ettiği ve sonrasında bunun açık kaynak olarak yayımlandığı yazıya [0] 400 yorum gelmişti
    O başlıktaki dikkat çekici en üst düzey yorum, yayımlanmanın aslında AMD’nin finansmanı kesmesinin sonucu olduğunu söylüyordu: “2 yıllık geliştirme ve değerlendirmeden sonra AMD, CUDA uygulamalarını AMD GPU’larında çalıştırmanın ticari olarak anlamlı olmadığına karar verdi. AMD ile sözleşmemin koşullarından biri, AMD’nin daha fazla geliştirme için uygun olmadığına karar vermesi halinde bunu yayımlayabilmemdi. Böylece bugünlere geldik.” Kaynak: https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq
    [0] https://news.ycombinator.com/item?id=39344815

  • AMD’nin bu projeye verdiği finansmanı kesmesi gerçekten saçma. Çünkü açık kaynak olarak yayımlanır yayımlanmaz AMD kullanıcıları için değer üretmeye başladı
    Böyle bir şey AMD’nin en öncelikli işi olmalıymış gibi görünüyor; ama onlar birkaç yıl boyunca desteği de zayıf olan iki, şimdi üç mü oldu, alternatif API’nin peşinde bocalayıp durdular

    • Bu güvenilir bir seçenek hâline geldiği anda Nvidia hemen bir durdurma emri gönderip dava açacaktır. Ciddi bir çözüm olarak çıkmaz sokak, o bağlamda anlaşılabilir
    • İnsanların HIP kullanmasını istedikleri için de olabilir
      “HIP çok incedir; doğrudan CUDA modunda kodlamaya kıyasla performans etkisi yok denecek kadar azdır ya da hiç yoktur”
      “HIPIFY aracı CUDA kaynaklarını otomatik olarak HIP’e dönüştürür”
      1. https://github.com/ROCm/HIP
    • Stratejik düşününce bunun AMD için en iyisi olduğunu söylemek zor. Ürün seviyesinde ve hukuken doğrulanmış bir şey değilse, geliştiricilerin uygulamayı AMD’de yapıp dağıtımı Nvidia’da yapmasına yarayan bir araçtan ibaret olur
      Tüketici ekran kartları tarafında kısa vadeli kazanç sağlayabilir ama uzun vadede veri merkezlerinde Nvidia’nın konumunu pekiştiren bir kendi kalesine gol gibi
    • NVIDIA duyurusuyla ilgili önceden bilgi alıp bu yükleniciyi serbest bırakmış olmaları kuvvetle muhtemel. Sözleşme şartları gereği proje açık kaynak olacaktı
    • Burada AMD’nin vazgeçmeyi seçtiği varsayımı var. Belki de daha iyi bir şey geliştiriyorlardır, olamaz mı?
  • Bu tartışmayla “Nvidia’nın CUDA yazılımını başka çiplerde çalıştırmak için çeviri katmanları kullanımını yasakladığı” yazı da ilgili görünüyor [1]


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

    • Nvidia donanımı kullanmıyorsanız, Nvidia sürücüsü kullanmıyorsanız ve Nvidia’nın EULA’sını hiç kabul etmediyseniz neden umursamanız gerektiğini anlamıyorum
      Emülasyon hem açıkça hem de içtihatla hukuki koruma altında. Uyumluluk amacıyla API kopyalama ABD Yüksek Mahkemesi’ne kadar gitti ve telif hakkına konu olmadığına karar verildi. En azından epey geniş bir kapsamda böyle olduğunu düşünüyorum
      Avukat değilim ama Nvidia’nın hangi hukuki zemine güvenmeyi umduğunu pek göremiyorum. Hiç Nvidia donanımı olmayan bir kişi ya da şirket için anlamsız bir mesele gibi geliyor. Zaten Nvidia donanımı olan bir şirketse bir ölçüde iddia ileri sürebilirler, ama bu da doğrudan rekabet karşıtı davranış alanına girmiyor mu?
    • Bunun Wine/Proton’dan farkı ne, bilmiyorum. Microsoft EULA’sında da benzer bir şart olmalı; uygulanabilir olsaydı Microsoft Wine geliştiricilerine aynı şekilde durdurma emri göndermez miydi?
    • Söz konusu hükmün, makaledeki iddianın aksine Ocak 2022’den beri CUDA EULA’sında bulunduğunu ve makaledeki güncellemenin aksine indirmeye de dahil edildiğini yeniden vurgulamak gerekiyor
    • Bunun bir anlamı var mı? Başka sistemlerle uyumlu arayüze sahip bir sistem uygulamak için kimseden izin almak gerekmez
      EULA’yı ihlal eder, ama CUDA yazılımını indirmediğiniz sürece EULA’yı kabul etmeniz de gerekmez; ZLUDA yazarları muhtemelen bundan kaçınabilmiştir
    • NVIDIA’nın bunu yapmaya hakkı yok. Burada NVIDIA SDK devreye girmiyor
  • “Intel de sonunda ‘Intel GPU’larında CUDA uygulamalarını çalıştırmanın ticari olarak anlamlı olmadığına’ karar verdi” denmesi gerçekten can sıkıcı

    • Kısacası, belirli bir ölçeğe ve yaşa ulaşan her şirket rakip olmayı hayal etmekten çok tekelci olmayı hayal etmeye başlıyor
    • Intel’in grafik bölümü o kadar kötüydü ki insanların zihninde bıraktığı kötü izlenim yüzünden Intel HD adını kullanmayı bırakmak zorunda kaldılar
  • AMD GPGPU’ya bir kez bile dokunmuş olan herkesin bildiği bir gerçek doğrulanmış oldu. AMD’nin 2 trilyon dolarlık şirket olmasını engelleyen tek şey gerçekten berbat yazılımı
    AMD’nin OpenCL derleyicisinde bir hata bulduğumu hatırlıyorum [1]; OpenCL derleyicisini segmentation fault ile çökertmek de çok kolaydı. Bu hata asla düzeltilmediği için bildirmeyi bıraktım
    AMD’nin bir CUDA rakibi geliştirmemiş olması, gördüğüm en kısa görüşlü kararlardan biri. En iyi donanımı yapsanız bile, onu kullanan yazılım kibarca söylemek gerekirse berbatsa kimsenin satın almayacağını ya da kullanmayacağını anlayan kişilerle yönetim kurulunun neden değiştirilmediğini bilmiyorum
    Müşteriler olarak biz, AMD yönetim kurulunun masada bıraktığı yaklaşık 1 trilyon dolarlık değeri umursamayacak kadar zengin olduğu için pahalı Nvidia kartları almak zorundayız. AMD hissesi olan biriyseniz soru sormalısınız. O yönetim kurulu en yakın gidere doğru akıp gitmeli
    [1] https://github.com/msoos/amdmiscompile -- sonunda bu düzeltildi

    • JavaScript’e anlatır gibi GPGPU’nun ne olduğunu açıklayabilir misin?
      Benim saf anlayışıma göre ekran kartı, komutları ve verileri yükleyip kendi başına hesap yapmasını sağlayabildiğin tuhaf bir bilgisayar
      CUDA’nın neden bu kadar büyük mesele olduğunu bilmiyorum. AMD kendi GPU’suna 4096 Arduino kartlık bir dizi gibi doğrudan erişmemize izin veremez mi?
    • Doğru. Öte yandan AMD genel olarak Nvidia’dan daha açık kaynak dostu. Nvidia bir süre aktif biçimde düşmancaydı; Linus’un “F* you!” videosuna bakmak yeterli
      Donanım geliştiren şirketler genelde yazılımda iyi değildir. İstisnalar var ama çok değil; o şirketler de bunun karşılığını gerçekten hisse fiyatlarıyla aldı. AMD’nin yazılım birimi kültürünü bilmiyorum ama genelde böyle bir şeyi düzeltmek epey büyük bir değişim gerektirir
      Sadece yönetim kurulunu değiştirmekle çözülmesi zor olur. Şirketi aşağı çeken tek etken üst yönetimin talimatları değilse, çok daha fazla yönetim kademesini değiştirmek ve epey sayıda orta kademe yöneticiyi de yenilemek gerekir. Yazılım işe alımları düzgün yapılmadıysa bireysel katkı sağlayanlara kadar değişiklik gerekebildiği zamanlar da olur
    • AMD’nin Intel ile iş birliği yapıp SYCL’i standart GPGPU ve heterojen programlama yöntemi olarak neden öne çıkarmadığını anlamıyorum
      Intel yazılımda iyi, SYCL açık bir standart; bu yüzden iki şirket de aynı koddan faydalanabilir ve müşteriler isterse Threadripper üzerinde de SYCL kodu çalıştırabilir. Günümüzde bazı Threadripper’lar bazı GPU’lar kadar hızlı bile olabiliyor
      AMD kendi özel kilitleme ekosistemini mi kurmaya çalışıyor? Neden çapraz platform açık standarda bağlı kalmadığını anlamıyorum
    • AMD Software’in kendisini ben epey sevmiştim. Oyunlar veya yazılımlar yerel olarak desteklemediğinde GPU’nun sonuna kadar çalışmasını önlemek için kare hızını 60 ile sınırlamak kolaydı; Shadowplay gibi son birkaç dakikayı sürekli kaydeden anında tekrar özelliğini de bir kısayola atayabiliyordum
      UPS iyi değilken GPU güç sınırı koymak da mümkündü; RX 580’i yaklaşık bir yıl daha kullanabilmek için otomatik overclock da yapabiliyordum
      Ancak 2020 civarından sonraki yazılım/sürücüler VR oyunlarını bir saat dolmadan çökertiyor. Linux için yazılım paketi de yok ve CoreCtrl o kadar iyi değil. Anında tekrar bazen hiç çalışmıyor. Hem Windows hem Linux’ta yerel LLM’e ROCm’i bir kez bile düzgün bağlayamadım; DKMS de her apt upgrade sırasında bir sürü gereksiz derleme yapmayı seviyor
      Bir sonraki GPU olarak meraktan Intel Arc’a mı geçsem, yoksa doğrudan Nvidia’ya mı dönsem diye düşünüyorum. Adaylar A580, RX 6600, RTX 3050 civarında; diğer parça fiyatları düşene kadar dayanabilirim de
  • Metal, CUDA ve AMD tarafındaki bir şeyler gibi çeşitli kernel dillerine derlenen bir programlama dili var mı? Yoksa neden yok?
    C derleyicisi çeşitli CPU mimarilerine derleme yapıyor. GPU mimarilerine giden bir derleyici de olması gerekmez mi? Belki de henüz kimse yapmamıştır

    • OpenCL’i de buna dahil sayabilir miyiz?
      https://www.khronos.org/api/opencl
    • OpenMP 5 GPU desteğini açıkça belirtti. Üstünkörü arayınca bazı derleyicilerin artık en azından kısmen desteklediği anlaşılıyor
  • Meshroom gibi açık kaynak fotogrametri araçları çalıştırmak için bunu deneyen oldu mu? Makalede birkaç kapalı kaynak araçtan bahsediliyor ama benim ihtiyacım epey küçük

  • Bu, JVM bytecode kullanımı etrafındaki Oracle - Google davasına neredeyse tamamen benziyor

    • Bana öyle görünmüyor. Mesele bytecode dönüşümü değil, daha yüksek seviyedeki kütüphane fikri mülkiyetini donanıma bağlamak
      Bu, Google’ın “Android uygulamalarımız yalnızca Google’ın onayladığı telefonlarda çalışabilir” demesine benziyor. Anladığım kadarıyla Google, Play framework’ü veya Maps gibi şeyler için bunu gerçekten yapıyor
  • Yakın zamanda ilginç bir söylenti duydum: NVIDIA’da CUDA’dan sorumlu kişi, yıllarca kaynak bulmak ve şirketi bu projeyi ciddiye almaya ikna etmek için mücadele etmiş
    CUDA olmasaydı NVIDIA’nın bugün neredeyse 1 trilyon dolarlık bir şirket olması kesinlikle mümkün olmazdı

  • geohot’un pahalı AMD GPU ile sürekli boğuşması da bununla ilgili: https://twitter.com/tinygrad/status/1764734675002810622