Rust ile bir GPU Çekirdek Sürücüsü Yazmak: GPU sürücülerinin çalışma prensiplerine kısa bir giriş

• Bu yazı, Rust ile geliştirilen Linux çekirdeği için en son GPU sürücüsü Tyrin geliştirme sürecine ve GPU sürücülerinin çalışma prensiplerine odaklanır
• GPU sürücü geliştirmesinde UMD (Kullanıcı Modu Sürücüsü) ile KMD (Çekirdek Modu Sürücüsü) rollerinin ayrımı ve etkileşimi VkCube örneğiyle açıklanır
• UMD, yüksek seviyeli API'leri GPU'nun anlayabileceği düşük seviyeli komutlara dönüştürürken, KMD bellek tahsisi, iş zamanlama, cihaz başlatma gibi temel görevleri üstlenir
• Tyr sürücüsünün sunduğu API, Panthor ile aynıdır ve cihaz sorgulama, bellek yönetimi, grup yönetimi, iş gönderme, Tiler yığın yönetimi gibi bileşenlerden oluşur
• Bir sonraki yazıda Arm CSF donanım mimarisi ve temel bileşenleri (ör. MCU) ile önyükleme süreci ele alınacaktır

---

Giriş: Rust tabanlı modern bir GPU çekirdek sürücüsü geliştirme

• Bu yazı, Linux çekirdeğinde Arm Mali CSF tabanlı GPU'yu destekleyen en yeni Rust GPU çekirdek sürücüsü Tyr geliştirme serisinin ikinci yazısıdır
• Pratik bir örnek olarak Vulkan API ile dönen bir küpü render eden basit bir 3D program olan VkCube seçilerek GPU sürücüsünün iç çalışma mantığı anlatılır
• VkCube'un sade yapısı, GPU sürücüsü çalışma prensiplerini öğrenmek için uygun bir örnektir

GPU Sürücüsünün Temelleri: UMD ve KMD'nin Rolü ile Yapısı

• User Mode Driver(UMD) ve Kernel Mode Driver(KMD) olmak üzere iki katmandan oluşur
  • UMD: panvk (Mesa'nın Vulkan sürücüsü vb.) gibi genel program API'lerini (Vulkan, OpenGL vb.) uygular
  • KMD: Tyr gibi yetkili bir kernel seviyesindeki donanım sürücüsü olup Linux çekirdeğinin bir parçası olarak çalışır
• Kernel mod sürücüsü, UMD ile gerçek GPU arasındaki bağı kurar; UMD ise API komutlarını GPU'nun anlayabileceği komut setine çevirir
• UMD, bir sahneyi oluşturmak için gereken geometri, doku, shader gibi verileri hazırlar ve çalıştırmadan önce bunların GPU belleğinde ayrılmasını KMD'den ister
• Shader, GPU'da çalışan bağımsız bir programdır; VkCube'da küp yerleştirme, renklendirme ve dönüşüm uygulama gibi görevleri üstlenir. Shader çalıştırmak dış veriler (geometri, renk, dönüş matrisi vb.) gerektirir
• UMD, hazırlanan komutları (ör. VkCommandBuffers) KMD'ye ileterek çalıştırır; iş tamamlandığında bildirim alır ve sonucu belleğe yazabilir

KMD (Kernel Mode Driver)'in Başlıca Sorumlulukları

• GPU belleği tahsis ve eşleme (uygulama bazında izolasyon sağlar)
• Donanım kuyruğuna iş gönderme ve tamamlanma anında kullanıcıya bildirim verme
• Asenkron ve paralel donanım ortamlarında iş bağımlılığı yönetimi zorunludur; doğru sonuç için KMD, zamanlama ve bağımlılık doğrulama görevini üstlenir
• Cihaz başlatma, saat/gerilim regülatörü sürme, başlangıç kodunun çalıştırılması, birden fazla istemciye donanımın adil şekilde paylaşılması için erişim rotasyon yönetimi gibi ek görevler de dahildir

Karmaşıklığın Yeri: UMD ile KMD'nin İş Bölümü

• GPU sürücüsünün karmaşıklığının çoğu UMD'de yoğunlaşır
  • UMD: Yüksek seviyeli API komutlarını donanım komutlarına çevirir
  • KMD: UMD'nin düzgün çalışması için bellek izolasyonu, paylaşım ve adil erişim gibi kritik işlevleri sağlar

Tyr'nin Sağladığı Sürücü Arayüzü (API) Yapısı

• Tyr sürücü API'si (=Panthor ile aynı) 5 ana gruba ayrılır
  1. Cihaz Bilgisi Sorgulama: DEV_QUERY (IOCTL ile GPU donanım bilgilerini kontrol etme, ROM alanını kullanma)
  2. Bellek Tahsisi ve İzolasyon: VM_CREATE, VM_BIND, VM_DESTROY, VM_GET_STATE, BO_CREATE, BO_MMAP_OFFSET
  3. Zamanlama Grubu Yönetimi: GROUP_CREATE, GROUP_DESTROY, GROUP_GET_STATE (ayrıntılar bir sonraki yazıda)
  4. İş Gönderme: GROUP_SUBMIT (cihaz komut tamponu ile GPU'da çalıştırma isteği)
  5. Tiler Heap Yönetimi: TILER_HEAP_CREATE, TILER_HEAP_DESTROY (tile tabanlı render GPU'larının bellek gereksinimlerini karşılar)
• Bu API'ler doğrudan çizim yapmakla ilgili değildir; gerçek komut yürütme UMD tarafından yapılır ve KMD yalnızca donanıma erişim için yalnızca bu arayüzü sağlar

Sonuç ve Sonraki Plan

• Bu yazıda GPU sürücüsünün genel mimarisi ve iç akışı ile Tyr'nin sunduğu temel API'ler incelendi
• Bu temele dayanarak serinin ilerleyen yazılarında Arm CSF donanım mimarisi, Mikro Kontrolör Birimi (MCU) gibi kritik bileşenler ve sürücü başlatma süreci ele alınacaktır

[GN⁺]

Hacker News Yorumları

• Gerçekten iyi bir yazıydı ama biraz kısa kaldı; daha yeni ilginç olmaya başlamışken bitmiş gibi hissettirdi, bir sonraki bölümü bekliyordum
  • Bir sonraki hafta da yine çok heyecanlı bir bölüm geleceğini umuyorum; GPU'da beklemede olan komutların kuyruktan çıkıp çalıştırılmasını göreceğiz. Bu yazının ele aldığı soyutlama seviyesi, kullanıcı/çekirdek sınırında veri aktarımıyla ilgili. Bu yüzden çoğunlukla sadece kuyruk ve tampon yönetimi işleniyor, doğrudan hesaplama kısmı az. Asıl önemli olan şey, kuyruğa atılan komutlar çalıştırılmaya başladığında ortaya çıkıyor. GPU'dan da ters yönde bir başka komut tamamlama sinyali iletiliyor; bu da merak uyandırıcı. Bu tür asenkron işlemelerin çoğu sürücüde değil kullanıcı tarafı kodunda ele alınıyor; sürücü yalnızca tamamlama sinyali ileten bir yapı sunuyor.
• rk3588 cihazlarından birini masaüstüm olarak kullanıyorum ve panfrost ile çalıştırıyorum ama ara sıra Firefox ekranında siyahlaşma veya şeffaf bölgeler oluşuyor; garip bir hata bu
  • RK3588 aslında panfrost değil, yazının konusu olan panthor sürücüsünü kullanıyor
• uring_cmd'nin ioctls yerine kullanılması düşünülmüş müydü bilmiyorum; bu projenin sıfırdan inşa edilmesi nedeniyle uygulanabilir gibi de görünüyor, yani bunun neredeyse hiç avantajı olmadığını düşündüğünüz sebep neydi diye merak ediyorum
  • GPU zaten kendi asenkron komut kuyruğuna sahip olduğu için IOCTL, o kuyruk içine yazma işini zaten nispeten uygun maliyetle yapıyor; bu yüzden CPU tarafında ayrıca bir asenkron kuyruk açıp yazma işlemlerini planlamak sınırlı bir seçenek olur. Eğer öneri, GPU komut kuyruğunu doğrudan uring olarak userspace'e mapleyip bağlamaksa, io_uring API spesifikasyonunu gerçekten desteklemek için firmware'de ciddi bir yeniden yazım gerekir ve donanım özellikleri gereği tamamen imkânsız bile olabilir
  • Yazıda anlatılan sürücü, userspace Mesa kütüphanesinin istediği API'yi bire bir takip ediyor
• Gerçekten ilginçti; bir devam bölümü ya da mantıksal bir takip metni olur mu diye merak etmiştim
  • İlk kez bugün yayımlanmış bir yazı bu yüzden sonrasında güncelleme geleceğini umuyorum
• "Rust GPU driver" başlığının daha çok tıklanmayı çekmesi anlaşılır, ama fiilen bu bir Arm Mali CSF tabanlı GPU sürücüsü değil mi? Kişisel olarak odağın bir meta araç geliştirme tarafına kayması bana çok iyi gelmiyor; asıl amacın Rust ile bir şeyler üretmek olduğu izlenimi veriyor. Makalede "arm mali tabanlı gpu sürücü çekirdeği" diye yazmasına rağmen özellikle Arm Mali sürücüsü denmemesi de garip. Bir sürücü yazmak, işletim sistemi API'sini donanım üretici API'siyle birleştirmekten başka bir şey değil; bunun üzerine bir de ek soyutlama katmanı kurup bir çerçeve oluşturmaya gitmez. Az çok keskin ifade ettim, kusuruma göz yummak dileğiyle
  • Bu örnek Linux'ta Rust altyapısıyla yapılan ilk (ya da ilklerden biri) GPU sürücüsü girişimlerinden biri olduğu için Rust burada kritik bir anahtar kelime
  • Sert konuştuğum için üzülmüyorum; söyleşinin tonundan modern GPU sürücülerinin ne olduğunu pek bilmediğiniz anlaşılıyor. 15 yıl öncesine kadar da kullanmış olsam da o zamandan beri çok daha karmaşıklaştıklarını biliyor olmam da cabası. Linux çekirdek kaynak koduna bakmak bile GPU sürücülerinin satır sayısı açısından en büyük payı aldığı alan olduğunu gösterir. Hemen tüm sürücüler birden fazla grafik kartını destekler. Her GPU kartı için her seferinde tamamen bağımsız bir sürücü geliştirmek tamamen mantıksız; bunu görmek istemediğinizi düşünüyorum. GPU sürücü geliştirmek iki API'yi sadece "birkaç çizgiyle" birleştirmek demek değil, pratikte düşündüğünüzden çok daha farklı. İtiraz etmek isterseniz yazdığınız bir GPU sürücüsünü gösterin, gerçekten sadece birkaç çizgi çekip işi bitirip bitirmediğinizi göreyim
  • Rust'ın önemli olmasının sebebi, bunun Linux için Rust altyapısını GPU sürücülerinde kullanan ilklerden biri olması