Anukari開発者からAppleへの技術的な公開要望

 (anukari.com)
1 ポイント 投稿者 GN⁺ 2025-05-07 | 1件のコメント | WhatsAppで共有
  • 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エンジニアからの返答を待っている

関連記事

1件のコメント

 
GN⁺ 2025-05-07
Hacker Newsのコメント

  • 皆さんこんにちは。Metalチームの適切な担当者と非常に生産的な話し合いができた。Appleの注意を引くのを手伝ってくれてありがとう。これほど多くの支援を受けるとはまったく予想していなかった

    • AnukariのShow HN投稿をご覧になった方もいると思う
    • そのスレッドでmacOSのパフォーマンスが話題になった。基本的にAnukariはAppleシリコン、特にベースモデルのM1ハードウェアでほとんどうまく動作する。すべてのテストはベースM1で行い、見事に動作した。ハードウェアは驚異的だ
    • ただし、これを動かすために、macOSがオーディオ処理を十分高速にするようGPUクロック速度を引き上げるための異常な回避策を実装しなければならなかった。GPUのパフォーマンス状態に対するmacOSの通常のヒューリスティックは、Anukariの特殊なワークロードを理解していない
    • ともあれ、Appleの適切な担当者、おそらくMetal APIに携わっている人に連絡を取る助けを求められるよう、状況全体を詳しく記録する時間が取れた
    • 助けてほしい :)

  • Anukariという名前の由来が気になる

  • 有名企業2社で、Apple App Storeに非常に有名なアプリを出していた経験がある

    • Appleと話したチームは、私たちの問題にはまったく関心を示さなかった。しかし、しばしばWWDCで発表する最新機能を議論するために私たちをオフィスに招待した。彼らとの関わりはいつもそうやって始まり、そうやって終わった。彼らのバグのあるソフトウェアがなぜ動かないのかについて洞察を得るために、技術サポートチケットを消費しなければならなかった
    • Appleのデベロッパーリレーションズは真剣な人たちではない

  • Metalプロファイラには非常に便利な機能がある。アプリケーションをプロファイルしている間にMetalの「パフォーマンス状態」を選択できる。これはプロファイラの外では設定できない

    • おそらくこれ用の非公開APIがあるのだろう。特別な権限が不要なら、リバースエンジニアリングの道に進むほうが簡単かもしれない

  • この問題に対するAPIを公開する際の問題は、あまりに多くの開発者が常に最高のパフォーマンス状態を強制しようとするだろうという点だ。それを防ぎつつAPIを維持する良い方法があるかは分からない

  • この問題を解決する最善の方法:

    • WWDCの動画を通じて、この問題を最もよく知っているエンジニアを見つける
    • この形式でその人に直接メールを送る: mthomson@apple.com (Michael Thomson)

  • 最後から2番目の段落に投げ込まれているリンクを見逃さないでほしい。Mick Gordonが作ったデモへのリンクだ。@anukarimusicがこれに返信している

    • 2日目にはすでに、私が作ったすべてのデモを完全に打ち負かしていて、それ以来毎日これを使っている

  • 余談だが、AnukariはMick Gordonサウンドパックを出して、彼と収益を分け合うべきだ。あの人は驚くべきものを作っている。彼のデモは素晴らしい。強力なツールを持っているときにアーティストと協力するのは、良いビジネスであり、世界にとっても良いことだ。Mick Gordonが好きなら。私は好きだ

  • このアプリは自分には必要ないが、本当にクールだ。こういうアプリはコンピューティングに「楽しさ」を取り戻してくれる。今が楽しくないというわけではないが、グラフィックスや実験的なプログラムがもっと出回っていた昔を思い出させる。デモシーンさえも