Trình điều khiển GPU M1 đầu tiên đạt chứng nhận tương thích OpenGL ES

 (rosenzweig.io)
1 điểm bởi GN⁺ 2023-08-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đã có trình điều khiển Linux cho phép chạy ứng dụng OpenGL ES 3.1 đúng theo tiêu chuẩn trên GPU dòng M1·M2
  • Trình điều khiển miễn phí và mã nguồn mở dựa trên kỹ thuật đảo ngược của Asahi Linux là bản triển khai OpenGL ES 3.1 duy nhất vượt qua bài kiểm tra tương thích của Khronos trên phần cứng đồ họa M1·M2
  • Chứng nhận yêu cầu vượt qua bộ kiểm thử chính thức, nộp kết quả lên Khronos và trải qua 30 ngày xem xét, với các mục M1, M1 Pro/Max/Ultra, M2, M2 Pro/Max đã được đăng ký
  • OpenGL ES 3.1 là bản cập nhật từ hỗ trợ thử nghiệm OpenGL ES 3.0·OpenGL 3.1 hồi tháng 6, bổ sung compute shader và các phép toán nguyên tử trên ảnh
  • M1 không có lệnh chuyên dụng cho phép toán nguyên tử trên ảnh nên đã phải обход qua tính toán địa chỉ, sau đó tìm ra lệnh bit interleave giúp giảm từ 10 lệnh xuống còn 1 lệnh

Chứng nhận tương thích OpenGL ES 3.1 cho M1·M2

  • Đã có trình điều khiển đạt chứng nhận tương thích OpenGL ES 3.1 cho GPU dòng M1·M2
    • Tương thích với các ứng dụng OpenGL ES 3.1
    • Có thể sử dụng bằng cách cài Linux
  • Người dùng Asahi Linux hiện tại có thể nhận trình điều khiển mới nhất bằng lệnh nâng cấp tùy theo bản phân phối
    • Fedora: dnf upgrade
    • Arch: pacman -Syu
  • Trình điều khiển đồ họa miễn phí và mã nguồn mở dựa trên kỹ thuật đảo ngược được công khai tại asahi/mesa
  • Đây là bản triển khai đạt chứng nhận tương thích OpenGL ES 3.1 duy nhất trên thế giới cho phần cứng đồ họa dòng M1·M2
    • Đã vượt qua hàng chục nghìn bài kiểm tra để chứng minh độ chính xác
    • Được tổ chức tiêu chuẩn ngành công nhận

Quy trình của Khronos và các dòng chip đã được đăng ký

  • Để đạt chứng nhận tương thích, bản triển khai phải vượt qua bộ kiểm thử tương thích chính thức
    • Bộ kiểm thử được thiết kế để xác minh mọi tính năng trong đặc tả
    • Kết quả kiểm thử được nộp lên tổ chức tiêu chuẩn Khronos
    • Nếu không có vấn đề gì trong thời gian xem xét 30 ngày, nó sẽ trở thành bản triển khai đạt chứng nhận tương thích
  • Trên trang web của Khronos, các trình điều khiển sau đã được đăng ký là bản triển khai đạt chứng nhận tương thích
  • Thành quả lần này không chỉ dừng ở OpenGL ES
    • Đây là bản triển khai đạt chứng nhận tương thích đầu tiên trong toàn bộ hệ tiêu chuẩn đồ họa dành cho M1

Khoảng cách giữa trình điều khiển của nhà sản xuất và API tiêu chuẩn

  • Trình điều khiển M1 của nhà sản xuất chưa đạt chứng nhận tương thích với bất kỳ API đồ họa tiêu chuẩn nào, bao gồm Vulkan, OpenGL và OpenGL ES
  • Trên các môi trường M1·M2 không dùng Linux, không có gì bảo đảm rằng các ứng dụng dựa trên tiêu chuẩn sẽ hoạt động
  • Trong trường hợp Vulkan, MoltenVK xếp chồng một phần Vulkan lên trên trình điều khiển độc quyền
    • Trình điều khiển độc quyền đó thiếu các tính năng cốt lõi
    • Ứng dụng Vulkan hợp lệ có thể bị lỗi
    • Đây là trở ngại cho cả nhà phát triển lẫn người dùng chưa chuyển máy M1·M2 sang Linux
  • Việc phát triển trình điều khiển Asahi Linux hướng tới mục tiêu chạy phần mềm tiêu chuẩn trên M1 mà không cần hack riêng hay port riêng cho M1
    • Không chấp nhận việc phụ thuộc vào trình điều khiển độc quyền, API độc quyền hay từ chối triển khai tiêu chuẩn
    • Coi triển khai tiêu chuẩn mở đúng đặc tả là hướng đi mong muốn của hệ sinh thái

Các tính năng bổ sung cốt lõi của OpenGL ES 3.1

  • OpenGL ES 3.1 là bản cập nhật cho hỗ trợ thử nghiệm OpenGL ES 3.0 và OpenGL 3.1 được cung cấp vào tháng 6
  • Tính năng bổ sung quan trọng nhất là compute shader
    • Chủ yếu được dùng để tăng tốc tính toán tổng quát bên trong ứng dụng đồ họa
    • Game 3D có thể chạy mô phỏng vật lý trong compute shader
    • Nếu dùng ngay kết quả mô phỏng cho việc render, có thể giảm tình trạng dừng do đồng bộ giữa GPU và mô phỏng vật lý trên CPU
    • Nhờ đó game có thể chạy nhanh hơn

Vì sao cần các phép toán nguyên tử trên ảnh

  • Các phiên bản trước của OpenGL ES cho phép ứng dụng đọc ảnh để hiển thị lên màn hình
  • ES 3.1 cho phép ứng dụng ghi vào ảnh thường là từ compute shader
    • Điều này giảm bớt ràng buộc phải ép các thuật toán xử lý ảnh vào pipeline 3D chức năng cố định
  • GPU là kiến trúc song song quy mô lớn, chạy đồng thời hàng nghìn luồng
    • Nếu hai luồng ghi vào cùng một vị trí, kết quả sẽ thay đổi tùy theo thứ tự thực thi
    • Tình huống này là race condition
  • Truy cập bộ nhớ nguyên tử là cách giải quyết cơ bản cho race condition
    • Phần cứng đặc biệt trong hệ thống bộ nhớ bảo đảm kết quả nhất quán cho các phép toán được chọn, bất kể thứ tự luồng
    • Phần cứng đồ họa hiện đại hỗ trợ nhiều phép toán nguyên tử như phép cộng
  • Phần mở rộng OpenGL ES OES_shader_image_atomic bổ sung các phép toán nguyên tử trên pixel ảnh
    • Phần mở rộng này là bắt buộc trong ES 3.2
    • Ví dụ, compute shader có thể tăng giá trị của pixel (10, 20) một cách nguyên tử

Cách triển khai phép toán nguyên tử trên ảnh trên M1

  • Những GPU khác cung cấp lệnh chuyên dụng cho phép toán nguyên tử trên ảnh nên việc triển khai phía trình điều khiển đơn giản hơn
  • M1 không có lệnh phần cứng chuyên dụng cho phép toán nguyên tử trên ảnh
    • Có hỗ trợ phép toán nguyên tử không phải trên ảnh
    • Cũng có các chức năng ảnh không nguyên tử
  • Vì vậy, thay vì thực hiện trực tiếp phép toán nguyên tử lên pixel, trình điều khiển tính địa chỉ bộ nhớ của pixel rồi thực hiện phép toán nguyên tử thông thường tại địa chỉ đó
  • Nếu ảnh được bố trí tuyến tính trong bộ nhớ thì việc tính địa chỉ khá đơn giản
    • Nhân tọa độ Y với stride là số byte trên mỗi hàng
    • Nhân tọa độ X với số byte trên mỗi pixel
    • Cộng hai giá trị để lấy byte offset tính từ pixel đầu tiên
    • Cộng offset vào địa chỉ của pixel đầu tiên để có địa chỉ cuối cùng
  • Nhưng ảnh thực tế thường không được bố trí tuyến tính
    • Phần cứng đồ họa hiện đại xen kẽ tọa độ X·Y để tăng hiệu quả cache
    • Cách bố trí pixel trong bộ nhớ không theo từng hàng mà theo đường cong gần giống xoắn ốc

Tối ưu hóa bit interleave và tìm lệnh ẩn

  • Cách xen kẽ tọa độ X·Y bằng việc mask và shift từng bit là không hiệu quả
  • Một thuật toán thao tác bit nổi tiếng trộn các nhóm bit để song song hóa bài toán
    • Khi triển khai thuật toán này trong mã shader, hiệu năng được cải thiện
  • Trên thực tế, chỉ các bit thấp hơn hoặc bằng 7 của mỗi tọa độ mới được xen kẽ
    • Có thể đặt tọa độ X·Y vào 16 bit thấp và 16 bit cao của thanh ghi 32 bit để xử lý đồng thời bằng lệnh 32 bit
    • Có thể giảm một nửa số lệnh
    • Đồng thời tận dụng lệnh kết hợp shift-and-add của GPU
  • Kết hợp các kỹ thuật này cho phép thực hiện interleave bằng 10 lệnh assembly trên GPU M1
  • Sau đó, nhóm phát triển xem xét khả năng tồn tại lệnh bit interleave chuyên dụng
    • PowerVR có lệnh shuffle shfl
    • GPU M1 có một số thành phần lấy từ PowerVR nên có khả năng tồn tại lệnh tương tự
    • Tuy nhiên, vì trình biên dịch độc quyền không dùng lệnh đó khi biên dịch shader thử nghiệm nên rất khó đảo ngược chỉ bằng cách quan sát kết quả biên dịch

Xác nhận lệnh interleave bằng suy đoán và kiểm chứng

  • Dougall Johnson đã suy đoán ứng viên dựa trên mã hóa lệnh đã biết
  • Lệnh đảo bit có trường 2 bit để chỉ định phép toán và giá trị của nó là 01
    • Lệnh đếm số bit được đặt là 10
    • Lệnh tìm bit được đặt đầu tiên là 11
    • Các lệnh thao tác bit phức tạp đã biết đều dùng ba giá trị này
  • Giá trị còn lại 00 là giá trị chưa biết chưa từng được quan sát
    • Nếu lệnh interleave tồn tại, giả thuyết là nó có thể giống lệnh đảo bit nhưng dùng mã phép toán 00
  • Ba lệnh đã biết chỉ có một nguồn đầu vào, nhưng lệnh interleave cần hai nguồn
    • Các lệnh của GPU M1 thường mã hóa vị trí nguồn một cách nhất quán
    • Trong các lệnh số học hai nguồn có một khoảng trống đúng chỗ nguồn thứ hai, nên vị trí đó được giả định là nguồn thứ hai
  • Việc kiểm chứng được thực hiện bằng cách sửa trình biên dịch để thay các phép toán số nguyên hai nguồn như phép nhân bằng mã hóa interleave được suy đoán
    • Dùng phép toán đó trong compute shader
    • Shader kiểm thử xác minh với mọi đầu vào có thể rằng lệnh chưa biết trả về kết quả interleave hay không
    • Vì lệnh nhận hai nguồn 16 bit nên có khoảng 4 tỷ đầu vào
    • Nhờ hỗ trợ compute mới của trình điều khiển, GPU M1 xác minh toàn bộ các đầu vào trong chưa đến 1 giây
  • Cuối cùng, đoạn assembly vector hóa 10 lệnh đã được thay bằng 1 lệnh interleave duy nhất
    • Cách này nhanh hơn và cũng vượt qua bài kiểm tra tương thích

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-08-23
Ý kiến trên Hacker News

  • Tôi tự hỏi liệu hỗ trợ OpenGL/Vulkan có được cải thiện không khi Apple hợp tác với nVidia, Adobe, Autodesk, Microsoft và các bên khác về OpenUSD, định dạng cho cảnh render/animation/CAD/3D
    Nếu cốt lõi của OpenUSD là “một định dạng tệp duy nhất được render nhất quán ở mọi nơi”, thì Apple có thể dùng nó như một cách để lôi kéo thêm các hãng phần mềm 3D sang macOS
    Về sau có vẻ có hai con đường: Apple tuân theo các chuẩn OpenGL/Vulkan hiện có, vốn có sức nặng trong pipeline sản xuất phim và game, hoặc ngược lại, thúc đẩy Metal mạnh hơn nữa để kéo thế giới về Metal + macOS
    Trong lòng thì tôi mong điều trước, nhưng trực giác mách rằng Apple sẽ dồn toàn lực cho điều sau; và không chỉ Apple, mà nVidia, Autodesk, Adobe, Microsoft cũng thường không thích các chuẩn mà họ không kiểm soát

    • Tôi muốn thêm sắc thái kiểu “Apple thích chuẩn mở khi họ ở thế yếu”
      iMac và OS X thời kỳ đầu đã quảng bá mạnh các chuẩn như USB, JPEG, MPEG, mp3, PostScript, TCP/IP tích hợp, .rtf, và Jobs cũng nhấn mạnh điều này
      Sau đó, khi hồi phục từ bờ vực, họ lại bắt đầu “tăng thêm giá trị”, và iPhone ban đầu cũng được nhấn mạnh là một thiết bị HTML thay vì Flash độc quyền tệ hại hay “HTML di động” còn non nớt
      Ngay cả hiện nay, trong những lĩnh vực mà sức thống trị thị trường của họ còn yếu, họ vẫn hỗ trợ các chuẩn không do họ kiểm soát như H.264, Matter/Thread
    • Apple hỗ trợ nhiều chuẩn mở, nhưng nói “họ không muốn phụ thuộc vào những chuẩn mà họ không kiểm soát” có vẻ chính xác hơn
      Vì họ kết hợp chặt chẽ phần cứng và phần mềm để tạo ra trải nghiệm người dùng theo ý đồ, nên có thể hiểu được lập trường muốn triển khai các chuẩn mà họ có thể kiểm soát ở mức nào đó, để trải nghiệm đó không bị người khác chi phối
      Ngay cả các chuẩn công nghiệp như USB-C, khi hướng đi chưa hoàn toàn cố định, nếu đi trước thì có thể ảnh hưởng đến hướng phát triển, nên đôi khi Apple sẽ áp dụng
    • OpenUSD là cách đóng gói và đặc tả dữ liệu để render, tách biệt với việc ứng dụng dùng API nào để tăng tốc render
      Phần lớn như Adobe, Autodesk, Blender đã hỗ trợ các backend khác nhau tùy hệ điều hành, và trên macOS cũng bao gồm Metal
    • Tôi không nghĩ Apple sẽ quay lại với OpenGL
      OpenGL quá cũ, việc dùng driver tốt gần như là ác mộng, và ngay cả viết mã ứng dụng có hiệu năng tốt cũng khó, nên tôi không tiếc
      Tuy vậy, tôi vẫn ước họ đã thúc đẩy Vulkan thay vì tạo ra Metal; nhưng ngoài Linux, Vulkan nhìn chung gần như là công dân hạng hai, dù vẫn là một công dân hạng hai khá ổn để nhắm tới
      Xét từ góc độ game hay hỗ trợ Steam, nhiều game giao việc xử lý API cho engine, và nếu một đội có đủ năng lực tự xử lý API trực tiếp thì, miễn là không dùng các tính năng quá tối tân, nhiều khả năng MoltenVK cũng đủ tốt
      Tôi đã dùng OpenGL rất nhiều cho cross-platform suốt đời, nhưng vì global state, những hàm không nên dùng, các cạm bẫy, header extension khổng lồ và việc debug khó khăn, đó thật sự là một API tệ; Vulkan thì dài dòng nhưng ở nhiều mặt lại dễ hơn
    • Tình hình Metal/Vulkan/OpenGL thật đáng tiếc và tôi không hiểu rõ động cơ của Apple
      Nhưng chiếc Mac tôi đang dùng hiện kết nối với nhiều thiết bị ngoại vi và màn hình lớn chỉ qua các cổng USB-C bằng các giao thức chuẩn
      Nhìn chung, có vẻ Apple ưu tiên chuẩn mở khi chuẩn đó đã đủ tốt; thời USB2 chưa làm được nhiều việc mà Lightning làm, họ đã tạo ra Lightning, nhưng khi USB-C xuất hiện thì họ chấp nhận ngay trên Mac và iPad, còn trên iPhone thì đáng tiếc là vẫn đang chậm chạp

  • Asahi và Alyssa là những người khổng lồ của kỹ thuật đảo ngược, và công việc của họ gần như khó tin
    Tôi nghĩ rất có khả năng Apple đã cố tuyển họ, hoặc đã thử rồi nhưng bị từ chối

    • Alyssa hiện đã ký hợp đồng với Valve
      Cũng có thể nói Valve có lý do kinh doanh lớn hơn Apple để tận dụng năng lực này
    • Có lẽ Apple đã thử rồi nhưng bị từ chối vì NDA và điều khoản không cạnh tranh, hoặc có thể bộ phận HR đã không đánh giá đúng hồ sơ của họ
    • Tuyển dụng không phải là một đề nghị hay cho lắm
      Nhân viên thông thường được trả lương thấp so với lợi nhuận họ tạo ra, đặc biệt là trong IT
      Người có tài tốt hơn nên lập pháp nhân và bán dịch vụ với mức giá xứng đáng, nhưng ở một số quốc gia, các tập đoàn lớn đã vận động chính phủ để chặn con đường này

  • Mánh với phép toán nguyên tử rất thỏa mãn, và việc suy luận ra lệnh swizzle từ phả hệ PowerVR cũng đặc biệt ấn tượng
    Tôi nghĩ các kỹ sư Apple cũng sẽ học được từ đây, hoặc ít nhất đánh giá cao sự thông minh đó
    Nó làm tôi nhớ tới chuyện trước đây ở Accolade, khi reverse-engineer phần cứng video của Sega Genesis, các kỹ sư đã lấy tài liệu công khai của Texas Instruments TMS9918 VDP làm điểm xuất phát để suy luận VDP phái sinh từ 9918 của Genesis (Mega Drive)

    • Apple có tài liệu nội bộ về chip của chính họ, nên dù chắc chắn họ đánh giá cao công việc này, đây không phải là tình huống họ tạo ra một hộp đen rồi khi viết phần mềm lại quên mất cách nó được thiết kế

  • Nói cho rõ, đây không phải là driver Linux đầu tiên đạt chứng nhận phù hợp; ý nghĩa còn lớn hơn thế
    Bản thân Apple cũng không phù hợp với OpenGL ES 3.1, nên đây đúng nghĩa là driver OpenGL ES 3.1 đầu tiên cho dòng M, trên bất kỳ hệ điều hành nào, đạt chứng nhận phù hợp
    Vì vậy mới có lời kêu gọi quyên góp cho nhóm
    https://asahilinux.org/support/

    • Tôi rất thích những gì họ làm, nhưng trước đây khi bấm vào liên kết asahilinux trên Hacker News, một popup hiện lên nói rằng độc giả Hacker News không được chào đón trên trang, nên tôi không đọc được nội dung
    • Tôi tự hỏi liệu có thể dùng cái này trên macOS không
    • Liên kết GitHub ở đó dẫn tới marcan, người dẫn dắt Asahi, nhưng tôi chủ yếu muốn hỗ trợ phát triển driver
      Nếu có lựa chọn như vậy thì tôi muốn biết có thể làm ở đâu; nếu không có thì sau này tôi sẽ dùng liên kết đó

  • Hiện nay, khi debug các ứng dụng OpenGL trên macOS vốn không còn được khuyến nghị nữa, vấn đề này trở nên rất rõ ràng
    Vì lớp trừu tượng không phơi bày trạng thái OpenGL thực tế theo cách mà trình debug OpenGL cũ của Apple có thể đọc được
    Nếu không có một máy Mac đời cũ cài macOS cũ, nơi OpenGL chưa chạy nội bộ trên Metal, thì về cơ bản không thể debug OpenGL trên macOS bằng trình debug mặc định
    Trình debug hoặc ứng dụng đơn giản là crash

  • Việc này có vẻ chủ yếu hữu ích cho game, chứ không giúp nhiều cho deep learning
    Điểm hấp dẫn nhất của Mac M1 là dung lượng bộ nhớ lớn, và dù có thể không phù hợp lắm cho huấn luyện vì không thể phân tán trên nhiều card, nó lại tốt làm engine suy luận cho các mô hình lớn như Stable Diffusion, LLaMA

    • Hai chuẩn GPU đa dụng đa nền tảng mới nhất mà Apple Silicon về lý thuyết có thể dùng hoặc triển khai là SYCL và Vulkan Compute
      SYCL là framework lập trình cấp cao, trung lập nhà cung cấp của Khronos Group, nhưng mức hỗ trợ từ ứng dụng còn hạn chế; hy vọng sẽ dần tốt hơn nhờ sự hỗ trợ của Intel
      Vulkan Compute lách vấn đề bằng compute shader, nhưng tôi không rõ tình hình hỗ trợ từ ứng dụng ra sao
      SYCL có thể được triển khai trên OpenCL và phần mở rộng SPIR-V của OpenCL, nhưng do sự phụ thuộc mạnh vào nhà cung cấp, hướng này phần lớn đã bị bỏ ngoài Intel và Mesa; hiện nay nó thường được triển khai dưới dạng backend cho API của từng hãng GPU như ROCm, HIP, CUDA
      Áp dụng cách tương tự cho Metal sẽ rất khó; Mesa có hỗ trợ thử nghiệm OpenCL+SPIR-V cho Intel và AMDGPU, nên về lý thuyết có thể mở rộng sang Apple Silicon, nhưng OpenCL trên Apple Silicon hiện hoàn toàn chưa được hỗ trợ và mới chỉ ở mức có trong roadmap
    • Đúng vậy
      Muốn chạy deep learning thì cần các backend như CUDA, ROCm, MPS
      Việc huấn luyện mô hình PyTorch trên một máy chủ CUDA lớn rồi chạy suy luận trên MacBook Air là tương đối dễ
    • Phần compute shader là một bước tiến tốt, nhưng vẫn chưa cung cấp được interface mà các công cụ deep learning này kỳ vọng
      Tuy nhiên eiln đã viết driver cho Apple Neural Engine, giúp dùng phần cứng chuyên dụng thay vì GPU, và dự kiến sẽ được merge vào linux-asahi trong tương lai
    • TensorFlow Lite thực ra có hỗ trợ OpenGL ES

  • Cách nói Asahi Lina và hai người với nguồn vốn tối thiểu đã đánh bại một tập đoàn lớn nghe rất hay, nhưng thực tế có lẽ không phải là họ đã đánh bại, mà gần hơn là Apple không quan tâm
    Ngay từ đầu Apple đã không tham gia cuộc đua đó

  • Tôi thích cách nói giảm nói tránh “hai người với nguồn vốn tối thiểu đã đánh bại một tập đoàn lớn”
    Đây rõ ràng là chuyện đáng xấu hổ với Apple, và Apple không quan tâm đến tiêu chuẩn hay tuân thủ; họ muốn mọi người bị nhốt trong khu vườn đóng kín của riêng họ
    Nếu không phải là lập trình viên iOS thì tôi đã rời hệ sinh thái Apple từ lâu rồi
    Tôi thích phần cứng của họ, và cũng từng thích thương hiệu đề cao sự sáng tạo và con người như Apple thập niên 80–90, nhưng công ty hiện nay trông như đã mục ruỗng vì lòng tham đằng sau các video marketing đúng đắn về chính trị

    • Hoàn toàn đồng ý, nhưng việc tìm một lựa chọn thay thế có ý nghĩa thực tế gần như là bất khả thi
      Lần nâng cấp gần nhất tôi đã thử tìm phương án thay thế, nhưng để rời Apple thì phải chấp nhận vô số thỏa hiệp
      Thay cho iPhone, tôi đã cân nhắc Pixel với Android thuần và hỗ trợ dài hạn, nhưng các câu chuyện về vấn đề pin cứ liên tục xuất hiện; độ hoàn thiện phần mềm, hệ sinh thái ứng dụng và độ ổn định cũng là trở ngại
      Cũng khó tìm được sản phẩm có tỷ lệ giá/hiệu năng gần với MacBook Air M1 bản cơ bản về chất lượng hoàn thiện, pin và độ ổn định
      Tôi còn dùng iPad để đọc truyện tranh và tạp chí, nhưng suốt nhiều năm nay vẫn không rõ lựa chọn thay thế nào đáng kể trên thị trường tablet; Apple Watch có thể bỏ được, nhưng nó đơn giản là hoạt động tốt và có rất nhiều phụ kiện bên thứ ba
      Thời mỗi ngày flash ROM mới đã qua rồi, và thật tiếc là về độ ổn định cùng sự dễ dùng thì có vẻ rất khó thắng Apple
    • Bí mật lớn nhất của ngành này có lẽ là hai người có thể tạo ra nhiều thành quả hơn cả những công ty lớn nhất
      Lý do duy nhất khiến công việc của mọi người vẫn an toàn là không ai xác định chính xác được hai người đó là ai
    • Có vẻ mọi người đang bỏ qua việc Apple hoàn toàn có thể khóa laptop tương đối dễ dàng, nhưng họ vẫn để ngỏ cánh cửa cho các hệ điều hành khác và việc phát triển chúng
      Apple tự làm silicon và xây dựng toàn bộ nền tảng, nên khó có thể xem việc để lại khả năng chạy hệ điều hành khác chỉ là sai sót đơn thuần
      Rõ ràng họ đã có ý thức để ngỏ cánh cửa cho phát triển bên thứ ba, vậy mà bầu không khí chỉ trích Apple là điều đáng thất vọng
    • Tôi không cho rằng chỉ vì một tiêu chuẩn tồn tại thì Apple bắt buộc phải triển khai nó
      Ví dụ, để hỗ trợ một triển khai Vulkan liên tục sẽ cần nguồn lực đáng kể và tạo áp lực lên lịch phát hành, nên phải có lý do kinh doanh
      “Để tránh xấu hổ” nhiều khả năng là chưa đủ
      Lập luận về thiện chí với cộng đồng thì có thể, nhưng tôi không nghĩ Apple sẽ chạy theo thiện cảm của những người gọi họ là “công ty mục ruỗng vì lòng tham đằng sau các video marketing đúng đắn về chính trị”
    • OpenGL là một đặc tả đang chết dần dựa trên một mô hình lập trình cũ kỹ và tệ hại, còn bài kiểm tra tính phù hợp của Khronos cũng có những điểm kỳ lạ và quá mức
      Bài kiểm tra tính phù hợp không phải là mã nguồn mở, và “conformance suite” riêng trên GitHub là dựa trên dEQP của Google, chứ không phải bộ kiểm thử nội bộ của Khronos
      Một triển khai vẫn có thể nhận “chứng nhận tương thích chuẩn” dù còn khá nhiều lỗi lớn và lỗ hổng
      Apple chỉ hứa hỗ trợ OpenGL 3.1, và driver OpenGL cho M1 cũng được viết lại thành một lớp giả lập trên Metal để các ứng dụng hiện có tiếp tục hoạt động, nhưng họ sẽ không triển khai các phiên bản OpenGL mới hơn, và cũng không cần làm vậy
      Có nhiều điều để phê bình Apple, và Metal API cùng công cụ vẫn còn nhiều chỗ có thể cải thiện, nhưng việc không bận tâm đến OpenGL ở đây là một quyết định đủ hợp lý

  • Thật thú vị là trong nguyên văn không hề xuất hiện từ ‘Apple’ lần nào, mà chỉ dùng ‘nhà sản xuất’ và ‘tập đoàn lớn’
    Nếu là cố ý thì tôi tò mò liệu có phải vì lý do pháp lý không

    • Có lẽ vì đây không phải là bài viết về Apple
      Mối quan tâm là chạy Linux đúng cách trên kiến trúc M1/M2, chứ không phải Apple; nếu đối tượng là Microsoft, Amazon hay Google thì có lẽ họ cũng sẽ xử lý theo cách tương tự

  • Xem livestream về quá trình phát triển driver này rất thú vị, và đây thật sự là một công trình đáng kinh ngạc

    • Dành cho những ai chưa biết: có thể xem tại https://www.youtube.com/c/AsahiLina
      Đây là một trong những công việc lập trình cấp thấp ấn tượng nhất mà tôi từng thấy