M1’de bir ay içinde Vulkan 1.3 desteği

• Honeykrisp henüz son kullanıcılar için yayımlanmış değil; şu anda yalnızca geliştiricilere yönelik source code açık durumda
• M1 için Honeykrisp, Apple hardware üzerinde ilk conformant Vulkan uygulaması ve portability muafiyeti olmadan Vulkan 1.3’ün tüm spesifikasyonunu uyguluyor
• Honeykrisp, mevcut M1 Vulkan çalışmasının devamı değil; NVIDIA GPU’lar için açık kaynaklı NVK driver temel alınarak başlandı, ardından M1 kodu eklendi ve NVIDIA’ya özgü bölümler çıkarıldı
• Vulkan 1.3 conformance test suite için nihai sonuç Pass 686930, Fail 0 olarak kaydedildi
• Tüm durumları dinamik durum olarak ele alıp prolog ve epilogları derleme, compile etme ve cache’leme kodu eklenerek full dynamic state ve EXT_shader_object yönünde bir uygulama yapıldı
• Zero-copy rendering için EXT_image_drm_format_modifier uygulandı
• Direct3D uyumluluğu için DXVK ve vkd3d-proton’ın gerektirdiği EXT_custom_border_color destekleniyor; border colour düzeltmesi, shader içine kod enjekte edilerek emüle ediliyor
• Custom border colour emülasyonu “simple, correct, and slow” olarak tanımlandı; ileride driver tricks ile hızın artırılması planlanıyor
• Sıradaki iş, DXVK ve vkd3d-proton tarafından Direct3D katmanlaması için istenen öğeleri uygulamak; buna örnek olarak transform feedback veriliyor

[GN⁺]

Hacker News görüşleri

• Gerçekten etkileyici bir çalışma ve paylaşılan, yinelenerek iyileştirilen açık bileşenlerin değerini iyi gösteriyor.
  Proton’un port edilmesinin ne kadar süreceğini merak ediyorum; ancak Vulkan uygulaması optimum olsa bile GPU mimarisi farkları, ARM dönüşüm ek yükü ve Proton’un kendi maliyeti nedeniyle birçok oyunun performansının kötü olacağını düşünüyorum.
  Yine de Snapdragon gibi SoC’ler masaüstünde daha yaygın hale gelirse, ileride daha fazla oyunun birleşik bellek ve ARM hedefleyeceği konusunda iyimserim.

  • Asahi’de oyun deneyimi macOS’tan daha kolay ve basit hale gelirse epey ironik olur.
    Bu, Apple’ın son 10 yılda Vulkan’ı görmezden gelmesinin ne kadar büyük bir hata olduğunu gösteriyor; ama çok geç olmadan bunu asla kabul etmeyecek gibi görünüyor.
  • dxvk gerektirmeyen epey oyun 60 FPS’in üzerinde çalışıyor. Bkz. https://vt.social/@lina/112524118075585601
    Alyssa son dönemde FEX performans iyileştirmeleri üzerinde de çalışıyor.

• Linux’a Vulkan ekleme ve Asahi Linux’ta DirectX’i dönüştürme yönündeki bu çalışmanın, Apple’ın Apple Silicon’a AAA oyunlar çekme hayalini etkileyip etkilemeyeceğini merak ediyorum.
  Apple muhtemelen AAA geliştiricilerinin oyunları Metal’e port edip iPhone, iPad, Mac ve Vision Pro’da tek bir kod tabanıyla çalıştırmasını istiyor.
  Belki de Mac oyuncuları AAA PC oyunlarını oynamak için Asahi Linux kurmaya başlayabilir.

  • Apple’ın hayali AAA oyunların Apple Silicon’a gelmesi değil, Apple App Store’a gelmesi. Proton gibi katmanlar GPTK gibi yapılabilir.
    Asıl istedikleri, AAA oyunların Steam veya Epic Games Store’a değil App Store’a girmesi; bu yüzden GPTK’nin yarım yamalak olduğunu ve lisansının da Valve’ın onu doğrudan Steam’e entegre etmesini engellediğini düşünüyorum.
  • Asahi Linux, oyun oynamak için çift önyükleme yapan Mac kullanıcıları için yeni Boot Camp olabilir.
    M1’de Whiskey ile Diablo II Resurrected oynadım; Windows’a özgü bir oyunun böyle doğrudan çalışması oldukça etkileyiciydi. Şu anda yalnızca aptalca Blizzard launcher güncellemesi çökerek oyunun başlamasını engelliyor.
    Eski bir DX9 oyunu olsa da EverQuest II de M1 Mac mini’de 1440p’de çok iyi çalışıyordu; Asahi Linux, Guild Wars gibi eski 32 bit oyunlara da yardımcı olabilir.
  • Apple gerçekten bunu isteseydi sadece Vulkan’ı uygulardı.
  • Apple zaten Game Porting Toolkit’i yayımladı.

• Vulkan 1.3’ü iyi bilmiyorsanız ama düşük seviyeli grafik API çalışmalarıyla ilgileniyorsanız kesinlikle göz atmaya değer. Vulkan 1.0’dan tamamen farklı bir seviye ve oyunun kurallarını değiştiriyor.
  İlk eşiği aştıktan sonra çalışması keyifli; tüm dinamik durumlar ve önceden render pass ayarı yapma zorunluluğunun kaldırılması sayesinde çok daha yönetilebilir. 20 yıldır kullandığım OpenGL’den bile daha kolay hale geldi ve grafik programlama yeniden eğlenceli oldu.
  Güncel sürücüleriniz varsa, yaklaşık son 10 yıl içinde üretilmiş GPU’ya sahip tüm masaüstü platformlarında çoğu özelliği kullanabilirsiniz.
  Ne yazık ki hemen başlamayı sağlayan “makul varsayılanlar” sunan bir framework yok; ancak çeşitli diller için yararlı birçok yardımcı kütüphane var.

  • OpenGL’le 20 yıldır ara ara uğraşıyorum; profesyonel oyun programcısı değilim ama boş zamanlarımda 3D içerik üretiyorum.
    Vulkan’a geçmeye zaman bulamamıştım; sanırım sonunda yalnızca başlatma ve yapılandırma eşiğini aşmam gerekecek. Ondan sonra OpenGL’e geri döneceğimi sanmıyorum.
    Bu yazı beni biraz dürttü; gerçekten denemem gerektiğini düşündürdü.
  • Vulkan 1.3’e özel olarak başlamayı sağlayan bir eğitim veya dokümantasyon var mı? En son baktığımda, eski yöntemlerle yeni yöntemlerin çeşitli kombinasyonlar halinde karıştığı kaynaklar vardı sadece.
    OpenGL de zaten böyleydi; belki çok farklı sayılmaz ama Khronos’un bunu da başarmış olması ayrı bir his veriyor.

• ES 3.2 desteği nedeniyle az önce güncelledim ve şimdiden şaşırdım. M1’im sanki Asahi için yapılmış gibi hissettiriyor.
  Dürüst olmak gerekirse macOS muhtemelen ya kuruluyken ya da yanlışlıkla yalnızca bir kez önyüklenmiştir. Böyle ayrıntılı güncellemelerin olması güzel.
  Tarayıcılardan herhangi birinin sıfır kopyalı render destekleyip desteklemediğini, yoksa hâlâ araya birden fazla compositor katmanının mı girdiğini merak ediyorum. WebGL2 transform feedback’in geri okuma tetiklediği için takıldığını da hatırlıyorum.

  • macOS tamamen kaldırılabiliyor mu? Bunu görünce seyahat için Mac mini düşünmeye başladım.

• Bir şey çökse bile bunun asla derleyici hatası olamayacağını düşünürdüm; ama 16 Nisan’da gerçekten derleyici hatasıymış.
  Kariyerim boyunca böyle bir şey yaşamadığımı gönül rahatlığıyla söyleyebilirim; ancak soyutlama seviyesi düştükçe bu durum daha az nadir hale gelebilir.

  • Derleyici hatası olamaz, CPU hatası da kesinlikle olamaz.
    Tabii düşük seviyeli kernel geliştiricisiyseniz ikisi de doğru olabilir.
    Şaka bir yana, gerçekte çoğu zaman öyle değildir; ama kesinlikle olur.
  • En azından register allocator kısmını kendisi yazmadı mı?
    Test edilen şey kendi üzerinde çalıştığı, geliştirme aşamasındaki bir derleyiciyse “derleyici hatası olamaz” özdeyişi pek geçerli olmaz.

• Shader’da alışılmadık bir yapı var: if (condition) { while (true) { } }
condition her zaman yanlış, ama derleyici bunu bilmiyor.
  Standartlara uyan shader derleyicisi yazarlarını zorlayan zehirli bir girdinin ötesinde, bu yapının amacının ne olduğunu merak ediyorum.

  • Testin özü, derleyici yazarlarının önüne zehir gibi bir girdi atıp hangi shader gelirse gelsin bozulmamasını sağlamak değil mi?
    Söz konusu kodun pratikte faydalı olmasından ziyade, bir shader’ın bir kısmı belirli durumlarda işlevsel olarak böyle bir forma indirgenebiliyorsa derleyicinin bunu doğru işlemesi gerekir.
  • Bu yapının amacı, koşulun her zaman yanlış olduğu bilgisini derleyiciye vererek optimizasyoncunun daha fazla optimizasyon yapmasını sağlamak olabilir.
    Kavram tanıdık değilse C++, LLVM ve Rust’taki şu özelliklere bakılabilir:
    https://en.cppreference.com/w/cpp/utility/unreachable
    https://en.cppreference.com/w/cpp/language/attributes/assume
    https://en.cppreference.com/w/cpp/memory/assume_aligned
    https://llvm.org/docs/LangRef.html#unreachable-instruction
    https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic
    https://doc.rust-lang.org/std/hint/fn.unreachable_unchecked....
    https://doc.rust-lang.org/std/hint/fn.assert_unchecked.html
    Sonsuz döngü fiilen erişilemez bir komuttur; bir dallanmadan sonraki erişilemez komut da fiilen bir assume komutuna dönüşür.
  • Shader’ın “panic” üretme yolu bu mu?
  • Bir tür kod üretimi uç durumu da olabilir.

• Bunu bir VM içinde kullanıp kullanamayacağımı merak ediyorum. macOS’ta geliştiriyorum ve genel olarak memnunum, ama test için VMware’de bir Ubuntu imajı çalıştırıyorum.
  3D grafik uygulaması geliştirdiğim için VMware’in passthrough’unun ne düzeyde olduğunu pek bilmiyorum. VM’de Apple Silicon GPU’nun sanallaştırılıp sanallaştırılmadığını, bu dağıtımı çalıştırırsam grafik performansının iyileşip iyileşmeyeceğini merak ediyorum.

  • Yerel olarak kurmak gerekir. macOS üzerindeki Windows/Linux/macOS VM’lerinde iyi 3D performansı istiyorsanız Parallels, VMware’den çok daha iyi.

• Bunun MoltenVK ile ilişkisini açıklayabilir misiniz? Yerel bir sürücü olduğu için MoltenVK’ye gerek kalmıyor mu?

  • MoltenVK, macOS’ta Vulkan uygulamalarının çalışmasını sağlamak için Metal tabanlı geliştirilmiş bir Vulkan implementasyonudur.
    Asahi Linux, Apple M serisi işlemcilerde Linux’u uyumlu hâle getirmeyi amaçlayan, geliştirme aşamasındaki bir dağıtımdır; bu yazı da Asahi’de GPU hızlandırmalı Vulkan’ın çalışır hâle getirilmesiyle ilgilidir.
  • Bu, M1 Mac donanımında Asahi Linux üzerinde Vulkan kullanma konusu. MoltenVK ise macOS’ta Metal üzerinde Vulkan sağlar.
  • Bu, macOS değil Linux’ta Vulkan ile ilgili bir konu.
  • MoltenVK, Metal’i Vulkan’a çevirir. Metal, OS X ve iOS’in ana grafik API’sidir; bu ise Linux için yerel Vulkan implementasyonudur.
    Yazıda da böyle söyleniyor. Bu OS X üzerinde doğrudan çalıştırılamayacağı için MoltenVK ihtiyacını ortadan kaldırmaz.