- Apple M1/M2 GPU’ları için çekirdek grafik sürücüsü, Rust tabanlı olmasının yanı sıra OpenGL 4.6 ve Vulkan 1.3 uyumluluğuna da ulaşarak standart desteğinin kapsamını genişletti
- OpenGL 4.0’ın merkezindeki tessellation, Apple GPU donanım özellikleriyle tek başına standardı karşılamakta zorlandığı için Microsoft referans tessellator’ı OpenCL C’ye taşınıp GPU üzerinde çalıştırılarak işleniyor
- Bir M2 Mac’teki Vulkan demosunda OpenCL tabanlı tessellation 265fps kaydetti; bu, yalnızca yazılım uygulamasının 1fps altındaki hızından çok daha yüksek, ancak donanım tessellator’ının 820fps değerinin gerisinde
- AAA oyunları çalıştırmak için DirectX·Windows·x86·4KB sayfa ortamının Linux·Arm64·16KB sayfa tabanlı Apple Silicon’a uyarlanması gerekiyor; bunun için birden fazla çeviri katmanı ve sanal makine yapılandırması birlikte kullanılıyor
- Portal, The Witcher 3, Cyberpunk 2077 gibi oyunlar gerçekten çalıştırıldı; ancak bellek gereksinimleri ve ray tracing destek kapsamı hâlâ önemli kısıtlar olarak duruyor
OpenGL 4.6’ya kadar çıkan Apple GPU sürücüsü
- Apple M1/M2 GPU’ları için çekirdek grafik sürücüsü Rust ile yazıldı ve çeşitli grafik standartlarında uyumluluk sağladı
- Alyssa Rosenzweig, X.Org Developers Conference 2024’te sürücünün durumunu ve desteklenebilecek oyunları güncelledi
- Sunum materyalleri YouTube videosu ve slaytlar olarak yayımlandı
- Önceki yılki XDC’de sürücü OpenGL ES 3.1 uyumluluğuna ulaşmıştı; daha sonra OpenGL 4.6 uyumluluğuna kadar geldi
- OpenGL 4.0 için gereken tessellation), sahnedeki detayı dinamik olarak artırıp azaltmaya yarayan bir tekniktir
Apple GPU donanım tessellator’ının sınırları
- Apple GPU’da donanım tessellator’ı var, ancak OpenGL standardı uygulaması için gereken özelliklerden bazıları eksik olduğundan sürücü bunu olduğu gibi kullanamıyor
- Donanımın point mode ve isoline desteklemediği görülüyor; bu iki özellik emüle edilebiliyor
- Daha büyük sorun transform feedback ve geometry shader
- Donanım ikisini de desteklemiyor
- Sürücü bunları compute shader ile emüle ediyor
- Donanım tessellator’ı ile emülasyonun tessellation algoritmaları arasındaki fark invariance hatasına yol açabileceğinden bu kombinasyondan kaçınmak gerekiyor
- Apple, OpenGL 4.1’i destekliyor ancak uyumluluğa sahip değil; donanımın desteklemediği özellikleri yazılımla ikame ediyor
- Rosenzweig, Metal’i uygulamadığını, bu yüzden böyle bir yola gitmeyeceğini belirtti
OpenCL C’ye taşınan referans tessellator
- Sürücü, Microsoft’un 10 yıldan uzun süre önce yayımladığı referans tessellatordan yararlanıyor
- Aslen, donanım üreticilerine tessellation’ı devreye alırken uygulamaları gereken davranışı göstermek için yazılmış kod
- Yaklaşık 2000 satır C++ kodundan oluşuyor ve tek bir patch üzerinde tessellation yapıyor
- GPU sürücüsünde 2000 satırlık C++ kodu olduğu gibi çalıştırılamadığı için bu kod OpenCL C’ye taşındı
- OpenCL C, sıradan CPU C’sine oldukça benzer, ancak GPU’ya yönelik kısıtları ve uzantıları vardır
- Amaç kodu tamamen anlamak değil, port etme sırasında davranışı bozmamaktır
- CPU tessellator’ı aynı anda yalnızca bir patch işler, ancak bir sahnede 10.000 patch bulunabilir
- GPU’nun büyük ölçekli paralelliğinden yararlanılarak birden çok iş parçacığı tessellation yapar
- Paralel işleme sırasında çıktı tamponu tahsisi GPU atomic komutlarıyla yönetilir
- Tessellator çıktısı, GPU’nun gerektirdiği packed data structure biçimindeki draw komutlarıyla çizilmelidir
- Normalde C sürücü kodunda bunu GenXML tool tarafından üretilen fonksiyonlar işler
- Tessellator, OpenCL sayesinde C kodu biçiminde olduğundan, üretilen fonksiyonlar GPU’da çalışan koda dahil edilebilir
Tessellation performansı
- OpenCL tabanlı tessellation, M2 Mac’te Vulkan demosunun terrain tessellation’ını çalıştırmak için kullanıldı
- Performans karşılaştırması şöyle
- Yalnızca yazılım terrain tessellation: 1fps altı
- OpenCL tabanlı tessellation: 265fps
- Donanım tessellator’ı bağlanarak ölçülen değer: 820fps
- Rosenzweig, OpenCL yönteminin performansını “fena değil” diye değerlendirdi ve gerçek oyunlarda darboğaz olma ihtimalinin düşük olduğunu düşündü
- Sürücü performansında hâlâ iyileştirme alanı var
Vulkan 1.3 ve Honeykrisp
- Honeykrisp M1/M2 GPU sürücüsü Vulkan 1.3 uyumluluğuna ulaştı
- Başlangıç noktası, NVIDIA GPU’ları için NVK Vulkan driver’ın kopyalanıp OpenGL 4.6 sürücüsüyle birleştirilmiş haliydi
- Yaklaşık bir ay içinde uyumluluk test paketini geçmeye başladı
- Bu zaman, sunuma göre 6 ay öncesiydi
- Ardından şu özellikler eklendi
- geometry shader
- tessellation shader
- transform feedback
- shader object
- Mevcut sürücü, çeşitli DirectX sürümleri için gereken tüm özellikleri destekliyor
AAA oyunları çalıştırmak için çeviri katmanları
- Apple Silicon ortamında AAA oyunları çalıştırmak için aynı anda birden çok ortam farkıyla baş etmek gerekiyor
- Oyunun hedef ortamı: DirectX, Windows, x86 CPU, 4KB sayfa
- Gerçek hedef donanım: Linux, Arm64, 16KB sayfa tabanlı Apple Silicon
- DirectX’ten Vulkan’a çeviriyi ve Windows’tan Linux üzerinde çalıştırmayı sırasıyla DXVK ve Wine üstleniyor
- x86’dan Arm64’e çeviri için FEX-Emu veya Box64 gibi mevcut seçenekler var
- En büyük engel sayfa boyutu farkı
- FEX-Emu 4KB sayfa gerektiriyor
- Box64’ün 16KB sayfa kullanan bir hack’i var, ancak Wine’da çalışmadığı için burada işe yaramıyor
- macOS, x86 emülasyonu için 4KB sayfa kullanabiliyor, ancak son derece müdahaleci çekirdek desteği gerekiyor
- Asahi Linux zaten mainline çekirdeğe gidecek yaklaşık 1000 yamaya sahip olduğundan, Linux bellek yöneticisini yeniden yazma yaklaşımı makul değil
4KB konuk çekirdek VM yapılandırması
- Linux, farklı süreçler arasında heterojen sayfa boyutlarını desteklemiyor; ancak farklı çekirdekler arasında bu mümkün ve sanallaştırmayla ele alınıyor
- KVM konuk çekirdeği, ana makine çekirdeğinden farklı bir sayfa boyutuna sahip olabilir
- FEX-Emu, Wine, DXVK, Honeykrisp, Steam ve oyunun tamamını 4KB konuk çekirdek çalıştıran bir sanal makineye koyan bir yapı kullanılıyor
- Donanım sanallaştırması sayesinde CPU ek yükünün düşük olması bekleniyordu; asıl yük çevre birimleri tarafında
- Honeykrisp, ana makine çekirdeğinde değil, konukta virtgpu native contexts üzerinden çalışıyor
- Nihai GPU command buffer’ı oluşturma işi konukta yapılıyor
- Her Vulkan çağrısının sanal makine sınırını geçmesi yerine, tamamlanmış command buffer ana makineye aktarılıyor
- Ana makinedeki VirGL renderer bunu GPU’ya iletiyor
- Rosenzweig, bu yöntemin %100 native hızda olmadığını, ancak kesinlikle %90’ın üzerinde olduğunu söyledi
- CPU ve GPU ek yükleri paralel çalıştığından maliyetleri birbirine eklenmiyor
Gerçekten çalıştırılan oyunlar ve açık durum
- Bu yapılandırma gerçekten birden çok oyunu çalıştırıyor
- Portal
- Portal 2
- Castle Crashers
- The Witcher 3
- Fallout 4
- Control
- Ghostrunner
- Cyberpunk 2077
- İlgili bileşenler, sunum günü olan 10 Ekim’de açıklandı
- Fedora Asahi Remix kullanıcıları hemen güncelleme yaparak bu bileşenleri alabilir
- Sunum sırasında Steam’in açılması, sanal makine ve x86 emülasyonu nedeniyle zaman aldı; ardından Control, M1 MAX sisteminde 45fps ile çalıştı
Bellek ve ray tracing kısıtları
- 8GB RAM’li Mac’lerde de bazı oyunlar çalıştırılabiliyor
- Rosenzweig konferans sırasında 8GB’lık bir sistemde Castle Crashers oynadı
- Portal da 8GB sistemde çalışıyor
- Üst düzey oyunların büyük olasılıkla yalnızca 16GB veya üzeri sistemlerde çalışması bekleniyor
- Rosenzweig, zamanla gerekli kaynakların azalmasını umuyor
- ray tracing desteği yüksek öncelikli değil
- Control bu özelliği kullanabiliyor
- Apple donanımı ray tracing’i yalnızca M3’ten itibaren destekliyor
- Mevcut sürücü M1 ve M2 GPU’ları için
- Rosenzweig yakında M3 üzerinde çalışmaya başlamayı planlıyor
1 yorum
Hacker News yorumları
M1/M2 desteğini sonuna kadar tamamlamaya yönelik bu adanmışlık gerçekten saygı uyandırıyor
Parlak yeni ışın izleme oyuncakları çıkar çıkmaz terk edilen o kadar çok proje var ki; böyle işler, belgelendirmesi yetersiz donanım yüzünden acı verici ama çalıştığında ödülü büyük oluyor
Ben de M1'imi bu proje ve Alyssa'nın OpenGL+ES çalışmaları nedeniyle aldım ve yalnızca Asahi Linux boot ediyorum
Bu cihazlar uzun ömürlü olacak şekilde yapılmış ve hem Apple'ın kendisinin hem de Linux topluluğunun uzun vadeli desteği övgüye değer
Açık kaynak olduğu için Apple'ın da bunu izliyor olma ihtimali yüksek; yazıda çipte eksik olan özelliklerin etrafından dolaşma çalışmaları da ele alınıyordu
20 yılı aşkın süredir kod yazıyorum ama kariyerimdeki en mutlu an da en depresif an da yalnızca 4 ay dahil olduğum bir donanım projesinden çıktı
4KB ile 16KB sayfa boyutu farkını çözmek için her şeyi sanal makinede çalıştıran Alyssa'nın yaklaşımı zekice bir hack gibi, ama aynı zamanda potansiyel bir performans darboğazı gibi de geliyor
Bu tür geçici çözümlerin uzun vadede ne anlama geldiğini merak ediyorum
Kapalı bir ekosistem için tasarlanmış tescilli donanımın boşluklarını kapatmanın karmaşıklığının, faydasını aştığı noktaya gelmiş olabilir miyiz?
M1 MAX'te açık kaynak sürücülerle Control'ün 45fps çalışması cesaret verici, ancak topluluğun kapalı sistemleri daha açık hale getirmek için büyük kaynaklar harcamaya devam etmesi mi, yoksa daha açık donanım standartlarını zorlaması mı gerektiğini sorguluyorum
Apple, tessellation shader gibi standart özellikleri zorlaştıran GPU kısıtları ve standart dışı sayfa boyutlarıyla geliştiricilerin önüne gereksiz engeller koyuyor; bu kapalı ekosistem yalnızca açık kaynak katkıcılarını zorlamakla kalmıyor, tüm kullanıcılara fayda sağlayacak inovasyonu da bastırıyor
Bunun kapalı iş modelini desteklediği açık ve Apple için gerçekten çok iyi işliyor
Harika donanımlar üretiyorlar; son dönemde yazılım biraz istikrarsız olsa bile sıradan kullanıcı, donanım ve yazılım birleşiminden genellikle oldukça iyi bir deneyim alıyor
Dolayısıyla Apple'ın donanımı şu anki gibi tasarlaması geliştiricilerin önüne “gereksiz engeller” koyduğu anlamına gelmiyor; yalnızca kendi ihtiyaçlarına göre donanım tasarımına odaklandığı anlamına geliyor
Üstelik donanım harika olmasaydı, Apple'ın niyet etmediği şekillerde kullanmaya yönelik ilgi de bu kadar büyük olmazdı
Standartları görmezden gelip daha iyi bir tekerleği yeniden icat etmek ile uyumluluğu engellemek için kasıtlı olarak standartlardan sapmak arasında epey büyük fark var
Mesele, standart davranışı sürdürmek için kaynak harcamamak mı, yoksa standarttan sapmak için aktif olarak kaynak harcamak mı; ilkiyse şahsen suçlanacak bir şey olduğunu düşünmem
Bu ekosistemde Apple'ın asıl önemseyeceği şeyler muhtemelen yerel uygulama uyumluluğu ve benzer düzeyde bir AI inference deneyimi olur; ikisi de zaman zaman ortak çabayla çözülüyor gibi
Bunun dışında mümkün olduğunca çok şeyi kilitlemeyi tercih ediyorlar; topluluk ise ne yazık ki iyi açık girişimlerden çok genel çekiciliğe kapılıyor
İkisini de yapabilirsiniz
Başta Alyssa'nın Valve'da çalışıp Mac'teki Linux üzerinde Steam'in çalışmasına yardım etmesi gerektiğini söyleyecektim, ama zaten öyle görünüyor [1]
[1] https://en.wikipedia.org/wiki/Alyssa_Rosenzweig#Career
Valve'ın burada ne planladığı oldukça ilginç bir soru doğuruyor
Zor olur ama Mac'te Steam/Proton çalıştırmak Valve için çok mantıklı; insanlar oyun oynamak için Mac'lerinde Linux boot ederse Apple muhtemelen epey sinir olur
Alyssa R ve Asahi Lina'nın çalışmaları harika
Ancak sürücü koduna aşina değilseniz bunun büyük kısmı gerçekten anlaşılması güç; donanım tarafında da fazla kendine özgü nokta var, keşke böyle kodları yazmak çok daha kolay olsaydı
Cadı kostümü gibi eski usul şakacılığı da oldukça keyifle izledim
Bunu yapabilen bilinen bir donanım olup olmadığını merak ediyorum
Aradım ama PowerPoint ile ilgili blog spam'leri arasında istediğim sonucu bulmak zordu; Google'ın yapay zekası da yardımcı olmadı
Donanımda bu kadar çok şeyin eksik olması ve bu kadar çok kısmın emüle edilmesi başka kimseyi şaşırtıyor mu merak ediyorum
Fiilen her şey emülasyon sayılabilir
GPU üreticilerinin sürücülerini açık kaynak olarak yayımlamak istememesinin nedenlerinden biri de gizli sosun önemli bir kısmının, büyük ölçekli paralel hesaplama mimarisi üzerindeki sürücü yazılımında gerçekleşmesi
Geometry shader'lar baştan standartlaştırılmaması gereken bir hata olarak yaygın biçimde görülüyor; Metal de bunları hiç desteklemediği için ancak macOS'taki eski OpenGL kodlarında karşımıza çıkabilirler, dolayısıyla Apple'ın bunu donanımda desteklememesini suçlamak zor
https://x.com/pointinpolygon/status/1270695113967181827
Alyssa harika biri
GPU çalışmalarıyla ilgili ilk yazısını hatırlıyorum; ardından onun henüz 17 yaşında olduğunu öğrenince beynim patlayacak gibi olmuştu
Herhangi birinin böyle bir işi başarması başlı başına şaşırtıcı; bunu bir gencin yapmış olması ise gerçekten şok edici
Güncel OpenGL ve Vulkan’ı Apple Silicon’a getirmek zaten bir emülasyon katmanı olmadan mümkün değilse, teorik olarak Linux için yerel bir Metal API yapılabilir mi?
Yoksa Metal, macOS SDK’sına fazla mı derinden gömülü?
MoltenVK de Alyssa’nın sunumunda bahsettiği aynı sorunu çözmeye çalışıyor [1, issue’daki son yorum Alyssa’ya ait]
[1] https://github.com/KhronosGroup/MoltenVK/issues/1524
Alyssa Rosenzweig’in sunumunun vardığı sonuç fiilen buydu
Apple, dahili dokümantasyonu bildiği için daha iyi bir düşük seviye uygulama geliştirmek için en iyi konumda
Şu anki ana engel, Metal’e port etmenin tek resmî destek yolu olduğu yönündeki inatçı tutum
Valve, Apple desteği olmadan AAA oyunları Mac’te çalıştıracak kara büyü tarzı bir yöntem çıkarırsa ilginç bir tablo oluşur; Apple kendi platformunda köşeye sıkışmak istemiyorsa bu, yaklaşımını yeniden düşünmesine yol açabilir
Linux için DirectX uygulamaları da var, Proton da bu şekilde çalışıyor
Mesele, bu API’nin Vulkan üzerinde bir katman olarak mı yapılacağı, MoltenVK ya da dxvk gibi tamamen istemci tarafında mı ele alınacağı, yoksa Mesa’ya daha derin mi entegre edileceği
Başlangıç için ilkinin kesinlikle daha kolay olacağını düşünüyorum
Böyle başlıklı bir yazı görünce artık “desteği sonlandırıp acqui-hire oluyorlar” gibi bir şey bekleyecek şekilde şartlanmışım
Alyssa Rosenzweig Turing Award’u hak ediyor
Bu tür /SubscriberLink/ bağlantılarını hep merak etmişimdir
Paylaşmak etik dışı mı acaba
Kişisel e-posta, proje mailing list mesajı, blog yazısı; bunların hepsi uygun ve abone kazanma çabalarını dolanmak için kullanılmadığı sürece paylaşılmasından memnun olduklarını söylüyor
Yalnızca siteyi, yazarları ve editörleri ayakta tutmaları gerektiği için fazla aşırı yaymamamızı nazikçe rica etmişlerdi; benim anladığım kadarıyla bunun finansmanı yalnızca aboneliklerden geliyor
LWN abonelik ücreti oldukça karşılanabilir düzeyde ve Linux ile ilgili konulardaki en iyi derinlemesine teknik haberciliği destekliyor
LWN ile bir bağım yok, sadece memnun bir aboneyim; LWN yazılarından edindiğim bilginin kariyer başarımda da kısmen payı olduğunu düşünüyorum
İnsanların abone olabilmesi için önce LWN’in varlığından haberdar olması gerekiyor
FAQ’ya bakabilirsiniz: https://lwn.net/op/FAQ.lwn#slinks
LWN’in ödeme duvarı kendine özgü; tüm içerik bir hafta sonra ücretsiz açılıyor
Abone bağlantıları, imkânınız varsa abone olmayı teşvik etmek için var
Yanılıyor olabilirim ama daha önce ücretli olan içeriğin, muhtemelen yazı bazında açılması için finanse edilmiş gibi okunuyor
Gerçekten böyle olup olmadığını bilen var mı merak ediyorum