Rust'ı tüm GPU'larda çalıştırmayı başardılar

 (rust-gpu.github.io)
10 puan yazan GN⁺ 2025-07-27 | 1 yorum | WhatsApp'ta paylaş
  • Rust ile yazılmış tek bir kod tabanının CUDA, Vulkan(SPIR-V), Metal, DirectX 12, WebGPU, CPU dahil tüm başlıca GPU ve CPU platformlarında çalıştığını gösteren bir demo proje yayımlandı
  • Mevcut GPU programlama, GLSL, HLSL gibi ayrı diller kullanılması nedeniyle karmaşıklık ve tekrar sorunları yaratırken bu demo, yalnızca saf Rust koduyla tüm GPU hedeflerini destekliyor
  • Başlıca bileşenler olarak Rust GPU(SPIR-V), Rust CUDA(NVVM IR), Naga(GPU dil dönüştürme katmanı) projeleri bir araya getirildi; aynı bitonic sort algoritması CPU ve tüm GPU'larda çalışıyor ve Rust'ın no_std, koşullu derleme, newtype, enum, trait gibi dil özellikleri GPU kodunda da aynen uygulanabiliyor
  • Resmî rustc entegrasyonu, hata ayıklama, API tutarlılığı gibi iyileştirilmesi gereken konular hâlâ bulunsa da bu girişim, GPU çapraz platform hesaplama için bir dönüm noktası niteliğinde

Rust tabanlı GPU çapraz platform hesaplamanın gerçeğe dönüşmesi

Proje tanıtımı ve önemi

  • Tek bir Rust kod tabanı ile CUDA(NVIDIA), Vulkan(SPIR-V), Metal(Apple), DirectX 12(Windows), WebGPU(tarayıcı), CPU gibi ortamlarda aynı kernel kodu çalıştırılabiliyor
  • Shader veya kernel'e özel diller(GLSL, HLSL vb.) kullanmadan, saf Rust koduyla GPU ve CPU üzerinde aynı işlemleri yürütmek mümkün
  • Bu yaklaşım GPU ve CPU arasındaki kod tekrarını ve karmaşıklığı büyük ölçüde azaltıyor; ayrıca Rust ekosisteminin araç ve dil avantajlarını(tip güvenliği, test, dokümantasyon, build yönetimi vb.) GPU programlamaya da taşıyor

Arka plan

  • Geleneksel GPU programlama, her platform için özelleşmiş shader dillerinin(örn: GLSL, HLSL, MSL, WGSL vb.) kullanılmasını zorunlu kılıyor
  • Bunun sonucu olarak CPU ve GPU kodu ayrışıyor; mantık tekrarı ve geliştirme karmaşıklığı artıyor
  • Rust topluluğu buna yanıt olarak genel amaçlı Rust'ı GPU hedefi için derleme yaklaşımını izliyor
    • Rust GPU: Rust kodunu SPIR-V'ye derler; Vulkan ve SPIR-V uyumlu GPU'larda çalışır
    • Rust CUDA: Rust kodunu NVIDIA CUDA için IR'ye (NVVM IR, PTX) derler; CUDA'da çalışır
    • Naga: Çeşitli GPU dilleri(WGSL, SPIR-V, GLSL, MSL, HLSL) arasında dönüşüm sağlayan bir ara katman(çoğunlukla wgpu projesinde kullanılır). Backend taşınabilirliğinden sorumludur
  • Her proje bağımsız başladığı için API ve yapı farklıydı; ancak son dönemdeki iş birliği sayesinde ortak bir kod tabanının GPU üzerinde çalıştırılması mümkün oldu

Uygulama yöntemi

  • Örnek demoda bitonic sort algoritması tek bir Rust koduyla implemente ediliyor ve aynı kod GPU ile CPU'nun tüm hedeflerinde çalışıyor
  • Başlıca bileşen terimleri
    • Host: CPU üzerinde çalışan Rust kodu(işi başlatır)
    • Device: Kernel'in fiilen çalıştığı GPU/CPU
    • Driver API: CUDA, Vulkan, Metal, DX12 vb.; aygıtla iletişim için düşük seviyeli API
    • Backend: Rust tarafında driver API'leri için soyutlama sağlar(cust, ash, wgpu vb.)
  • Rust'ın feature flag'leri ve hedef kombinasyonları üzerinden backend seçimi ve build kontrolü yapılabiliyor
    • Örn: wgpu, ash, cuda gibi her backend için bağımsız build seçenekleri sunuluyor
    • Birden çok backend'i tek bir binary içinde derleyip çalışma anında dinamik olarak seçen bir yapı kurmak da mümkün

Kernel derleme akışı

  • Hedefe ve feature'lara göre GPU çalıştırma binary'leri(SPIR-V, PTX vb.) build sırasında üretilip nesne dosyasına gömülüyor
  • Çalışma anında gömülü kernel yükleniyor, Naga vb. aracılığıyla platformun istediği formata dönüştürülüyor ve ardından çalıştırılıyor
  • Örnekler:
    • macOS: SPIR-V, MSL'ye dönüştürülür → Metal üzerinde çalıştırılır
    • Windows: SPIR-V, HLSL'ye dönüştürülür → DX12 üzerinde çalıştırılır
    • Linux/Android: SPIR-V → Vulkan üzerinde çalıştırılır
    • CUDA: PTX, SASS'a derlenir; GPU'ya yüklenip çalıştırılır

Rust dostu GPU kodlama teknikleri

  • no_std desteği

    • GPU'da işletim sistemi desteği olmadığından Rust'ın no_std kullanımı zorunludur
    • Rust ekosisteminin gömülü sistemler, firmware ve kernel gibi işletim sistemi olmayan ortamları zaten temel olarak desteklemesi sayesinde GPU'lar da ayrı bir "özel mod" olmadan standart Rust yaklaşımıyla desteklenebiliyor

  • Koşullu derleme

    • cfg öznitelikleri ve feature flag kombinasyonlarıyla platforma özel kod ile GPU/CPU ayrımını yapan kodlar açık ve kısa biçimde yazılabiliyor
    • IDE ve derleyici tüm kod yollarını anlayabildiği için yüksek kod güvenilirliği ve üretkenlik sağlanıyor

  • newtype kullanımı

    • GPU tarafında yapılabilecek örtük indeks ve struct eşleme hataları, newtype ile tip seviyesinde önlenebiliyor
    • #[repr(transparent)] özniteliği sayesinde pratikte ek yük oluşturmadan tip soyutlaması sağlanabiliyor

  • Enum ve güvenli gösterim

    • Magic number yerine Rust enum'ları kullanılıyor; #[repr(u32)] ile yerel tamsayı eşlemesi sağlanıyor
    • Pattern matching ve exhaustiveness(tüm olası durumların ele alınması) sayesinde daha güvenli kod kurulabiliyor
    • Ancak CPU ile GPU arasında paylaşılan buffer'larda enum değerleri aktarılırken tüm değerlerin geçerli enum olması gerektiği için dikkat gerekiyor

  • Trait tabanlı jenerik algoritmalar

    • trait kullanılarak farklı değer tipleri için ortak karşılaştırma, dönüştürme ve işlem gibi GPU operasyonları soyutlanabiliyor
    • Jenerik algoritmalarda trait bound'ların açıkça belirtilmesiyle tip güvenliği ve optimizasyon birlikte sağlanabiliyor

  • #[inline] ve performans optimizasyonu

    • #[inline] kullanımıyla soyutlama katmanlarının gerçek derleme sonucunda ortadan kalkması teşvik ediliyor
    • GPU'nun doğası(performance, sınırlı stack vb.) gereği soyutlamanın maliyetsiz olması hedefleniyor

  • Struct bileşimi ve anlamsal gruplama

    • Karmaşık GPU parametreleri anlamlı birimler hâlinde struct içinde toplanarak tip güvenliği sağlanıyor ve parametre patlaması önleniyor
    • Smart constructor deseni ile geçersiz durumlar derleme aşamasında engellenebiliyor

  • Bellek yerleşimi ve #[repr(C)] kontrolü

    • GPU ile veri uyumluluğu için #[repr(C)] kullanılarak struct yerleşimi açıkça belirleniyor
    • İleride GPU'ya özgü padding işlemlerinin otomatikleştirilmesi gibi ek dil desteğine ihtiyaç olduğu da belirtiliyor

  • Pattern matching

    • switch/case kavramının genişletilmiş bir biçimi olarak GPU kodundaki tüm dallanmalar ve durumlar açıkça ele alınabiliyor
    • Derleyici tarafından kod yolları kontrol edilebiliyor ve performans optimizasyonu yapılabiliyor

  • Jenerik fonksiyonlar

    • Veri tipinden bağımsız olarak farklı tipler için aynı mantık uygulanabiliyor
    • trait bound, monomorphization vb. sayesinde bakım kolaylığı ve test edilebilirlik güçleniyor

  • Derive makroları

    • Copy, Clone, Debug, PartialEq, Pod gibi GPU'ya uygun trait'ler otomatik uygulanabiliyor
    • Güvenlik artıyor ve boilerplate kod azalıyor

  • Modül sistemi, workspace yönetimi

    • Rust'ın paket/modül sistemiyle host kodu, kernel, tipler ve backend'e göre kaynak yapısı düzenlenebiliyor
    • Cargo workspace ve workspace dependency kullanımıyla crate'ler arası bağımlılık tutarlılığı ve bakım kolaylığı sağlanıyor

  • Formatting, lint ve dokümantasyon

    • rustfmt, clippy gibi standart Rust araçlarıyla GPU kodu da tamamen aynı şekilde yönetilebiliyor ve tutarlı kalite korunabiliyor
    • Doc comment ve cargo doc ile GPU kodu da belgelenebiliyor

  • Build script'leri

    • Cargo'nun build.rs yapısı üzerinden feature flag tabanlı kernel build'i ve binary gömme süreçleri otomatikleştirilebiliyor

  • Unit test ve geliştirme üretkenliği

    • GPU kernel kodu CPU üzerinde de test edilebildiğinden geliştirme ve hata bulma kolaylaşıyor
    • println ile debug, gdb/lldb gibi geleneksel araçlar kullanılabiliyor
    • Vulkan kernel'leri yazılım sürücüleri(SwiftShader, lavapipe) ile CI ortamında da test edilebiliyor
    • Test, kod kapsama ölçümü, property-based test gibi üçüncü taraf araçlarla sorunsuz entegrasyon mümkün

Eksik kalan geliştirici deneyimi ve sorunlar

  • GPU backend'leri resmî Rust derleyicisine gömülü olmadığı için ayrı codegen backend'leri(spirv, nvvm) kullanmak ve nightly sürümüne sabitlenmek gerekiyor
  • CUDA hedefi, NVIDIA'nın LLVM 7.1 sürümüne bağımlı olduğundan yeni Linux dağıtımlarında ayrı build gerekebiliyor
  • Kernel build ve debug deneyimi henüz yetersiz; hata izleme ve debug bilgisi konusunda eksikler var
  • Rust GPU ile Rust CUDA'nın API'leri ve standart kütüphane adlandırmaları farklı olduğu için kafa karışıklığı yaratabiliyor
  • Uzun vadede Rust dili ve ekosistemi genelinde GPU odaklı daha güçlü tutarlılık ve entegrasyon gerekiyor

Topluluk katılımı ve gelecek

  • Rust ile tüm başlıca GPU platformlarında aynı kodun çalıştırılması artık mümkün hâle geldi
  • Bundan sonra build ve debug iyileştirmeleri, Rust dili ile API desteğinin genişletilmesi ve performans ayarı gibi konular öne çıkıyor
  • Katılmak ve katkı sunmak isteyen geliştiriciler rust-gpu ve rust-cuda GitHub depolarına bakabilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-27
Hacker News yorumu

  • Bu tekniğin mümkün olması gerçekten etkileyici.
    Ama benim kullanım senaryom rastgele istemci donanımında çalıştırmak olduğu için GPU API’lerinin üstüne kurulmuş tüm soyutlama katmanlarına çok güvenmiyorum.
    Amaç GPU’nun düşük seviye ayrıntılarından olabildiğince yararlanmak ve bu ayrıntıları angarya gibi gören yaklaşımlar hata ve performans kaybına yol açıyor.
    Çünkü her hedef anlamlı biçimde farklı.
    Bunu aşmak için benzer bir sistemin doğrudan üreticiler tarafından sunulması gerektiğini düşünüyorum.
    Ama üreticiler arasında hâlâ bir uzlaşı olmadığı için platformlar arasında farkların büyük olduğu görülüyor.
    Bazı durumlarda Angle gibi istisnalar var ama bunlar da ancak özellikleri kısıtlayarak kararlılık sağlıyor ve sonuçta performans kaybı yaşanıyor.
    Yine de koşullu derleme gibi yaklaşımların mümkün olması kesinlikle faydalı.

    • Rust bir sistem dili olduğu için istenen ölçüde kontrol sahibi olunabilir.
      GPU ayrıntılarını ve API’lerini dile ve core/std kütüphanelerine yansıtmayı, GPU ve sürücü özelliklerini de cfg() sistemi üzerinden açığa çıkarmayı planlıyoruz.
      (Yazarıyım)

    • Ben de tamamen aynı düşünüyorum.
      İleride yeterince destek alıp almayacağı belirsiz olan soyutlama katmanları, adaptörler ve dönüştürme katmanları üstüne ticari bir şey inşa ederken her zaman temkinli davranıyorum.
      2025 neredeyse geldi ama hâlâ tüm üreticilerin desteklediği ve en yeni GPU donanımının tüm özelliklerini kullanmayı mümkün kılan açık bir standarda büyük ihtiyaç olduğunu hissediyorum.
      Durum zaten buyken, en güçlü yazılım giriş engelini yaratan Nvidia’nın Khronos’un başında oturuyor olması da manidar geliyor.

    • Performansa çok önem veriyor gibisin, o yüzden merakımdan sormak istiyorum.
      Bana göre GPU dünyasının bugünkü hali eskiden CPU tarafının durumuna epey benziyor.
      CPU’larda üç aşamalı derleyici yapısı vardı; orta katmanda optimizasyon yapılıp son katmanda her donanıma uygun kod üretiliyordu.
      Bu yapının avantajı soyutlama katmanının uzun ömürlü olması ve derleyicinin zamanla daha akıllı hale gelmesiydi.
      GPU tarafında da böyle bir yapının mümkün olup olmadığını merak ediyorum.
      Yoksa GPU çeşitliliği bunu imkânsız ya da ekonomik olmayan bir şey mi yapıyor, ya da aslında doğal yön bu ama teknoloji henüz oraya gelmedi mi?

    • Kesinlikle doğru.
      Nvidia GPU’larda Rust çalıştırmanın mevcut CUDA koduna göre neden daha iyi olduğunu pek göremiyorum.
      Daha fazla soyutlama eklenmesini anlıyorum ama sonuçta biraz her şeyi dağınık biçimde yapmaya çalışan bir his veriyor.

    • Aslında her şey bir soyutlama.
      CUDA da sonuçta birbirinden tamamen farklı donanımları kavramsal olarak birleştiren bir soyutlama sadece.

  • Ben yerel ses uygulamaları geliştiriyorum ve burada her işlem döngüsü önemli.
    Ayrıca sadece grafik shader’ları değil, tam bir compute API gerekiyor.
    Rust -> WebGPU -> SPIR-V -> MSL -> Metal hattının performans açısından sağlam olup olmadığını merak ediyorum.
    İçinde çok fazla dönüşüm adımı var, bu yüzden kırılgan ve öngörülemez görünüyor.
    ... -> Vulkan -> MoltenVk -> ... için de aynısı geçerli.
    Buna karşılık Julia -> Metal, MSL’yi atlıyor ve Apple Silicon’a özgü optimizasyonlardan doğrudan yararlanabiliyor; örneğin Unified Memory.
    Buradaki yenilik shader dili değil, Rust gibi tam teşekküllü bir programlama dili kullanılması.
    Rust newtype, trait, macro gibi pek çok özelliği destekliyor.

    • rust-gpu kullanırken WebGPU katmanından geçmek zorunda değilsiniz.
      Çünkü rust-gpu, derleyicinin kod üretim backend’i.
      Yapı, Rust MIR’i doğrudan SPIRV’e derleyebiliyor.

    • "Rust -> WebGPU -> SPIR-V -> MSL -> Metal" hattı performans açısından sağlam mı?
      Temelde bu, Apple’ın GPU için kullandığı Clang optimizasyon yaklaşımına benzer bir fikir.
      SPIR-V, LLVM’de kullanılan IR gibi bir ara temsil olduğu için sistem bazında optimize edilebilir.
      Teoride tek bir kod tabanıyla desteklenen tüm raster GPU’lar hedeflenebilir.
      Buna karşılık Julia -> Metal yığını daha az taşınabilir.
      Ses eklentisi gibi platforma özel geliştirme yapanlar için bu önemli olmayabilir ama u-he ya da Spectrasonics gibi çapraz platform şirketleri için daha karmaşık SPIR-V tabanlı hat daha cazip olabilir.

    • Sayısal hesaplama ve sonrasındaki optimizasyonlar söz konusu olduğunda Julia, sistem dili olan Rust’tan çok daha uygun.
      Rust-CUDA’nın uyumluluk matrisine bakınca Rust’a CUDA programlama için talebin çok düşük olduğu görülüyor.
      İnsanların CUDA’da sevdiği özelliklerin çoğu eksik ve gerçekten yoğun talep olsaydı daha fazla ilerleme görürdük ama öyle olmadı.
      CUDA programcıları Rust kullanmaya pek istekli görünmüyor.
      https://github.com/Rust-GPU/Rust-CUDA/blob/main/guide/src/features.md

  • Benim gibi GPU’da çalıştırmak istediği kodu olanlar için bile GPU programlamadaki her şey o kadar acı verici ki insan sonunda hiç yapmıyor.
    rust-gpu’nun asıl kullanım alanı, bir miktar performans kaybını göze alarak CPU geliştiricilerini GPU geliştiricisine dönüştürmek olabilir.
    Zaten GPU tarafına hâkimseniz ve cuda/vulkan/metal/dx hakkında her şeyi biliyorsanız bu tür araçlar size çok cazip gelmeyebilir.

  • Ben sadece basit bir web geliştiricisiyim; belki aptalca bir soru ama GPU programlaması hiç yapmadım.
    WebGPU tüm GPU backend’leriyle uyumlu tek bir API olduğuna göre bunun bu sorunların hepsini çözmüş olması gerekmiyor mu diye merak ediyorum.
    WebGPU bunun da desteklediği backend’lerden biri gibi görünüyor; eğer öyleyse bu, mevcut soyutlamanın üstüne bir soyutlama daha koyup sonunda yine yerel GPU backend’lerini çağırmak anlamına gelmiyor mu?

    • Hayır.
      WebGPU; D3D, Vulkan, SDL GPU gibi CPU’dan GPU’yu kontrol edip shader çalıştırma gibi çeşitli grafik işleri yapmayı sağlayan bir API.
      Rust-GPU ise HLSL, GLSL, WGSL’ye benzer biçimde GPU’da gerçekten çalışan shader kodunu yazabildiğiniz bir dil.

    • Microsoft etkiliyken DirectX vardı.
      Ama bugünlerde GPU üreticilerinin kendi özgün teknolojileri için ayrı API’leri ne ölçüde uyguladığını pek bilmiyorum.
      DLSS, MFG, RTX gibi türlü benzersiz özellikler var.
      Eğer bir çizgi film kötüsü olsaydınız, mevcut API’leri bilerek yavaşlatıp yeni ve daha hızlı üreticiye özel API’leri hızlı hale getirebilirdiniz.
      Bu arada ben de web geliştiricisiyim, çok bilmiyorum ama en azından LLM’ler böyle şeyleri öğrenmiş oluyor.

    • WebGPU’yu en düşük ortak payda API’si gibi görmek daha doğru.
      Örneğin Zed editörü Mac sürümünde doğrudan Metal’i hedefliyor.
      Ayrıca “ortak”ın ne anlama geldiği konusunda da herkesin fikri farklı.
      OpenGL ve Vulkan örneğinde olduğu gibi, güçlü şirketler CUDA, Metal, DirectX gibi kendi ekosistemlerini pazar standardı haline getirmeye çalışıyor.

    • Gerçekten bu kadar kolay olsaydı CUDA bugün Nvidia’nın bu kadar güçlü hendeği olmazdı.

    • Bu proje için wgpu-rs WebGPU uygulamasına verilen emek önemli bir temel oluşturuyor.
      WebGPU yerel uygulamalar için ideal değil.
      Vulkan’ın eski sürümleri temel alınarak, özellikle de pre-RTX dönemi düşünülerek tasarlandığı için, sonradan gelişen gerçek yerel API’ler çok daha ileri bir noktaya geldi.

  • Şimdilik hâlâ kaba saba ama bunun mümkün olması gerçekten inanılmaz.
    Bu gelişim böyle devam ederse GPU yazılımındaki sert üretici bağımlılığını kırıp donanım üreticileri arasında gerçek rekabeti mümkün kılma potansiyeli olduğunu hissediyorum.
    Bir gün makine öğrenimi modellerini Rust ile yazıp hem Nvidia hem AMD’de çalıştırabildiğimiz bir dünya görebiliriz diye hayal ediyorum.
    Elbette en yüksek performans için üreticiye özel kod yazmak gerekecek ama bu bir optimizasyon meselesi.
    Yine de çapraz platform çalışan, taşınabilir çekirdekler kullanabilmek büyük şey.

    • CUDA ve ROCm dahil çeşitli backend’lere sahip https://burn.dev adlı bir Rust makine öğrenimi framework’ü var.
      Bakmaya değer.

    • Makine öğrenimi modellerini Rust ile yazıp Nvidia ve AMD’de birden çalıştırabildiğimiz bir geleceğin on yıl içinde gelmesi zor görünüyor.
      Gerçekte tüm ekosistem jax ve torch gibi araçlarla Python tabanlı.
      Sektördeki tüm geliştiricileri Rust araçlarına geçirmeyi sağlamak neredeyse hayal bile edilemeyecek kadar zor.

  • Soyutlama katmanlarını sayarsak

    1. Alan özelinde Rust kodu
    2. cust, ash, wgpu crate’leri üzerinde backend soyutlaması
    3. wgpu gibi katmanlarda platform, sürücü ve API soyutlaması
    4. Vulkan, OpenGL, DX12, Metal’de sürücü ve platform soyutlaması
    5. Sürücüde üreticiye özgü donanım soyutlaması (muhtemelen bunun içinde daha da fazlası var)
    6. Donanım
      Yani en az 6 gizli karmaşıklık katmanı var.
      Bu kadar çok katmanın içinden geçip platforma özgü özellikleri performans açısından aynen yansıtmanın mümkün olup olmadığından emin değilim.

    • rust-gpu’nun yaptığı şey sonuçta SPIRV’ye, yani Vulkan’ın IR’ına derlemek.
      Bu yüzden 2 ve 3. katmanları atlamak ya da paralel bir yapıda tutmak mümkün olabilir.
      Ayrıca Rust geliştirme ekosistemindeki cargo, cargo test, cargo clippy, rust-analyzer gibi araçlar GPU shader geliştirmede de aynen kullanılabiliyor.
      Aslında GPU mimarisinin fazla uzaylı gibi olması yüzünden değil, tüm ekosistemin üreticiye bağımlı ve eski araçlara takılı kalmış olması yüzünden GPU programlamasının zor olduğunu düşünüyorum.

    • Demo kesinlikle karmaşık bir Rube Goldberg makinesine benziyor ama bunun nedeni bunun ilk kez mümkün oluyor olması.
      Zamanla daha doğal ve entegre hale gelecektir.
      Ayrıca Rust ekosisteminin başka bir avantajı da istediğiniz kadar soyut ya da istediğiniz kadar somut geliştirme yapabilmeniz.
      Örneğin std::arch ile platforma özel özellikleri kullanabilir, hatta assembly de yazabilirsiniz.
      Allocator ve panic handler değiştirilebiliyor; yakında gelecek externally implemented items özelliği etkinleştiğinde soyutlama katmanlarını istediğiniz ölçüde ele alma esnekliği daha da artacak.

    • İyi nokta.
      Ama 4-6. katmanlar shader ya da CUDA kodunda da her zaman var.
      1 ve 3. katmanlar da aslında sadece başka katmanlarla yer değiştiriyor, özellikle çapraz platform düşünülünce.
      Bu Rust projesi soyutlama katmanı ekliyor olsa bile bu en fazla bir katman daha demek.
      Ayrıca 4-6. katmanlarda çalışan biri olarak, bunların içinde de akıl almaz derecede çok gizli karmaşıklık olduğunu rahatlıkla söyleyebilirim.
      Dürüst olmak gerekirse daha da fazla katman oluyor :P

    • Gerçekçi olmak gerekirse kullanıcıların çoğu en fazla (3) ya da (4) katmanına kadar uğraşacak.
      Yani pratikte o kadar da büyük bir ekstra adım eklenmiyor.
      Bu arada 6. katmanın üstünde de soyutlama katmanları var.
      Firmware ve mikro mimari, bizim düşündüğümüz komut setini uyguluyor.

    • Farklı CPU mimarileri için farklı derleyici ve runtime kullanmaktan çok da farklı olduğunu sanmıyorum.
      Farklı çağrı kuralları, endianness farkları var; donanım seviyesinde de firmware ve microcode bulunuyor.

  • Mevcut no_std + no alloc crate’lerinin neredeyse hiç değişiklik yapılmadan GPU’da çalışabilmesi gerçekten şaşırtıcı.
    Bu, çok çeşitli uygulama fikirlerinin önünü açıyor gibi hissettiriyor.

    • Kod CPU’da çalışacağı varsayımıyla yazıldıysa performans açısından oldukça farklı davranacaktır.

  • Gerçekten çok etkileyici.
    Rust GPU proje listesi şimdiden inanılmaz büyüdü.
    Bu çalışma burn’den daha düşük seviyeli bir soyutlamaya yakın ve burn de candle’dan daha düşük seviyeli.
    Şimdi geriye sanki naga gibi backend’leri yukarıdaki projelere eklemek kalmış gibi görünüyor.
    Herkesin farklı bir temel üstüne bir şeyler kurduğu hissi var ama sanırım bunun nedeni naga çalışmalarının yeni olması.
    burn’ün platform desteğine odaklandığını da eklemek isterim.
    Ama gördüğüm kadarıyla naga kullanan tek backend wgpu.
    O zaman sonuçta sadece wgpu kullanmak yetmiyor mu?
    Özetle wgpu/ash(vulkan, metal) ya da cuda.
    Ek bir not: bu çabaya yakın başka bir crate daha var.
    https://github.com/tracel-ai/cubecl
    [0]: https://github.com/tracel-ai/burn
    [1]: https://github.com/huggingface/candle/

  • Bunun gerçekten GPU üzerinde çalışan “Rust” olup olmadığından emin değilim.
    Koda kabaca bakınca, sonunda shader dili üreten ve üzerine bolca programlama makrosu eklenmiş bir Rust sözdizimi gibi görünüyor.
    GPU programlama çok farklı olduğu için özel dikkat gerektirdiğini düşünüyorum.
    Böyle soyutlamalar eklenince bazı belirli optimizasyonlar imkânsız hale gelebilir.

    • Pratikte çalışan Rust kodu doğrudan spirv bytecode’una derleniyor.

  • Bu projeyi gördüğüme gerçekten sevindim.
    Platform savaşlarına bulaşmak istemeyen geliştiricilere büyük yardım sağladığını düşünüyorum.
    https://github.com/cogentcore/webgpu gibi örnekler de güzel.
    Ben golang kullanıyorum ve sadece tüm platformlarda GPU’nun düzgün kullanılmasını istiyorum; bu tür çalışmalar sayesinde GPU her yerde kullanılabiliyor.
    Rust’a gerçekten teşekkürler.