Vulkan 1.3 được triển khai trên M1 chỉ trong một tháng
Giới thiệu driver Honeykrisp
- Driver Honeykrisp: Driver đầu tiên triển khai đầy đủ đặc tả Vulkan 1.3 trên phần cứng Apple.
- Trạng thái phát triển: Chưa được phát hành cho người dùng cuối và vẫn đang được bổ sung tính năng cũng như cải thiện hiệu năng. Mã nguồn đã được công khai cho các nhà phát triển.
Quá trình phát triển
Ngày 2 tháng 4
- Bắt đầu: Khởi động phát triển driver Vulkan cho M1 dựa trên driver NVK.
Ngày 3 tháng 4
- Descriptor set: Điều chỉnh descriptor set của M1, vốn khác với NVIDIA, để phù hợp với NVK.
Ngày 4 tháng 4
- Compute shader: Biên dịch compute shader và triển khai chức năng sao chép buffer và image bằng các lệnh Vulkan.
Ngày 6 tháng 4
- Xử lý trạng thái đồ họa: Viết mã xử lý trạng thái đồ họa, lấy mã từ driver OpenGL và kết hợp với NVK.
Ngày 7 tháng 4
- Trạng thái động: Chọn chiến lược xử lý mọi trạng thái theo cách động, thêm mã để biên dịch và cache phần mở đầu và kết thúc.
Ngày 8 tháng 4
- Kết quả kiểm thử: Kết quả kiểm thử ban đầu là 149.770 bài kiểm thử vượt qua, 7.741 thất bại và 2.396 bị crash.
Ngày 9 tháng 4
- Vulkan 1.3: Sau khi đạt tỷ lệ vượt qua 99,6% ở Vulkan 1.1, chuyển sang Vulkan 1.3 và đạt tỷ lệ 98,3%.
Ngày 10 tháng 4 ~ ngày 12 tháng 4
- Kiểm thử bổ sung: Xác nhận Vulkan renderer hoạt động trong SuperTuxKart và Zink, đồng thời sửa lỗi trong bài kiểm thử.
Ngày 16 tháng 4 ~ ngày 17 tháng 4
- Sửa lỗi compiler: Sửa lỗi compiler được phát hiện trong bài kiểm thử descriptor indexing, giải quyết vấn đề vòng lặp vô hạn.
Ngày 18 tháng 4
- Kết xuất zero-copy: Triển khai extension
EXT_image_drm_format_modifier để có layout bề mặt hiệu quả.
Ngày 22 tháng 4
- Rà soát kiến trúc driver: Sau khi rà soát kiến trúc driver, tiến hành tối ưu hóa và đạt 100 triệu lệnh draw mỗi giây trong bài kiểm thử vkoverhead.
Ngày 24 tháng 4 ~ ngày 25 tháng 4
- Hỗ trợ YCbCr: Bổ sung tính năng YCbCr, tận dụng mã NVK của Mohamed Ahmed.
- Sao chép query: Triển khai chức năng sao chép query trên GPU.
Ngày 26 tháng 4
- Màu viền: Triển khai extension
EXT_custom_border_color để tương thích với Direct3D, giải quyết vấn đề màu viền.
Ngày 27 tháng 4
- Kiểm thử cuối cùng: Vượt qua toàn bộ bài kiểm thử, 686.930 bài vượt qua, 0 bài thất bại.
Kế hoạch tương lai
- Hỗ trợ DXVK và vkd3d-proton: Dự kiến triển khai thêm các tính năng cho lớp tương thích Direct3D.
- Chạy game Windows: Có kế hoạch chạy game Windows trên Asahi Linux bằng Wine và trình giả lập x86 mã nguồn mở.
Ý kiến của GN⁺
- Thử thách kỹ thuật: Việc triển khai Vulkan 1.3 trên M1 là một công việc rất thách thức về mặt kỹ thuật. Nguyên nhân là do kiến trúc độc đáo của phần cứng Apple.
- Có ích cho nhà phát triển game: Khi driver Vulkan hoàn thiện, các nhà phát triển game sẽ có thể chạy game trên nhiều nền tảng hơn.
- Cần tối ưu hiệu năng: Ở giai đoạn đầu, có thể vẫn cần tối ưu hiệu năng. Đặc biệt phải giải quyết vấn đề overhead CPU do xử lý trạng thái động gây ra.
- Đóng góp cộng đồng: Vì là dự án mã nguồn mở, sự đóng góp của cộng đồng rất quan trọng. Cần có thêm kiểm thử và phản hồi trong nhiều môi trường phần cứng và phần mềm khác nhau.
- Sản phẩm cạnh tranh: Ngoài DXVK và vkd3d-proton, còn có các lớp tương thích khác như Wine. Việc so sánh ưu và nhược điểm của từng sản phẩm trước khi lựa chọn là điều quan trọng.
1 bình luận
Ý kiến trên Hacker News
Đây là một nỗ lực ấn tượng, chứng minh giá trị của các thành phần dùng chung, lặp lại và mở. Tò mò không biết sẽ mất bao lâu để port Proton. Có khả năng nhiều trò chơi sẽ không chạy đúng do khác biệt về kiến trúc GPU và chi phí chuyển đổi ARM. Dù vậy, vẫn lạc quan rằng khi SoC trở nên phổ biến hơn, sẽ có nhiều game hơn nhắm tới bộ nhớ hợp nhất và ARM.
Tò mò liệu nỗ lực đưa Vulkan lên Linux và chuyển đổi DirectX trên Asahi Linux có ảnh hưởng đến giấc mơ đưa game AAA của Apple lên Apple Silicon hay không. Apple muốn các nhà phát triển AAA port game sang Metal để chạy trên iPhone, iPad, Mac và Vision Pro. Cũng có khả năng game thủ Mac sẽ cài Asahi Linux để chơi các tựa game PC AAA.
Nếu chưa quen với Vulkan 1.3 nhưng quan tâm đến công việc với API đồ họa cấp thấp, thì rất đáng để tìm hiểu. Khi vượt qua được rào cản ban đầu, việc này trở nên khá thú vị. Tất cả trạng thái động và render pass không cần preset khiến công việc dễ hơn nhiều. Có thể dùng trên mọi nền tảng desktop với GPU không quá 10 năm tuổi. Tuy vậy, không có framework với "các giá trị mặc định hợp lý", nhưng có nhiều thư viện helper hữu ích cho nhiều ngôn ngữ.
Ước gì khả năng lập trình của mình được bằng một nửa cô ấy. Thật sự quá đỉnh.
Phép màu lập trình đáng kinh ngạc của Alyssa. Không biết cô ấy làm thế nào, nhưng rất vui khi cô ấy đang chiến đấu cho điều đúng đắn.
Bug trình biên dịch thì chắc chắn không bao giờ xảy ra. Nhưng hóa ra lần này đúng là bug trình biên dịch. Trong suốt sự nghiệp tôi chưa từng gặp, nhưng ở mức độ trừu tượng này thì có lẽ nó ít hiếm hơn.
Tôi vừa cập nhật hỗ trợ ES 3.2, và M1 cứ như được tạo ra cho Asahi vậy. Tôi chỉ boot vào macOS đúng một lần khi cài đặt. Tò mò không biết trình duyệt có hỗ trợ 'zero-copy rendering' hay không. Tôi nhớ mình từng bị kẹt với vấn đề transform feedback của WebGL2 kích hoạt thao tác đọc.
Có một cấu trúc shader kỳ lạ. Điều kiện luôn là false nhưng trình biên dịch lại không biết điều đó. Tò mò mục đích của cấu trúc này là gì.
Có dùng được trong VM hay không. Tôi phát triển trên macOS và dùng image VMware để test Ubuntu. Tôi làm ứng dụng đồ họa 3D, nhưng không rõ cơ chế passthrough của VMware tốt đến đâu. Tò mò liệu GPU Apple Silicon có được ảo hóa trong VM không, và có thể chạy bản phân phối này để có hiệu năng đồ họa tốt hơn không.
Tò mò liệu ai đó có thể giải thích mối quan hệ với MoltenVK. Không rõ công việc này có loại bỏ nhu cầu dùng MoltenVK hay không, và liệu đây có phải là driver native không.