VUDA: CUDAのVulkan実装

 (github.com/jgbit)
1 ポイント 投稿者 GN⁺ 2023-07-03 | 1件のコメント | WhatsAppで共有
  • VUDA は Vulkan ベースのヘッダーオンリーライブラリで、GPU アクセラレーションアプリケーション作成のための CUDA Runtime API インターフェースを提供
  • 機能は可能な範囲で CUDA runtime 仕様に従っており、通常の利用では NVIDIA CUDA Runtime API リファレンスドキュメントを参照可能
  • すべての機能は vuda.hpp のインクルードと vuda:: 名前空間の使用でアクセスでき、vuda_runtime.hpp は CUDA 機能をラップしてリダイレクトする
  • 例のワークフローでは cudaSetDevice, cudaMalloc, cudaMemcpy, cudaFree のような CUDA Runtime API 呼び出しを使用し、NVCC でない場合は vuda::launchKernel("add.spv", "main", ...) で Vulkan shader module を実行
  • ドキュメント項目として Change List、Setup and Compilation、Deviations from CUDA、Implementation Details を提供

関連記事

1件のコメント

 
GN⁺ 2023-07-03
Hacker News のコメント

  • CUDA の実装ではなく、CUDA ランタイム APIの実装です
    この API はカード設定、メモリの割り当て・コピー、カーネル実行に使われます
    重要なのは、これで GPU 上で実際に動くカーネルコードを書けるわけではないという点です

    • AMD GPU で CUDA コードを実行できるという意味かと少し期待しましたが、説明を見る限りそうではありません
    • だとすると、これがどこで役に立つのか気になります
    • CUDA の代替を名乗るなら、PTX サポートと複数言語での開発サポートが必要です
      そうでなければ、多くのワークロードでは始めることすらできません
    1. これは粗い C スタイル API を実装したものです
      自動エラーチェックや RAII によるリソース制御などを提供する Modern C++ API ラッパーもあります: https://github.com/eyalroz/cuda-api-wrappers
      ちなみに私が作者です
    2. ランタイム APIを実装するのは適切な選択ではありません
      コンテキスト分離や、新しくコンパイルした JIT カーネルをモジュールとして動的に追加する機能などを実現するには、ドライバー APIの実装が重要です
    3. このプロジェクトは 3000 行にも満たないものです
      中核となる CUDA API 全体、つまりドライバー、ランタイム、NVTX、CUDA-C++、および PTX JIT コンパイルをラップするには 14,000 行以上かかりました

  • George Hotz が語っていた、AMD チップで機械学習を可能にし、Nvidia の支配力を崩すという目標と、これがどう関係するのか気になります
    専門家ではありませんが、このアプローチは強力で重要に見えます
    ただ、システムが非常に複雑なので個人で作れるのか疑問で、始めるには企業の後援が必要そうです
    AMD が直接エンジニア費用を負担して、反復的に改善することに関心を持つ可能性もあるのではないかと思います

    • Hotz はユーザー空間ライブラリだけでなく、ドライバーについても話しています

      The software is terrible! There’s kernel panics in the driver. You have to run a newer kernel than the Ubuntu default to make it remotely stable. I’m still not sure if the driver supports putting two cards in one machine, or if there’s some poorly written global state. When I put the second card in and run an OpenCL program, half the time it kernel panics and you have to reboot.
      ユーザー空間側も扱っていますが、こうしたライブラリの上下にあるスタック全体に手を入れるべき箇所が多いと見ているのは明らかです

    • https://www.youtube.com/watch?v=Mr0rWJhv9jU と https://geohot.github.io/blog/jekyll/update/2023/06/07/a-div... を見つけました
      AMD を使って経験した道のりについて、今は少し気が楽になりました
      GPU ドライバーに大きな問題があるように見えていましたが、自分だけではなかったのだと分かりました

  • AMD GPU を Windows で使って機械学習モデルを学習または実行したい人は、torch-directml と tensorflow-directml を確認してみるとよいでしょう

    • AMD が ROCm/MiOpen/HIP で CUDA 互換性を追いかけるより、DirectML の方が妥当なのかはよく分かりません
      CUDA と DirectX は、AMD と Nvidia というかなり異なるハードウェア上で、性能をあまり犠牲にせず互換 API として使うには低レベルすぎるように見えます
      cuDNN はより高レベルなので、AMD と Nvidia のハードウェアに合わせたカーネル実装を別々に持ちながら、性能損失なしに互換性を提供できる余地がより大きいです
      しかし PyTorch のようなフレームワークが行う処理のかなりの部分は、cuDNN だけでなくカスタムカーネルに基づいています
      AMD にとって最良の選択は、揺るぎない堅牢な低レベル API と、PyTorch・TensorFlow・JAX のようなフレームワークベンダーがその上にサポートを載せやすくする高レベルの最適化機械学習コンパイラサポートのように見えます
      結局その恩恵を受けるのはフレームワークベンダーなので、AMD は彼らと非常に緊密に協力する必要があります
      AMD が何年も機械学習サポートを後回しのように扱ってきたのは不思議です
      コンシューマー向け機械学習市場はグラフィックス・ゲーム市場に比べて小さく見え、労力をかける価値が低いと見たのかもしれませんが、Nvidia が示したように、これははるかに収益性の高いデータセンター受注への道です
    • 実際にどう動くのか気になります
      最後に DirectML を試したときはサポートがあまり良くなく、対応しているソフトウェアも少なかったです
      性能もあまり良さそうには見えませんでした
      今は Linux 環境を使っていますが、ROCm のおかげで Automatic111 webui や oobabooga のような人気ツールを使えています
    • それは実際にできるのですか？
      AMD が妥当な価格で、機械学習において Nvidia を上回る GPU を出すなら、新しい GPU を買うかもしれません
      まともな Nvidia GPU は高すぎて、購入を正当化しにくいです

  • 死んだプロジェクトのように見えます
    最後のコミットは2022年2月です

    • しかもそのコミットも 1 行追加しただけでした
      コードの大半は 3〜5 年前のものです

  • GPU を直接プログラミングしたことがないので聞きたいのですが、これは HIP と比べるとどうなのでしょうか？
    Nvidia と AMD GPU の上で効率的な抽象化レイヤーになり得ますか？

  • AMD には期待できません
    互換性ツールはとっくに作っておくべきでした

  • この種のプロジェクトはかなり頻繁に出てきますが、勢いを得られず、私は今も Nvidia GPU を使っています
    これも大きくは違わない気がします

  • かなり興味深いです
    だとすると、私の CUDA アクセラレーション対応プログラムを AMD や Intel のデバイスでも実行できるはず、という意味なのでしょうか？