ZLUDA、AMD GPUでCUDAアプリケーションを実行可能に
- Andrzej Janik が開発したオープンソースプロジェクト ZLUDA 3 は、NVIDIA GPU向けに設計されたGPUベースのアプリケーションを、他社製ハードウェア上で実行できるようにする。
- この技術は、開発者による追加作業なしに、既存アプリケーションを新しいハードウェア上で動作させられるよう設計されている。
- 以前のバージョンの ZLUDA はCUDAアプリケーションをIntel GPUで実行できるようにしていたが、バージョン3ではAMD GPU向けに切り替えられた。
ZLUDA はIntel GPU向けではないのですか？
- ZLUDA は2020年に、Intel GPU向けCUDA代替として初めて公開された。
- 2021年にバージョン2が公開された後、Janik はプロジェクト開発を継続できないと発表したが、その後 Intel は ZLUDA を正式な技術として評価し始めた。
- Intel は、CUDAアプリケーションをIntel GPUで実行することにビジネス上の妥当性がないと判断し、Janik は同社を離れて AMD に接触した。
- AMD は2年間にわたり ZLUDA を評価したが、プロジェクトをこれ以上進めないことを決定し、Janik は更新後のコードをオープンソースとして公開した。
なぜCGアーティストにとって重要なのですか？
- ZLUDA バージョン3は、NVIDIA の CUDA API を使って開発されたGPUベースのアプリケーションを AMD GPU 上で実行できるようにする。
- VFX、モーショングラフィックス、ビジュアライゼーションなどの業界では、多くの主要なCGアプリケーション、特にレンダラーがCUDAベースで、NVIDIA専用となっている。
- AMD は独自技術として HIP を持っているが、ソフトウェア開発者の作業が必要になる。
- ZLUDA は実際には HIP を基盤に構築されており、CUDAアプリケーションを修正なしで AMD GPU 上で実行できるよう設計されている。
ZLUDA 上でCUDAアプリケーションを実行した場合の速度はどのくらいですか？
- Janik は、CUDAアプリケーションは AMD GPU 上で「ほぼネイティブ性能」で動作すると説明している。
- ただし ZLUDA の GitHub リポジトリによれば、3DF Zephyr と RealityCapture は ZLUDA 上では「はるかに遅い」。
- 多くのGPUレンダラー開発者は、性能に寄与するもう1つの NVIDIA API である OptiX も使用しているが、ZLUDA は OptiX に対して「最小限」のサポートしか提供していない。
他のCGアプリケーションも、AMD GPU上で ZLUDA を通じて実行できますか？
- ユーザーテストなしでは、他のCUDAベースCGアプリケーションが ZLUDA 上でどの程度うまく動作するかを判断するのは難しい。
- 既知の問題は多く、Janik は他のGPUレンダラーでは限定的な成功しか収めていない。
将来的に、より多くのCUDAベースCGアプリケーションが ZLUDA 上で実行可能になるでしょうか？
- Janik は、Intel または AMD の支援がなければ、ZLUDA は「現実的には放棄された状態」だと述べている。
- 彼はプロジェクトを前進させられる提案には前向きだが、そうでなければ個人的に関心のある NVIDIA 技術のみをサポートする可能性が高い。
- ソースコードは公開されており、現状でも ZLUDA は、ソフトウェア開発者が CUDA から HIP へ「より段階的な移植」を進める一環として利用できる。
ライセンスとシステム要件
- ZLUDA 3 のコンパイル済みバージョンは Windows と Linux で利用可能。ソースコードは Apache 2.0 または MIT ライセンスで提供される。
GN⁺ の見解
- ZLUDA は、NVIDIA の独占的な CUDA エコシステムを AMD ユーザーに開放することで、GPU市場での競争を促進できる可能性を持つ。
- このプロジェクトは、特に CUDA に依存するレンダリングソフトウェアや科学計算アプリケーションのユーザーに対し、多様なハードウェア選択肢を提供することで恩恵をもたらしうる。
- ただし ZLUDA はまだ初期段階であり、完全な性能と互換性を提供していない点を踏まえると、実際のプロダクション環境での採用には慎重さが必要だ。
- AMD と NVIDIA の技術格差を縮めることは、消費者により良い価格と選択肢をもたらし、市場に健全な競争を促す可能性がある。
- オープンソースコミュニティの継続的な関心と貢献が、このプロジェクトの成功にとって重要であり、関連分野の専門家にとって貢献の好機にもなる。
1件のコメント
Hacker Newsの意見
前回の議論は22日前: AMDがROCmベースでCUDA実装を開発し、オープンソースとして公開 [0]、コメントは400件。
AMDがこのプロジェクトへの資金提供を打ち切ったのはまったく不合理だ。オープンソース化された瞬間からAMDユーザーに価値を提供し始めており、これこそAMDの最優先課題であるべきに思えるのに、AMDはほとんどサポートのない代替APIを2つ（あるいは3つ？）抱えたまま何年も時間を無駄にしてきた。
議論に関連する話題: Nvidiaが他社チップで動かすためのCUDAソフトウェアの変換レイヤー利用を禁止 [1]
Intelも結局、「Intel GPUでCUDAアプリケーションを実行することにビジネス上の合理性はない」と判断した。これは、AMD GPGPUに関わったことのある人なら誰でも知っている事実を裏づけるものだ。
AMDのソフトウェアが非常にひどいことは周知の事実であり、AMDが2兆ドル企業になるのを妨げている唯一の要因がそれだ。AMDのOpenCLコンパイラにはバグがあり、segfaultで簡単にコンパイラをクラッシュさせることができた（結局あきらめて報告もしなかった）。AMDがCUDAに対抗できる競合を作らなかったのは、あまりにも短期的な見方だった。なぜAMDの取締役会が入れ替わっていないのか理解できない。どれだけ優れたハードウェアを作れても、それを使うソフトウェアがひどければ誰も買わず、使わない。顧客としては、AMDの取締役会がテーブルの上に置き去りにされた何兆ドルもの価値を気にしていないように見えるので、割高なNvidiaカードを買うしかない。AMD株を持っている人は問いただすべきであり、その取締役会は最寄りの排水口へ流されるべきだ。
Metal、CUDA、AMDが持っているものなど、さまざまなカーネル言語にコンパイルできるプログラミング言語があるのだろうか。もしないのなら、なぜないのだろう？ さまざまなCPUアーキテクチャ向けにコンパイルするCコンパイラがあるように、GPUアーキテクチャ向けにコンパイルするコンパイラもあるべきではないだろうか。おそらく、まだ誰も作っていないのかもしれない。
誰かこれをMeshroomのようなOSSフォトグラメトリツールで動かしてみた人はいるのだろうか。記事ではいくつかのプロプライエタリなものに触れているが、必要なものはそれほど多くない。
AMD GPUの問題は個々のカーネルではなくライブラリだ。リリースノートに「cuDNN、cuBLAS、cuSPARSE、cuFFT、NCCL、NVMLの最小限のサポートを追加」とあることからも、このプロジェクトがその方向へ進んでいたことがうかがえる。AMDが資金提供を打ち切った後も、このプロジェクトが勢いを維持できるかどうかは誰にも分からない。
これはOracle対GoogleにおけるJVMバイトコードの利用とほぼ同じ問題だ。
geohotの継続中のAMD GPUとの（高くつく）格闘も関連している: Twitterリンク