Rust chạy thành công trên mọi GPU

 (rust-gpu.github.io)
10 điểm bởi GN⁺ 2025-07-27 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đã công bố một dự án demo trong đó một codebase viết bằng Rust có thể chạy trên mọi nền tảng GPU và CPU chủ chốt như CUDA, Vulkan (SPIR-V), Metal, DirectX 12, WebGPU, CPU
  • Lập trình GPU trước đây vốn phức tạp và dễ trùng lặp do phải dùng các ngôn ngữ riêng như GLSL, HLSL, nhưng demo lần này hỗ trợ mọi đích GPU chỉ bằng mã Rust thuần
  • Dự án tích hợp các triển khai chính như Rust GPU (SPIR-V), Rust CUDA (NVVM IR), Naga (lớp chuyển đổi ngôn ngữ GPU) — cùng một thuật toán bitonic sort hoạt động trên CPU và mọi GPU, đồng thời các tính năng ngôn ngữ của Rust như no_std, biên dịch có điều kiện, Newtype, Enum, Trait cũng được áp dụng nguyên vẹn cho mã GPU
  • Dù vẫn còn các hạng mục cần cải thiện như tích hợp chính thức vào rustc, gỡ lỗi và tính nhất quán API, đây vẫn là một nỗ lực có thể trở thành bước ngoặt cho điện toán GPU đa nền tảng

Hiện thực hóa điện toán GPU đa nền tảng dựa trên Rust

Giới thiệu dự án và ý nghĩa

  • Một codebase Rust duy nhất có thể chạy cùng một mã kernel trên CUDA (NVIDIA), Vulkan (SPIR-V), Metal (Apple), DirectX 12 (Windows), WebGPU (trình duyệt) và CPU
  • Không cần dùng các ngôn ngữ chuyên cho shader hoặc kernel như GLSL, HLSL; chỉ với mã Rust thuần, có thể xử lý cùng một phép toán trên cả GPU lẫn CPU
  • Cách làm này giúp giảm mạnh sự trùng lặp mã và độ phức tạp giữa GPU và CPU, đồng thời mang các ưu điểm về công cụ và ngôn ngữ của hệ sinh thái Rust như độ an toàn kiểu, kiểm thử, tài liệu hóa, quản lý build... vào cả lập trình GPU

Bối cảnh

  • Lập trình GPU truyền thống đòi hỏi phải dùng các ngôn ngữ shader chuyên biệt cho từng nền tảng như GSL, HLSL, MSL, WGSL...
  • Vì vậy mã CPU và GPU bị tách rời, dẫn đến trùng lặp logic và làm tăng độ phức tạp trong phát triển
  • Cộng đồng Rust đã theo đuổi hướng tiếp cận biên dịch Rust thông thường sang đích GPU để giải quyết vấn đề này
    • Rust GPU: biên dịch mã Rust sang SPIR-V, chạy trên Vulkan và các GPU tương thích SPIR-V
    • Rust CUDA: biên dịch mã Rust sang IR cho NVIDIA CUDA (NVVM IR, PTX), chạy trên CUDA
    • Naga: lớp trung gian hỗ trợ chuyển đổi giữa nhiều ngôn ngữ GPU khác nhau (WGSL, SPIR-V, GLSL, MSL, HLSL), chủ yếu được dùng trong dự án wgpu. Phụ trách tính di động giữa các backend
  • Các dự án này ban đầu phát triển độc lập nên API và cấu trúc khác nhau, nhưng nhờ hợp tác gần đây, việc chạy GPU từ một codebase chung đã trở thành hiện thực

Cách triển khai

  • Trong demo ví dụ, thuật toán bitonic sort được cài đặt bằng một mã Rust duy nhất, và cùng đoạn mã đó chạy được trên mọi đích GPU cũng như CPU
  • Các thuật ngữ thành phần chính
    • Host: mã Rust chạy trên CPU (khởi động tác vụ)
    • Device: GPU/CPU nơi kernel thực sự được thực thi
    • Driver API: các API mức thấp để giao tiếp với thiết bị như CUDA, Vulkan, Metal, DX12...
    • Backend: lớp trừu tượng trong Rust hướng tới Driver API (cust, ash, wgpu...)
  • Có thể chọn backend và điều khiển build thông qua tổ hợp feature flag và target của Rust
    • Ví dụ: cung cấp các tùy chọn build độc lập cho từng backend như wgpu, ash, cuda
    • Cũng có thể xây dựng kiến trúc gộp nhiều backend vào một binary duy nhất và chọn động lúc chạy

Luồng biên dịch kernel

  • Tùy theo target và feature, binary thực thi cho GPU (SPIR-V, PTX...) được tạo ra trong lúc build và được nhúng vào object file
  • Lúc runtime, kernel đã nhúng được nạp, rồi được chuyển sang định dạng mà từng nền tảng yêu cầu thông qua Naga... trước khi thực thi
  • Ví dụ:
    • macOS: chuyển SPIR-V sang MSL → chạy bằng Metal
    • Windows: chuyển SPIR-V sang HLSL → chạy bằng DX12
    • Linux/Android: SPIR-V → chạy bằng Vulkan
    • CUDA: biên dịch PTX sang SASS, tải lên GPU và thực thi

Kỹ thuật viết mã GPU thân thiện với Rust

  • Hỗ trợ no_std

    • GPU không có hỗ trợ hệ điều hành, vì vậy việc dùng no_std của Rust là bắt buộc
    • Do hệ sinh thái Rust vốn dĩ đã hỗ trợ các môi trường không có OS như embedded, firmware, kernel..., GPU cũng có thể được hỗ trợ theo cách tiêu chuẩn của Rust mà không cần một “chế độ đặc biệt” riêng

  • Biên dịch có điều kiện

    • Có thể viết mã phân biệt nền tảng và phân biệt GPU/CPU một cách rõ ràng, gọn gàng bằng cách kết hợp thuộc tính cfg với feature flag
    • IDE và trình biên dịch hiểu được toàn bộ các nhánh mã, giúp nâng cao độ tin cậy và năng suất phát triển

  • Tận dụng newtype

    • Những lỗi ngầm liên quan đến chỉ số hoặc ánh xạ struct trên GPU có thể được ngăn chặn ở cấp kiểu bằng cách dùng newtype
    • Với thuộc tính #[repr(transparent)], có thể tạo lớp trừu tượng kiểu mà gần như không phát sinh overhead thực tế

  • Enum và biểu diễn an toàn

    • Thay vì dùng magic number, có thể dùng Enum của Rust và áp dụng #[repr(u32)] để đảm bảo ánh xạ sang số nguyên native
    • Pattern matching và tính exhaustiveness (xử lý mọi trường hợp) giúp cấu thành mã an toàn hơn
    • Tuy nhiên, khi trao đổi giá trị Enum qua buffer dùng chung giữa CPU và GPU, cần lưu ý rằng mọi giá trị đều phải là Enum hợp lệ

  • Thuật toán generic dựa trên Trait

    • Có thể dùng Trait để cung cấp lớp trừu tượng chung cho các phép so sánh, chuyển đổi, tính toán GPU trên nhiều kiểu giá trị khác nhau
    • Việc chỉ định rõ trait bound cho thuật toán generic giúp cân bằng giữa type safety và khả năng tối ưu

  • #[inline] và tối ưu hiệu năng

    • Việc dùng #[inline] giúp dẫn hướng để các lớp trừu tượng biến mất trong kết quả biên dịch thực tế
    • Thiết kế này nhằm đảm bảo đặc tính GPU như hiệu năng cao và hạn chế stack không phải trả giá cho sự trừu tượng

  • Kết hợp struct và nhóm ngữ nghĩa

    • Các tham số GPU phức tạp có thể được gom theo đơn vị ý nghĩa và quản lý bằng struct, qua đó đảm bảo an toàn kiểu và tránh bùng nổ số lượng tham số
    • Có thể dùng mẫu Smart constructor để chặn trạng thái không hợp lệ ngay từ giai đoạn biên dịch

  • Bố cục bộ nhớ và kiểm soát #[repr(C)]

    • Để đảm bảo tương thích dữ liệu với GPU, bố cục struct được chỉ định tường minh bằng #[repr(C)]
    • Bài viết cũng nhắc tới nhu cầu hỗ trợ ngôn ngữ bổ sung trong tương lai, chẳng hạn tự động hóa padding theo từng GPU

  • Pattern matching

    • Đây là khái niệm mở rộng hơn của switch/case, cho phép xử lý rõ ràng mọi nhánh và trạng thái trong mã GPU
    • Trình biên dịch có thể kiểm tra đường đi của mã và tối ưu hiệu năng

  • Hàm generic

    • Có thể triển khai cùng một logic cho nhiều kiểu dữ liệu mà không bị phụ thuộc vào kiểu cụ thể
    • trait bound, monomorphization... giúp tăng tính bảo trì và sự thuận tiện trong kiểm thử

  • Derive macro

    • Tự động triển khai các trait phù hợp cho GPU như Copy, Clone, Debug, PartialEq, Pod
    • Giúp tăng độ an toàn và giảm boilerplate

  • Hệ thống module, quản lý workspace

    • Hệ thống package/module của Rust cho phép tổ chức có cấu trúc mã host, kernel, kiểu dữ liệu và mã nguồn theo từng backend
    • Cargo workspace và workspace dependency giúp đảm bảo tính nhất quán phụ thuộc giữa các crate và cải thiện khả năng bảo trì

  • Formatting, lint, tài liệu hóa

    • Có thể quản lý mã GPU bằng chính các công cụ chuẩn của Rust như rustfmt, clippy, giống hệt cách quản lý mã Rust thông thường, từ đó duy trì chất lượng nhất quán
    • Mã GPU cũng có thể được tài liệu hóa bằng doc comment và cargo doc

  • Build script

    • Có thể tự động hóa việc build kernel dựa trên feature flag và nhúng binary thông qua build.rs của Cargo

  • Unit test và năng suất phát triển

    • Mã kernel GPU có thể được kiểm thử cả trên CPU, giúp dễ phát triển và phát hiện lỗi hơn
    • Có thể dùng các công cụ truyền thống như debug bằng println, gdb/lldb
    • Kernel Vulkan cũng có thể được kiểm thử CI bằng driver phần mềm như SwiftShader, lavapipe
    • Hỗ trợ tích hợp mượt mà với công cụ bên thứ ba như đo test, code coverage, property-based testing...

Trải nghiệm phát triển còn chưa hoàn thiện và các thách thức

  • Vì backend GPU chưa được tích hợp chính thức vào trình biên dịch Rust, nên vẫn cần dùng các backend codegen riêng (spirv, nvvm) và khóa vào phiên bản nightly
  • Target CUDA phụ thuộc vào LLVM 7.1 của NVIDIA, nên trên các bản phân phối Linux mới cần build riêng
  • Trải nghiệm build và debug kernel vẫn còn hạn chế, còn thiếu khả năng truy vết lỗi và thông tin debug đầy đủ
  • API và tên gọi thư viện chuẩn giữa Rust GPU và Rust CUDA khác nhau, dễ gây nhầm lẫn
  • Về lâu dài, cần tăng cường tính nhất quán và mức độ tích hợp theo hướng GPU trên toàn bộ ngôn ngữ Rust và hệ sinh thái

Tham gia cộng đồng và tương lai

  • Việc chạy cùng một mã trên mọi nền tảng GPU chủ chốt bằng Rust nay đã trở thành hiện thực
  • Trong thời gian tới, các nhiệm vụ còn lại gồm cải thiện build và debug, mở rộng hỗ trợ ngôn ngữ Rust và API, cũng như tinh chỉnh hiệu năng
  • Các nhà phát triển muốn tham gia và đóng góp có thể tham khảo các repository GitHub của rust-gpu và rust-cuda

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-07-27
Ý kiến Hacker News

  • Việc kỹ thuật này khả thi thực sự rất ấn tượng
    Nhưng trường hợp sử dụng của tôi là chạy trên phần cứng máy khách tùy ý, nên tôi có xu hướng không tin tưởng mọi lớp trừu tượng được dựng trên API GPU
    Mục tiêu là tận dụng tối đa các chi tiết mức thấp của GPU, và cách tiếp cận xem những chi tiết đó là phiền phức thường dẫn đến lỗi và suy giảm hiệu năng
    Vì mỗi mục tiêu đều khác nhau một cách đáng kể
    Để vượt qua điều này, theo tôi một hệ thống tương tự phải được chính các nhà cung cấp cung cấp trực tiếp
    Nhưng vì lập trường giữa các hãng vẫn chưa thống nhất, có vẻ khác biệt theo từng nền tảng vẫn rất lớn
    Trong một số trường hợp có ngoại lệ như Angle, nhưng ngay cả những trường hợp đó cũng chỉ có được sự ổn định bằng cách giới hạn tính năng và rốt cuộc vẫn bị mất hiệu năng
    Dù vậy, việc các cách tiếp cận như biên dịch có điều kiện là khả thi rõ ràng vẫn rất hữu ích

    • Vì Rust là ngôn ngữ hệ thống nên bạn có thể có mức độ kiểm soát nhiều đến đâu tùy ý
      Chúng tôi dự định phản ánh các chi tiết và API của GPU vào ngôn ngữ cùng thư viện core/std, đồng thời phơi bày các tính năng của GPU và driver thông qua hệ thống cfg()
      (tác giả đây)

    • Tôi cũng nghĩ y hệt
      Tôi luôn thận trọng khi xây dựng thứ gì đó mang tính thương mại trên các lớp trừu tượng, adapter hoặc lớp chuyển đổi mà không biết liệu sau này chúng có tiếp tục được hỗ trợ đầy đủ hay không
      Sắp đến năm 2025 rồi mà tôi vẫn thấy rất cần một tiêu chuẩn mở được mọi nhà cung cấp hỗ trợ và cho phép dùng đầy đủ tính năng của phần cứng GPU hiện đại
      Trong bối cảnh hiện tại, việc Nvidia — công ty đã tạo ra rào cản phần mềm mạnh nhất — lại ngồi ở vị trí đại diện của Khronos khiến tôi thấy rất đáng suy ngẫm

    • Có vẻ bạn rất quan tâm đến hiệu năng nên tôi muốn hỏi vì tò mò
      Theo tôi thì hiện trạng của GPU khá giống CPU ngày xưa
      Với CPU, đã từng có cấu trúc trình biên dịch 3 tầng, tối ưu ở tầng trung gian rồi ở tầng cuối mới xuất mã phù hợp với từng phần cứng
      Ưu điểm của cấu trúc này là lớp trừu tượng tồn tại lâu dài và trình biên dịch ngày càng thông minh hơn theo thời gian
      Tôi tự hỏi liệu phía GPU cũng có thể có cấu trúc như vậy không
      Hay là vì GPU quá đa dạng nên điều đó bất khả thi hoặc không kinh tế, hoặc thực ra hiển nhiên là sẽ đi theo hướng đó nhưng công nghệ vẫn chưa tới mức ấy

    • Chính xác luôn
      Tôi không thấy rõ việc cố chạy Rust trên GPU Nvidia thì tốt hơn mã CUDA hiện có ở điểm nào
      Tôi hiểu chuyện thêm lớp trừu tượng, nhưng rốt cuộc lại có cảm giác kiểu “tạp nham cái gì cũng làm được”

    • Thật ra mọi thứ đều là trừu tượng
      CUDA cũng rốt cuộc chỉ là một lớp trừu tượng nhằm thống nhất về mặt khái niệm các phần cứng vốn hoàn toàn khác nhau

  • Tôi phát triển ứng dụng âm thanh native, và ở đây mọi chu kỳ xử lý đều quan trọng
    Ngoài ra tôi cần toàn bộ compute API chứ không chỉ shader đồ họa
    Tôi tò mò liệu pipeline "Rust -> WebGPU -> SPIR-V -> MSL -> Metal" có vững vàng về mặt hiệu năng hay không
    Có quá nhiều bước chuyển đổi nên trông khá mong manh và khó đoán
    "... -> Vulkan -> MoltenVk -> ..." cũng vậy
    Trong khi đó "Julia -> Metal" bỏ qua MSL và có thể tận dụng trực tiếp các tối ưu đặc thù của Apple Silicon, ví dụ Unified Memory
    Điểm đổi mới ở đây không phải ngôn ngữ shader, mà là dùng một ngôn ngữ lập trình hoàn chỉnh như Rust
    Rust hỗ trợ nhiều tính năng như newtype, trait, macro, v.v.

    • Khi dùng rust-gpu thì không nhất thiết phải đi qua lớp WebGPU
      Vì rust-gpu là backend sinh mã của trình biên dịch
      Cấu trúc của nó cho phép biên dịch Rust MIR trực tiếp sang SPIRV

    • "Pipeline Rust -> WebGPU -> SPIR-V -> MSL -> Metal có vững vàng về mặt hiệu năng không?"
      Về cơ bản đây là ý tưởng tương tự cách Apple dùng tối ưu hóa của Clang cho GPU
      SPIR-V là một biểu diễn trung gian giống IR dùng trong LLVM, nên có thể tối ưu theo từng hệ thống
      Về lý thuyết, một codebase có thể nhắm tới mọi GPU raster được hỗ trợ
      Ngược lại, stack Julia -> Metal kém tính di động hơn tương đối
      Với các nhà phát triển chỉ làm cho một nền tảng như plugin âm thanh thì điều này có thể không quan trọng, nhưng với các công ty phát triển đa nền tảng như u-he hay Spectrasonics thì một pipeline phức tạp dựa trên SPIR-V có thể hấp dẫn hơn

    • Về tính toán số và các tối ưu theo sau đó, Julia phù hợp hơn nhiều so với Rust là một ngôn ngữ hệ thống
      Nếu nhìn vào ma trận tương thích của Rust-CUDA thì có vẻ nhu cầu dùng Rust cho lập trình CUDA là rất thấp
      Phần lớn các tính năng mà mọi người thích ở CUDA đều bị thiếu, và nếu thực sự có nhu cầu lớn thì hẳn đã có tiến triển mạnh hơn, nhưng thực tế không phải vậy
      Có vẻ các lập trình viên CUDA không mấy muốn dùng Rust
      https://github.com/Rust-GPU/Rust-CUDA/blob/main/guide/src/features.md

  • Tôi cũng có đoạn mã muốn chạy trên GPU, nhưng mọi thứ trong lập trình GPU đều quá đau khổ nên cuối cùng chẳng làm
    Có lẽ công dụng thực sự của rust-gpu là biến các lập trình viên CPU thành lập trình viên GPU, dù phải chấp nhận mất mát hiệu năng ở mức nào đó
    Nếu bạn đã quen với phía GPU và nắm rõ cuda/vulkan/metal/dx thì có lẽ bạn sẽ không thấy công cụ này quá hấp dẫn

  • Tôi chỉ là một web developer bình thường nên có thể đây là câu hỏi ngớ ngẩn, nhưng tôi chưa từng lập trình GPU
    Tôi thắc mắc liệu WebGPU không phải là API duy nhất tương thích với mọi backend GPU hay sao, vậy chẳng phải nó đã giải quyết hết các vấn đề này rồi à
    Có vẻ WebGPU cũng chỉ là một trong các backend được hỗ trợ, nếu vậy chẳng phải là chồng thêm một lớp trừu tượng lên một lớp trừu tượng đã có sẵn rồi cuối cùng vẫn gọi backend GPU native sao?

    • Không phải vậy
      WebGPU là API để CPU điều khiển GPU thực hiện nhiều tác vụ đồ họa như chạy shader, tương tự D3D, Vulkan hay SDL GPU
      Rust-GPU là ngôn ngữ cho phép viết mã shader thực sự chạy trên GPU, tương tự HLSL, GLSL hay WGSL

    • Hồi Microsoft còn có ảnh hưởng mạnh thì đã có DirectX
      Nhưng giờ tôi không rõ các hãng GPU đang triển khai API riêng cho công nghệ độc quyền của họ đến mức nào
      Có đủ loại tính năng đặc thù như DLSS, MFG, RTX, v.v.
      Nếu là phản diện trong phim hoạt hình, người ta hoàn toàn có thể cố tình làm chậm các API cũ rồi chỉ cung cấp API riêng mới và nhanh
      Nhân tiện tôi cũng là web developer nên không biết rõ, nhưng ít nhất thì LLM cũng sẽ học được mấy chuyện này

    • Tôi xem WebGPU như một API kiểu mẫu số chung tối thiểu
      Ví dụ editor Zed nhắm trực tiếp vào Metal trên bản Mac
      Và ngay cả việc “chung” nghĩa là gì thì mỗi người cũng hiểu khác nhau
      Giống như OpenGL so với Vulkan, các công ty có thế lực thường muốn biến hệ sinh thái của riêng mình như CUDA, Metal, DirectX thành chuẩn thị trường

    • Nếu thực sự dễ như vậy thì CUDA đã không trở thành con hào cực mạnh của Nvidia như hiện nay

    • Dự án này được xây trên nền tảng rất quan trọng là nỗ lực của phần triển khai WebGPU là wgpu-rs
      WebGPU không tối ưu cho ứng dụng native
      Nó được thiết kế dựa trên các phiên bản Vulkan cũ hơn, đặc biệt là thời kỳ trước RTX, trong khi các API native thực thụ sau đó đã tiến hóa xa hơn nhiều

  • Hiện tại vẫn còn khá thô sơ, nhưng việc điều này khả thi đã là điều rất khó tin
    Nếu đà phát triển này tiếp tục, tôi cảm nhận được tiềm năng phá vỡ vấn đề khóa chặt theo nhà cung cấp vốn rất nặng trong phần mềm GPU và mở ra cạnh tranh thực sự giữa các hãng phần cứng
    Tôi tưởng tượng một ngày nào đó có thể viết mô hình machine learning bằng Rust và chạy được trên cả Nvidia lẫn AMD
    Tất nhiên để đạt hiệu năng cao nhất thì vẫn sẽ phải viết mã tối ưu riêng cho từng hãng, nhưng đó là bài toán tối ưu hóa
    Dù vậy, vẫn có thể có những kernel có tính di động tốt và chạy đa nền tảng

    • Có framework machine learning Rust tên là https://burn.dev, có nhiều backend như CUDA và ROCm
      Có thể đáng để tham khảo

    • Tương lai viết mô hình machine learning bằng Rust rồi chạy trên cả Nvidia lẫn AMD có lẽ là điều khó xảy ra trong vòng mười năm tới
      Thực tế là toàn bộ hệ sinh thái như jax và torch đều dựa trên Python
      Việc khiến toàn bộ lập trình viên trong ngành chuyển sang công cụ Rust gần như còn khó hình dung nổi

  • Nếu đếm các lớp trừu tượng thì

    1. Mã Rust đặc thù miền bài toán
    2. Trừu tượng hóa backend trên các crate như cust, ash, wgpu
    3. Trừu tượng hóa nền tảng, driver và API trong wgpu, v.v.
    4. Trừu tượng hóa driver và nền tảng trong Vulkan, OpenGL, DX12, Metal
    5. Trừu tượng hóa phần cứng đặc thù nhà cung cấp trong driver (chắc trong này còn nhiều lớp nữa)
    6. Phần cứng
      Tức là có ít nhất 6 tầng phức tạp ẩn bên dưới
      Tôi nghi ngờ liệu có thể xuyên qua ngần ấy lớp mà vẫn phản ánh nguyên vẹn các điểm đặc thù của từng nền tảng về mặt hiệu năng hay không

    • Điều rust-gpu làm rốt cuộc là biên dịch sang SPIRV, tức IR của Vulkan
      Vì vậy các tầng 2 và 3 có thể được bỏ qua hoặc đặt song song
      Bạn cũng có thể tận dụng nguyên bộ công cụ trong hệ sinh thái phát triển của Rust như cargo, cargo test, cargo clippy, rust-analyzer cho việc phát triển shader GPU
      Thật ra tôi không nghĩ lập trình GPU khó là vì kiến trúc GPU quá xa lạ, mà vì cả hệ sinh thái đều bị khóa theo nhà cung cấp và mắc kẹt với các công cụ cũ kỹ

    • Demo chắc chắn giống một cỗ máy Rube Goldberg phức tạp, nhưng lý do là vì đây là thời điểm đầu tiên mà chuyện này trở nên khả thi
      Theo thời gian nó sẽ trở nên tự nhiên và tích hợp hơn
      Và một lợi thế khác của hệ sinh thái Rust là bạn có thể trừu tượng hóa hoặc đi sát phần cụ thể đúng mức mình muốn
      Ví dụ có thể dùng tính năng đặc thù nền tảng qua std::arch, hoặc thậm chí viết cả assembly
      Bạn cũng có thể thay allocator, panic handler, và khi tính năng externally implemented items sắp ra mắt được bật lên thì độ linh hoạt trong việc xử lý các lớp trừu tượng theo ý muốn sẽ còn cao hơn nữa

    • Nhận xét hay đấy
      Nhưng các tầng 4-6 luôn tồn tại cả với shader hay mã CUDA
      Tầng 1 và 3 thực ra cũng chỉ được thay bằng các lớp khác thôi, nhất là khi làm đa nền tảng
      Kể cả dự án Rust này có thêm một lớp trừu tượng thì cùng lắm cũng chỉ thêm khoảng một tầng
      Và với tư cách là người làm việc thực tế ở các tầng 4-6, tôi có thể khẳng định bên trong đó còn ẩn rất nhiều phức tạp
      Thành thật mà nói còn có thể có nhiều tầng hơn nữa :P

    • Nhìn thực tế thì phần lớn người dùng cùng lắm chỉ chạm tới tầng (3) hoặc (4)
      Không thực sự là có thêm nhiều bước phụ trội đến vậy
      Nhân tiện, phía trên tầng 6 cũng còn thêm các lớp trừu tượng khác
      Firmware và vi kiến trúc sẽ hiện thực hóa tập lệnh mà chúng ta nghĩ tới

    • Tôi không nghĩ điều này khác quá nhiều so với việc vận hành các trình biên dịch và runtime riêng cho từng kiến trúc CPU
      Cũng có các calling convention khác nhau, khác biệt về endianness, và ở tầng phần cứng thì còn có firmware với microcode nữa

  • Điều thật sự đáng kinh ngạc là các crate no_std + no alloc sẵn có có thể chạy trên GPU gần như không cần sửa đổi
    Điều này thực sự mở ra rất nhiều ý tưởng ứng dụng

    • Nếu đó là mã được viết với giả định chạy trên CPU thì về mặt hiệu năng nó có thể hoạt động khá khác

  • Quá ấn tượng
    Danh sách các dự án Rust GPU giờ đã dài khủng khiếp rồi
    Cái này có vẻ là lớp trừu tượng thấp hơn burn, và burn lại thấp hơn candle
    Có vẻ việc còn lại bây giờ là thêm một backend như naga vào các dự án phía trên
    Cảm giác mọi người đang xây thứ gì đó trên những nền móng khác nhau, nhưng có lẽ vì công việc với naga là chuyện khá mới
    Tôi cũng muốn nói thêm rằng burn tập trung vào hỗ trợ nền tảng
    Nhưng nhìn lại thì backend duy nhất dùng naga là wgpu
    Vậy rốt cuộc cứ dùng wgpu thôi chẳng phải cũng ổn sao?
    Tóm lại là hoặc wgpu/ash(vulkan, metal) hoặc cuda
    Thêm một mẩu nữa: còn có một crate khác khá gần với nỗ lực này
    https://github.com/tracel-ai/cubecl
    [0]: https://github.com/tracel-ai/burn
    [1]: https://github.com/huggingface/candle/

  • Tôi băn khoăn không biết đây có thực sự là “Rust” đang chạy trên GPU hay không
    Lướt qua mã nguồn thì trông giống như cú pháp Rust được phủ đầy macro lập trình rồi cuối cùng đặt lên trên một ngôn ngữ shader
    Vì lập trình GPU khác biệt quá nhiều nên tôi nghĩ cần có sự cẩn trọng đặc biệt
    Việc thêm trừu tượng theo cách này có thể khiến một số tối ưu trở nên bất khả thi

    • Trên thực tế đây là cấu trúc mà mã Rust chạy được sẽ được biên dịch thành bytecode spirv

  • Tôi thực sự vui khi thấy dự án này
    Tôi cảm thấy nó giúp ích rất nhiều cho những lập trình viên không muốn bị cuốn vào cuộc chiến nền tảng
    Các ví dụ như https://github.com/cogentcore/webgpu cũng rất hay
    Tôi dùng golang và chỉ cần GPU hoạt động tốt trên mọi nền tảng là được, và nhờ những thứ như thế này mà có thể dùng GPU ở khắp nơi
    Thật sự biết ơn Rust