Blog Detayları

Geleneksel olarak bir GPU sürücüsü geliştirmek, yıllar süren devasa bir mühendislik çabası gerektirir. Ancak Cody Ho ve iş ortağı Niklas, bu algıyı kökten değiştirerek M4 Mac Mini ve MacBook Neo cihazları için tam olarak OpenGL ES 3.0 uyumlu bir GPU sürücüsü geliştirmeyi yaklaşık bir ayda başardı. Bu başarı, Chrome ve Firefox tarayıcılarında WebGL'in sorunsuz çalışmasını ve Minecraft gibi ağır grafikli oyunların 200 fps hızında akıcı bir şekilde çalışmasını mümkün kıldı. Bu süreç, Apple'ın AGX olarak adlandırdığı GPU'nun inanılmaz derecede karmaşık yazılım arayüzünü (firmware ABI) ve kullanıcı alanı bileşenlerini tersine mühendislik yoluyla çözmeyi gerektirdi. Tüm bu çalışmalar, kanıtlanabilir şekilde temiz oda (clean room) prensiplerine uygun olarak, iyi kurulmuş teknikler kullanılarak şeffaf bir şekilde gerçekleştirildi.

Projenin temel motivasyonu, daha önce macOS'u tersine mühendislik yapmak için geliştirilen bir hipervizörün pratik bir ürüne dönüştürülmesiydi. Modern sistemlerde GPU, CPU'nun yapması gereken işlerin katlar kat daha hızlı ve enerji verimli bir şekilde işlemesi için vazgeçilmezdir. Hedef, M4 Mac Mini ve MacBook Neo için hem OpenGL hem de yakın zamanda Vulkan uyumlu sürücüler oluşturmaktı. Günler içinde bitirmek çok iyimser bir tahmin olsa da, haftalar içinde tamamlanması sektör standartlarına göre devrim niteliğinde bir hız artışıdır. Bu süre zarfında, M4, A18 Pro ve büyük ölçüde M5 kullanıcı alanları yalnızca canlı sondalama (live probing) teknikleriyle tersine mühendislik yapılarak keşfedildi. Apple'ın kendi sürücüsünün üretmediği, ancak donanımın desteklediği özellikler ve komutlar da bu süreçte ortaya çıkarıldı.

Geliştirilen sürücü, tamamen işlevsel bir kullanıcı alanı sürücüsünü, özel bir IR/shader derleyicisini, komut akışı oluşturucuyu ve daha birçok bileşeni içerir. En zorlu kısımlardan biri, daha önce geliştirilen hipervizörden alınan izler kullanılarak AGX firmware ABI'sinin baştan sona tersine mühendisliğinin yapılması ve bu ABI için tam bir Linux çekirdek sürücüsünün implemente edilmesiydi. Bu süreçte Apple'ın ikili dosyalarına (binaries) asla bakılmadı; yalnızca donanım izleri ve kendileri tarafından oluşturulan shader'lar kullanıldı. Kullanıcı alanı grafik tersine mühendisliğinde, gerekli Apple blob'ları opak nesneler olarak ele alındı. Bu blob'lar hakkında bir arkadaşın yazdığı dokümantasyon sayesinde, kendi temiz oda implementasyonlarını büyük ölçüde deneme-yanılma yöntemiyle ve körü körüne deneysel süreçlerle inşa ettiler. Tüm deneyleri, işin menşeini herkesin doğrulayabilmesi için kamuya açık olarak yayımladılar.

Bu blog yazısı ve teknik süreç, modern GPU sürücülerindeki temel mimari ayrımı yansıtarak iki ana bölüme ayrılır: kullanıcı alanı ve çekirdek alanı. Çekirdek, firmware ile arayüz kurmaktan, tamponları (buffer) ayırmaktan ve zamanlamayı (scheduling) yönetmekten sorumludur. Oysa bu tamponların içeriği ve zamanlanan işlerin doğası, çekirdek için opak kalır. Kullanıcı alanı ise GPU'nun nasıl çalıştığını asıl anlayan ve bu tamponları doğru verilerle dolduran katmandır. Apple Silicon mimarisinde çekirdek sürücüsü donanımla doğrudan konuşmaz; bunun yerine, RTKit adlı özel bir gerçek zamanlı işletim sistemi (RTOS) üzerinde çalışan GPU firmware'i ile iletişim kurar. Bu durum, çekirdek sürücüsü geliştirmenin ilk adımının donanımla konuşmak değil, firmware ABI'sini çözmek olduğunu gösterir.

Firmware ABI'si, bu projedeki en sinir bozucu ve karmaşık kısımdı. Apple, makul bir arayüz tasarlamak yerine, standart bir çekirdek sürücüsünü ikiye bölmüş ve yarısını AGX'in içine firmware olarak yerleştirirken, diğer yarısını da bellekteki paylaşımlı yapılarla (shared structs) iletişim kuracak şekilde tasarlamıştır. Bu yapıların çoğu, asla değiştirilmemesi ve tersine mühendislik yoluyla öğrenilmesi gereken firmware tarafından sahip olunan alanlarla, host tarafından kontrol edilen alanların iç içe geçtiği karmaşık bir yapıya sahiptir. M1 ve M2 modellerindeki paylaşımlı bellek ağacının karmaşıklığı, bu ABI'nin ne denli detaylı ve zorlu olduğunu gözler önüne serer. Bu seviyede bir mimari derinlik, yazılım mimarisi ve sistem programlaması açısından mühendislik topluluğu için ilham verici bir vaka çalışması niteliğindedir.

Bu çalışma, donanım seviyesinde sürücü geliştirme sürecinin ne kadar derin ve çok katmanlı olduğunu göstermektedir. Sadece bir API'nin sarmalanması değil, donanımın en alt katmanındaki firmware mantığının, bellek yönetiminin ve komut akışının tamamen anlaşılarak yeniden inşa edilmesi söz konusudur. Temiz oda yaklaşımı, yasal ve etik sınırlar içinde kalınarak, mevcut kapalı kaynak kodlara bağımlılık olmadan, saf donanım davranışlarının gözlemlenmesiyle yeni bir yazılım katmanı oluşturulduğunu kanıtlamaktadır. Bu yöntem, özellikle Apple gibi kapalı ekosistemlerde çalışan geliştiriciler için, donanımın gerçek yeteneklerini keşfetmenin ve bunları açık kaynak platformlara taşımanın mümkün olduğunu gösteren kritik bir referans noktasıdır.

Sonuç olarak, bu proje bir ay gibi kısa bir sürede, yıllar alacak bir işin nasıl verimli bir şekilde çözülebileceğinin somut bir örneğidir. Hipervizör tabanlı izleme tekniklerinin, geleneksel tersine mühendislik yöntemlerine kıyasla ne kadar güçlü ve doğru sonuçlar ürettiğini kanıtlamıştır. Geliştirilen sürücünün henüz nihai kullanıcılar için hazır olmamasına rağmen, süreç şeffaf bir şekilde belgelenmiş ve kod tabanları paylaşılmıştır. Bu, topluluk tabanlı geliştirme ve açık kaynak katkılarının, en kapalı donanım ekosistemlerinde bile bileşenlerin yeniden kullanılabilir ve anlaşılır hale getirilebileceğini göstermektedir. M4 Mac Mini üzerindeki bu başarı, gelecekteki Linux ve açık kaynak işletim sistemleri için GPU desteğinin ne kadar genişleyebileceğine dair umut verici bir sinyal niteliğindedir.