ZLUDA、CUDAアプリをAMD GPUで実行可能にするオープンソースプロジェクト
(cgchannel.com)- 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ハードウェアへ移植する技術だが、ソフトウェア開発者の作業が必要
- 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アプリが動作するかどうかは、ユーザーテストなしでは判断しにくい
- 既知の問題が残っている
- V-Ray benchmarkは、一部の「lucky」な旧版ZLUDAとHIPの組み合わせで動作する
- OctaneBenchはまったく動作しない
プロジェクト継続性とライセンス上の制約
- 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リポジトリから可能
1件のコメント
Hacker News の意見
22日前にも関連する議論があった：AMD が ROCm ベースの CUDA ドロップイン実装に資金提供し、その後オープンソースとして公開されたという投稿 [0] にコメントが400件付いた
そのスレッドで注目すべきトップレベルコメントは、公開そのものが AMD が資金提供を打ち切った結果だったという内容：「2年にわたる開発とレビューの末、AMD は AMD GPU で CUDA アプリケーションを実行することに事業性はないと判断した。AMD との契約条件の1つに、AMD がさらなる開発に適さないと判断した場合、私が公開できるというものがあった。だから今日に至った。」出典: https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq
[0] https://news.ycombinator.com/item?id=39344815
Zluda: Run CUDA code on Intel GPUs, unmodified - https://news.ycombinator.com/item?id=36341211 - 2023年6月、コメント90件
Zluda: CUDA on Intel GPUs - https://news.ycombinator.com/item?id=26262038 - 2021年2月、コメント77件
最近の関連投稿としては Nvidia bans using translation layers for CUDA software to run on other chips - https://news.ycombinator.com/item?id=39592689 - 2024年3月、コメント155件がある
AMD がこのプロジェクトへの資金提供を打ち切ったのは本当にばかげている。オープンソースとして公開された途端、AMD ユーザーに価値を生み始めたからだ
こういうことこそ AMD の最優先課題であるべきに思えるのに、実際には何年もの間、サポートも乏しい代替 API を2つ、今では3つなのか、それにしがみついて迷走していた
「HIP は非常に薄いので、CUDA モードで直接コーディングする場合と比べて性能への影響はほとんどないか、まったくない」
「HIPIFY ツールは CUDA ソースを HIP に自動変換する」
コンシューマー向けグラフィックカードでは短期的な利益になり得るが、長期的にはデータセンターでの Nvidia の地位を固め続ける自滅策に近い
この議論には「Nvidia が CUDA ソフトウェアを他のチップで動かすための変換レイヤーの使用を禁止した」という投稿も関係していそうだ [1]
[1] https://news.ycombinator.com/item?id=39592689
エミュレーションは明示的にも、判例上も法的保護を受けている。互換性目的の API 複製は米国最高裁まで争われ、著作権の対象ではないと判断されたことがある。少なくともかなり広い範囲ではそうだと思う
弁護士ではないが、Nvidia がどんな法的根拠を期待しているのかよく見えない。Nvidia ハードウェアをまったく持たない個人や会社なら、意味のない争点のように感じる。すでに Nvidia ハードウェアを持つ会社ならある程度主張を展開できるかもしれないが、それはむしろ反競争的行為の領域に正面から入るのではないか？
EULA には違反するが、CUDA ソフトウェアをダウンロードしない限り EULA に同意する必要もなく、ZLUDA の作者たちはおそらくそれを避けられたはずだ
「Intel も結局『Intel GPU で CUDA アプリケーションを実行することに事業性はない』と判断した」とは、なんとも厄介だ
AMD GPGPUを一度でも触ったことがある人なら知っている事実が確認された。AMDが2兆ドル企業になるのを阻んでいる唯一のものは、本当にひどいソフトウェアだ。
AMDのOpenCLコンパイラのバグを見つけた記憶があるし [1]、セグメンテーションフォルトでOpenCLコンパイラを落とすのもとても簡単だった。それは結局直らなかったので、報告するのを諦めた。
AMDがCUDAの競合を開発しなかったのは、私が見た中で最も近視眼的な判断だ。最高のハードウェアを作っても、それを使うソフトウェアが控えめに言ってもひどければ、誰も買わないし使わないということを理解している人たちに、なぜ取締役会が入れ替わらなかったのか分からない。
顧客である私たちは、AMDの取締役会がテーブルの上に置き去りにした1兆ドルほどの価値を気にかけるには彼らが裕福すぎるせいで、高価なNvidiaカードを買わざるを得ない。AMD株を持っている人なら問いただすべきだ。その取締役会は一番近い排水口に流されるべきだ。
[1] https://github.com/msoos/amdmiscompile -- 結局これは修正された
私の素朴な理解では、グラフィックカードは命令とデータを載せて、あとは勝手に計算させられる奇妙なコンピュータだ。
CUDAがなぜそんなに大ごとなのか分からない。AMDが自社GPUをArduinoボード4096枚の配列みたいに直接アクセスできるようにしてくれればいいのでは？
ハードウェアを開発する会社は、たいていソフトウェアが苦手だ。例外はあるが多くはなく、そうした会社は実際に株価で報われている。AMDのソフトウェア部門の文化は知らないが、普通こういうものを直すにはかなり大きな変化が必要だ。
取締役会を入れ替えるだけで解決するのは難しいだろう。経営トップの指示だけが会社の足を引っ張っている唯一の要因でないなら、もっと多くの管理層を変えなければならず、中間管理職も相当数入れ替える必要がある。ソフトウェア採用がうまくいっていなかったなら、個々の貢献者まで替えなければならない場合もある。
Intelはソフトウェアが得意で、SYCLは公開標準なので両社とも同じコードから利益を得られ、顧客は望めばThreadripperでもSYCLコードを走らせられる。最近の一部Threadripperは一部GPU並みに速いこともある。
AMDは独自のプロプライエタリなロックイン・エコシステムを作ろうとしているのか？ なぜクロスプラットフォームの公開標準にコミットしないのか分からない。
UPSがよくなかったときはGPUの電力制限もできたし、RX 580をあと1年ほど使うために自動オーバークロックもできた。
ただし2020年ごろ以降のソフトウェア/ドライバは、VRタイトルを1時間もしないうちにクラッシュさせる。Linux向けのソフトウェアパッケージもなく、CoreCtrlはそこまで良くない。インスタントリプレイがときどき単に動かないこともある。WindowsとLinuxの両方で、ローカルLLMにROCmを一度もまともにつなげられなかったし、DKMSはapt upgradeのたびに無駄なコンパイルを大量にしたがった。
次のGPUを好奇心でIntel Arcにするか、素直にNvidiaに戻るか悩んでいる。候補はA580、RX 6600、RTX 3050あたりで、ほかの部品の価格が下がるまで粘るかもしれない。
Metal、CUDA、AMD側の何かのような複数のカーネル言語にコンパイルされるプログラミング言語はあるのだろうか？ ないなら、なぜないのだろう？
CコンパイラはさまざまなCPUアーキテクチャ向けにコンパイルする。GPUアーキテクチャ向けのコンパイラもあるべきではないか？ まだ誰も作っていないだけかもしれない。
https://www.khronos.org/api/opencl
Meshroomのようなオープンソースのフォトグラメトリツールを動かすために、これを使ってみた人はいる？ 記事ではいくつかのプロプライエタリなツールが言及されているが、私の必要性はかなり小さい。
これはJVMバイトコードの使用をめぐるOracle対Google事件とほとんど同じに見える。
これはGoogleが「我々のAndroidアプリケーションはGoogleが承認した携帯電話でしか実行できない」と言うのに近い。私の理解では、GoogleはPlayフレームワークやMapsのようなものについては実際にそうしている。
最近興味深いうわさを聞いたのだが、NVIDIAでCUDAを担当していた人が、何年もの間、リソースを獲得し、会社を説得してこのプロジェクトを真剣に受け止めさせようと闘っていたらしい。
CUDAがなければ、NVIDIAが今日ほぼ1兆ドル企業になることは絶対になかっただろう。
geohotが高価なAMD GPUと格闘し続けていたことも関係している: https://twitter.com/tinygrad/status/1764734675002810622