- Trình điều khiển đồ họa nhân cho GPU Apple M1/M2 nổi bật ở chỗ dựa trên Rust, đồng thời đã đạt mức tương thích OpenGL 4.6 và Vulkan 1.3, mở rộng phạm vi hỗ trợ tiêu chuẩn
- Tessellation, thành phần cốt lõi của OpenGL 4.0, khó đáp ứng tiêu chuẩn chỉ bằng các tính năng phần cứng GPU của Apple, nên được xử lý bằng cách chuyển bộ tham chiếu tessellator của Microsoft sang OpenCL C để chạy trên GPU
- Trong bản demo Vulkan trên máy Mac M2, tessellation dựa trên OpenCL đạt 265fps, nhanh hơn rất nhiều so với triển khai chỉ bằng phần mềm ở mức dưới 1fps, nhưng vẫn kém bộ tessellator phần cứng với 820fps
- Việc chạy game AAA đòi hỏi phải thích ứng môi trường DirectX·Windows·x86·trang 4KB với Apple Silicon dựa trên Linux·Arm64·trang 16KB, nên nhiều lớp chuyển đổi và cấu hình máy ảo được dùng cùng lúc
- Các game như Portal, The Witcher 3 và Cyberpunk 2077 đã thực sự chạy được, nhưng yêu cầu bộ nhớ và phạm vi hỗ trợ ray tracing vẫn là những hạn chế quan trọng
Trình điều khiển GPU Apple đã lên tới OpenGL 4.6
- Trình điều khiển đồ họa nhân cho GPU Apple M1/M2 được viết bằng Rust và đã đạt mức tương thích với nhiều tiêu chuẩn đồ họa
- Alyssa Rosenzweig đã cập nhật trạng thái trình điều khiển và các game có thể hỗ trợ tại X.Org Developers Conference 2024
- Tài liệu trình bày được công bố qua video YouTube và slide
- Tại XDC năm trước, trình điều khiển đã đạt mức tương thích OpenGL ES 3.1, và sau đó tiếp tục đạt tới OpenGL 4.6
- Tessellation) cần cho OpenGL 4.0 là kỹ thuật tăng hoặc giảm chi tiết của cảnh một cách động
Giới hạn của bộ tessellator phần cứng trên GPU Apple
- GPU Apple có bộ tessellator phần cứng, nhưng thiếu các tính năng cần thiết để triển khai tiêu chuẩn OpenGL, nên trình điều khiển không thể dùng nguyên trạng
- Phần cứng dường như không hỗ trợ point mode và isoline, và hai tính năng này có thể được giả lập
- Vấn đề lớn hơn là transform feedback và geometry shader
- Phần cứng không hỗ trợ cả hai
- Trình điều khiển giả lập chúng bằng compute shader
- Sự khác biệt giữa thuật toán tessellation của bộ tessellator phần cứng và phần giả lập có thể làm invariance thất bại, nên cần tránh tổ hợp này
- Apple hỗ trợ OpenGL 4.1 nhưng không đạt mức tương thích, và các tính năng phần cứng không hỗ trợ được thay bằng phần mềm
- Rosenzweig cho biết mục tiêu không phải là triển khai Metal, nên sẽ không đi theo hướng đó
Bộ tham chiếu tessellator được chuyển sang OpenCL C
- Trình điều khiển sử dụng bộ tham chiếu tessellator mà Microsoft công bố hơn 10 năm trước
- Ban đầu đây là mã nhằm cho thấy hành vi mà các hãng phần cứng cần triển khai khi đưa tessellation vào
- Nó gồm khoảng 2000 dòng C++ và tessellate một patch đơn lẻ
- Vì trình điều khiển GPU không thể chạy nguyên 2000 dòng C++, nên mã này được chuyển sang OpenCL C
- OpenCL C gần giống C thông thường trên CPU nhưng có các giới hạn và mở rộng dành cho GPU
- Mục tiêu không phải là hiểu hoàn toàn mã nguồn, mà là tránh làm hỏng hành vi trong quá trình port
- Tessellator trên CPU chỉ xử lý một patch mỗi lần, trong khi một cảnh có thể có 10.000 patch
- Khả năng song song quy mô lớn của GPU được dùng để nhiều luồng cùng thực hiện tessellation
- Việc cấp phát buffer đầu ra trong quá trình xử lý song song được quản lý bằng lệnh atomic của GPU
- Đầu ra của tessellator phải được vẽ bằng lệnh draw theo dạng packed data structure mà GPU yêu cầu
- Thông thường trong mã trình điều khiển C, việc này do các hàm được GenXML tool sinh ra xử lý
- Vì tessellator có dạng mã C nhờ OpenCL, có thể đưa các hàm được sinh ra vào mã chạy trên GPU
Hiệu năng tessellation
- Tessellation dựa trên OpenCL được dùng để chạy terrain tessellation trong bản demo Vulkan trên máy Mac M2
- So sánh hiệu năng như sau
- Terrain tessellation chỉ bằng phần mềm: dưới 1fps
- Tessellation dựa trên OpenCL: 265fps
- Số đo khi nối với bộ tessellator phần cứng: 820fps
- Rosenzweig đánh giá hiệu năng của cách dùng OpenCL là “ổn”, và cho rằng trong game thực tế nó khó trở thành nút thắt cổ chai
- Hiệu năng trình điều khiển vẫn còn dư địa để cải thiện
Vulkan 1.3 và Honeykrisp
- Trình điều khiển GPU M1/M2 Honeykrisp đã đạt mức tương thích Vulkan 1.3
- Điểm khởi đầu là sao chép NVK Vulkan driver for NVIDIA GPUs rồi kết hợp với trình điều khiển OpenGL 4.6
- Chỉ sau khoảng một tháng, nó đã bắt đầu vượt qua bộ kiểm thử tương thích
- Thời điểm đó là 6 tháng trước lúc công bố
- Sau đó các tính năng sau được bổ sung
- geometry shader
- tessellation shader
- transform feedback
- shader object
- Hiện tại trình điều khiển hỗ trợ mọi tính năng cần cho nhiều phiên bản DirectX
Các lớp chuyển đổi để chạy game AAA
- Để chạy game AAA trong môi trường Apple Silicon, cần xử lý đồng thời nhiều khác biệt môi trường
- Môi trường mục tiêu của game: DirectX, Windows, CPU x86, trang 4KB
- Phần cứng đích thực tế: Apple Silicon dựa trên Linux, Arm64, trang 16KB
- Việc chuyển từ DirectX sang Vulkan và chạy từ Windows sang Linux lần lượt do DXVK và Wine đảm nhiệm
- Việc chuyển từ x86 sang Arm64 có các lựa chọn sẵn như FEX-Emu hoặc Box64
- Trở ngại lớn nhất là sự khác biệt kích thước trang
- FEX-Emu yêu cầu trang 4KB
- Box64 có một bản hack dùng trang 16KB, nhưng không hoạt động với Wine nên không hữu ích trong trường hợp này
- macOS có thể dùng trang 4KB cho giả lập x86, nhưng cần hỗ trợ kernel rất xâm lấn
- Asahi Linux đã có khoảng 1000 bản vá hướng tới kernel mainline, nên cách tiếp cận viết lại trình quản lý bộ nhớ của Linux là không hợp lý
Cấu hình VM với guest kernel 4KB
- Linux không hỗ trợ kích thước trang dị thể giữa các tiến trình khác nhau, nhưng có thể giữa các kernel khác nhau, và điều này được xử lý bằng ảo hóa
- Guest kernel KVM có thể có kích thước trang khác với host kernel
- FEX-Emu, Wine, DXVK, Honeykrisp, Steam và toàn bộ game được đặt trong một máy ảo chạy guest kernel 4KB
- Chi phí CPU được dự đoán là thấp nhờ ảo hóa phần cứng, và gánh nặng thực tế nằm ở phía thiết bị ngoại vi
- Honeykrisp chạy trong guest chứ không phải host kernel, thông qua virtgpu native contexts
- Việc tạo GPU command buffer cuối cùng được thực hiện trong guest
- Thay vì mỗi lệnh gọi Vulkan phải vượt qua ranh giới máy ảo, command buffer hoàn chỉnh được chuyển sang host
- VirGL renderer ở host sẽ chuyển nó tới GPU
- Rosenzweig nói rằng cách này không đạt 100% tốc độ native, nhưng chắc chắn vượt 90%
- Overhead CPU và GPU chạy song song nên chi phí của chúng không cộng dồn vào nhau
Các game đã chạy thực tế và tình trạng phát hành
- Cấu hình này thực sự đã chạy được nhiều game
- Portal
- Portal 2
- Castle Crashers
- The Witcher 3
- Fallout 4
- Control
- Ghostrunner
- Cyberpunk 2077
- Các thành phần liên quan đã được công bố vào ngày 10 tháng 10, đúng ngày diễn ra bài trình bày
- Người dùng Fedora Asahi Remix có thể cập nhật ngay để nhận các thành phần này
- Trong lúc trình bày, việc chạy Steam mất thời gian do máy ảo và giả lập x86, sau đó Control chạy ở 45fps trên hệ thống M1 MAX
Hạn chế về bộ nhớ và ray tracing
- Ngay cả máy Mac RAM 8GB cũng có thể chạy một số game
- Rosenzweig đã chơi Castle Crashers trên hệ thống 8GB trong lúc hội nghị diễn ra
- Portal cũng chạy được trên hệ thống 8GB
- Các game cao cấp nhiều khả năng chỉ chạy được trên hệ thống 16GB trở lên
- Rosenzweig hy vọng tài nguyên cần thiết sẽ giảm dần theo thời gian
- Hỗ trợ ray tracing không phải ưu tiên cao
- Control có thể dùng tính năng này
- Phần cứng Apple chỉ hỗ trợ ray tracing từ M3 trở đi
- Trình điều khiển hiện tại dành cho GPU M1 và M2
- Rosenzweig dự định sẽ sớm bắt đầu làm việc với M3
1 bình luận
Ý kiến trên Hacker News
Thật sự rất đáng khâm phục sự tận tâm muốn hoàn thiện hỗ trợ M1/M2 đến cùng
Có quá nhiều dự án bị bỏ rơi ngay khi món đồ chơi ray tracing mới bóng bẩy xuất hiện, trong khi kiểu công việc này rất khổ sở vì phần cứng thiếu tài liệu, nhưng khi chạy được thì phần thưởng rất xứng đáng
Tôi cũng mua M1 vì dự án này và công việc OpenGL+ES của Alyssa, và chỉ boot Asahi Linux
Những thiết bị như vậy được làm ra để dùng lâu dài, và sự hỗ trợ dài hạn từ chính Apple lẫn cộng đồng Linux đều đáng được khen ngợi
Vì là mã nguồn mở nên khả năng cao Apple cũng đang theo dõi, và bài viết cũng đề cập đến việc tìm cách lách qua các tính năng còn thiếu trên chip
Tôi đã code hơn 20 năm, nhưng cả khoảnh khắc hạnh phúc nhất lẫn u ám nhất trong sự nghiệp đều đến từ đúng một dự án phần cứng mà tôi chỉ tham gia 4 tháng
Cách Alyssa chạy mọi thứ trong máy ảo để xử lý khác biệt giữa kích thước trang 4KB và 16KB vừa là một cú hack thông minh, vừa có cảm giác như một nút thắt hiệu năng tiềm ẩn
Tôi tò mò không biết những giải pháp vòng này sẽ có ý nghĩa gì về lâu dài
Có phải chúng ta đã đến điểm mà độ phức tạp để lấp khoảng cách của phần cứng độc quyền được thiết kế cho hệ sinh thái đóng còn lớn hơn lợi ích mang lại không
Việc Control chạy ở 45fps trên M1 MAX với driver mã nguồn mở là điều đáng khích lệ, nhưng tôi vẫn băn khoăn liệu cộng đồng có nên tiếp tục đổ nhiều nguồn lực để mở hơn một hệ thống khép kín, hay nên thúc đẩy các tiêu chuẩn phần cứng cởi mở hơn
Apple đang tạo ra những rào cản không cần thiết cho nhà phát triển bằng các giới hạn GPU và kích thước trang phi tiêu chuẩn khiến những tính năng chuẩn như tessellation shader trở nên khó khăn, và hệ sinh thái đóng kiểu này không chỉ làm các cộng tác viên mã nguồn mở vất vả hơn mà còn kìm hãm những đổi mới có thể mang lại lợi ích cho mọi người dùng
Việc điều đó chống lưng cho mô hình kinh doanh khép kín của họ là quá rõ ràng, và thực tế là nó hoạt động rất hiệu quả với Apple
Họ tạo ra phần cứng tuyệt vời, và dù phần mềm gần đây có phần thiếu ổn định thì người dùng bình thường nhìn chung vẫn có trải nghiệm tốt với tổ hợp phần cứng và phần mềm đó
Vì vậy, việc Apple thiết kế phần cứng như hiện nay không hẳn là đặt ra “rào cản không cần thiết” cho nhà phát triển, mà đơn giản là tập trung vào việc thiết kế phần cứng phù hợp với nhu cầu của họ
Hơn nữa, nếu phần cứng đó không đủ tốt thì cũng đã không có nhiều sự quan tâm đến mức muốn dùng nó theo những cách Apple không hề nhắm tới
Bỏ qua tiêu chuẩn để làm lại một bánh xe tốt hơn và cố tình lệch khỏi tiêu chuẩn nhằm chặn khả năng tương thích là hai chuyện khá khác nhau
Mấu chốt là họ chỉ không bỏ tài nguyên để duy trì hành vi chuẩn, hay chủ động bỏ tài nguyên để lệch khỏi chuẩn; nếu là trường hợp đầu thì cá nhân tôi không nghĩ nên trách họ
Trong hệ sinh thái này, điều Apple chủ yếu quan tâm có lẽ là tương thích ứng dụng native và mức trải nghiệm suy luận AI tương đương, mà cả hai dường như đôi khi đều được giải quyết bằng nỗ lực chung
Ngoài ra họ có xu hướng muốn khóa được càng nhiều càng tốt, và cộng đồng thì tiếc là thường bị sức hấp dẫn tổng thể lôi cuốn hơn là các sáng kiến mở đúng nghĩa
Làm cả hai là được
Lúc đầu tôi định nói Alyssa làm ở Valve thì nên giúp Steam chạy trên Linux trên máy Mac, nhưng có vẻ thực ra đã là như vậy rồi [1]
[1] https://en.wikipedia.org/wiki/Alyssa_Rosenzweig#Career
Điều này đặt ra một câu hỏi khá thú vị về việc Valve đang tính toán gì ở đây
Dù sẽ khó, việc chạy Steam/Proton trên Mac lại rất hợp lý với Valve, và nếu người ta boot Linux trên Mac để chơi game thì Apple chắc hẳn sẽ khá khó chịu
Công việc của Alyssa R và Asahi Lina thật tuyệt vời
Chỉ là nếu không quen với mã driver thì phần lớn nội dung này thật sự rất khó hiểu, và phía phần cứng có quá nhiều chỗ quá khác thường nên giá mà việc viết loại mã này dễ hơn nhiều thì tốt biết mấy
Tôi cũng khá thích kiểu tinh thần nghịch ngợm old-school như bộ đồ phù thủy
Tôi tò mò không biết có phần cứng nào được biết đến có thể làm vậy không
Tôi đã tìm thử nhưng rất khó ra kết quả mong muốn giữa đống blog spam về PowerPoint, còn AI của Google cũng không giúp được gì
Không biết có ai khác cũng ngạc nhiên khi thấy phần cứng thiếu nhiều thứ đến vậy, và nhiều phần như thế lại được giả lập không
Nói cách khác, gần như mọi thứ đều có thể xem là giả lập
Một trong những lý do các hãng GPU không muốn công khai driver dưới dạng mã nguồn mở là vì phần bí mật đáng kể nằm ở phần mềm driver chạy trên kiến trúc tính toán song song quy mô lớn đó
Geometry shader được xem rộng rãi là một sai lầm lẽ ra không nên được chuẩn hóa ngay từ đầu, còn Metal thì chưa từng hỗ trợ nó, nên thứ đó chỉ có thể xuất hiện trong mã OpenGL cũ trên macOS; vì vậy cũng khó mà trách Apple vì không hỗ trợ nó bằng phần cứng
https://x.com/pointinpolygon/status/1270695113967181827
Alyssa thật phi thường
Tôi nhớ bài viết đầu tiên về công việc GPU của cô ấy, rồi sau đó biết rằng khi ấy cô ấy mới chỉ 17 tuổi và cảm giác như đầu óc nổ tung
Việc bất kỳ ai làm được điều đó đã là đáng kinh ngạc, huống chi lại là một thiếu niên
Nếu việc mang OpenGL và Vulkan mới nhất lên Apple Silicon rốt cuộc vốn là bất khả thi nếu không có một lớp giả lập, thì về mặt lý thuyết có thể tạo ra một Metal API gốc cho Linux không
Hay Metal đã ăn quá sâu vào macOS SDK rồi
MoltenVK cũng đang cố giải những vấn đề giống như Alyssa đã nói trong bài thuyết trình [1, bình luận cuối cùng của issue là của Alyssa]
[1] https://github.com/KhronosGroup/MoltenVK/issues/1524
Đó thực chất là kết luận của bài thuyết trình của Alyssa Rosenzweig
Apple biết tài liệu nội bộ nên ở vị thế tốt nhất để tạo ra một triển khai low-level tốt hơn
Trở ngại chính hiện nay là lập trường cứng nhắc rằng việc port sang Metal là con đường được hỗ trợ chính thức duy nhất
Sẽ là một cục diện thú vị nếu Valve lôi ra được kiểu phù thủy để chạy game AAA trên Mac mà không cần Apple hỗ trợ, và nếu Apple không muốn bị dồn vào chân tường ngay trên nền tảng của mình thì điều đó có thể buộc họ phải xem lại cách tiếp cận
Đã có các triển khai DirectX cho Linux, và Proton cũng hoạt động theo kiểu đó
Chỉ là vấn đề sẽ tạo API đó thành một lớp trên Vulkan, xử lý hoàn toàn ở phía client như MoltenVK hay dxvk, hay tích hợp sâu hơn vào Mesa
Có lẽ phương án đầu tiên chắc chắn sẽ dễ hơn để bắt đầu
Cứ thấy những bài có tiêu đề kiểu này là tôi đã bị rèn cho phải nghĩ rằng nội dung sẽ là kiểu “ngừng hỗ trợ rồi bị acqui-hire”
Alyssa Rosenzweig xứng đáng nhận giải Turing
Tôi luôn thắc mắc về các liên kết /SubscriberLink/ kiểu này
Chia sẻ chúng có phải là điều thiếu đạo đức không
Email cá nhân, tin nhắn trên mailing list dự án, bài viết blog đều phù hợp, và miễn là không dùng chúng như một cách để lách nỗ lực thu hút người đăng ký thì họ hoan nghênh việc chia sẻ
Tuy nhiên họ cũng lịch sự đề nghị đừng phát tán quá mức, vì họ phải duy trì site cùng các tác giả và biên tập viên, và theo hiểu biết của tôi thì nguồn tài chính cho việc đó chỉ là đăng ký thuê bao
Phí đăng ký LWN khá dễ chi trả, và nó hỗ trợ mảng báo chí kỹ thuật chuyên sâu tốt nhất về Linux và các chủ đề liên quan
Tôi không có liên hệ gì với LWN, chỉ là một người đăng ký hài lòng, và tôi cho rằng kiến thức học được từ các bài của LWN cũng đã góp phần vào thành công sự nghiệp của mình
Muốn người ta đăng ký thì trước hết họ phải biết LWN tồn tại
Xem FAQ: https://lwn.net/op/FAQ.lwn#slinks
Paywall của LWN khá độc đáo ở chỗ mọi nội dung đều được mở miễn phí sau một tuần
Liên kết dành cho subscriber tồn tại để khuyến khích mọi người đăng ký nếu họ có điều kiện
Có thể tôi sai, nhưng đọc vào thì giống như có lẽ họ gắn nguồn tài trợ để mở quyền truy cập cho từng bài vốn trước đó phải trả phí
Tôi tò mò không biết có ai biết thực tế có đúng như vậy không