Hỗ trợ Vulkan 1.3 trên M1 chỉ sau một tháng
(rosenzweig.io)- Honeykrisp hiện vẫn chưa phát hành cho người dùng cuối, mới chỉ công bố source code dành cho nhà phát triển
- Honeykrisp cho M1 là triển khai conformant Vulkan đầu tiên trên phần cứng Apple, và triển khai toàn bộ đặc tả Vulkan 1.3 mà không cần waiver
portability - Honeykrisp không dựa trên công việc Vulkan M1 trước đó, mà dựa trên NVK driver mã nguồn mở dành cho GPU NVIDIA; quá trình bắt đầu bằng cách thêm mã cho M1 và loại bỏ các phần liên quan đến NVIDIA
- Kết quả cuối cùng của Vulkan 1.3 conformance test suite được ghi nhận là Pass 686930, Fail 0
- Triển khai theo hướng full dynamic state và
EXT_shader_objectbằng cách xử lý mọi state dưới dạng dynamic state, đồng thời thêm mã để build, compile và cache prolog/epilog - Triển khai
EXT_image_drm_format_modifierđể zero-copy rendering - Hỗ trợ
EXT_custom_border_color, vốn được DXVK và vkd3d-proton yêu cầu cho khả năng tương thích Direct3D; việc hiệu chỉnh border colour được giả lập bằng cách chèn mã vào shader - Phần giả lập custom border colour được mô tả là “simple, correct, and slow”; về sau có kế hoạch tăng tốc bằng driver tricks
- Công việc tiếp theo là triển khai các hạng mục mà DXVK và vkd3d-proton yêu cầu cho lớp Direct3D, với transform feedback được nêu làm ví dụ
1 bình luận
Ý kiến trên Hacker News
Đây là một công việc thật sự ấn tượng, và thể hiện rõ giá trị của các thành phần mở được chia sẻ và cải tiến lặp lại
Tôi tò mò không biết sẽ mất bao lâu để Proton được port sang, nhưng ngay cả khi bản triển khai Vulkan là tối ưu, nhiều game có lẽ vẫn sẽ có hiệu năng kém vì khác biệt về kiến trúc GPU, overhead chuyển đổi ARM và chi phí của chính Proton
Dù vậy, tôi vẫn lạc quan rằng khi các SoC như Snapdragon trở nên phổ biến hơn trên desktop, trong tương lai sẽ có nhiều game nhắm tới bộ nhớ hợp nhất và ARM hơn
Điều đó cho thấy việc Apple phớt lờ Vulkan trong 10 năm qua là sai lầm lớn đến mức nào, nhưng có lẽ họ sẽ không bao giờ thừa nhận cho đến khi quá muộn
Alyssa gần đây cũng đang cải thiện hiệu năng FEX
Tôi tò mò liệu việc thêm Vulkan vào Linux và chuyển đổi DirectX trên Asahi Linux này có ảnh hưởng đến giấc mơ của Apple trong việc thu hút game AAA lên Apple Silicon hay không
Apple hẳn muốn các studio AAA port game sang Metal để chạy trên iPhone, iPad, Mac và Vision Pro với một codebase duy nhất
Có khi các game thủ Mac sẽ cài Asahi Linux để chơi các tựa AAA PC
Thứ họ thật sự muốn là game AAA vào App Store, chứ không phải Steam hay Epic Games Store, và vì vậy tôi nghĩ GPTK là một giải pháp nửa vời, với giấy phép cũng ngăn Valve tích hợp trực tiếp vào Steam
Tôi đã thử Diablo II Resurrected bằng Whiskey trên M1, và khá ấn tượng khi một game Windows native có thể chạy ngay như vậy. Hiện giờ chỉ có bản cập nhật ngu ngốc của launcher Blizzard gây crash và chặn việc khởi động game
Dù là game DX9 cũ, EverQuest II cũng chạy rất tốt ở 1440p trên M1 Mac mini, và Asahi Linux có thể giúp cả các tựa 32-bit cũ như Guild Wars
Nếu bạn chưa rõ về Vulkan 1.3 nhưng quan tâm đến việc làm với API đồ họa cấp thấp, đây chắc chắn là thứ đáng xem. Nó ở một đẳng cấp hoàn toàn khác so với Vulkan 1.0 và thay đổi cuộc chơi
Khi vượt qua rào cản ban đầu, làm việc với nó rất thú vị; nhờ toàn bộ dynamic state và việc loại bỏ cấu hình render pass trước, nó dễ xử lý hơn nhiều. Nó thậm chí còn dễ hơn OpenGL mà tôi đã dùng suốt 20 năm, và khiến lập trình đồ họa trở nên thú vị trở lại
Chỉ cần có driver mới, hầu hết tính năng có thể dùng trên mọi nền tảng desktop với GPU trong khoảng 10 năm trở lại đây
Đáng tiếc là chưa có framework “giá trị mặc định hợp lý” nào giúp bắt đầu ngay, nhưng có rất nhiều thư viện hỗ trợ hữu ích cho nhiều ngôn ngữ
Tôi chưa có thời gian chuyển sang Vulkan, nhưng có vẻ cuối cùng chỉ cần vượt qua rào cản khởi tạo và cấu hình. Sau đó chắc tôi sẽ không quay lại OpenGL nữa
Bài này khiến tôi hơi được thúc đẩy và nghĩ rằng mình nên thật sự thử
OpenGL vốn cũng như vậy nên có lẽ không khác nhiều, nhưng đúng là cảm giác Khronos đã làm rất “tốt” chuyện đó
Tôi vừa cập nhật vì hỗ trợ ES 3.2 và đã thấy ngạc nhiên rồi. Chiếc M1 của tôi có cảm giác như được tạo ra cho Asahi
Thành thật mà nói, khả năng cao macOS chỉ đang được cài, hoặc tôi từng vô tình boot vào đúng một lần. Thật tốt khi có các bản cập nhật chi tiết như thế này
Tôi tò mò liệu có trình duyệt nào hỗ trợ render không sao chép hay không, hay vẫn còn nhiều lớp compositor chồng lên nhau. Tôi cũng nhớ là transform feedback của WebGL2 từng bị chặn vì gây readback
Tôi từng nghĩ nếu có gì đó crash thì tuyệt đối không thể là lỗi compiler, nhưng vào ngày 16/4 thì thực sự đó là lỗi compiler
Tôi có thể tự tin nói rằng trong sự nghiệp mình chưa từng gặp chuyện như vậy, nhưng có lẽ càng xuống mức trừu tượng thấp thì nó càng ít hiếm hơn
Trừ khi bạn là lập trình viên kernel cấp thấp, khi đó cả hai đều có thể đúng
Đùa vậy thôi, trên thực tế phần lớn trường hợp không phải như thế, nhưng rõ ràng là chúng vẫn xảy ra
Nếu đó là một compiler đang phát triển, là sản phẩm của chính mình đang được kiểm thử, thì châm ngôn “không thể là lỗi compiler” không còn áp dụng tốt nữa
Có một cấu trúc kỳ lạ trong shader:
if (condition) { while (true) { } }conditionluôn là false, nhưng trình biên dịch không biết điều đóTôi tò mò mục đích của cấu trúc này là gì, ngoài việc như một liều thuốc độc để hành hạ những người viết trình biên dịch shader tuân thủ chuẩn
Bản thân đoạn code đó không hẳn hữu ích trong thực tế, nhưng nếu một phần shader trong một tình huống nào đó có thể được đơn giản hóa về mặt chức năng thành dạng này, thì trình biên dịch phải xử lý đúng
Nếu chưa quen với khái niệm này, có thể xem các tính năng tương tự trong C++, LLVM, Rust:
https://en.cppreference.com/w/cpp/utility/unreachable
https://en.cppreference.com/w/cpp/language/attributes/assume
https://en.cppreference.com/w/cpp/memory/assume_aligned
https://llvm.org/docs/LangRef.html#unreachable-instruction
https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic
https://doc.rust-lang.org/std/hint/fn.unreachable_unchecked....
https://doc.rust-lang.org/std/hint/fn.assert_unchecked.html
Vòng lặp vô hạn về thực chất là một lệnh không thể tới được, và lệnh không thể tới được sau một nhánh về thực chất trở thành một lệnh assume
Tôi tò mò liệu có thể dùng cái này trong VM không. Tôi phát triển trên macOS và nhìn chung khá hài lòng, nhưng để test thì chạy image Ubuntu trên VMware
Vì đang làm một ứng dụng đồ họa 3D nên tôi không rõ passthrough của VMware đến mức nào. Tôi muốn biết GPU Apple Silicon có được ảo hóa trong VM không, và nếu chạy bản phân phối này thì hiệu năng đồ họa có thể tốt hơn không
Có ai giải thích được cái này liên quan gì đến MoltenVK không? Vì đây là driver native nên có phải không cần MoltenVK nữa không?
Asahi Linux là một bản phân phối đang được phát triển nhằm làm cho Linux tương thích với các bộ xử lý Apple M series, và bài này nói về việc làm cho Vulkan tăng tốc GPU hoạt động trên Asahi
Bài viết cũng nói như vậy. Cái này không thể chạy trực tiếp trên OS X, nên không làm mất đi nhu cầu dùng MoltenVK