▲

GN⁺: SCALE - AMD GPU에서 수정 없이 CUDA 실행

 (docs.scale-lang.com)
12P by neo 4달전 | favorite | 댓글 1개
  • SCALE은 CUDA 애플리케이션을 AMD GPU용으로 네이티브 컴파일할 수 있게 해주는 GPGPU 프로그래밍 툴킷
  • CUDA 프로그램이나 빌드 시스템을 수정할 필요가 없으며, 더 많은 GPU 벤더와 CUDA API 지원이 개발 중임

어떻게 작동하는가?

  • SCALE은 다른 크로스 플랫폼 GPGPU 솔루션과 비교해 몇 가지 주요 혁신을 가짐
    • CUDA 프로그램을 그대로 수용함. 다른 언어로 포팅할 필요가 없음. 이는 프로그램이 인라인 PTX asm을 사용하는 경우에도 해당됨
    • SCALE 컴파일러는 nvcc와 동일한 명령줄 옵션과 CUDA 방언을 수용하여 드롭인 대체품으로 작동함
    • NVIDIA CUDA Toolkit 설치를 "가장"하여 기존 빌드 도구와 스크립트가 그대로 작동함

어떤 프로젝트가 테스트되었는가?

  • 오픈 소스 CUDA 프로젝트를 컴파일하고 테스트를 실행하여 SCALE을 검증함
  • 현재 다음 오픈 소스 프로젝트가 야간 자동 테스트에 포함되어 있으며 완전히 통과함
    • NVIDIA Thrust, Blender Cycles, AMGX, llama-cpp, faiss, xgboost, GOMC, stdgpu, hashcat

어떤 GPU가 지원되는가?

  • 다음 GPU 타겟이 지원되며 Nightly 테스트에 포함됨
    • AMD gfx1030 (Navi 21, RDNA 2.0)
    • AMD gfx1100 (Navi 31, RDNA 3.0)
  • 다음 GPU 타겟은 임시 수동 테스트를 거쳤으며 "작동하는 것 같음"
    • AMD gfx1010
    • AMD gfx1101
  • 다음 GPU 지원을 위해 작업 중임
    • AMD gfx900 (Vega 10, GCN 5.0)
  • 특정 AMD GPU 아키텍처 지원을 신속히 원하면 연락 바람

SCALE의 구성 요소

  • AMD GPU용 nvcc 방언 CUDA를 컴파일할 수 있는 nvcc 호환 컴파일러, PTX asm 포함
  • AMD GPU용 CUDA 런타임 및 드라이버 API 구현
  • ROCm 라이브러리에 위임하여 "CUDA-X" API를 제공하는 오픈 소스 래퍼 라이브러리. cuBLAS 및 cuSOLVER와 같은 라이브러리가 이렇게 처리됨

SCALE과 다른 솔루션의 차이점

  • 새로운 GPGPU 소프트웨어 작성 방법을 제공하는 대신, SCALE은 널리 사용되는 CUDA 언어로 작성된 프로그램을 AMD GPU용으로 직접 컴파일할 수 있게 함
  • SCALE은 NVIDIA CUDA와 완전히 호환되도록 목표함. 사용자가 여러 코드베이스를 유지하거나 성능을 타협하지 않고 여러 GPU 벤더를 지원할 수 있어야 한다고 믿음
  • SCALE의 언어는 NVIDIA CUDA의 _슈퍼셋_으로, nvcc에서 벗어나고자 하는 사용자에게 GPU 코드 작성이 더 쉽고 효율적이게 하는 선택적 언어 확장을 제공함
  • SCALE은 진행 중인 작업임. 사용을 방해하는 API가 누락된 경우 연락 바람. 개발 우선순위를 조정할 것임

GN⁺의 정리

  • SCALE은 CUDA 애플리케이션을 AMD GPU용으로 네이티브 컴파일할 수 있게 해주는 중요한 툴킷임
  • 기존 CUDA 프로그램을 수정할 필요 없이 AMD GPU에서 실행할 수 있어 개발자에게 큰 이점이 있음
  • NVIDIA CUDA와의 완전한 호환성을 목표로 하여 여러 GPU 벤더를 지원하는 데 유리함
  • 진행 중인 프로젝트로, 필요한 API가 누락된 경우 개발팀에 연락하여 우선순위를 조정할 수 있음
  • 비슷한 기능을 가진 프로젝트로는 ROCm과 HIP이 있음
▲
neo 4달전  [-]
Hacker News 의견

  • 많은 사람들이 AMD가 번역 레이어를 지원해야 한다고 생각하지만, 이는 나쁜 아이디어라는 의견이 있음

    • CUDA는 벤더 중립적으로 설계되지 않았으며 Nvidia는 기술적, 법적으로 어려움을 만들 수 있음
    • 예를 들어, cuDNN이나 cuBLAS를 이 위에서 실행하는 것은 라이선스 계약에 위배될 수 있음
    • 이러한 Nvidia 라이브러리들은 AMD가 재구현하고 지원해야 하는 API 경계의 일부가 될 것임

  • 버그 호환성을 추구하는 것은 어리석은 일이라는 의견이 있음

    • 중요한 CUDA 사용자들은 오픈 소스임
    • AMD는 pytorch나 llama.cpp 같은 업스트림 프로젝트에 직접 지원을 구현할 수 있음
    • 지원이 있으면 커뮤니티가 유지 관리할 수 있음

  • 하드웨어에 크게 의존하는 코드가 AMD에서 "그냥 작동"할 수 있는지 이해할 수 없다는 의견이 있음

    • 대부분의 진지한 CUDA 코드는 레지스터 파일과 공유 메모리 크기, wgmma 명령어, 최적의 텐서 코어 메모리 및 레지스터 레이아웃, 텐서 메모리 가속기 명령어 등을 인식함

  • 사실이라면 인상적이지만, 오픈 소스가 아니며 작동 방식에 대한 정확한 세부 정보가 부족하다는 의견이 있음

    • 요즘 프로젝트가 오픈 소스이거나 최소한 소스 사용 가능하다고 기대하는 이유를 잘 모르겠음

  • Nvidia의 높은 평가의 주요 원인은 AMD가 GPU를 ML에 유용하게 만드는 데 투자하지 않기 때문이라는 의견이 있음

    • AMD가 반독점 조치를 두려워하거나, 하드웨어 접근 방식에 경쟁력을 제한하는 무언가가 있을 수 있음
    • 회사는 암호화폐 채굴 GPU 수요 급증과 현재 AI 붐 수요 급증 동안 수십억 달러를 놓친 것 같음

  • AMD가 너무 잘못해서 이런 프로젝트를 축하하고 싶다는 의견이 있음

    • 특히 Linux에서 노트북의 기능이 물리적으로 존재하지만 사용할 수 없어서 매우 좌절스러움

  • 몇 년 전 Spectral Compute에서 일했었음

    • 매우 똑똑하고 능력 있는 기술 팀이었음
    • 당시 AMD를 대상으로 했을 뿐만 아니라, 기본 LLVM ptx 백엔드와 NVCC를 능가했음

  • CUDA를 조금 작성해본 적이 있음

    • AMD 카드용 코드를 작성하기 위한 기본 설정은 무엇인지 궁금함

  • 이 프로젝트가 훌륭하다는 의견이 있음

    • AMD가 Nvidia와 직접 경쟁하게 되는 것을 기대함

  • 현재 제한 사항에 대한 페이지가 있는 것은 좋지만, 대부분의 사람들이 "CUDA"라고 설명하는 것은 실제 CUDA 기능의 작은 부분이라는 의견이 있음

    • 워프 셔플, 원자적 연산, DPX, TMA, MMA 등 고급 기능에 대한 비교 표가 있으면 좋겠음
    • PTX 명령어를 RDNA 대응 명령어 또는 이를 에뮬레이트하는 명령어 목록으로 매핑하는 표가 이상적임

  • 기술적으로 가능하므로 실제일 수 있다는 의견이 있음

    • 인라인 PTX를 파싱하고 AMDGPU에 매핑하는 것은 큰 고통이 될 것임
    • 인라인 PTX를 사용하지 않는 CUDA 소스에서 AMDGPU를 대상으로 작업하는 것은 HIP으로 대체하는 것과 비슷함
    • 일부 세부 사항은 의심스러울 수 있음, 예를 들어 원자적 모델이 일치하지 않거나 Volta가 다른 명령어 포인터 모델을 가질 수 있음
    • 그러나 올바르게 수행될 수 있음
    • AMD는 이를 하지 않을 것임
    • CUDA는 일반적으로 매우 좋은 것이 아니며 법률 팀이 문제를 일으킬 것임
    • 그러나 다른 사람들은 충분히 할 수 있음
답변달기