▲

Rust를 모든 GPU에서 실행하기 성공

 (rust-gpu.github.io)
2P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • Rust로 작성한 하나의 코드베이스가 CUDA, Vulkan(SPIR-V), Metal, DirectX 12, WebGPU, CPU 등 모든 주요 GPU 및 CPU 플랫폼에서 동작하는 데모 프로젝트 공개
  • 기존 GPU 프로그래밍은 GLSL, HLSL 등 별도의 언어 사용으로 복잡성과 중복 문제가 발생하지만 이번 데모는 순수 Rust 코드만으로 모든 GPU 타겟 지원
  • 주요 구현체로 Rust GPU(SPIR-V), Rust CUDA(NVVM IR), Naga(GPU 언어 변환 계층) 프로젝트를 통- 동일한 비토닉 정렬 알고리듬이 CPU와 모든 GPU에서 동작하며, Rust의 no_std, 조건부 컴파일, Newtype, Enum, Trait 등 언어 기능이 GPU 코드에도 그대로 적용됨
  • 아직 공식 rustc 통합, 디버깅, API 일관성 등 개선 과제가 남아 있으나, GPU 크로스플랫폼 컴퓨팅의 전환점이 되는 시도임

Rust 기반 GPU 크로스플랫폼 컴퓨팅의 실현

프로젝트 소개 및 의의

  • 하나의 Rust 코드베이스로 CUDA(NVIDIA), Vulkan(SPIR-V), Metal(Apple), DirectX 12(Windows), WebGPU(브라우저), CPU 등에서 동일한 커널 코드 실행
  • 셰이더 또는 커널 전용 언어(GLSL, HLSL 등) 사용 없이, 순수 Rust 코드만으로 GPU 및 CPU에서 동일한 연산 처리 가능함
  • 이는 GPU·CPU 간 코드 중복 및 복잡도를 대폭 줄이고, Rust 생태계의 도구 및 언어 장점(타입 안정성, 테스트, 문서화, 빌드 관리 등)을 GPU 프로그래밍에도 적용함

배경

  • 전통적 GPU 프로그래밍은 각 플랫폼별로 특화된 셰이더 언어(예:GSL, HLSL, MSL, WGSL 등) 사용이 필수임
  • 이에 따라 CPU와 GPU 코드가 분리되고 로직 중복 및 개발 복잡성 증가 문제를 낳음
  • Rust 커뮤니티는 이에 대응해 일반 Rust를 GPU 대상으로 컴파일하는 접근을 추구 중임
    • Rust GPU: Rust 코드를 SPIR-V로 컴파일, Vulkan 및 SPIR-V 호환 GPU에서 동작
    • Rust CUDA: Rust 코드를 NVIDIA CUDA용 IR(NVVM IR, PTX)로 컴파일, CUDA에서 실행
    • Naga: 다양한 GPU 언어( WGSL, SPIR-V, GLSL, MSL, HLSL) 간 변환을 지원하는 중간 계층(주로 wgpu 프로젝트에서 사용). 백엔드 이식성을 담당
  • 각 프로젝트가 독립적으로 시작되어 API, 구조가 달랐으나, 최근 협력을 통해 공동 코드베이스의 GPU 실행이 실현됨

구현 방식

  • 예제 데모에서는 비토닉 정렬 알고리듬을 단일 Rust 코드로 구현하고, GPU와 CPU의 모든 대상으로 동일 코드가 실행됨
  • 주요 컴포넌트 용어
    • Host: CPU에서 실행되는 Rust 코드(작업 시작)
    • Device: 커널이 실제로 실행되는 GPU/CPU
    • Driver API: CUDA, Vulkan, Metal, DX12 등, 장치와 통신용 저수준 API
    • Backend: 러스트에서 드라이버 API 대상으로 추상화 제공(cust, ash, wgpu 등)
  • 러스트의 feature 플래그와 타깃 조합을 통해 백엔드 선택 및 빌드 제어 가능
    • 예: wgpu, ash, cuda 등 각 백엔드 별 독립 빌드 옵션 제공
    • 여러 백엔드를 하나의 바이너리로 빌드해 런타임에서 동적으로 선택하는 구조 구현 가능

커널 컴파일 흐름

  • 타깃 및 feature에 따라 GPU 실행 바이너리(SPIR-V, PTX 등)를 빌드 시 생성, 객체 파일에 임베드됨
  • 런타임에서 임베드된 커널을 로드, Naga 등을 통해 플랫폼별 요구 포맷으로 변환 후 실행
  • 예:
    • macOS: SPIR-V를 MSL로 변환→Metal 실행
    • Windows: SPIR-V를 HLSL로 변환→DX12 실행
    • Linux/Android: SPIR-V→Vulkan 실행
    • CUDA: PTX를 SASS로 컴파일, GPU 업로드 및 실행

Rust 친화적 GPU 코딩 기법

  • no_std 지원

    • GPU에는 OS 지원이 없으므로 Rust의 no_std 사용이 필수임
    • 기본 Rust 생태계가 내장적으로 임베디드, 펌웨어, 커널 등 OS 없는 환경을 가정함에 따라 GPU도 별도 "특수 모드" 없이 Rust 표준 방식으로 지원 가능함

  • 조건부 컴파일

    • cfg 속성과 feature 플래그 조합으로 플랫폼 구분 코드와 GPU/CPU 구분 코드를 명확하고 간결하게 작성 가능함
    • IDE와 컴파일러가 모든 코드 경로를 이해하여, 높은 코드 신뢰성 및 생산성 확보

  • newtype 활용

    • GPU에서 실수할 수 있는 암묵적 인덱스·구조체 매핑을 newtype 사용으로 타입 레벨에서 오류 방지
    • #[repr(transparent)] 속성으로 실질적인 오버헤드 없이 타입 추상화 가능

  • Enum과 안전한 표현

    • 매직 넘버 사용 대신 Rust Enum 사용, #[repr(u32)] 적용으로 네이티브 정수 매핑 확보
    • 패턴 매칭과 exhaustiveness(모든 경우 분기 처리)로 안전한 코드 구성
    • 단, CPU-GPU 간 공유 버퍼에 Enum 값을 주고받을 때는 모든 값이 올바른 Enum이어야 하므로 주의 필요

  • Trait 기반 제네릭 알고리듬

    • Trait을 이용해 다양한 값 타입에 대해 공통된 비교, 변환, 연산 등 GPU 연산 추상화 제공
    • 제네릭 알고리듬에 trait bound를 명확하게 지정하여 type safety와 최적성 양립

  • #[inline] 및 성능 최적화

    • #[inline] 사용으로 추상화 계층이 실제 컴파일 결과에서 사라지도록 유도
    • GPU 특성(성능, 스택 부족 등)상 추상화의 비용이 없도록 설계됨

  • Struct 조합 및 의미론적 그룹화

    • 복잡한 GPU 파라미터를 의미 단위로 묶어 struct로 관리, 타입 안정성 확보 및 파라미터 폭증 방지
    • Smart constructor 패턴으로 invalid 상태를 컴파일 단계에서 차단

  • 메모리 레이아웃 및 #[repr(C)] 제어

    • GPU와의 데이터 호환성을 위해 #[repr(C)]로 구조체 레이아웃을 명시적으로 지정
    • 향후 GPU별 padding 자동화 등 추가 언어 지원 필요성 언급

  • 패턴 매칭

    • Switch/case의 확장된 개념으로, GPU 코드 내 모든 분기 및 상태를 명확하게 처리할 수 있음
    • 컴파일러에 의한 코드 경로 체크 및 성능 최적화 가능

  • 제네릭 함수

    • 데이타 타입에 구애받지 않고 여러 타입에 대해 동일 로직 구현
    • trait bound, 모노모피제이션 등으로 유지보수성·테스트 용이성 강화

  • Derive 매크로

    • Copy, Clone, Debug, PartialEq, Pod 등 GPU-적합 트레잇 자동 구현
    • 안전성 및 코드 보일러플레이트 최소화

  • 모듈 시스템, 워크스페이스 관리

    • Rust의 패키지/모듈 시스템으로 호스트 코드, 커널, 타입, 백엔드 별 소스 구조화
    • Cargo workspace, workspace dependency로 크레이트 간 의존성 일관성, 유지보수 편의성 확보

  • 포매팅, 린트, 문서화

    • rustfmt, clippy 등 Rust 표준 도구와 완전히 동일한 방식으로 GPU 코드 관리, 일관된 품질 유지 가능
    • Doc comment, cargo doc으로 GPU 코드도 문서화

  • 빌드 스크립트

    • Cargo의 build.rs를 통해 feature flag 기반 커널 빌드 및 바이너리 임베드 자동화

  • 유닛 테스트 및 개발 생산성

    • GPU 커널 코드를 CPU에서도 테스트할 수 있어 개발 및 버그 탐지 용이
    • println 디버그, gdb/lldb 등 전통 도구 사용 가능
    • Vulkan 커널도 소프트웨어 드라이버(SwiftShader, lavapipe)로 CI 테스트 가능
    • 테스트 및 코드 커버리지 측정, property-based 테스트 등 서드파티 도구와 원활 연동

미완성된 개발자 경험 및 과제

  • GPU 백엔드가 공식 Rust 컴파일러에 내장되지 않아 별도 코드젠 백엔드(spirv, nvvm) 사용 및 nightly 버전 고정 필요
  • CUDA 타깃은 NVIDIA의 LLVM 7.1에 종속적이어서 최신 리눅스 배포판에서 별도 빌드 필요
  • 커널 빌드·디버깅 경험 부족, 에러 트레이싱/디버그 정보 미흡 문제가 있음
  • Rust GPU와 Rust CUDA의 API, 표준 라이브러리 명칭 등이 달라 혼란 야기
  • 장기적으로 Rust 언어와 생태계 전반에 GPU 위주의 일관성, 통합성 강화 필요

커뮤니티 참여 및 미래

  • Rust로 모든 주요 GPU 플랫폼에서 동일 코드 실행이 실현됨
  • 앞으로는 빌드 및 디버깅 개선, Rust 언어 및 API 지원 확대, 성능 튜닝 등이 과제로 남아있음
  • 참여 및 기여를 원하는 개발자는 rust-gpu, rust-cuda의 GitHub 레포지토리를 참조할 것
▲
GN⁺ 11시간전  [-]
Hacker News 의견

  • 이 기술이 가능하다는 점이 정말 인상적임
    하지만 내 사용사례는 임의의 클라이언트 하드웨어에서 실행하는 것이라 GPU API 위로 구성된 모든 추상화 계층을 신뢰하지 않는 편임
    GPU의 저수준 세부사항을 최대한 활용하는 게 목적이고, 이런 세부사항을 귀찮다고 여기는 접근은 버그와 성능 저하로 이어짐
    각 타겟이 의미 있게 다르기 때문임
    이를 극복하려면 비슷한 시스템을 공급업체에서 직접 제공해야 한다고 봄
    하지만 업체 간 입장이 여전히 합의되지 않았기 때문에 플랫폼별 차이가 큰 걸로 보임
    특정 경우엔 Angle 같은 예외도 있지만, 이런 경우도 기능 제한을 통해서만 안정성을 얻으며 결과적으로 성능 손실이 있음
    그래도 조건부 컴파일 같은 접근이 가능하다는 점은 분명히 도움이 되는 부분임

    • Rust는 시스템 언어이기 때문에 원하는 만큼의 제어권을 가질 수 있음
      우리는 GPU의 세부사항과 API를 언어와 core/std 라이브러리에 반영하고, GPU와 드라이버 기능을 cfg() 시스템을 통해 노출할 계획임
      (작성자임)

    • 나도 똑같이 생각함
      앞으로 충분한 지원을 받을 수 있을지 모르는 추상화 계층, 어댑터, 변환 레이어 위에 상업적인 무언가를 구축하는 데 항상 조심스러움
      2025년이 다 되어가지만 여전히 모든 공급업체가 지원하고, 최신 GPU 하드웨어의 전체 기능을 쓸 수 있게 해주는 오픈 스탠다드가 절실하다고 느낌
      현재 상황이 이런데다가 가장 강력한 소프트웨어 진입장벽을 만든 Nvidia가 Khronos의 대표로 앉아있는 현실이 의미심장하게 느껴짐

    • 성능에 관심이 많은 것 같아서 궁금해서 묻고 싶음
      내가 보기엔 GPU 분야의 현재 모습이 예전 CPU와 많이 비슷함
      CPU에서는 3단계 컴파일러 구조로, 중간 계층에서 최적화한 뒤 최종 계층에서 각 하드웨어에 맞는 코드를 내보내는 방식이었음
      이 구조의 장점은 추상화 계층이 오래가고, 컴파일러가 시간이 지나며 더 똑똑해진다는 점임
      GPU 쪽에서도 이런 구조가 가능한지 궁금함
      아니면 GPU의 다양성이 너무 커서 불가능하거나 비경제적인지, 혹은 당연히 그쪽으로 갈 방향인데 아직 기술이 안 된 것인지 궁금함

    • 정확히 맞는 말임
      Nvidia GPU에서 Rust를 굳이 실행하는 게 기존의 CUDA 코드보다 더 나은 점을 잘 모르겠음
      추상화를 더하는 건 이해하지만, 결과적으로 '잡다하게 모든 것을 할 수 있는' 느낌이 있음

    • 사실 모든 게 추상화임
      CUDA도 실제로는 서로 완전히 다른 하드웨어를 개념적으로 통일시키는 추상화에 불과함

  • 나는 네이티브 오디오 앱을 개발하는데, 여기선 모든 연산 주기가 중요함
    또한 그래픽 셰이더가 아니라 전체 컴퓨트 API가 필요함
    "Rust -> WebGPU -> SPIR-V -> MSL -> Metal" 파이프라인이 성능 측면에서 견고한지 궁금함
    너무 여러 단계의 변환이 들어가서 약하고 예측 불가해 보임
    "... -> Vulkan -> MoltenVk -> ..."도 마찬가지임
    반면 "Julia -> Metal"은 MSL을 건너뛰고, Apple Silicon의 특수 최적화(예: Unified Memory)를 바로 활용할 수 있음
    여기서 혁신은 셰이더 언어가 아니라, Rust처럼 완전한 프로그래밍 언어를 쓴다는 점임
    Rust는 newtype, trait, macro 등 다양한 기능을 지원함

    • rust-gpu 사용시 꼭 WebGPU 계층은 거치지 않아도 됨
      rust-gpu는 컴파일러의 코드 생성 백엔드이기 때문임
      Rust MIR을 바로 SPIRV로 컴파일 가능한 구조임

    • "Rust -> WebGPU -> SPIR-V -> MSL -> Metal" 파이프라인이 성능 면에서 견고한가요?
      기본적으로 GPU를 위한 Apple의 Clang 최적화 방식과 비슷한 개념임
      SPIR-V는 LLVM에서 쓰는 IR과 같은 중간 표현이라, 시스템별로 최적화할 수 있음
      이론상, 하나의 코드 베이스로 지원되는 모든 래스터 GPU를 타깃으로 할 수 있음
      Julia -> Metal 스택은 반면 이식성이 상대적으로 떨어짐
      오디오 플러그인처럼 플랫폼 한정 개발자에겐 상관없지만, u-he나 Spectrasonics 등 크로스 플랫폼 개발사라면 복잡한 SPIR-V 기반 파이프라인이 더 매력적일 수 있음

    • 수치 연산과 그 후속 최적화에 있어 Julia가 시스템 언어인 Rust보다 훨씬 어울림
      Rust-CUDA의 호환성 매트릭스를 보면 CUDA 프로그래밍에 Rust 수요가 아주 적은 걸 알 수 있음
      사람들이 좋아하는 CUDA의 기능이 대부분 빠져 있고, 실제로 수요가 많았다면 더 큰 진전이 있을 텐데 이렇지 않음
      CUDA 프로그래머들은 Rust를 쓸 의향이 별로 없는 듯함
      https://github.com/Rust-GPU/Rust-CUDA/blob/main/guide/src/features.md

  • 나처럼 GPU에서 돌고 싶은 코드가 있어도, GPU 프로그래밍의 모든 것이 고통이라 결국 안 하게됨
    rust-gpu의 진짜 용도는 CPU 개발자를 성능 손해를 어느 정도 감수하더라도 GPU 개발자로 만들어주는 게 아닐까 싶음
    이미 GPU 쪽에 익숙하고 cuda/vulkan/metal/dx를 꿰고 있다면 이런 도구에 큰 매력을 못 느낄 것임

  • 나는 단순 웹 개발자라 어쩌면 바보 같은 질문일 수 있지만, GPU 프로그래밍을 해본 적이 없음
    WebGPU가 모든 GPU 백엔드에 호환되는 단일 API이니 이런 문제를 다 해결한 것 아닌지 궁금함
    WebGPU도 지원 백엔드 중 하나인 걸로 보이는데, 만약 그렇다면 기존에 있던 추상화 위에 또 다른 추상화를 얹어 결국 네이티브 GPU 백엔드를 호출하게 되는 셈 아닌지?

    • 그렇지 않음
      WebGPU는 D3D, Vulkan, SDL GPU처럼 CPU에서 GPU를 제어해 셰이더 실행 등 여러 그래픽 작업을 하게 만드는 API임
      Rust-GPU는 HLSL, GLSL, WGSL과 비슷하게 GPU에서 실제로 실행되는 셰이더 코드를 쓸 수 있는 언어임

    • 마이크로소프트가 영향력이 있을 때는 directx가 있었음
      그런데 요즘은 GPU 제조사들이 각자 독자적인 기술을 위한 전용 API를 얼마만큼 구현하고 있는지 잘 모르겠음
      DLSS, MFG, RTX 등 각종 독특한 기능들이 있음
      만약 만화 영화 속 악당이라면, 기존 API를 일부러 느리게 만들고, 새롭고 더 빠른 벤더 전용 API만 빠르게 제공할 수도 있음
      참고로 나도 웹 개발자라 잘 모르지만, 최소한 LLM이 이런 내용을 학습하게 되는 셈임

    • WebGPU는 최소 공통 API에 가깝다고 봄
      예를 들어 Zed 에디터는 Mac 버전에서 Metal을 직접 타깃으로 함
      또 "공통"이 의미하는 바에 대해서도 각자 의견이 다름
      OpenGL 대 Vulkan처럼, 힘 있는 업체들은 CUDA, Metal, DirectX 등 자기 생태계를 시장 표준으로 만들려는 움직임을 보임

    • 정말 그렇게 쉬웠으면 CUDA가 지금 Nvidia의 막강한 해자 역할을 하지는 않았을 것임

    • 이 프로젝트는 wgpu-rs WebGPU 구현의 노력이 중요한 기반임
      WebGPU는 네이티브 앱에는 최적이 아님
      Vulkan의 예전 버전(특히 pre-RTX)을 토대로 설계됐기에, 그 후 본격적인 네이티브 API들은 훨씬 더 진화함

  • 아직은 조악한 수준이지만, 이런 게 가능하다는 게 정말 믿기지 않음
    앞으로 이런 발전이 이어진다면, GPU 소프트웨어의 거센 벤더 종속 문제를 깨고, 하드웨어 업체 간 진짜 경쟁이 가능해질 수도 있다는 잠재력을 느끼는 중임
    언젠가 머신러닝 모델을 Rust로 작성해 Nvidia, AMD 양쪽에서 실행할 수 있는 세상이 올 수도 있다고 상상해봄
    물론 최고 성능을 내기 위해서는 각 벤더에 특화된 코드를 써야 하겠지만 그건 최적화 문제임
    그럼에도 크로스플랫폼으로 도는 이식성 좋은 커널을 쓸 수 있음

    • https://burn.dev 이라는 Rust 머신러닝 프레임워크가 있는데 CUDA와 ROCm 등 다양한 백엔드가 있음
      참고해볼 만함

    • 머신러닝 모델을 Rust로 짜서 Nvidia, AMD에서 모두 돌릴 수 있는 미래는 십 년 안엔 힘들 것 같음
      현실적으로 jax와 torch 등 전체 생태계가 Python 기반임
      현업 개발자 모두를 Rust 툴로 갈아타게 만드는 일은 거의 상상조차 어렵게 느껴짐

  • 추상화 계층을 세어 보면

    1. 도메인 특화 Rust 코드
    2. cust, ash, wgpu 크레이트 위에서 백엔드 추상화
    3. wgpu 등에서 플랫폼, 드라이버, API 추상화
    4. Vulkan, OpenGL, DX12, Metal에서 드라이버 및 플랫폼 추상화
    5. 드라이버에서 벤더 특정 하드웨어 추상화 (아마 이 안에도 더 있음)
    6. 하드웨어
      이렇게 적어도 6개의 숨어 있는 복잡성이 존재함
      이런 여러 계층을 다 뚫고 플랫폼 특이점을 성능상 그대로 반영하는 게 가능할지 의문임

    • rust-gpu가 하는 일은 결국 SPIRV(즉, Vulkan의 IR)로 컴파일하는 것임
      그래서 2, 3번 계층은 생략하거나 평행 구조로 두는 것도 가능함
      Rust의 개발 생태계에 있는 cargo, cargo test, cargo clippy, rust-analyzer 같은 툴도 GPU 셰이더 개발에 그대로 활용할 수 있음
      사실 GPU 아키텍처가 너무 외계적이라 GPU 프로그래밍이 힘든 게 아니라, 생태계 전체가 벤더 종속적이면서 오랜 도구에 발목 잡힌 결과라 생각함

    • 데모는 확실히 복잡한 루브 골드버그 머신에 가깝지만, 그 이유는 이런 게 처음으로 가능한 시점이기 때문임
      시간이 지나면 더 자연스럽고 통합적으로 바뀔 것임
      그리고 Rust 생태계의 또 다른 장점으로, 원하는 만큼 추상화하거나 구체적으로 개발할 수 있음
      예를 들어 std::arch로 플랫폼 특화 기능을 쓰거나, 어셈블리도 쓸 수 있음
      할당자, 패닉 핸들러 교체도 가능하고, 곧 나올 externally implemented items 기능이 활성화되면 추상화 계층도 원하는 만큼 다룰 수 있는 유연성이 더 커질 전망임

    • 좋은 지적임
      하지만 4-6단계 계층은 셰이더나 CUDA 코드에도 항상 존재하는 부분임
      1, 3단계도 사실 다른 계층으로 대체될 뿐임(특히 크로스플랫폼이라면)
      이 Rust 프로젝트가 추상화 계층을 추가한다 해도 한 단계 정도임
      그리고 4-6단계 실무 담당자로서, 그 안에도 숨어 있는 복잡성이 엄청나게 많음을 확신함
      솔직히 더 많은 계층이 들어가기도 함 :P

    • 현실적으로 봤을 때, 대부분의 사용자는 최대 (3) 혹은 (4) 계층까지만 다루게 됨
      실제로 그렇게 큰 추가 단계가 늘어나는 건 아님
      참고로 6단계 위로도 추상화 레이어는 더 있음
      펌웨어, 마이크로아키텍처가 우리가 생각하는 명령어 셋을 구현함

    • CPU 아키텍처별로 다른 컴파일러와 런타임을 운용하는 것과 그리 다를 게 없다고 생각함
      각기 다른 호출 규약, 엔디안 차이 등도 있고 하드웨어 수준에서는 펌웨어와 마이크로코드까지 있음

  • 기존의 no_std + no alloc 크레이트가 거의 수정없이 GPU에서 돌아간다는 점이 정말 놀라움
    이게 정말 다양한 응용 아이디어를 열어주는 느낌임

    • CPU에서 실행을 가정한 코드라면 성능 면에서 꽤 다르게 작용할 것임

  • 정말 대단함
    벌써 Rust GPU 프로젝트 리스트도 엄청 많아졌음
    이번 것은 burn보다 더 저수준 추상화에 가깝고, burn은 candle보다 더 저수준임
    이제 남은 건 naga 같은 백엔드를 저 위 프로젝트에 더하는 일인 듯
    다들 서로 다른 기반 위에 뭔가를 만드는 느낌이긴 한데, naga 작업이 최근 일이어서 그런 듯함
    burn은 플랫폼 지원에 집중한다는 점도 첨언하고 싶음
    그런데 보니까 naga를 쓰는 유일한 백엔드는 wgpu임
    그래서 결과적으로는 wgpu만 써도 괜찮은 거 아님?
    요약하면 wgpu/ash(vulkan, metal) 아니면 cuda임
    추가 토막: 이 노력과 가까운 또 하나의 크레이트
    https://github.com/tracel-ai/cubecl
    [0]: https://github.com/tracel-ai/burn
    [1]: https://github.com/huggingface/candle/

  • 이게 진짜로 "Rust"가 GPU 위에서 돌아가는 게 맞는지 의문임
    코드를 대충 살펴보면, 프로그래밍 매크로가 잔뜩 들어간 Rust 문법 위에 최종적으로 셰이더 언어를 얹은 구조로 보임
    GPU 프로그래밍은 워낙 다르기 때문에 특별한 주의가 필요하다고 생각함
    이렇게 추상화를 넣으면 특정 최적화가 불가능해질 수 있음

    • 현실적으로 바로 동작하는 러스트 코드가 spirv 바이트코드로 컴파일되는 구조임

  • 이 프로젝트를 보고 정말 기쁨
    플랫폼 싸움에 휘말리기 싫은 개발자들에게 큰 도움을 주고 있다고 느낌
    https://github.com/cogentcore/webgpu 같은 예시도 좋음
    나는 golang을 쓰고 모든 플랫폼에서 GPU만 잘 활용되면 되는데, 이런 덕분에 GPU를 어디서나 쓸 수 있음
    Rust에 정말 감사함

답변달기