Menulis driver kernel GPU dengan Rust: Pengantar singkat tentang cara kerja driver GPU

• Artikel ini berfokus pada proses pengembangan Tyr, driver GPU terbaru untuk kernel Linux yang dibangun dengan Rust, dan prinsip kerja driver GPU.
• Dalam pengembangan driver GPU, perbedaan peran serta interaksi UMD (user mode driver) dan KMD (kernel mode driver) dijelaskan melalui contoh VkCube.
• UMD menerjemahkan API tingkat tinggi menjadi perintah tingkat rendah yang dapat dipahami GPU, sedangkan KMD menangani tugas inti seperti alokasi memori, penjadwalan pekerjaan, inisialisasi perangkat, dan lain-lain.
• API yang disediakan oleh driver Tyr sama dengan Panthor, yang terdiri dari query perangkat, manajemen memori, manajemen grup, pengiriman tugas, dan manajemen heap Tiler.
• Pada tulisan berikutnya, akan dibahas arsitektur perangkat keras Arm CSF dan komponen intinya (misalnya MCU) serta proses boot.

---

Pengantar: Pengembangan Driver Kernel GPU Canggih Berbasis Rust

• Tulisan ini adalah artikel kedua dalam seri pengembangan driver kernel GPU terbaru untuk mendukung GPU Arm Mali CSF di Linux.
• Sebagai contoh nyata, dipilih VkCube, sebuah program 3D sederhana yang merender kubus berputar dengan menggunakan Vulkan API, untuk menjelaskan cara kerja internal driver GPU.
• Struktur sederhana VkCube merupakan contoh yang baik untuk mempelajari prinsip kerja driver GPU.

Dasar-Dasar Driver GPU: Peran dan Struktur UMD serta KMD

• Terdiri dari User Mode Driver(UMD) dan Kernel Mode Driver(KMD).
  • UMD: mengimplementasikan API aplikasi umum, seperti Vulkan, OpenGL, seperti panvk (driver Vulkan pada Mesa)
  • KMD: seperti Tyr; driver tingkat kernel yang memiliki akses penuh ke perangkat keras, yang berjalan sebagai bagian dari kernel Linux
• Driver GPU mode kernel menghubungkan UMD dengan GPU sebenarnya, dan UMD menerjemahkan perintah API agar dapat dipahami GPU.
• UMD mempersiapkan data yang diperlukan untuk menyusun adegan, seperti geometri, tekstur, shader, dan lain-lain, lalu meminta KMD agar mengalokasikannya ke memori GPU sebelum dieksekusi.
• Shader adalah program independen yang berjalan di GPU; pada VkCube, shader bertanggung jawab atas tata letak kubus, pewarnaan, dan implementasi rotasi. Eksekusi shader membutuhkan data eksternal seperti geometri, warna, dan matriks rotasi.
• UMD menyerahkan perintah yang sudah disiapkan (mis. VkCommandBuffers) ke KMD untuk dieksekusi, dan ketika pekerjaan selesai, menerima notifikasi agar dapat menyimpan hasilnya ke memori.

Tanggung Jawab Utama KMD (Kernel Mode Driver)

• Alokasi dan pemetaan memori GPU (memberikan isolasi per aplikasi)
• Pengiriman tugas ke antrean perangkat keras dan pemberian notifikasi kepada pengguna ketika tugas selesai
• Dalam lingkungan perangkat keras paralel dan asinkron, manajemen dependensi tugas sangat penting, dan KMD menjalankan peran penjadwalan serta validasi dependensi agar hasil yang benar dapat diperoleh.
• Termasuk juga inisialisasi perangkat, pengaturan regulator clock/tegangan, eksekusi kode startup, serta pengelolaan rotasi akses sehingga banyak klien dapat berbagi perangkat keras secara adil.

Letak Kompleksitas: Pembagian Tugas antara UMD dan KMD

• Kompleksitas driver GPU sebagian besar terkonsentrasi di UMD
  • UMD: mengkonversi perintah API tingkat tinggi menjadi perintah perangkat keras
  • KMD: menyediakan fitur inti agar UMD dapat berfungsi dengan benar, seperti isolasi memori, berbagi, dan akses yang adil

Struktur Antarmuka (API) yang Disediakan Tyr

• API driver Tyr (= sama dengan Panthor) dapat dibagi menjadi 5 kelompok utama:
  1. Kueri informasi perangkat: DEV_QUERY (memonitor informasi perangkat keras GPU menggunakan IOCTL, memanfaatkan area ROM)
  2. Alokasi dan isolasi memori: VM_CREATE, VM_BIND, VM_DESTROY, VM_GET_STATE, BO_CREATE, BO_MMAP_OFFSET, dll.
  3. Manajemen grup penjadwalan: GROUP_CREATE, GROUP_DESTROY, GROUP_GET_STATE (penjelasan detail akan dibahas pada tulisan berikutnya)
  4. Pengiriman tugas: GROUP_SUBMIT (meminta eksekusi ke GPU melalui device command buffers)
  5. Manajemen heap Tiler: TILER_HEAP_CREATE, TILER_HEAP_DESTROY (memenuhi kebutuhan memori GPU untuk rendering tiled)
• API ini dalam praktiknya tidak langsung berhubungan dengan penggambaran, karena UMD yang menjalankan perintah eksekusi aktual, sementara KMD hanya menyediakan antarmuka ini agar UMD dapat mengakses perangkat keras.

Kesimpulan dan Rencana Selanjutnya

• Dalam artikel ini, kita membahas struktur dan alur kerja internal driver GPU secara menyeluruh serta API inti yang disediakan oleh Tyr.
• Berdasarkan pembahasan ini, tulisan lanjutan di seri ini akan membahas arsitektur perangkat keras Arm CSF, Microcontroller Unit (MCU), serta proses inisialisasi driver sebagai komponen inti.

[GN⁺]

Komentar Hacker News

• Tulisan ini sangat bagus, tapi isinya terlalu pendek; saya baru mulai merasa tertarik lalu rasanya langsung selesai, jadi saya menanti bagian berikutnya.
  • Minggu depan sepertinya juga ada episode menarik, ketika kita akan melihat perintah yang tertunda di GPU keluar dari antrean dan mulai dieksekusi. Pada level abstraksi yang dibahas di tulisan ini, yang disorot adalah pengiriman data di batas user space/kernel, jadi kebanyakan membahas manajemen antrean dan buffer saja; operasi komputasi itu sendiri tidak banyak. Bagian paling penting justru terjadi saat perintah yang telah masuk antrean benar-benar dieksekusi. GPU juga mengirimkan sinyal penyelesaian lain secara terbalik, itu juga menarik untuk diketahui. Sebagian besar pemrosesan asynchronous seperti ini biasanya ditangani di sisi user code, bukan driver; driver hanya menyediakan jalur untuk meneruskan sinyal selesai.
• Saya menggunakan salah satu perangkat RK3588 sebagai desktop dengan panfrost, dan kadang muncul bug layar hitam atau area transparan di Firefox; ini gejala yang aneh.
  • RK3588 sebenarnya memakai driver panthor yang menjadi topik artikel ini, bukan panfrost.
• Penasaran apakah pernah dipertimbangkan untuk memanfaatkan uring_cmd sebagai pengganti ioctl; karena proyek ini dibangun dari nol jadi sepertinya aplikasinya memungkinkan, penasaran kenapa dianggap hampir tidak ada keuntungannya.
  • Karena GPU sudah memiliki antrean perintah asynchronous sendiri, ioctl pada dasarnya memang berfungsi menulis ke antrean itu dengan biaya relatif rendah. Jadi membuat antrean async tambahan di sisi CPU untuk menjadwalkan penulisan tersebut adalah pilihan dengan nilai guna terbatas. Kalau usulan yang dimaksud adalah membuat antrean perintah GPU itu sendiri menjadi uring dan memetakannya ke userspace, maka agar memenuhi spesifikasi API io_uring dengan benar perlu perubahan firmware yang cukup besar, dan mungkin secara hardware bahkan tidak mungkin.
  • Driver yang dibahas dalam artikel ini mengikuti persis API yang diminta oleh library userspace Mesa.
• Saya membacanya dengan sangat menarik; penasaran apakah ada bagian kelanjutan atau materi yang berurutan secara logis.
  • Karena artikel ini baru dipublikasi hari ini, saya berharap akan ada pembaruan berikutnya.
• Judul "Rust GPU driver" memang jelas lebih menarik kliknya, tapi sebenarnya ini kan driver GPU berbasis Arm Mali CSF? Secara pribadi, saya kurang suka perhatian diarahkan ke metatool untuk pengembangan alat, yang terasa justru tujuan nyata adalah membuat sesuatu dengan Rust. Padahal artikel ini menyebut “kernel driver GPU berbasis arm mali”, tetapi sekaligus tidak menyebutnya sebagai driver arm mali. Menurut saya, membuat driver itu hanyalah menghubungkan API OS dengan API vendor hardware, bukan membangun kerangka kerja tambahan untuk membuat lapisan abstraksi di atasnya. Mohon maaf kalau saya menyebutnya agak lugas.
  • Rust menjadi kata kunci penting karena kasus ini salah satu (atau salah satu dari sedikit) upaya awal driver GPU berbasis Rust di Linux.
  • Saya tidak merasa perlu meminta maaf karena bahasanya kasar; dari gaya bicara Anda, sepertinya Anda tidak tahu apa itu driver GPU modern. Saya tahu, 15 tahun lalu saya juga pernah mencobanya, tapi saya tahu juga bahwa itu sudah jadi jauh lebih rumit. Dari kode sumber kernel Linux saja, driver GPU menyumbang porsi paling besar berdasarkan jumlah baris kode; hampir semua driver mendukung banyak kartu grafis juga. Saya ragu Anda menyadari bahwa membuat driver yang benar-benar independen secara terpisah untuk setiap kartu GPU jelas tidak rasional. Pengerjaan driver GPU bukan sekadar 'menghubungkan beberapa garis' antara dua API; kenyataannya berbeda jauh. Jika Anda ingin berargumen, tunjukkan driver GPU yang Anda buat—saya ingin melihat langsung apakah benar-benar hanya beberapa garis yang Anda sambungkan lalu selesai.
  • Rust penting karena inilah salah satu (atau salah satu dari awal) kasus penggunaan infrastruktur Rust pada driver GPU.