Xây dựng trình điều khiển GPU Linux cho Mac Mini M4 chỉ trong một tháng

Hai kỹ sư đã hoàn thành trình điều khiển GPU tuân thủ đầy đủ OpenGL ES 3.0 cho Mac Mini M4 và MacBook Neo chỉ trong khoảng một tháng, trong khi công việc tương tự thường mất nhiều năm. Họ đã dịch ngược firmware AGX của Apple và xây dựng cả trình điều khiển nhân Linux lẫn trình điều khiển không gian người dùng. Kết quả đủ nhanh để chạy Minecraft ở mức 200fps.

Bối cảnh: Từ hypervisor đến trình điều khiển GPU

Trước đây, tác giả Cody Ho đã xây dựng một hypervisor để dịch ngược macOS. Lần này, mục tiêu là tận dụng nó vào một việc thực sự hữu ích: viết trình điều khiển GPU. GPU là thành phần thiết yếu của mọi hệ thống hiện đại — nếu không có nó, mọi thứ phải được dựng bằng CPU, chậm hơn nhiều lần và tốn điện hơn đáng kể.

Mục tiêu đặt ra là hiện thực các trình điều khiển OpenGL (và sớm là Vulkan) tuân thủ chuẩn cho Mac Mini M4 và MacBook Neo. Công việc thông thường kéo dài hàng năm, nhưng nhóm đặt mục tiêu chỉ trong vài ngày. Thực tế cho thấy vài ngày là quá lạc quan, nhưng vài tuần vẫn là bước tiến vượt bậc.

Minh họa các bản demo WebGL với Three.js

Trong khoảng thời gian đó, nhóm đã:

• Dịch ngược không gian người dùng của M4, A18 Pro và phần lớn M5 chỉ bằng cách thăm dò trực tiếp phần cứng, phát hiện cả những tính năng và lệnh mà trình điều khiển của Apple không phát ra
• Xây dựng trình điều khiển không gian người dùng hoàn chỉnh, bao gồm trình biên dịch IR/shader tùy chỉnh, bộ dựng luồng lệnh và nhiều thành phần khác
• Dịch ngược toàn bộ ABI firmware AGX từ đầu, dựa trên dấu vết thu được từ hypervisor
• Hiện thực trình điều khiển nhân Linux đầy đủ cho ABI firmware đó

Rào cản lớn nhất: ABI firmware AGX

Trên Apple Silicon, trình điều khiển nhân không giao tiếp trực tiếp với phần cứng mà nói chuyện với firmware GPU chạy một RTOS tùy chỉnh gọi là RTKit. Vì vậy, bước đầu tiên không phải là giao tiếp với phần cứng mà là giải mã ABI firmware.

Đây là phần khó chịu nhất của dự án. Thay vì thiết kế một ABI hợp lý với các giao diện rõ ràng, Apple gần như lấy một trình điều khiển nhân thông thường, cắt đôi, đặt một nửa vào AGX và gọi đó là firmware. Nửa còn lại giao tiếp qua các struct dùng chung trong bộ nhớ, trong đó nhiều struct có các trường do firmware sở hữu xen kẽ với các trường do máy chủ kiểm soát.

ABI firmware của A18 Pro phức tạp hơn đáng kể so với M1 vốn đã rất rối rắm:

• Số lượng struct nhiều gấp 1,5 lần
• Số con trỏ nhiều gấp đôi
• Quy trình gửi công việc phức tạp hơn hẳn

So sánh cấu trúc ABI firmware giữa các thế hệ chip Apple

Cách tiếp cận của nhóm rất đơn giản: quan sát macOS làm gì, phát lại, rồi tự làm. Ba vấn đề lớn nảy sinh, tất cả đều do không thể thu được bản ghi sạch của công việc máy chủ:

1. Công việc render gửi sau khi firmware khởi động bị ACK và loại bỏ mà không thực sự thực thi. Vấn đề nằm ở chỗ agent đang cố phát lại một bản ghi quá muộn trong vòng đời AGX. Khi chuyển sang bản ghi đầu tiên ngay sau khi firmware khởi động, vấn đề được tìm ra chỉ sau vài ngày — thiếu một byte mô tả.
2. Khối lượng tính toán (compute) là vấn đề chặn đứng duy nhất. Bản ghi compute đầu tiên nặng tới 336 MB và không thể phát lại. Giải pháp đưa ra là khởi động vào chế độ người dùng đơn để vô hiệu hóa GUI, cài một LaunchDaemon chạy ngay khi Metal khả dụng, và chạy một chương trình Metal nhỏ do nhóm tự cung cấp.
3. Render một phần (partial render) xảy ra khi Tiled Vertex Buffer không đủ lớn để chứa toàn bộ hình học. Đây là phần khó nhất vì đòi hỏi thêm khả năng lưu và tiếp tục vào trình điều khiển GPU.

Từ nguyên mẫu Python đến trình điều khiển nhân Linux

Quá trình chuyển từ nguyên mẫu Python sang trình điều khiển Linux đầy đủ mất ba ngày, trong đó một ngày gần như bị lãng phí vì agent chọn giải quyết render một phần trước thay vì bắt đầu với compute — vốn là tác vụ dễ nhất. Sau khi được định hướng lại, mọi thứ diễn ra suôn sẻ.

Quy trình tổng thể gồm các bước:

• Viết lại drm-shim hiện có bằng Rust theo đúng mẫu cũ
• Viết lại phần giao diện thành bất đồng bộ, trong khi việc gửi GPU vẫn đồng bộ
• Tái cấu trúc việc gửi GPU thành bất đồng bộ, lắng nghe sự kiện firmware thay vì thăm dò
• Thêm các tối ưu hóa đơn giản như gửi công việc theo lô

Không gian người dùng: Nơi quy trình rõ ràng

Không gian người dùng của A18 Pro rất khác M1/M2 với định dạng mô tả mới, ISA mới và nhiều thứ khác. Quá trình dịch ngược diễn ra theo hai giai đoạn.

Giai đoạn đầu, Claude được giao nhiệm vụ xem xét mọi chương trình Metal có thể tìm thấy để xây dựng bộ dịch ngược, bộ hợp dịch và hiểu định dạng của các mô tả, luồng lệnh. Việc này thành công, nhưng Claude không thể tự xây dựng chương trình từ đầu.

Ở giai đoạn hai, Niklas tham gia với cách tiếp cận "Mesa first" — tập trung xây dựng Mesa trước và chỉ dịch ngược khi cần cho một chức năng cụ thể. Cách này tỏ ra hiệu quả hơn hẳn vì agent luôn bám sát mục tiêu thực tế thay vì mải mê các tác vụ nhỏ nhặt.

Sơ đồ ngăn xếp OpenGL hiện đại trên Linux

Một lợi thế cực lớn khi xây dựng đồ họa không gian người dùng là bộ kiểm thử tương thích Khronos (CTS) đã là một kho bài kiểm tra toàn diện mà trình điều khiển phải vượt qua. Bài toán khó nhất khi làm việc với LLM — cung cấp kiểm thử tốt để định hướng — đã được giải quyết sẵn.

Trong quá trình dịch ngược, nhóm phát hiện nhiều hành vi được phần cứng hỗ trợ nhưng Metal không dùng tới:

• Lệnh cộng 64-bit đơn chỉ duy nhất
• Hỗ trợ anisotropy lên đến 128x (Metal giới hạn ở 16x)
• Một chế độ mới của đơn vị ma trận
• Hỗ trợ immediate 7-bit cho lệnh uniform_mov

Còn lại gì phía trước

Định hướng tiếp theo bao gồm Vulkan 1.4, OpenGL 4.6, OpenGL ES 3.2, OpenCL 3.1, Direct3D 12 (qua Proton) và ray tracing. Nhóm đặt mục tiêu đưa trình điều khiển này ngang tầm với những trình điều khiển đồ họa tốt nhất thế giới.

Việc đưa mã nguồn lên upstream sẽ đối mặt với nhiều trở ngại mang tính con người và phi kỹ thuật hơn là kỹ thuật. Nhóm sử dụng Asahi UAPI không chỉnh sửa nên không có vấn đề chính sách với Mesa, nhưng vẫn cần kiểm thử nhiều hơn, đánh giá bởi con người và tái cấu trúc thành một PR có thể xem xét được. Họ dự đoán sẽ vấp phải hoài nghi đáng kể vì đây có thể là trình điều khiển GPU đầu tiên được viết hoàn toàn bởi LLM.

Trình điều khiển nhân Linux sẽ còn là vấn đề lớn hơn, bởi trình điều khiển M1/M2 vẫn chưa được upstream. Cách tiếp cận hợp lý nhất là chờ trình điều khiển M1/M2 lên upstream trước, rồi mới đưa trình điều khiển của nhóm lên sau.

Đây là một trong những dự án dịch ngược phần cứng táo bạo nhất thời gian gần đây, đồng thời là phép thử thú vị cho câu hỏi: LLM có thể thay thế bao nhiêu phần công việc kỹ thuật phức tạp của con người?

Với người dùng Việt Nam quan tâm đến Linux trên Apple Silicon, đây là tín hiệu đáng mừng: tương lai chạy Linux mượt mà trên Mac có thể đến gần hơn nhiều so với dự đoán. Nhóm nghiên cứu mời cộng đồng tham gia thảo luận qua Discord riêng của dự án.