▲

Anukari 개발자의 Apple에 보내는 기술적 호소문

 (anukari.com)
1P by GN⁺ 8일전 | ★ favorite | 댓글 1개
  • GPU 실시간 오디오 시뮬레이터 Anukari가 Apple Silicon macOS 기기에서 예측 가능한 성능을 보장받지 못하는 문제를 설명하며, Apple Metal 팀에 직접 연결되길 요청함
  • Anukari는 물리 기반 오디오 합성기로, 오디오 버퍼 블록마다 GPU에서 수백 개의 객체를 통합해야 하며, GPU ALU 성능에 전적으로 의존함
  • macOS의 자동 전력/성능 조절 로직이 이 특수한 오디오 워크로드를 잘 인식하지 못해, GPU 클럭이 낮게 유지되고 성능 저하 및 끊김 현상이 발생함
  • 이를 해결하기 위해 “waste makes haste” 전략으로 가짜 부하를 유발해 GPU를 속이는 spin kernel을 도입했지만, M1 이후의 고성능 Mac에서는 실패 가능성이 높아짐
  • 해결책으로는 GPU 명령큐의 실시간 인식 기능 도입 또는 Audio Workgroup 개념을 Metal까지 확장하는 방안 등을 제안함

Anukari란 무엇인가?

  • Anukari는 실시간 3D 물리 기반 오디오 합성기로, 대규모 스프링-질량 모델을 GPU에서 계산하여 오디오를 생성함
  • 오디오 워크스테이션(DAW)에서 AudioUnit/VST3 형태로 사용되며, 오디오 버퍼 단위로 GPU에 계산을 요청함
  • 계산은 메모리보다는 연산량(=ALU) 중심이며, GPU의 threadgroup memory를 활용해 L1 캐시 수준의 고속 처리를 구현함

성능 문제의 본질

  • macOS는 전력 효율성 중심으로 GPU 클럭을 자동 조절하며, GPU 부하가 낮게 감지되면 클럭을 낮춤
  • Anukari는 짧고 고밀도의 실시간 작업을 반복하는 구조로 인해, macOS가 GPU 부하를 제대로 인식하지 못함
  • 이는 실시간 제약 조건을 만족시키기 위해 필요한 성능을 확보하지 못하게 만듦

증거와 테스트

  • Apple Xcode의 Metal Profiler를 통해 성능 상태별 클럭 차이를 직접 확인
  • Maximum performance 상태에서는 매끄럽게 작동하지만, Minimum 상태에서는 음성 끊김이 발생함

“waste makes haste” 전략

  • GPU 클럭을 강제로 높이기 위해, Anukari는 spin loop 부하 생성용 GPU 작업을 동시에 수행함
  • 이 전략은 M1에서는 효과적이지만, Pro/Max급 칩에서는 오히려 부하가 다른 GPU 코어로 분산되며 실패할 가능성이 있음

제안하는 해결책

  1. Audio Workgroup을 GPU까지 확장하여 실시간 워크로드로 인식되게 하기
  2. Metal API에 실시간 민감도 플래그 추가
  3. (희망적) 이미 존재하는 방법이 있다면 안내받기를 희망

기타 대안 검토 및 한계

  • Game Mode는 전체 프로세스 기반이라 플러그인 형태의 Anukari에는 적용 불가
  • Windows에서는 문제 없음, 클럭 관리가 느슨하거나 설정 제어 가능성 때문
  • 헤징 방식의 멀티 커널 실행은 오디오 지연 증가 및 상태 동기화 문제로 부적절
  • GPU 코드 최적화는 이미 극한까지 수행됨 (FP16 사용, SIMD 그룹 정렬, ALU 최적화 등)

왜 CPU가 아닌 GPU인가?

  • Anukari는 768~1024개 객체의 물리 연산을 초당 48,000번 수행하며, 16중 복성(폴리포니)까지 지원
  • CPU는 계산량과 병렬성 모두에서 감당 불가능함
  • GPU의 ALU, L1 캐시 제어, threadgroup_barrier 병렬 제어 능력이 절대적으로 필요함

Apple이 이 문제를 왜 신경 써야 하는가?

  • Anukari는 소규모 스타트업의 틈새형 제품이지만, 열정적인 유저층과 유명 아티스트의 관심을 받고 있음
  • Apple Silicon은 이 워크로드를 충분히 처리할 수 있는 성능을 갖추고 있으나, 클럭 조절 정책만 바뀌면 해결 가능

GPU Audio API는 왜 불가능한가?

  • Anukari는 전통적 DSP가 아니라 수치 미분 방정식 통합기, 즉 게임 물리 엔진에 가깝기 때문에 GPU Audio의 추상화 수준과 맞지 않음
  • Metal API를 직접 사용하며, 도메인 특화된 극단적 최적화가 필수임

요청 요약: GPU 오디오를 위해 Metal API 또는 macOS 성능 조절 정책에 실시간 처리 인식 기능을 추가해줄 Apple 엔지니어의 응답을 기다림

▲
GN⁺ 8일전  [-]
Hacker News 의견

  • 모두 안녕하세요, Metal 팀의 적절한 사람과 매우 생산적인 대화를 나누었음. Apple의 주의를 끌 수 있도록 도와주셔서 감사합니다. 이렇게 많은 지원을 받을 줄은 전혀 예상하지 못했음

    • Anukari에 대한 Show HN 게시물을 보신 분들도 있을 것임
    • 해당 스레드에서 macOS 성능에 대한 주제가 나왔음. 기본적으로 Anukari는 Apple 실리콘, 특히 기본 모델 M1 하드웨어에서 대부분 잘 작동함. 모든 테스트를 기본 M1에서 수행했으며 훌륭하게 작동함. 하드웨어가 놀라움
    • 그러나 이를 작동시키기 위해 macOS가 오디오 처리 속도를 충분히 빠르게 하기 위해 GPU 클럭 속도를 높이도록 하는 비정상적인 해결책을 구현해야 했음. macOS가 GPU 성능 상태를 위한 일반적인 휴리스틱은 Anukari의 특이한 작업 부하를 이해하지 못함
    • 어쨌든, Apple의 적절한 사람, 아마도 Metal API를 작업하는 사람과 연락하기 위해 도움을 요청할 수 있도록 전체 상황을 자세히 기록할 시간이 있었음
    • 도움 요청함 :)

  • Anukari 이름의 기원에 대한 호기심이 있음

  • 두 개의 유명한 회사에서 Apple App Store에 매우 유명한 앱을 가진 경험이 있음

    • Apple과 대화한 팀은 우리의 문제에 전혀 관심이 없었음. 그러나 종종 WWDC에서 발표할 최신 기능을 논의하기 위해 우리를 사무실로 초대했음. 그들과의 참여는 항상 그렇게 시작되고 끝났음. 그들의 버그가 있는 소프트웨어가 작동하지 않는 이유에 대한 통찰력을 얻기 위해 기술 지원 티켓을 소모해야 했음
    • Apple의 개발자 관계는 진지한 사람들이 아님

  • Metal 프로파일러는 매우 유용한 기능을 가지고 있음: 애플리케이션을 프로파일링하는 동안 Metal "성능 상태"를 선택할 수 있음. 이는 프로파일러 외부에서는 구성할 수 없음

    • 아마도 이를 위한 비공개 API가 있을 것임. 역공학 경로로 가는 것이 더 쉬울지도 모름. 특별한 권한이 필요하지 않다면

  • 이 문제에 대한 API를 노출하는 문제는 너무 많은 개발자가 항상 최고 성능 상태를 강제로 설정할 것이라는 점임. 이를 막고 동시에 API를 유지할 수 있는 좋은 방법이 있는지 모르겠음

  • 이 문제를 해결하는 가장 좋은 방법:

    • WWDC 비디오를 통해 문제에 대해 가장 잘 알고 있는 엔지니어를 찾음
    • 이 형식으로 직접 이메일을 보냄: mthomson@apple.com (Michael Thomson)

  • 두 번째 마지막 단락에 던져진 링크를 놓치지 말 것. Mick Gordon이 만든 데모에 대한 링크임. @anukarimusic가 이에 답변함

    • 두 번째 날에 이미 내가 만든 모든 데모를 완전히 파괴했으며, 이를 매일 사용해왔음

  • 부가적으로, Anukari는 Mick Gordon 사운드 팩을 출시하고 그와 수익을 공유해야 함. 그 사람은 놀라운 것을 만들고 있음. 그의 데모는 훌륭함. 강력한 도구를 가지고 있을 때 아티스트와 협력하는 것은 좋은 비즈니스이며 세상에 좋음. Mick Gordon을 좋아한다면. 나는 좋아함

  • 이 앱이 필요하지 않지만 정말 멋짐. 이러한 앱은 컴퓨팅에 "재미"를 다시 가져다줌. 현재 재미가 없다는 것이 아니라, 더 많은 그래픽 및 실험적인 프로그램이 떠돌던 옛날을 상기시킴. 심지어 데모씬까지도

답변달기