1 điểm bởi GN⁺ 2024-06-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • 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 stateEXT_shader_object bằ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à DXVKvkd3d-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

 
GN⁺ 2024-06-06
Ý 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

    • Sẽ khá mỉa mai nếu trải nghiệm chơi game trên Asahi trở nên dễ dàng và đơn giản hơn macOS
      Đ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
    • Khá nhiều game không cần dxvk chạy ở mức trên 60FPS. Xem https://vt.social/@lina/112524118075585601
      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

    • Giấc mơ của Apple không phải là game AAA xuất hiện trên Apple Silicon, mà là xuất hiện trên Apple App Store. Một lớp như Proton có thể được tạo ra giống GPTK
      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
    • Asahi Linux có thể trở thành Boot Camp mới cho người dùng Mac từng dual boot để chơi game
      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 Apple thật sự muốn điều đó thì chỉ cần triển khai Vulkan là được
    • Apple đã phát hành Game Porting Toolkit rồi
  • 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 đã động chạm OpenGL từng chút một trong 20 năm, và dù không phải lập trình viên game chuyên nghiệp, tôi vẫn tạo nội dung 3D lúc rảnh
      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ử
    • Có tutorial hay tài liệu nào để bắt đầu cụ thể với Vulkan 1.3 không? Lần cuối tôi tìm thì chỉ thấy tài liệu trộn lẫn nhiều tổ hợp giữa cách cũ và cách mới
      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

    • Có thể gỡ hoàn toàn macOS không? Thấy cái này làm tôi bắt đầu cân nhắc Mac mini để mang đi du lịch
  • 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

    • Không thể là lỗi compiler, và cũng tuyệt đối không thể là lỗi CPU
      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
    • Ít nhất phần register allocator chẳng phải là do họ tự viết sao?
      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) { } }
    condition luô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

  • 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

    • Phải cài native. Nếu muốn có hiệu năng 3D tốt trong VM Windows/Linux/macOS chạy trên macOS, Parallels tốt hơn VMware rất nhiều
  • 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?

    • MoltenVK là một implementation Vulkan dựa trên Metal, cho phép chạy ứng dụng Vulkan trên macOS
      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
    • Đây là câu chuyện dùng Vulkan trên Asahi Linux chạy trên phần cứng M1 Mac. MoltenVK cung cấp Vulkan trên Metal trong macOS
    • Đây là nội dung về Vulkan trên Linux, không phải macOS
    • MoltenVK chuyển đổi Metal thành Vulkan. Metal là API đồ họa chính của OS X và iOS, còn đây là implementation Vulkan native cho Linux
      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