การเขียนไดรเวอร์เคอร์เนล GPU ด้วย Rust: บทแนะนำสั้นๆ ถึงหลักการทำงานของไดรเวอร์ GPU

• บทความนี้มุ่งเน้นที่กระบวนการพัฒนาของ Tyr ไดรเวอร์ GPU สมัยใหม่สำหรับเคอร์เนล Linux ที่พัฒนาด้วย Rust และหลักการทำงานของไดรเวอร์ GPU
• ในการพัฒนาไดรเวอร์ GPU อธิบายการแยกความรับผิดชอบและการโต้ตอบระหว่าง UMD (User Mode Driver) และ KMD (Kernel Mode Driver) ผ่านตัวอย่าง VkCube
• UMD จะแปลง API ระดับสูงเป็นคำสั่งระดับต่ำที่ GPU เข้าใจได้ ในขณะที่ KMD รับผิดชอบงานหลัก เช่น การจัดสรรหน่วยความจำ การกำหนดตารางงาน และการเริ่มต้นอุปกรณ์
• API ที่ Tyr ไดรเวอร์ให้มามีโครงสร้างเช่นเดียวกับ Panthor ประกอบด้วยการสืบค้นอุปกรณ์ การจัดการหน่วยความจำ การจัดการกลุ่ม การส่งงาน และการจัดการ Tiler heap เป็นต้น
• ในบทความต่อไปจะอธิบาย สถาปัตยกรรมฮาร์ดแวร์ Arm CSF และส่วนประกอบสำคัญ (เช่น MCU) รวมถึงกระบวนการบูต

---

บทนำ: การพัฒนาไดรเวอร์เคอร์เนล GPU สมัยใหม่ด้วย Rust

• บทความนี้เป็นบทความที่สองของซีรีส์การพัฒนาของ Tyr ไดรเวอร์ GPU Rust สมัยใหม่ที่รองรับ GPU อิงสถาปัตยกรรม Arm Mali CSF ในเคอร์เนล Linux
• เพื่อเป็นตัวอย่างจริง จึงเลือกโปรแกรม 3D แบบง่ายอย่าง VkCube ซึ่งเรนเดอร์ลูกบาศก์หมุนโดยใช้ Vulkan API เพื่ออธิบายการทำงานภายในของไดรเวอร์ GPU
• โครงสร้างที่เรียบง่ายของ VkCube เหมาะเป็นตัวอย่างกรณีศึกษาในการเรียนรู้หลักการทำงานของไดรเวอร์ GPU

พื้นฐานไดรเวอร์ GPU: บทบาทและโครงสร้างของ UMD และ KMD

• ประกอบด้วย User Mode Driver (UMD) และ Kernel Mode Driver (KMD)
  • UMD: ทำหน้าที่นำ API ของโปรแกรมทั่วไปมาทำงาน เช่น Vulkan, OpenGL ผ่านการใช้งานจริงอย่าง panvk (ไดรเวอร์ Vulkan ของ Mesa เป็นต้น)
  • KMD: เช่น Tyr เป็นต้น เป็นไดรเวอร์ระดับเคอร์เนลที่มีสิทธิ์เข้าถึงฮาร์ดแวร์ และทำงานเป็นส่วนหนึ่งของเคอร์เนล Linux
• ไดรเวอร์ GPU โหมดเคอร์เนลเชื่อมต่อ UMD กับ GPU จริง โดยแปลงคำสั่ง API ที่ได้รับให้เป็นชุดคำสั่งที่ GPU สามารถเข้าใจได้
• UMD เตรียมข้อมูลที่จำเป็นสำหรับการประกอบฉาก เช่น geometry, texture, shader เป็นต้น แล้วก่อนการทำงานจะขอให้ KMD จัดสรรหน่วยความจำ GPU
• Shader คือโปรแกรมอิสระที่ทำงานบน GPU และใน VkCube มีบทบาทในการจัดตำแหน่งลูกบาศก์ การลงสี และการหมุน การรัน shader ต้องอาศัยข้อมูลภายนอก เช่น geometry, color, แมทริกซ์การหมุน เป็นต้น
• UMD ส่งคำสั่งที่เตรียมไว้ (เช่น VkCommandBuffers) ให้ KMD เพื่อดำเนินการ และเมื่อเสร็จสิ้นงานจะรับการแจ้งเตือนเพื่อบันทึกผลลัพธ์ลงในหน่วยความจำ

ความรับผิดชอบหลักของ KMD (Kernel Mode Driver)

• การ จัดสรรและแมปหน่วยความจำ GPU (จัดสรรแบบแยกสำหรับแต่ละแอปพลิเคชัน)
• การส่งงานไปยังคิวฮาร์ดแวร์ และให้การแจ้งเตือนแก่ผู้ใช้เมื่อทำงานเสร็จ
• ในสภาพแวดล้อมฮาร์ดแวร์แบบไม่ตรงเวลาและแบบขนาน การ จัดการความขึ้นต่อกันของงาน เป็นสิ่งจำเป็น และเพื่อให้ได้ผลลัพธ์ที่ถูกต้อง KMD จะรับหน้าที่กำหนดตารางและตรวจสอบ dependency
• รวมถึงการเริ่มต้นอุปกรณ์ การขับตัวควบคุมคลอค/แรงดันไฟ การรันโค้ด startup และการจัดการรอบการเข้าถึงเพื่อให้หลายไคลเอนต์แบ่งปันฮาร์ดแวร์ได้อย่างเป็นธรรม

ตำแหน่งของความซับซ้อน: การแบ่งงานระหว่าง UMD และ KMD

• ความซับซ้อนของไดรเวอร์ GPU ส่วนใหญ่อยู่ที่ UMD
  • UMD: แปลงคำสั่ง API ระดับสูงเป็นคำสั่งฮาร์ดแวร์
  • KMD: จัดฟังก์ชันหลักเพื่อให้ UMD ทำงานได้อย่างถูกต้อง เช่น การแยกความเป็นส่วนตัวของหน่วยความจำ การแบ่งปัน และการเข้าถึงที่เป็นธรรม

โครงสร้างอินเทอร์เฟซไดรเวอร์ (API) ของ Tyr

• API ของไดรเวอร์ Tyr (=เหมือนกับ Panthor) แบ่งได้เป็น 5 กลุ่มหลัก
  1. การสืบค้นข้อมูลอุปกรณ์: DEV_QUERY (ตรวจสอบข้อมูลฮาร์ดแวร์ GPU ผ่าน IOCTL และใช้พื้นที่ ROM)
  2. การจัดสรรและแยกหน่วยความจำ: VM_CREATE, VM_BIND, VM_DESTROY, VM_GET_STATE, BO_CREATE, BO_MMAP_OFFSET เป็นต้น
  3. การจัดการกลุ่ม scheduling: GROUP_CREATE, GROUP_DESTROY, GROUP_GET_STATE (รายละเอียดจะอธิบายในบทความต่อไป)
  4. การส่งงาน: GROUP_SUBMIT (ส่งคำสั่งรันผ่าน device command buffer ไปยัง GPU)
  5. การจัดการ Tiler Heap: TILER_HEAP_CREATE, TILER_HEAP_DESTROY (รองรับความต้องการหน่วยความจำของ GPU แบบ tiled rendering)
• API เหล่านี้ยังห่างไกลจากงานการวาดภาพจริง แต่ UMD รับผิดชอบการรันคำสั่งจริง ในขณะที่ KMD มีเพียงให้บริการอินเทอร์เฟซเหล่านี้เพื่อการเข้าถึงฮาร์ดแวร์

สรุปและแผนต่อไป

• บทความนี้ได้สำรวจ โครงสร้างโดยรวมและแนวทางการไหลภายในของไดรเวอร์ GPU และ API สำคัญที่ Tyr ให้
• โดยใช้เนื้อหานี้เป็นฐาน บทความต่อๆ ไปในซีรีส์จะครอบคลุม สถาปัตยกรรมฮาร์ดแวร์ Arm CSF, Microcontroller Unit (MCU) และส่วนประกอบหลักอื่นๆ รวมถึงขั้นตอนการเริ่มต้นไดรเวอร์