OpenGL ES uygunluk sertifikası alan ilk M1 GPU sürücüsü
(rosenzweig.io)- M1·M2 serisi GPU'larda OpenGL ES 3.1 uygulamalarını standarda uygun şekilde çalıştırabilen bir Linux sürücüsü sunuldu
- Asahi Linux'un tersine mühendislikle geliştirilen ücretsiz ve açık kaynak sürücüsü, M1·M2 grafik donanımında Khronos uygunluk testlerini geçen tek OpenGL ES 3.1 uygulaması
- Sertifikasyon; resmî testlerin geçilmesi, Khronos'a gönderim ve 30 günlük inceleme süreci sonrasında tamamlanıyor; M1, M1 Pro/Max/Ultra, M2, M2 Pro/Max girdileri kaydedildi
- OpenGL ES 3.1, hazirandaki deneysel OpenGL ES 3.0·OpenGL 3.1 desteğini güncelliyor ve compute shader ile image atomic işlemlerini ekliyor
- M1'de image atomic işlemleri için özel komut olmadığından adres hesaplamasıyla dolaylı bir yol kullanıldı; ardından bit interleave komutu bulunarak 10 komut 1 komuta indirildi
M1·M2 için OpenGL ES 3.1 uygunluk sertifikası
- M1·M2 serisi GPU'lar için OpenGL ES 3.1 uygunluk sertifikalı bir sürücü sunuldu
- OpenGL ES 3.1 uygulamalarıyla uyumlu
- Linux kurulumu ile kullanılabiliyor
- Mevcut Asahi Linux kullanıcıları, dağıtıma göre yükseltme komutlarıyla en yeni sürücüyü alabilir
- Fedora:
dnf upgrade - Arch:
pacman -Syu
- Fedora:
- Tersine mühendislikle geliştirilen ücretsiz ve açık kaynak grafik sürücüsü asahi/mesa üzerinde yayımlanıyor
- Bu sürücü, M1·M2 serisi grafik donanımında dünyadaki tek OpenGL ES 3.1 uygunluk sertifikalı uygulama
- On binlerce testi geçerek doğruluğunu kanıtlıyor
- Sektör standardı kuruluşundan onay alıyor
Khronos süreci ve kayıtlı çip aileleri
- Uygunluk sertifikası almak için uygulamanın resmî uygunluk test paketini geçmesi gerekiyor
- Test paketi, spesifikasyondaki tüm özellikleri doğrulayacak şekilde tasarlanmış
- Test sonuçları standart kuruluşu Khronos'a gönderiliyor
- 30 günlük inceleme süresi içinde sorun çıkmazsa uygunluk sertifikalı uygulama oluyor
- Khronos web sitesinde şu sürücüler uygunluk sertifikalı uygulama olarak kayıtlı
- Bu başarı yalnızca OpenGL ES ile sınırlı değil
- M1 için tüm grafik standartları içinde ilk uygunluk sertifikalı uygulama anlamına geliyor
Üretici sürücüsü ile standart API'ler arasındaki boşluk
- Üreticinin M1 sürücüsü, Vulkan, OpenGL ve OpenGL ES dahil hiçbir standart grafik API'sinde uygunluk sertifikası almadı
- Linux kullanılmayan M1·M2 ortamlarında, standarda dayalı uygulamaların çalışacağına dair bir garanti yok
- Vulkan örneğinde MoltenVK, özel mülk bir sürücünün üzerine Vulkan'ın bir kısmını katmanlıyor
- İlgili özel mülk sürücüde temel özellikler eksik
- Geçerli Vulkan uygulamaları bozulabiliyor
- Bu durum, M1·M2 bilgisayarlarını Linux'a geçirmemiş geliştirici ve kullanıcıların tamamı için bir engel oluşturuyor
- Asahi Linux sürücü geliştirmesinin hedefi, standart yazılımların M1'e özel hack'ler veya portlar olmadan çalışması
- Özel mülk sürücülerden, özel API'lerden ve standart uygulamaların reddedilmesinden memnun değil
- Spesifikasyona uygun açık standart uygulamalarını ekosistemin tercih edilmesi gereken yönü olarak görüyor
OpenGL ES 3.1'in temel yeni özellikleri
- OpenGL ES 3.1, haziranda sunulan deneysel OpenGL ES 3.0 ve OpenGL 3.1 desteğini güncelliyor
- Başlıca yeni özellik compute shader
- Esas olarak grafik uygulamalarında genel amaçlı hesaplamaları hızlandırmak için kullanılıyor
- 3D oyunlar fizik simülasyonunu compute shader üzerinde çalıştırabiliyor
- Simülasyon sonucunu doğrudan render etmede kullanmak, GPU ile CPU fizik simülasyonu arasındaki senkronizasyondan doğan duraklamayı azaltabiliyor
- Sonuç olarak oyunlar daha hızlı çalışabiliyor
Image atomic işlemleri neden gerekli?
- OpenGL ES'in önceki sürümleri, uygulamaların ekrana gösterim için görüntüleri okumasına izin veriyordu
- ES 3.1, uygulamaların genellikle compute shader içinde görüntülere yazmasına izin veriyor
- Böylece görüntü işleme algoritmalarını sabit işlevli 3D işlem hattına uydurma zorunluluğu azalıyor
- GPU, aynı anda binlerce iş parçacığı çalıştıran büyük ölçekli paralel bir yapı
- İki iş parçacığı aynı konuma yazarsa sonuç çalışma sırasına göre değişebiliyor
- Bu duruma race condition deniyor
- Atomik bellek erişimi, race condition ile başa çıkmanın temel çözümü
- Bellek alt sistemindeki özel donanım, seçilen işlemler için iş parçacığı sırasından bağımsız olarak tutarlı sonuçları garanti ediyor
- Modern grafik donanımı toplama gibi çeşitli atomik işlemleri destekliyor
- OpenGL ES uzantısı OES_shader_image_atomic, görüntü pikselleri üzerinde atomik işlemler ekliyor
- Bu uzantı ES 3.2'de zorunlu
- Örneğin bir compute shader,
(10, 20)pikselinin değerini atomik olarak artırabiliyor
M1'de image atomic işlemleri nasıl uygulandı?
- Diğer GPU'lar, image atomic işlemleri için özel komutlar sunduğundan sürücü uygulaması basit oluyor
- M1'de image atomic işlemlerine özel donanım komutu yok
- Görüntü dışı atomik işlemler var
- Atomik olmayan görüntü işlevleri de var
- Bu yüzden piksel üzerinde doğrudan atomik işlem yapmak yerine, pikselin bellek adresi hesaplanıp o adres üzerinde genel atomik işlem uygulanıyor
- Görüntü bellekte doğrusal yerleştirilmişse adres hesabı basit
- Y koordinatı, satır başına bayt sayısı olan stride ile çarpılıyor
- X koordinatı, piksel başına bayt sayısı ile çarpılıyor
- Bu iki değer toplanarak ilk piksele göre bayt ofseti elde ediliyor
- İlk piksel adresine ofset eklenerek nihai adres bulunuyor
- Gerçek görüntüler genellikle doğrusal yerleştirilmiyor
- Modern grafik donanımı, önbellek verimliliğini artırmak için X·Y koordinatlarını interleave ediyor
- Bellekteki piksel yerleşimi satır satır değil, spirale yakın bir eğriyi izliyor
Bit interleave optimizasyonu ve gizli komutun keşfi
- X·Y koordinatlarını interleave ederken her biti tek tek maskeleyip kaydırmak verimsiz
- İyi bilinen bit manipulation algoritması, bit gruplarını karıştırarak sorunu paralelleştiriyor
- Bu algoritma shader kodunda uygulanınca performans iyileşiyor
- Pratikte her koordinatın yalnızca alt 7 biti interleave ediliyor
- X·Y koordinatları 32 bitlik bir register'ın alt ve üst 16 bitine yerleştirilip 32 bitlik komutla aynı anda işlenebiliyor
- Komut sayısı yarıya indirilebiliyor
- GPU'nun shift-and-add birleşik komutu da kullanılıyor
- Bu teknikler birleştirildiğinde M1 GPU assembly'sinde interleave işlemi 10 komutla yapılabildi
- Sonrasında özel bir bit interleave komutu olasılığı araştırıldı
- PowerVR'da
shflshuffle komutu bulunuyor - M1 GPU, PowerVR'dan alınmış öğeler taşıdığı için benzer bir komut olabileceği değerlendirildi
- Özel mülk derleyici test shader'ını derlerken bu komutu kullanmadığından, yalnızca derleme çıktısını gözlemleyerek tersine mühendislik yapmak zordu
- PowerVR'da
Tahmin ve doğrulamayla interleave komutunun bulunması
- Dougall Johnson, zaten bilinen komut kodlamalarına dayanarak adayı tahmin etti
- Bit reverse komutunda işlemi belirleyen 2 bitlik bir alan var ve değeri
01- Set edilmiş bit sayısını sayma komutunda bu değer
10 - İlk set biti bulma komutunda
11 - Bilinen karmaşık bit işleme komutları bu üç değeri kullanıyor
- Set edilmiş bit sayısını sayma komutunda bu değer
- Geriye kalan
00değeri, gözlemlenmemiş bilinmeyen değerdi- Bir interleave komutu varsa, bit reverse komutuna benzer ama işlem kodu
00olan bir komut olabileceği değerlendirildi
- Bir interleave komutu varsa, bit reverse komutuna benzer ama işlem kodu
- Bilinen üç komutta yalnızca bir giriş kaynağı var, ancak interleave komutu iki kaynak gerektiriyor
- M1 GPU komutları genelde kaynak konumlarını tutarlı biçimde kodluyor
- İki kaynaklı aritmetik komutlarda ikinci kaynağın bulunduğu yerde boş bir alan vardı; bunun ikinci kaynak olabileceği varsayıldı
- Doğrulama, derleyiciyi değiştirip çarpma gibi iki kaynaklı tamsayı işlemlerini tahmin edilen interleave kodlamasıyla değiştirmek şeklinde yapıldı
- Bu işlem compute shader içinde kullanıldı
- Test shader'ı, mümkün olan tüm girdiler için bilinmeyen komutun interleave sonucunu döndürüp döndürmediğini doğruladı
- Komut iki adet 16 bitlik kaynak aldığı için yaklaşık 4 milyar girdi vardı
- M1 GPU, sürücünün yeni compute desteği sayesinde tüm girdileri 1 saniyeden kısa sürede doğruladı
- Sonuçta 10 komutluk vektörleştirilmiş assembly, tek bir interleave komutuyla değiştirildi
- Bu yöntem hızlı ve uygunluk testlerini de geçiyor
1 yorum
Hacker News yorumları
Apple’ın OpenUSD render/animasyon/CAD/3D sahne formatı konusunda nVidia, Adobe, Autodesk, Microsoft gibi şirketlerle iş birliği yapmasıyla OpenGL·Vulkan desteğinin iyileşip iyileşmeyeceğini merak ediyorum.
OpenUSD’nin özü “her yerde tutarlı biçimde render edilen tek bir dosya formatı” ise, Apple bunu daha fazla 3D yazılım şirketini macOS’a çekmenin bir aracı olarak kullanabilir.
Bundan sonrası için Apple’ın film ve oyun üretim pipeline’larında güç kazanan mevcut OpenGL/Vulkan standartlarını izlemesi ya da tersine Metal’i daha güçlü şekilde dayatıp dünyayı Metal + macOS tarafına çekmeye çalışması gibi iki yol var gibi görünüyor.
Gönlüm ilkinden yana ama içgüdülerim Apple’ın ikincisini tüm gücüyle zorlayacağını söylüyor; ayrıca yalnızca Apple değil, nVidia, Autodesk, Adobe ve Microsoft da kendi kontrollerinde olmayan standartları pek sevmez.
iMac ve ilk OS X; USB, JPEG, MPEG, mp3, PostScript, yerleşik TCP/IP, .rtf gibi standartları güçlü biçimde öne çıkarmıştı, Jobs da bunu vurgulamıştı.
Sonra uçurumun kenarından toparlanınca yeniden “değer katmaya” başladı; iPhone da başlangıçta kapalı ve berbat Flash ya da ham “mobil HTML” yerine kendini bir HTML cihazı olarak vurguluyordu.
Bugün de pazar hâkimiyetinin zayıf olduğu alanlarda H.264, Matter/Thread gibi kendi kontrolünde olmayan standartları destekliyor.
Donanım ve yazılımı güçlü biçimde birleştirerek amaçladığı kullanıcı deneyimini oluşturduğu için, bu deneyimin başkalarının elinde şekillenmemesi adına belli ölçüde kontrol edebileceği standartları uygulamak istemesini anlayabiliyorum.
USB-C gibi yönü henüz tam kesinleşmemiş endüstri standartlarında da erken davranırsa yönü etkileyebileceği için Apple’ın benimsediği durumlar oluyor.
Adobe, Autodesk, Blender gibi çoğu yazılım işletim sistemine göre farklı backend’leri zaten destekliyor; macOS’ta buna Metal de dahil.
OpenGL çok eski, iyi sürücü kullanmak neredeyse kâbus gibi ve yüksek performanslı uygulama kodu yazmak bile zor; bu yüzden özlenecek bir şey değil.
Yine de Metal’i yapmak yerine Vulkan’ı destekleselerdi isterdim; fakat Linux dışında Vulkan genelde ikinci sınıf vatandaş gibi ve buna rağmen hedeflemek için gayet makul bir ikinci sınıf vatandaş.
Oyunlar ya da Steam desteği açısından, birçok oyun API işini motora bırakıyor; API ile doğrudan uğraşacak kapasitesi olan ekipler de çok ileri seviye özellikler kullanmıyorsa MoltenVK ile muhtemelen idare edebilir.
Hayatım boyunca çapraz platform için OpenGL’i çok kullandım ama küresel durum, kullanılmaması gereken fonksiyonlar, tuzaklar, devasa extension header’ları ve zor hata ayıklama yüzünden gerçekten berbat bir API’ydi; Vulkan lafı uzatıyor ama birçok açıdan aslında daha kolay.
Ama şu an kullandığım Mac, yalnızca USB-C portlarıyla birçok çevre birimine ve büyük monitöre standart protokoller üzerinden bağlanıyor.
Genel olarak Apple, standartlar yeterince iyiyse açık standartları tercih ediyor gibi; USB2’nin Lightning’in yaptığı birçok şeyi yapamadığı dönemde Lightning’i geliştirdi ama USB-C çıkınca Mac ve iPad’de hemen benimsedi, iPhone’da ise ne yazık ki işi ağırdan alıyor.
Asahi ve Alyssa, tersine mühendisliğin devleri; yaptıkları iş inanılmaz.
Apple’ın onları işe almaya çalıştığını ya da zaten denediğini ama reddedildiğini düşünüyorum.
Bu yetkinliği iş açısından kullanmak için Valve’ın Apple’dan daha fazla nedeni olduğu da söylenebilir.
Normalde çalışanların ücreti, yarattıkları kâra kıyasla düşüktür; IT’de bu özellikle böyledir.
Yetenekli kişilerin bir şirket kurup hizmetlerini adil fiyata satması daha iyidir, ancak bazı ülkelerde büyük şirketler hükümete lobi yaparak bu yolları kapattırdı.
Atomik işlem hilesi çok tatmin ediciydi; PowerVR soy ağacından swizzle komutunu çıkarsamaları da özellikle etkileyici.
Apple mühendislerinin de buradan bir şeyler öğreneceğini ya da en azından bu zekâyı takdir edeceğini düşünüyorum.
Eskiden Accolade’da Sega Genesis video donanımının tersine mühendisliği yapılırken, mühendislerin kamuya açık Texas Instruments TMS9918 VDP belgelerini başlangıç noktası alıp Genesis’in (Mega Drive) 9918 türevi VDP’sini çıkarsadığı olayı hatırlatıyor.
Açık olmak gerekirse bu, ilk uygunluk sertifikalı Linux sürücüsü değil; bundan daha büyük bir anlamı var.
Apple’ın kendisi de OpenGL ES 3.1 ile uyumlu olmadığı için, bu kelimenin tam anlamıyla herhangi bir işletim sisteminde M serisi için ilk uygunluk sertifikalı OpenGL ES 3.1 sürücüsü.
Bu yüzden ekibe bağış yapma çağrısı geliyor.
https://asahilinux.org/support/
Böyle bir seçenek varsa nereden yapabileceğimi bilmek isterim; yoksa daha sonra sadece o bağlantıyı kullanırım.
Artık önerilmeyen macOS OpenGL uygulamalarını debug etmeye çalışınca bu sorun çok net ortaya çıkıyor
Çünkü soyutlama katmanı gerçek OpenGL durumunu eski Apple OpenGL debugger'ının okuyabileceği şekilde açığa çıkarmıyor
OpenGL’in içeride Metal üzerinde çalışmadığı eski bir macOS kurulu eski bir Mac’iniz yoksa, varsayılan debugger ile macOS’ta OpenGL’i fiilen debug etmek mümkün değil
Debugger ya da uygulama doğrudan çöküyor
Bu daha çok oyunlara yardımcı olacak gibi görünüyor, derin öğrenmeye ise pek faydası yok
Mac M1’in en çekici yanı büyük bellek kapasitesi; birden fazla karta dağıtılamadığı için eğitim için çok uygun olmayabilir ama Stable Diffusion, LLaMA gibi büyük modeller için çıkarım motoru olarak iyi
SYCL, Khronos Group’un üreticiden bağımsız yüksek seviyeli programlama çatısı; ancak uygulama desteği sınırlı ve Intel’in desteğiyle zamanla iyileşmesi umuluyor
Vulkan Compute, compute shader’lar ile sorunun etrafından dolaşıyor ama uygulama desteğinin durumunu çok iyi bilmiyorum
SYCL, OpenCL ve OpenCL’in SPIR-V uzantısı üzerine uygulanabilir; ancak güçlü üretici bağımlılığı nedeniyle bu yol Intel ve Mesa dışında büyük ölçüde terk edildi ve günümüzde çoğunlukla ROCm, HIP, CUDA gibi her GPU üreticisinin kendi API’leri için backend olarak uygulanıyor
Aynı yaklaşımı Metal’e uygulamak çok zor olurdu; Mesa’da Intel ve AMDGPU için OpenCL+SPIR-V deneysel desteği var, teoride Apple Silicon’a genişletilebilir, ancak Apple Silicon’da OpenCL şu anda hiç desteklenmiyor ve en fazla yol haritasında yer alan bir şeydi
Derin öğrenme çalıştırmak için CUDA, ROCm, MPS gibi backend’lere ihtiyaç var
PyTorch modelini büyük bir CUDA sunucusunda eğitip çıkarımı MacBook Air’de çalıştırmak nispeten kolaydı
Ancak eiln, GPU yerine özel donanımı kullanabilmek için Apple Neural Engine sürücüsü yazdı ve ileride linux-asahi’ye birleştirilmesi planlanıyor
Asahi Lina ve iki kişinin çok az bütçeyle büyük bir şirketi yendiği ifadesi hoş, ama gerçekte yenmekten çok Apple’ın bunu umursamamasına daha yakın
Apple zaten o yarışa hiç katılmadı
“Çok az bütçeyle iki kişi büyük şirketi yendi” şeklindeki kibar ifade hoşuma gidiyor
Bu Apple için açıkça utanç verici bir durum; Apple standartlar ya da uyumlulukla ilgilenmiyor ve insanların kendi kapalı bahçelerinde hapsolmasını istiyor
iOS geliştiricisi olmasaydım Apple ekosistemini çoktan terk etmiş olurdum
Donanımını seviyorum, 80’ler ve 90’lardaki Apple gibi yaratıcılığı ve insan odaklılığı öne çıkaran markayı da sevmiştim; ama bugünkü şirket, politik olarak doğru pazarlama videolarının arkasında açgözlülükle çürümüş görünüyor
Son yükseltmemde alternatiflere baktım ama Apple’dan çıkmak için bitmek bilmeyen tavizleri kabul etmek gerekiyordu
iPhone yerine saf Android ve uzun destek umuduyla Pixel’e baktım, ama pil sorunları konuşulup duruyordu; yazılımın olgunluğu, uygulama ekosistemi ve kararlılık da engeldi
Temel model MacBook Air M1’in yapı kalitesine, piline ve kararlılığına yaklaşan, fiyat/performansı iyi bir ürün bulmak da zordu
iPad’de çizgi roman ve dergi de okuyorum; tablet pazarında yıllardır alternatifin ne olduğunu bilmiyorum, Apple Watch’tan belki vazgeçebilirim ama sorunsuz çalışıyor ve üçüncü taraf aksesuarı bol
Artık her gün yeni ROM yüklediğim dönem geride kaldı; kararlılık ve kullanım kolaylığında Apple’ı yenmek zor gibi, bu da üzücü
Herkesin işinin güvende olmasının tek nedeni, o iki kişinin kim olduğunu kimsenin tam olarak bulamaması
Apple kendi silikonunu yaptı ve tüm platformu kurdu; başka işletim sistemlerinin çalışabilmesini bırakmış olmasının basit bir hata olduğunu düşünmek zor
Üçüncü taraf geliştirme için bilinçli olarak kapıyı açık bıraktığı açıkken Apple’ı suçlayan havayı görmek hayal kırıklığı yaratıyor
Örneğin sürekli bir Vulkan implementasyonunu desteklemek ciddi kaynak ve yayın takvimi yükü getirir; bunun için iş açısından bir gerekçe gerekir
“Utançtan kaçınmak için” muhtemelen yeterli değildir
Topluluk iyi niyeti argümanı mümkün olabilir, ama Apple’ı “politik olarak doğru pazarlama videolarının arkasında açgözlülükle çürümüş şirket” diye niteleyen insanların sempatisinin peşinden koşacaklarını sanmıyorum
Uygunluk testleri açık kaynak değil; GitHub’daki ayrı “conformance suite” ise Khronos’un dahili test paketi değil, Google’ın dEQP’sine dayanıyor
Uygulamada epey büyük hatalar ve boşluklar olsa bile “standart uyumluluk sertifikası” alınabiliyor
Apple yalnızca OpenGL 3.1 desteği sözü verdi; M1 için OpenGL sürücüsünü de mevcut uygulamalar çalışmaya devam etsin diye Metal üzerinde bir emülasyon katmanı olarak yeniden yazdı, ancak daha yeni OpenGL sürümlerini uygulamayacak ve buna ihtiyacı da yok
Apple’a yönelik çok eleştiri var ve Metal API ile araçlarını daha iyi hâle getirmek için bolca alan bulunuyor, ancak OpenGL’i umursamamak burada gayet makul bir karar
Orijinal metinde ‘Apple’ kelimesinin bir kez bile geçmemesi, sadece ‘üretici’ ve ‘büyük şirket’ denmesi ilginç
Bilinçliyse hukuki bir nedeni olup olmadığını merak ediyorum
İlgi odağı Apple değil, M1/M2 mimarisinde Linux’u düzgün çalıştırmak; hedef Microsoft, Amazon ya da Google olsaydı da aynı şekilde ele alınırdı
Bu sürücünün geliştirilme sürecini gösteren canlı yayını izlemek eğlenceliydi; gerçekten şaşırtıcı bir iş
Şimdiye kadar gördüğüm en şaşırtıcı düşük seviye programlama çalışmalarından biri