SDL3'ün yeni GPU API'si birleştirildi

 (github.com/libsdl-org)
1 puan yazan GN⁺ 2024-08-31 | 1 yorum | WhatsApp'ta paylaş
  • SDL3'ün yeni GPU API PR'ı #9312, 29 Ağustos 2024'te birleştirildi; SDL 3.0 yaklaşırken daha fazla inceleme alabilmek için Refresh tabanlı yaklaşımın hızlıca öne çıkarıldığı bir süreç izlendi
  • Öneri, MoonWorks'ün grafik bileşeni Refresh'i SDL_gpu için nihai API adayı olarak benimseyen bir yapıdaydı; Vulkan ve PS5 grafik API'sini destekliyordu, D3D11 deferred context desteği de sürüyordu
  • API tasarımı, işleri render pass, compute pass ve copy pass olarak ayıran modern bir render modeli kullanıyor; kaynak yazma işlemleri ise kareler arası bağımlılıkları önlemek için dahili olarak cycle edilebilecek şekilde kurgulanmış
  • Shader tarafında, ilk çevrimdışı derleme odaklı öneri, çalışma zamanında shader üretimini desteklemeyi doğrulayan bir yöne kaydırıldı; SDL'in kendi içinde bir shader derleyicisini sarmalaması yerine, backend'e özgü IR formatlarını alan bir yapı tartışıldı
  • Birleştirmenin hemen ardından API fonksiyon adları, derleme yapılandırma makroları, UTF-8 BOM ve D3D12 swapchain'deki 60 FPS sınırı gibi konularda ek düzenlemeler yapıldı; thatcosmonaut'a commit yetkisi de eklendi

PR'ın başlangıç noktası ve birleştirilme durumu

  • PR #9312, SDL_gpu'nun hızlıca incelenmesini sağlamak için sunulan yeni GPU API önerisi olarak başladı
    • SDL 3.0 yaklaşırken amaç, hızlıca “daha fazla göz” toplamak oldu
    • 29 Ağustos 2024'te It's merged doğrulamasının ardından birleştirildi
  • Birleştirmenin hemen sonrasında, kısa süreliğine değişiklikleri durdurup inceleme ve ayarlamaların yapılması yönünde bir talep geldi
    • Sonrasında durum everything is merged haline geldi ve GPU tarafındaki değişikliklerin yeniden birleştirilebileceği belirtildi
    • thatcosmonaut, gelecek değişiklikleri büyük olasılıkla inceleyecek kişi olduğu için commit yetkisi verilenler arasına eklendi

Refresh tabanlı API adayı

  • Önerinin merkezinde, MoonWorks'ün grafik bileşeni Refresh'i SDL_gpu için nihai API adayı yapmak vardı
    • MoonWorks, FNA gibi XNA'yı yeniden uygulamaktan ziyade, XNA'nın devamı niteliğinde bir proje olarak tanıtıldı
    • Refresh, FNA3D'ye benziyor ancak Vulkan gibi modern API'leri hedefliyor
  • O sırada Refresh, Vulkan ve PS5 grafik API'sini destekliyordu
    • D3D11 deferred context desteği üzerinde çalışılıyordu
    • PC ve konsollarda Samurai Gunn 2'de üretimde kullanıldığı belirtildi
  • PR yazarı, başlıca iletişim kişisi olarak thatcosmonaut'u gösterdi; FNA core team'in de sürece dahil olacağı ifade edildi

API tasarımı ve kaynak yönetimi

  • API, deferred context merkezli modern bir render API olarak tasarlandı
    • İşler render pass, compute pass ve copy pass olarak ayrılıyor
    • Geri kalan API'nin, binding, render ve compute dispatch çağrılarına yakın standart bir yapıda olduğu açıklandı
  • Kaynaklara yazan tüm işlemler, kareler arası bağımlılıkları önlemek için cycle üzerinden çalışabiliyor
    • GpuBuffers gibi grafik kaynak handle'ları, dahili kaynak başvurularını cycle etmek için konteyner görevi görüyor
    • Daha sonra cycle kavramı bool ile sadeleştirildi ve çeşitli WriteOptions enum'ları kaldırıldı
  • Başlangıçta AMD D3D11 sürücüsüyle ilişkili veri API davranış sorunları nedeniyle birden çok WriteOptions enum'u vardı
    • D3D11 veri API'sinin AMD'de beklendiği gibi çalışmaması tam olarak dolanılamayan bir sorun olarak açıklandı
    • Sonrasında bu bölüm sadeleştirildi ve çalışma biçimi kod içinde belgelendi

Shader sistemi tartışmaları

  • İlk shader çözümü shaderbuild.py adlı bir betikti
    • İstemci makinedeki çevrimdışı shader derleme aracının ön yüzü görevini görüyordu
    • Birden çok formatı paketleyip her render backend'ine uygun şekilde ileten bir yapıdaydı
  • Bu yaklaşımın çevrimiçi shader derlemeyi engellemeyen bir tasarım olduğu belirtildi
    • Gelecekte SDLSL kaynaklarının ikili dosyaya gömülüp CreateShaderModule içinde ihtiyaç duyulan backend bytecode'una anında dönüştürülebileceği açıklandı
    • Açık API'yi bozmadan çevrimiçi derlemeye izin verebilmesi avantaj olarak sunuldu
  • Dış geri bildirimlerde, tamamen çevrimdışı derlemenin bazı motorlarla uyuşmayabileceği yönünde kaygılar dile getirildi
    • Python, glslc, spirv-cross araçlarının PATH'e kurulması gerekliliğinin geliştiriciler için zahmetli olabileceği belirtildi
    • SDL ekosisteminde, ayrı bir satellite library biçimindeki çevrimdışı shader derleme aracının daha doğal olabileceği görüşü de paylaşıldı
  • Sonrasında shader sistemi, “raw” shader'lar ile “portable” shader'ları ayıran bir yöne evrildi
    • FNA3D portu, çalışma zamanında shader üretimi desteği için bir stres testi olarak kullanıldı
    • MojoShader SPIR-V emitter ile Vulkan'da doğrudan iletim, diğer backend'lerde ise isteğe bağlı ayrı bir kütüphane olan SDL_shader üzerinden dönüşüm yapılması gündeme geldi
    • Hedef, SDL'in shader'ın nereden geldiğini bilmek ya da umursamak zorunda olmadığı bir yapıydı

Backend'ler ve test süreci

  • İlk Refresh tabanlı uygulamanın en güçlü yanlarından biri, Vulkan backend'inin zaten mevcut olmasıydı
    • Vulkan backend'inin Refresh 2.0 temelinde yüksek performans gösterdiği yönünde değerlendirmeler yapıldı
    • Compute'un birinci sınıf özellik olması da önceki SDL_GPU taslağına göre önemli bir fark olarak öne çıktı
  • Mart 2024 sonu ile Nisan başı arasında çeşitli gerçek oyun çalıştırma örnekleri paylaşıldı
    • Çevrimdışı shader derlemesi olmadan çalışan bir duruma ulaşıldığı açıklandı
    • Streets of Rage 4'ün açıldığı mevcut revision paylaşıldı
    • Wizorb'un Metal üzerinde çalıştığı belirtildi
    • Celeste'in trace database'in önemli bir bölümünde oyun içi duruma geçtiği aktarıldı
  • Özellik eklemeleri de eş zamanlı sürdü
    • Donanımsal instancing desteğinin bir sonraki push'a ekleneceği belirtildi
    • Sonrasında instancing ve occlusion queries eklendi; Metal tarafındaki uygulamanın tamamlanması gerektiği paylaşıldı

İncelemelerde öne çıkan derleme, API ve platform sorunları

  • Vulkan include sırası nedeniyle VkInstance, VkSurfaceKHR typedef yeniden tanımlama hataları oluştu
    • SDL_gpu_vulkan.c içinde Vulkan header'ları ile SDL_vulkan.h include sırasını değiştiren bir düzeltme önerildi
    • suitableQueueFamilyIndex değişkeninin başlatılmamış olabileceğine dair uyarıyı 0 ile başlatma yoluyla susturan bir düzeltme de sunuldu
  • dynapi güncelleme gereksinimi de gündeme geldi
    • src/dynapi/ altında gendynapi.py çalıştırıldığında güncellendiği bilgisi verildi
    • Çalıştırma sırasında çok sayıda belge eksikliği uyarısı çıktığı da bir not olarak eklendi
  • API fonksiyon imzalarındaki byte size türünün size_t yapılması önerildi, ancak GPU API'de Uint32'nin korunmasına karar verildi
    • Buffer boyutları çok büyüdüğünde 32/64 bit eşzamanlı uyumluluğun zorlaşabileceği görüşü paylaşıldı
    • Alternatif olarak Uint64 olasılığı anılsa da, sonunda Uint32'yi koruma görüşü benimsendi

Birleştirme sonrası ek düzenlemeler

  • Birleştirmenin ardından #10622 altında çeşitli tweak'ler yapıldı
    • Yeni fonksiyon adlarının beta kullanıcılarına ulaştırılması için önce bunların birleştirileceği belirtildi
    • Derleme yapılandırmasında SDL_GPU_VULKAN SDL_VIDEO_VULKAN, SDL_GPU_METAL SDL_VIDEO_METAL gibi sağ taraftaki makroların tanımlı olması gerekliliği #10622 ile düzeltildi
    • GPU kaynak dosyalarındaki UTF-8 BOM sorunu da #10622 ile giderildi
  • D3D12 tarafında D3D12_ClaimWindow()'un swapchain'i VSYNC ile ayarladığı ve bu nedenle testsprite'ın 60 FPS ile sınırlı kaldığı görüldü
    • Swapchain'in claim window aşamasında SDR ve VSYNC gibi evrensel destekli parametrelerle oluşturulup, ardından destek durumu sorgulandıktan sonra SetSwapchainParameters çağrılması iş akışının amaçlanan davranış olduğu açıklandı
    • Render driver, claim sonrasında SetSwapchainParameters çağırmasına rağmen D3D12 driver'da 60 FPS sınırının sürmesi araştırılması gereken bir konu olarak kaldı

İlgili okumalar

1 yorum

 
GN⁺ 2024-08-31
Hacker News yorumları

  • SDL3 hâlâ önizleme aşamasında, ancak yeni GPU API ana dala birleştirildi ve SDL3 bakımcıları son ayarlamaları yapıyor
    Anladığım kadarıyla bu yeni GPU API’nin özü, grafik kodunu ve shader’ları bir kez yazıp konsollar dâhil birçok platformda büyük zahmete girmeden çalıştırmayı sağlaması. Eskiden Unity ya da Unreal ya da kendi özel çözümünüz gerekiyordu
    WebGPU/WGSL de benzer bir çapraz platform grafik yığını, ancak bildiğim kadarıyla konsol backend’i yapan kimse yok. Buna karşılık SDL3 GPU API şu anda WebGPU’yu backend olarak desteklemiyor gibi görünüyor

    • Unreal/Unity tek çözüm değil. Oldukça popüler olan bgfx(https://github.com/bkaradzic/bgfx) de var; bildiğim kadarıyla sokol gfx(https://github.com/floooh/sokol) de mevcut. Elbette daha az bilinen birçok seçenek de var
    • Daha önce grafik kodunu ve shader’ları bir kez yazmayı sağlayan, konsolları da destekleyen bgfx’i [1] SDL2 yığını ve Swift [2] ile entegre etmeyi denemiştim. Bu tür araçları daha önce hiç kullanmamış biri olarak bile oldukça iyi bir deneyimdi
      SDL3 konsol soyutlaması getirdiği için GPU API’ye ek bağımlılık gerekmeyecek; bu yüzden heyecan verici. Üstelik Godot, Steam Deck’i resmen destekliyor ve ileride daha fazla konsolun da desteklenmesini umuyorum. Bununla bağlantılı olarak Miguel de Icaza, Godot’ta Swift’in benimsenmesini zorluyor ve iPad’de editörü SwiftUI’a portlama üzerinde de çalışıyor. İlerleme durumu [3] ilginç
      [1] https://bkaradzic.github.io/bgfx/overview.html
      [2] https://github.com/bgbernovici/myndsmith
      [3] https://blog.la-terminal.net/xogot-code-editing/
    • Godot’ta da çapraz platform shader olduğunu belirtmekte fayda var. GDShader dili güçlü biçimde OpenGL shader diline dayanıyor, ancak bire bir kopyası değil ve hedef platforma göre derleniyor. Yalnız PS5 ve Xbox için üçüncü taraf bir şirketle çalışmak gerekiyor. Nintendo NDA’si imzalamış kişiler için Nintendo derlemelerini yayımlayan biri de var
    • Peki SDL API’sine gfx-rs / wgpu yerine neden ihtiyaç var? Yeni bir tane daha yapmaya gerçekten gerek var mıydı, merak ediyorum

  • Ek bağlam burada: https://icculus.org/finger/flibitijibibo?date=2024-06-15&time=13-14-16

  • Bu akışın nasıl oturacağını merakla bekliyorum. Sonuçta özel oyun motorları ve uygulamalar geliştirmek için daha fazla seçeneğin olması iyi olur
    Son zamanlarda Vulkan’a derinlemesine dalıyorum; öğrenmesi eğlenceli ve aydınlatıcı, ama Vulkan’ın doğası gereği ilerleme yavaş hissediliyor. Başladığımda SDL3 olsaydı muhtemelen memnuniyetle onu seçerdim ve harcadığım zamana kıyasla gösterecek daha fazla sonucum olurdu

  • Bu API’nin pratikte gerçekten kullanışlı olup olmayacağını zaman gösterecek. Özellikle kaynak senkronizasyonu ve nesne adını değiştirme yöntemi belirleyici olacak
    WebGPU’dan veya diğer soyutlamalardan daha iyi performans verip vermeyeceğini de görmek gerek. Sürücü hatalarını dolanmak gereken durumlarda da küçük kalmaya devam edip etmeyeceğini izlemek gerekecek
    Shader dili için yeni bytecode konusunda da şüpheliyim. WebGPU’da çalışma zamanı shader ayrıştırması bir endişe kaynağı değildi ve çok hızlıydı. Yerel shader üretimi de hızlı [1]. Yavaş olan pipeline oluşturma ve bu bytecode buna yardımcı olmuyor
    [1] http://kvark.github.io/naga/shader/2022/02/17/shader-translation-benchmark.html

  • Bunu nasıl bu kadar hızlı başardıklarını merak ediyorum. WebGPU native’in geliştirme süresi uzun ve hâlâ nihai olarak kesinleşmiş değil; SDL GPU API ise daha fazla platformu desteklediği için tersine daha uzun sürer gibi görünüyordu

    • WebGPU’nun uzun sürmesinin nedeni, SPIR-V kullanmak yerine kendi shading dilini yapmaya karar vermesiydi. SDL bu hatayı yapmadı; shader derleyicilerini ve dönüştürme araçlarını kullanıcının getirmesine bırakıyor
      Çapraz platform shading dili için bir kardeş proje [1] ve mevcut dilleri birbirine dönüştüren başka bir proje [2] var; ama onlar hazır olunca hazır olur, API’nin geri kalanının bunu beklemesine gerek yok
      WebGPU, satıcılar ve dil hukukçuları ya da standart hukukçularından oluşan bir komitenin siyaset ve bürokrasi içinde ürettiği bir sonuç; bu da belli oluyor. SDL_GPU ise her şeyden önce pratikliği önemseyen oyun geliştiricileri tarafından yapıldı; bu yüzden de zaman zaman fildişi kulelerden küçümseniyor
      [1]: https://github.com/libsdl-org/SDL_shader_tools
      [2]: https://github.com/flibitijibibo/SDL_gpu_shadercross
    • SDL3 GPU projesinin temel katkıcıları, FNA3D ve Refresh adlı iki çapraz platform GPU soyutlama katmanıyla, yani hem PC’leri hem konsolları hedefleyen katmanlarla çalışma deneyimine sahip. Bu bilgi ve mevcut açık kaynak kod, hızlı ama kaliteli biçimde bir araya getirebilmeleri için basamak oldu
    • Çünkü ortada bir komite yoktu; kendi projeleri için sonuca ihtiyaç duyan, motive geliştiriciler vardı. Özellikle FNA tarafındaki insanlar böyleydi
    • Basit. SDL GPU, baykuşun geri kalanını, yani ortak formattaki shader’ları API’ye özgü ara temsillere dönüştüren kısmı dışarıda bıraktı

  • dx12 kısmına katkıda bulunduğum için mutluyum :)

    • Güzel. Modern HLSL’i hedefleyeceğim için başta muhtemelen o backend’i kullanacağım. DXC’nin sonunda düzgün bir SPIR-V üretmesini umuyorum
    • DX12 öğrenmek için hangi kaynakları önerirsiniz?

  • Bir ara deneyebilirim. SDL bana hep kaliteli bir yazılım gibi geldi. Hızlı derleniyor, çeşitli platformlarda kolayca derleniyor ve her zaman düzgün çalışıyor. Bu yüzden bu yeni API’den de beklentim var

  • Genel olarak SDL’in büyük hayranıyım
    Çapraz platform bir oyun kütüphanesi ararken SDL ve API’si tam doğru denge gibi gelmişti. Bir pencere ve grafik bağlamı oluşturmak için çağırabileceğim bir C/C++ kütüphanesi, hızlı bir sprite render etme çatısı istiyordum. Tam bir IDE’ye ya da şişkin bir kütüphaneye ihtiyacım yoktu; yeni bir dil öğrenmek de istemiyordum

  • SDL3, ikinci sistem etkisi yaşıyor gibi geliyor. SDL2, açık pencere handle’ları eklenmiş SDL1’e daha yakındı; dolayısıyla SDL3 üçüncü değil, ikinci sistem. SDL1/2, pencere açma ve giriş olaylarını işleme gibi platforma özgü boilerplate’i saran ince bir katmandı; gerçekten yazmak istediğin OpenGL render koduna hızlıca geçmeni sağlıyordu

    • Yalnızca Windows/Linux/Android desteklenecekse SDL GPU API’nin gereksiz yere şişkin olduğu söylenebilir
      Ama Apple işletim sistemlerini de desteklemek istiyorsan OpenGL 4.1’e bağlı kalıyorsun. Apple bunu 5 yıl önce resmen kullanımdan kaldırılacak olarak işaretlediği için compute shader gibi modern GPU özelliklerini kullanamıyorsun
      Vulkan yoluna gidip Apple sistemlerinde MoltenVK kullanmak da mümkün, ama Vulkan karmaşıklığı OpenGL’e göre epey artırıyor. İnsanların sık dediği gibi “tek bir üçgen için 1000 satır kod” düzeyinde. SDL3’ün GPU API hedefi, daha erişilebilir ama yeterince esnek bir alternatif sunmak
      Konsollar için de muhtemelen benzer bir durum vardır
      Pek çok kişi “SDL_render gibi olup tüm platformlarda çalışan shader desteği ekleyebilir misiniz?” diye talep etmiş; çıkış noktasının da bu olduğu söyleniyor
      SDL3 daha yüksek seviyeli bir ses API’si de ekliyor, ama onun avantajını pek bilmiyorum
    • SDL2 yalnızca “açık pencere handle’ları eklenmiş SDL1” değildi. API genelinde çeşitli değişiklikler ve yeni özellikler vardı; SDL3’te olduğu gibi grafik alt sisteminde de büyük değişim olmuştu. SDL1 yazılımsal render kullanıyordu, SDL2 ise donanım hızlandırma ekledi
      Ayrıca SDL2, 2.0.0’dan sonra epey gelişti; SDL3 de API uyumluluğunu bozan değişikliklere izin vererek bu evrimi sürdürüyor. SDL3 baştan yeniden yazılmış değil ve SDL kullanıcıları açısından SDL2’den SDL3’e geçmenin o kadar zor olmayacağını düşünüyorum
      Üstelik SDL1/2 de kendi yüksek seviyeli grafik sistemi olmayacak kadar “sadece ince” olmamıştı. Yeni kullanıcıların ya da temel kullanıcıların ekranda hemen bir şey gösterebilmesi için yerleşik bir şey sunulması faydalı
      ahefner’ın belirttiği gibi SDL1 modern ölçütlere göre epey “inceydi”, ama doğrudan piksel matematiği yazmadan ekrana temel şeyler çizecek kadarını sağlıyordu; 90’larda bu oldukça yardımcıydı
    • Sorun şu ki OpenGL fiilen öldü ve Vulkan, kullanım kolaylığı açısından OpenGL’in zayıf bir alternatifi
    • Render API de zaten birçok SDL kullanıcısı için gereksiz şişkinlikti. SDL2 de ikili dosya boyutu açısından SDL1’den zaten epey büyümüştü
      Yine de bu soyutlama, basit 2D oyunların ötesindeki ihtiyaçları karşılarken, ne yazık ki giderek parçalanan grafik API ekosistemini hedeflemeye olanak tanıyabilir. Evrensel bir OpenGL(Next) geleceği hayali yok oldu. Ancak en zor kısım olan shader dönüştürme hâlâ yok gibi görünüyor

  • Bu kütüphaneyi hiç kullanmadım ama bağlantı verilen başlıktan doğru anladıysam artık sağlanan çapraz platform GPU compute özelliğine dair örnekler görmek isterim. Nereden başlamak gerektiğine dair önerisi olan var mı?