- このリポジトリは NVIDIA Linux オープンGPUカーネルモジュール のソースリリースで、README基準のバージョンは 565.57.01
- ビルドしたカーネルモジュールは、同じ 565.57.01 ドライバーリリース のGSPファームウェアおよびユーザー空間NVIDIA GPUドライバー構成要素と一緒に使用する必要がある
- サポート対象は x86_64 と aarch64 で、Linuxカーネルは独自のNVIDIAカーネルモジュールと同じ範囲をサポートし、現時点では 4.15 以上
- カーネルモジュールはOS非依存コンポーネントと Linuxカーネルインターフェース層 に分かれており、対象カーネルに合わせてカーネルインターフェース層をビルドする必要がある
- 対応GPUは Turing以降のGPU で、表には NVIDIA GeForce RTX 4090 を含む複数の GeForce、RTX、A/H/L シリーズ製品とPCI IDが列挙されている
リリースとビルド条件
- このリポジトリは NVIDIA Linux open GPU kernel modules のソースリリースで、バージョンは 565.57.01
- 基本のビルドコマンドは次のとおり
- インストール前には既存のNVIDIAカーネルモジュールを削除する必要があり、root権限で次を実行する
make modules_install -j$(nproc)
- ここでビルドしたカーネルモジュールには、対応する 565.57.01 ドライバーリリース のGSPファームウェアとユーザー空間NVIDIA GPUドライバー構成要素が必要
- NVIDIA GPUドライバーの
.run ファイルを --no-kernel-modules オプション付きでインストールする方法が例として示されている
対応アーキテクチャとツールチェーン
- カーネルモジュールは現在 x86_64 または aarch64 向けにビルドできる
- クロスコンパイル時は
TARGET_ARCH=aarch64|x86_64 とともに CC, LD, AR, CXX, OBJCOPY をmakeコマンドラインで指定する
- GCC または Clang の比較的新しいバージョンでビルドできる
- カーネルモジュールの カーネルインターフェース層 は、対象カーネルのビルド時に使用したツールチェーンでビルドする必要がある
- 対応Linuxカーネルバージョンは独自のNVIDIAカーネルモジュールがサポートする範囲と同じで、現時点では Linux kernel 4.15 以上
ビルドオプション
NV_VERBOSE=1 は実行されるすべてのコマンドを出力する
DEBUG=1 はカーネルモジュールを デバッグビルド としてコンパイルする
- デフォルトビルドはデバッグ情報なしでコンパイルされる
- このオプションはカーネルモジュールの複数のデバッグログメッセージも有効にする
カーネルモジュール構造
- NVIDIAカーネルモジュールの大部分は2つの構成要素に分かれる
- OS-agnostic コンポーネント: OSに依存しない部分
- kernel interface layer: Linuxカーネルのバージョンと設定に特化した部分
- NVIDIA の
.run インストールパッケージでは OS-agnostic コンポーネントがバイナリとして提供される
- このコンポーネントは大きく、コンパイル時間も長いため、ドライバーをインストールするたびにユーザーが再コンパイルしなくて済むよう事前ビルド版が提供される
nvidia.ko における該当コンポーネント名は nv-kernel.o_binarynvidia-modeset.ko における該当コンポーネント名は nv-modeset-kernel.o_binarynvidia-drm.ko と nvidia-uvm.ko には OS-agnostic コンポーネントはない
- 各カーネルモジュールの カーネルインターフェース層 は対象カーネルに合わせてビルドする必要がある
ディレクトリ構成とNouveau連携
- 主なディレクトリの役割は次のとおり
kernel-open/: カーネルインターフェース層kernel-open/nvidia/: nvidia.ko 用カーネルインターフェース層kernel-open/nvidia-drm/: nvidia-drm.ko 用カーネルインターフェース層kernel-open/nvidia-modeset/: nvidia-modeset.ko 用カーネルインターフェース層kernel-open/nvidia-uvm/: nvidia-uvm.ko 用カーネルインターフェース層src/: OS-agnostic コードsrc/nvidia/: nvidia.ko 用 OS-agnostic コードsrc/nvidia-modeset/: nvidia-modeset.ko 用 OS-agnostic コードsrc/common/: nvidia.ko と nvidia-modeset.ko のいずれか、または両方で使われるユーティリティコードnouveau/: Nouveau デバイスドライバー連携ツール
nouveau ディレクトリのPythonスクリプトは、ソースコードにエンコードされた一部の ファームウェアバイナリイメージ と関連データを抽出して別ファイルとして保存する- これらのファイルは、Nouveau デバイスドライバーが GSPファームウェア をロードして通信する際に使用される
- バイナリファイルのレイアウトは
nouveau_firmware_layout.ods に説明されており、このファイルは OpenDocument Spreadsheet 形式
コントリビューションとIssue対応
- コントリビューションは NVIDIA の
open-gpu-kernel-modules リポジトリに pull request を作成する形で行う
- pull request の提出時には Contributor License Agreement への同意が求められる
- このコードベースは NVIDIA 独自ドライバーと共有されており、公開ソースは共有コードに複数の処理を施して生成される
- GitHub リポジトリは主に各ドライバーリリースの スナップショット のように機能する
- NVIDIA共有コードベースで行われた個別変更の revision history が提供されることは期待しにくい
- ドライバーリリースごとに git commit が1つだけである可能性が高い
- 個別のコントリビューションが GitHub リポジトリで別個の git commit として反映されない場合がある
- 公開前の処理工程のため、コントリビューションを共有コードベースに適用するには 手動マージ が必要
- 大規模なリファクタリングはマージや受け入れが難しい可能性があるため、事前の連絡と調整が必要
- Open GPU Kernel Modules に関する問題は、NVIDIA リポジトリの Issues、NVIDIA 開発者フォーラム、
linux-bugs@nvidia.com に報告できる
- セキュリティ脆弱性を発見した場合は、別途
SECURITY.md 文書を確認する必要がある
対応GPU範囲
- NVIDIA オープンカーネルモジュールは Turing以降のGPU で使用できる
- 機能サポートと制限事項の詳細は、NVIDIA GPU driver end user README の
kernel_open.html 文書を参照するよう案内されている
- vGPU サポートは vGPU Host Package に含まれる
README.vgpu を参照する必要がある
- 対応GPU表は製品名とPCI IDをあわせて列挙している
- 3つのIDがある場合、1つ目は PCI Device ID、2つ目は PCI Subsystem Vendor ID、3つ目は PCI Subsystem Device ID
- 表には NVIDIA GeForce RTX 4090、NVIDIA GeForce RTX 4090 D、NVIDIA GeForce RTX 4080 SUPER、NVIDIA GeForce RTX 4070 Ti SUPER、NVIDIA H100、NVIDIA H200、NVIDIA GH200、NVIDIA L40S など複数の製品が含まれる
1件のコメント
Hacker News のコメント
すごい。これが可能なのか気になっていたが、これでローカル LLM 用の 4x4090 マシンを妨げるものは、作る時間だけになった
テンソル並列化ができれば、推論では H100 SXM よりずっと安くて速い気がする。ただ、tinybox がなぜ GPU 6 枚構成を選んだのかはいまだによく分からない。多くのワークロードは 4 枚か 8 枚でしかうまく動かないのに、今は 6 枚分の価格を払って 4 枚しか使わないか、8 枚でもない中途半端な構成になっているように見える
6 枚を選んだ理由は、PCIe レーンが 128 本、つまり x16 ポートが 8 つあるからだ。NVMe に 1 つ、ネットワークに 1 つ使えば、GPU 6 枚をフルファブリックで接続できる。4 枚しか使わないと PCIe を無駄にするし、8 枚使うと USB3 をいくつか除いて外部接続の余地がなくなる
目標も 70B FP16 モデルの実行で、だいたい VRAM 140GB が必要になる。6*24GB = 144GB なのでちょうど合う
たとえば NVMe 4 台なら x16 レーン、10G ネットワークならさらに x4 レーンが必要になる
NVIDIA SXM はその後 3、4 へ更新され、この構成はそのベースでもないが、6-way が理にかなう理由がほかにもあるのかもしれない
本当に良いニュースだ。学界にいる関係で、4090 を複数枚でマシンを組んだのに、Nvidia がカード間の P2P 通信を塞いでいたことを知らなかった研究室をいくつも知っている
自分の用途ではずっと安かったのに 4090 を買わなかった理由の一つもそれだった。これは NVLink ではないが、Nvidia は最上位カード以外では NVLink をほぼ廃止してしまったので、ないよりはましだ。昨年末に NVLink H100 を 4 枚積んだ構成の見積もりを取ったが、納期は 13 か月で、非 NVLink 製品なら 4 か月で入手できた。今は研究室を維持するために L40S を 4 枚買ったが、サプライチェーン問題と大幅な値上がりのせいで研究は非常に難しくなっている。博士課程 6 人と学部生何人かを支えるにはまったく足りない
2015〜2018 年、以前いた大学では GPU 2 枚に NVLink が付いたマシンを 1 台 5,000 ドルで組めて、学生ごとに机の下に 1 台ずつ置けたのに、当時のほうがずっと楽だった
研究室の立場なら、MTBF が半分でも価格が 1/4 のカードをいつでも選ぶと思う
ここでいう P2P って何の意味？ 検索すると peer to peer っぽいけど、グラフィックカードの文脈では何を指すの？
https://developer.nvidia.com/gpudirect
もっと多くのハードウェア企業がドキュメントを公開し、残りはコミュニティに解明させてくれたらと思う
初期の IBM VGA で起きたことに似ている。"Mode X" や BIOS ではないハードウェアの実際のモード、さらには 800x600x16 まで調べれば見つかる。残念ながら大半は、製品利用のあらゆる側面をがっちり管理してユーザー層からより多くの金を引き出す方向を好んでいるように見える。個人的には、PC が最も生産的だった時代は最も オープンだった時代でもあったと思う
そうなれば製品価格は単純にもっと高くなるだけだ
敵対的相互運用性(adversarial interoperability) はよくあることで、メーカーが望もうが望むまいが、リバースエンジニアリングでソフトウェアを動かしていた。昔はまれで今では当たり前になったのが ソフトウェア・ハードウェアロックだ。暗号技術は私たちに力を与える技術であるはずだったのに、結局は自分自身のマシンから私たちを締め出すために使われるようになった。今や私たちは運転席にいない。OS ですら、もはやシステムを運用できていない。自由な Linux システムでさえ、メーカーにしか分からない独占的なファームウェアとシリコンを混ぜ込んだ塊の中では単なる「ユーザー OS」にすぎず、実際の動作ではサンドボックス化された小さな部品に近い
Nvidia がコンシューマー向けラインアップから NVLink を削除したときの当初の言い分は、PCIe 5 で十分に速いというものだった
ところが 40xx シリーズは PCIe 5 も P2P サポートもないまま発売された。今こうしてその半分だけでも埋まるのは良いことだが、次世代ファームウェアでもこれを許すとはちょっと想像しにくい
これは、コンシューマ向けカードで市場分離のために無効化されていた機能の1つなのか？
完璧ではないたとえだが、15軒ほどの家がある小さな住宅地が建設中だとしよう。普通は角に200kVAの変圧器を置いて、電力網から適切な電力を供給する。ところが変圧器が不足していたため、施工業者が業務用の1250kVA変圧器を設置した。必要以上に多くの家へ電力を供給できるので、容量を大きく余らせたまま動いている。ある日、住民の1人が大規模な栽培施設を始めたくなり、自分の家だけその余剰の変圧器容量を有効化する方法を見つけ出した。geohotが見つけたのは、まさにその「有効化」に当たる
昔からGeorge Hotzのハッキング能力にはいつも感嘆していた。個人プロジェクトにも大きな刺激をもらった
もっと知識のあるエンジニアならそれほど難しく感じないような、浅くて恣意的な問題によく引っかかっている。本当にひどいコードや、ひどいときには間違ったコードを書く場面もしばしば見られる。Twitter関連の場面はその好例だ。それでも1人で粘り強く試行を重ね、そのたびに驚くような改善を生み出している。学ぶ価値のある好例だ
geohotとtinygrad/commaの貢献者全員に祝意を送りたい
READMEをざっと見たが、気になる人のために言っておくと、これはNVLinkではなくPCIe上のP2Pだ
今後のアーキテクチャでは、これはファームウェアでロックされ始めるだろうから、続く間はありがたい話だ
だから最初から存在しないよりは、1世代でも使えるほうがいい
George本人がやったのか、それともtinycorpがかけていた報奨金を狙った誰かがやったのか気になる。
それと、PCIサブシステムに詳しい人に聞きたいのだが、これはNVIDIAが積極的に防ごうとしていたというより、気にしていなかったように見えないか？
なので、デバイスをいじってVRAM全体をアドレス空間に載せるよう構成するのは理にかなっている。resizable BARのサポートがあるか、固定サイズのBARが十分大きければよい。また、あるカードに対して、別のカードのVRAMへマッピングされたアドレスを読み書きするよう指示するのも理にかなっている。PCIeスイッチの帯域がボトルネックになるのか、それともポイントツーポイントのリンクとVRAMがボトルネックになるのかは気になる。どちらにしても、システムRAMを経由する往復を減らせるのは助けになるはずだ