이 기술이 가능하다는 점이 정말 인상적임
하지만 내 사용사례는 임의의 클라이언트 하드웨어에서 실행하는 것이라 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 툴로 갈아타게 만드는 일은 거의 상상조차 어렵게 느껴짐
추상화 계층을 세어 보면
도메인 특화 Rust 코드
cust, ash, wgpu 크레이트 위에서 백엔드 추상화
wgpu 등에서 플랫폼, 드라이버, API 추상화
Vulkan, OpenGL, DX12, Metal에서 드라이버 및 플랫폼 추상화
드라이버에서 벤더 특정 하드웨어 추상화 (아마 이 안에도 더 있음)
하드웨어
이렇게 적어도 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에 정말 감사함
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 툴로 갈아타게 만드는 일은 거의 상상조차 어렵게 느껴짐
추상화 계층을 세어 보면
이렇게 적어도 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에서 돌아간다는 점이 정말 놀라움
이게 정말 다양한 응용 아이디어를 열어주는 느낌임
정말 대단함
벌써 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/
CubeCL에 대한 내용도 정리되어 있음
이게 진짜로 "Rust"가 GPU 위에서 돌아가는 게 맞는지 의문임
코드를 대충 살펴보면, 프로그래밍 매크로가 잔뜩 들어간 Rust 문법 위에 최종적으로 셰이더 언어를 얹은 구조로 보임
GPU 프로그래밍은 워낙 다르기 때문에 특별한 주의가 필요하다고 생각함
이렇게 추상화를 넣으면 특정 최적화가 불가능해질 수 있음
이 프로젝트를 보고 정말 기쁨
플랫폼 싸움에 휘말리기 싫은 개발자들에게 큰 도움을 주고 있다고 느낌
https://github.com/cogentcore/webgpu 같은 예시도 좋음
나는 golang을 쓰고 모든 플랫폼에서 GPU만 잘 활용되면 되는데, 이런 덕분에 GPU를 어디서나 쓸 수 있음
Rust에 정말 감사함