ZLUDA, CUDA 앱을 AMD GPU에서 실행하게 하는 오픈소스 프로젝트

 (cgchannel.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • ZLUDA 3는 CUDA에 묶여 있던 NVIDIA GPU용 애플리케이션을 AMD GPU에서 수정 없이 실행하려는 오픈소스 기술임
  • Intel GPU용 CUDA 대체 구현으로 시작했지만 Intel과 AMD의 평가가 중단되면서, 이번에는 AMD GPU 대상 코드가 공개됨
  • Blender에서는 네이티브 HIP 백엔드와 비슷한 성능 사례가 있으나, 3DF Zephyr와 RealityCapture는 ZLUDA에서 “much slower”로 표시돼 앱별 편차가 큼
  • RealityCapture와 Arnold 같은 NVIDIA 전용 CG 앱 실행 가능성이 확인됐지만, OptiX 지원은 Linux에서 최소 수준에 머물러 렌더링 워크플로에는 제약이 있음
  • Intel·AMD의 지원이 없는 상태에서 프로젝트는 “realistically now abandoned”에 가깝고, NVIDIA SDK 라이선스도 비-NVIDIA 플랫폼용 변환 계층 개발을 제한함

ZLUDA 3가 풀려는 CUDA 종속 문제

  • ZLUDA 3는 NVIDIA GPU용으로 만들어진 GPU 기반 애플리케이션을 다른 제조사 하드웨어에서 실행하게 하는 오픈소스 프로젝트임
  • 기존 애플리케이션을 수정 없이 새 하드웨어에서 실행하도록 설계돼, 앱 개발자의 추가 포팅 작업을 요구하지 않음
  • ZLUDA는 2020년 Intel GPU용 CUDA 드롭인 대체 구현으로 처음 공개됐고, 2021년 버전 2 이후 개발 지속이 어려워짐
  • Andrzej Janik이 Intel 재직 중이던 2021년, Intel은 ZLUDA를 공식 기술 후보로 평가했지만 “Intel GPU에서 CUDA 애플리케이션을 실행할 비즈니스 케이스가 없다”고 판단함
  • Janik은 2022년 Intel을 떠난 뒤 AMD에 접근했고, AMD도 2년간 ZLUDA를 평가했지만 더 진행하지 않기로 함
  • 이후 업데이트된 코드가 오픈소스로 공개됐으며, 관련 배경은 Phoronix 기사에서 더 자세히 볼 수 있음

CG 앱에서 확인된 동작 범위

  • ZLUDA 3는 NVIDIA의 CUDA API로 개발된 GPU 앱을 AMD GPU에서 실행하는 것을 목표로 함
  • VFX, 모션 그래픽, 시각화 분야에서는 일부 핵심 CG 앱과 렌더러가 CUDA 기반이라 사실상 NVIDIA 전용으로 남아 있는 경우가 있음
  • AMD의 HIP는 CUDA 앱을 AMD 하드웨어로 포팅하는 기술이지만, 소프트웨어 개발자의 작업이 필요함
    • HIP는 Redshift와 Blender Cycles의 AMD 호환 버전에 사용됨
    • ZLUDA 3도 HIP 기반으로 만들어졌지만, 목표는 기존 CUDA 앱의 무수정 실행임
  • Janik이 ZLUDA로 테스트한 NVIDIA 전용 소프트웨어에는 3DF Zephyr, RealityCapture, Autodesk Arnold가 포함됨
  • Arnold 지원은 개념 증명 수준이며, ZLUDA의 OptiX 구현으로 성공적으로 렌더링된 장면은 제한적임

성능과 호환성의 현실적 한계

  • Janik은 CUDA 앱이 AMD GPU에서 “near-native performance”로 실행된다고 평가함
  • Phoronix 벤치마크와 Blender Artists 포럼의 스레드에 따르면, Blender에서는 ZLUDA 성능이 네이티브 HIP 백엔드와 비슷한 사례가 있음
  • 반면 ZLUDA GitHub 저장소는 3DF Zephyr와 RealityCapture를 ZLUDA에서 much slower로 표시함
  • 많은 GPU 렌더러는 레이 트레이싱 가속을 위해 CUDA 외에 NVIDIA OptiX도 함께 사용함
    • ZLUDA의 OptiX 지원은 “minimum” 수준임
    • OptiX 지원은 Linux에만 있고 Windows에는 없음
    • 구현 상태는 “buggy, unoptimized and incomplete”임
    • ZLUDA-OptiX는 재배포 버전에 포함되지 않아 직접 빌드해야 함
  • 다른 CUDA 기반 CG 앱의 실행 가능성은 사용자 테스트 없이는 판단하기 어려움

프로젝트 지속성과 라이선스 제약

  • Janik은 Intel이나 AMD의 지원이 없으면 ZLUDA가 “realistically now abandoned” 상태라고 봄
    • 프로젝트를 진전시킬 제안에는 열려 있음
    • 그렇지 않으면 DLSS처럼 개인적으로 관심 있는 NVIDIA 기술 지원만 추가할 가능성이 큼
    • 현재 코드도 CUDA에서 HIP로 점진적 포팅을 진행하는 소프트웨어 개발자에게 활용될 수 있음
  • 2024년 3월 14일 업데이트에 따르면, Tom’s Hardware는 NVIDIA SDK 라이선스 조건이 CUDA Toolkit을 포함한 SDK 산출물을 비-NVIDIA 플랫폼 대상 변환 기술 개발에 쓰는 것을 금지한다고 짚음
  • ZLUDA 3의 컴파일된 버전은 Windows와 Linux용으로 제공되며, 소스 코드는 Apache 2.0 또는 MIT license로 제공됨
  • ZLUDA 3 다운로드는 프로젝트 GitHub 저장소에서 가능함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 22일 전에도 관련 논의가 있었음: AMD가 ROCm 기반 CUDA 드롭인 구현에 자금을 지원했고, 이후 오픈소스로 공개됐다는 글 [0]에 댓글 400개가 달림
    그 스레드의 주목할 만한 최상위 댓글은, 공개 자체가 AMD가 자금 지원을 중단한 결과였다는 내용임: “2년 개발과 검토 끝에 AMD는 AMD GPU에서 CUDA 애플리케이션을 실행하는 데 사업성이 없다고 판단했다. AMD와의 계약 조건 중 하나는 AMD가 추가 개발에 적합하지 않다고 판단하면 내가 공개할 수 있다는 것이었다. 그래서 오늘에 이르렀다.” 출처: https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq
    [0] https://news.ycombinator.com/item?id=39344815

  • AMD가 이 프로젝트 자금 지원을 끊은 건 정말 터무니없음. 오픈소스로 공개되자마자 AMD 사용자에게 가치를 만들기 시작했기 때문임
    이런 일이야말로 AMD의 최우선 과제여야 할 것 같은데, 정작 몇 년 동안 지원도 미미한 대체 API 두 개, 이제는 세 개인가를 붙잡고 헤매고 있었음

    • 이게 신뢰할 만한 선택지가 되는 순간 Nvidia가 바로 중지명령을 보내고 소송할 것임. 진지한 해법으로는 막다른 길이라서, 그런 맥락에서는 이해됨
    • 사람들이 HIP을 쓰게 만들고 싶어서 그런 걸 수도 있음
      “HIP은 매우 얇아서 CUDA 모드로 직접 코딩하는 것 대비 성능 영향이 거의 없거나 전혀 없다”
      “HIPIFY 도구는 CUDA 소스를 HIP으로 자동 변환한다”
      1. https://github.com/ROCm/HIP
    • 전략적으로 생각하면 이게 AMD에 최선이었다고 보긴 어려움. 제품 수준이고 법적으로 검증된 게 아니라면, 개발자가 AMD로 애플리케이션을 만들고 배포는 Nvidia에서 하게 해주는 도구가 될 뿐임
      소비자용 그래픽카드 쪽에서는 단기 이익이 될 수 있지만, 장기적으로는 데이터센터에서 Nvidia의 지위를 계속 굳히는 자충수에 가까움
    • NVIDIA 발표에 대한 사전 정보를 받고 이 계약자를 풀어줬을 가능성이 큼. 계약 조건상 프로젝트는 오픈소스가 되었을 것임
    • 여기서는 AMD가 포기하기로 선택했다는 가정이 깔려 있음. 어쩌면 더 나은 걸 만들고 있는 중일 수도 있지 않나?

  • 이 논의에는 “Nvidia가 CUDA 소프트웨어를 다른 칩에서 실행하기 위한 변환 계층 사용을 금지했다”는 글도 관련 있어 보임 [1]

    [1] https://news.ycombinator.com/item?id=39592689

    • Nvidia 하드웨어를 쓰지 않고, Nvidia 드라이버도 쓰지 않고, Nvidia의 EULA에 동의한 적도 없다면 왜 신경 써야 하는지 모르겠음
      에뮬레이션은 명시적으로도, 판례상으로도 법적 보호를 받음. 호환 목적의 API 복제는 미국 대법원까지 갔고 저작권 대상이 아니라고 판단된 바 있음. 적어도 꽤 넓은 범위 안에서는 그렇다고 봄
      변호사는 아니지만 Nvidia가 어떤 법적 근거를 기대하는지 잘 안 보임. Nvidia 하드웨어가 전혀 없는 개인이나 회사라면 의미 없는 쟁점처럼 느껴짐. 이미 Nvidia 하드웨어를 가진 회사라면 어느 정도 주장을 펼칠 수는 있겠지만, 그건 오히려 반경쟁 행위 영역에 정면으로 들어가지 않나?
    • 이게 Wine/Proton과 뭐가 다른지 모르겠음. Microsoft EULA에도 비슷한 조건이 있을 텐데, 집행 가능했다면 Microsoft가 Wine 개발자들에게 똑같이 중지명령을 보내지 않았을까?
    • 해당 조항은 기사 주장과 달리 2022년 1월부터 CUDA EULA에 있었고, 기사 업데이트 내용과 달리 다운로드에도 포함돼 있었다는 점을 다시 강조해야 함
    • 그게 의미가 있나? 다른 시스템과 호환 인터페이스를 가진 시스템을 구현하는 데 누군가의 허락이 필요한 건 아님
      EULA를 위반하긴 하지만 CUDA 소프트웨어를 내려받지 않는 한 EULA에 동의할 필요도 없고, ZLUDA 작성자들은 아마 그걸 피할 수 있었을 것임
    • NVIDIA가 그렇게 할 권한은 없음. 여기에는 NVIDIA SDK가 관여하지 않음

  • “Intel도 결국 ‘Intel GPU에서 CUDA 애플리케이션을 실행하는 데 사업성이 없다’고 판단했다”라니, 참 난감함

    • 간단히 말하면, 일정 규모와 나이가 된 회사는 모두 경쟁자를 꿈꾸기보다 독점자를 꿈꾸게 됨
    • Intel의 그래픽 부문은 너무 나빠서 사람들 입에 남긴 안 좋은 인상 때문에 Intel HD라는 이름을 그만 써야 했음

  • AMD GPGPU를 한 번이라도 만져본 사람이 아는 사실이 확인됐음. AMD가 2조 달러 회사가 되는 걸 막는 유일한 건 정말 끔찍한 소프트웨어임
    AMD의 OpenCL 컴파일러 버그를 찾았던 기억이 있고 [1], 세그멘테이션 오류로 OpenCL 컴파일러를 죽이는 것도 아주 쉬웠음. 그건 끝내 고쳐지지 않아 보고를 포기했음
    AMD가 CUDA 경쟁자를 개발하지 않은 건 내가 본 것 중 가장 근시안적인 결정임. 최고 하드웨어를 만들어도 그걸 쓰는 소프트웨어가 아주 순하게 말해도 형편없으면 아무도 사거나 쓰지 않는다는 걸 이해하는 사람들로 이사회가 왜 교체되지 않았는지 모르겠음
    고객인 우리는 AMD 이사회가 테이블 위에 남겨둔 1조 달러쯤 되는 가치를 신경 쓰기엔 너무 부유한 탓에 비싼 Nvidia 카드를 사야 함. AMD 주식을 가진 사람이라면 질문을 던져야 함. 그 이사회는 가장 가까운 배수구로 내려가야 함
    [1] https://github.com/msoos/amdmiscompile -- 결국 이건 고쳐졌음

    • 자바스크립트에게 설명하듯 GPGPU가 뭔지 설명해줄 수 있나?
      내 순진한 이해로는 그래픽카드는 명령어와 데이터를 올려놓고 알아서 계산하게 할 수 있는 이상한 컴퓨터임
      CUDA가 왜 그렇게 큰일인지 모르겠음. AMD가 자기 GPU를 Arduino 보드 4096개짜리 배열처럼 직접 접근하게 해주면 안 되나?
    • 맞음. 반대로 AMD는 일반적으로 Nvidia보다 오픈소스 친화적임. Nvidia는 한동안 적극적으로 적대적이었고, Linus의 “F* you!” 영상만 봐도 됨
      하드웨어를 개발하는 회사들은 대체로 소프트웨어를 못함. 예외가 있긴 하지만 많지 않고, 그런 회사들은 실제로 주가로 보상받았음. AMD의 소프트웨어 사업부 문화는 모르지만, 보통 이런 걸 고치려면 꽤 큰 변화가 필요함
      이사회만 갈아치운다고 해결되긴 어려울 것임. 최고경영진 지시만이 회사를 끌어내리는 유일한 요인이 아니라면, 훨씬 많은 관리 계층을 바꿔야 하고 중간관리자도 상당수 교체해야 함. 소프트웨어 채용이 제대로 되지 않았다면 개별 기여자까지 바꿔야 할 때도 있음
    • AMD가 Intel과 협력해서 SYCL을 표준 GPGPU 및 이기종 프로그래밍 방식으로 밀지 않는 이유를 모르겠음
      Intel은 소프트웨어를 잘하고, SYCL은 공개 표준이라 두 회사 모두 같은 코드에서 이익을 얻을 수 있으며, 고객은 원하면 Threadripper에서도 SYCL 코드를 돌릴 수 있음. 요즘 일부 Threadripper는 일부 GPU만큼 빠르기도 함
      AMD는 자기만의 독점 잠금 생태계를 만들려는 건가? 왜 교차 플랫폼 공개 표준에 전념하지 않는지 모르겠음
    • 나는 AMD Software 자체는 꽤 마음에 들었음. 게임이나 소프트웨어가 기본 지원하지 않을 때 GPU가 최대치로 도는 걸 막으려고 프레임률을 60으로 제한하기 쉬웠고, Shadowplay처럼 최근 몇 분을 계속 녹화해두는 즉시 리플레이를 단축키로 설정할 수도 있었음
      UPS가 좋지 않았을 때 GPU 전력 제한도 가능했고, RX 580을 1년쯤 더 쓰려고 자동 오버클록도 할 수 있었음
      다만 2020년쯤 이후의 소프트웨어/드라이버는 VR 타이틀을 한 시간도 안 돼서 크래시시킴. Linux용 소프트웨어 패키지도 없고 CoreCtrl은 그만큼 좋지 않음. 즉시 리플레이가 가끔 그냥 동작하지 않기도 함. Windows와 Linux 양쪽에서 로컬 LLM에 ROCm을 한 번도 제대로 붙이지 못했고, DKMS는 apt upgrade 때마다 쓸데없는 컴파일을 잔뜩 하길 좋아했음
      다음 GPU로 호기심 때문에 Intel Arc를 갈지, 그냥 Nvidia로 돌아갈지 고민 중임. 후보는 A580, RX 6600, RTX 3050 정도이고, 다른 부품 가격이 떨어질 때까지 버틸 수도 있음

  • Metal, CUDA, AMD 쪽 무언가 같은 여러 커널 언어로 컴파일되는 프로그래밍 언어가 있나? 없다면 왜 없을까?
    C 컴파일러는 다양한 CPU 아키텍처로 컴파일함. GPU 아키텍처로 가는 컴파일러도 있어야 하지 않나? 아직 아무도 만들지 않았을 뿐일 수도 있음

    • OpenCL도 포함해서 보면 되나?
      https://www.khronos.org/api/opencl
    • OpenMP 5가 GPU 지원을 명시했음. 대충 검색해보니 일부 컴파일러는 이제 적어도 부분적으로 지원하는 듯함

  • Meshroom 같은 오픈소스 사진측량 도구를 돌리려고 이걸 써본 사람이 있나? 기사에는 몇몇 독점 도구가 언급되지만 내 필요는 꽤 작음

  • 이건 JVM 바이트코드 사용을 둘러싼 Oracle 대 Google 사건과 거의 똑같아 보임

    • 그렇게 보이진 않음. 쟁점은 바이트코드 변환이 아니라, 더 높은 수준의 라이브러리 지식재산을 하드웨어에 묶는 것임
      이건 Google이 “우리 Android 애플리케이션은 Google이 승인한 휴대폰에서만 실행할 수 있다”고 말하는 것과 비슷함. 내가 이해하기로 Google은 Play 프레임워크나 Maps 같은 것에 대해서는 실제로 그렇게 하고 있음

  • 최근 흥미로운 소문을 들었는데, NVIDIA에서 CUDA를 맡았던 사람이 수년 동안 자원을 얻고 회사를 설득해 이 프로젝트를 진지하게 받아들이게 하려고 싸웠다고 함
    CUDA가 없었다면 NVIDIA가 오늘날 거의 1조 달러 회사가 되는 일은 절대 없었을 것임

  • geohot이 비싼 AMD GPU와 계속 씨름한 것도 관련 있음: https://twitter.com/tinygrad/status/1764734675002810622

답변달기