GPU 大手のソフトウェアは依然として頭痛の種だが、Fedora と AMD は解決策を見つけるべく取り組んでいる。

Nvidia によれば、次期 560 ドライバはバージョン 515 および 555 と同様にオープンであり、より多くのデバイスをサポートするとのことです。

この最新のニュースは、GPU 大手各社がオープンソースの GPU カーネル モジュールを全面的に採用していることを示唆しています。

実際、NVIDIAの今回の動きは、2022年に予定していたオープンソース・グラフィック・ドライバー・イニシアチブの延長線上にあると言えるでしょう。当時の報道によると、一部の観測筋は、この取り組みは宣伝ほどオープンではないと感じていたようです（詳細は末尾の脚注を参照）。まず、明確にしておきたいのは、私たちはNVIDIAのオープンソース・イニシアチブを軽視しているわけではないということです。ただ…NVIDIAは当時、やや慎重な姿勢を見せており、それは今も変わりません。

同社の最新の発表では、このプログラムを継続的に推進し、サポートを拡大していくことが強調されています。2023年には、NVIDIAは新しいTuringハードウェアのサポートを追加しました。そして、同社は今回の発表で次のように述べています。

NVIDIA Grace HopperやNVIDIA Blackwellなどの最先端プラットフォームでは、オープンソースのGPUカーネルモジュールのみを使用できます。これらのプラットフォームは、プロプライエタリなドライバーをサポートしていません。

Turing、Ampere、Ada Lovelace、または Hopper アーキテクチャに属する新しい GPU の場合、NVIDIA はオープンソースの GPU カーネル モジュールへの切り替えを推奨しています。

古いGPUを使用している場合、または複数のGPUを混在させたアプリケーションを使用している場合は、スタンドアロンのプロプライエタリドライバーを使い続けるしかありません。オープンソースでサポートされている最新のGPUを使用している場合でも、ファームウェアBLOBを取り除くことはできません。

さまざまな Linux ディストリビューションはこの問題をどのように処理しますか?

これは、カーネルの暗号署名を必要とするメカニズムであるUEFIセキュアブートをサポートするLinuxディストリビューションでは明らかに問題となります。しかし、Ubuntuにはドライバーとインストールツールが直接含まれているため、状況は比較的単純です。

しかし、FedoraにはNVIDIAドライバなどのプロプライエタリ要素が含まれておらず、GNOME App Storeでも選択肢にありません。これは長年の問題ですが、近いうちに解決されるかもしれません。

新たな変更提案では、Fedora はユーザーがモジュールに自己署名できるオプションを追加します。この変更は現在も議論中ですが、承認されれば、できるだけ早く Fedora 41 に実装される予定です。

CUDAをNvidiaのコントロールから解放する

ハイエンドグラフィックカードを持つゲーマー以外にも、NVIDIA GPUの重要な用途の一つは、計算タスクをGPUチップにオフロードすることです。この並列処理手法は、最新のGPUの計算能力を大幅に最大化できます。NVIDIAはこれをCUDA（Compute Unified Device Architecture）と呼んでいますが、現在ではGPGPUコンピューティングと呼ばれることが一般的です。

問題は、CUDA用のコードを書いた場合、NVIDIAドライバを搭載したNVIDIAチップでしか実行できないことです。例えば、CUDAコードを完全なFOSS Nouveauドライバで実行することはできません。

AMDもROCmと呼ばれる独自のGPGPUソフトウェアスタックを提供しており、ユーザーはこれを使用して数値計算をAMD GPUにオフロードできます…しかし、ROCm用にコードを記述しても、同様にNVIDIAプラットフォームでは動作しません。GPU間の移植性を維持するため、AMDはHipの代替としてHeterogeneous Computing Portability Interfaceも提供しています。ただし、すべての機能がサポートされているわけではないことに注意してください。例えば、インラインPTXアセンブリ言語は動作しません。

そして今、新たな独立系競合が参戦しました。Spectral ComputeのSCALE言語です。プロジェクトのドキュメントには次のように記載されています。

SCALE は、CUDA アプリケーションを AMD GPU 用にネイティブにコンパイルできるようにする GPGPU プログラミング ツールキットです。

SCALE では、CUDA プログラムやそのビルド システムを変更する必要はありません。

SCALE は実際にインライン PTX アセンブリをサポートしており、このプロジェクトでは AMD HIP や FOSS ZLUDA ツールなどの競合テクノロジとのパフォーマンス比較も提供しています。

さらに、ベンダーに依存しないGPGPUコンピューティングを実現する製品も存在します。OpenCL規格は2008年から存在し、2020年にバージョン3.0がリリースされました。UXLと呼ばれる新たな競合製品が、今年後半に市場に参入すると予想されています。

しかし、こうした状況はNVIDIAが3兆ドルという驚異的な時価総額を達成する妨げにはなりませんでした。この分野における競争の激化は、間違いなく良いことだと私たちは考えています。

脚注: 本当に「オープン」であるとみなされるためには、どの程度オープンである必要がありますか?

オープンソースドライバーを常に宣伝しているからといって、Nvidiaのドライバースタック全体がオープンソース化されたわけではありません。実際、オープンソース化はされていません。Linuxオペレーティングシステムとやり取りする部分のみがオープンソース化されており、Nvidiaは独自のコードを数MBの「ファームウェア」ファイルに集約しています。当然のことながら、このファイルはクローズドソースのまま、秘密にされています。

515ドライバをリリースした際、Asahi Linuxプロジェクトのリーダーであるヘクター・マーティン氏は、NVIDIAが研究目的で公開しているコードの量について特に確認しました。彼は現在削除されているTwitterアカウントで、以下の調査結果を発表しました。

言い換えれば、Nvidia はオープンソースのカーネル ドライバーを「リリース」したことになります。

より正確に言うと、コードのほとんどをファームウェアに移し、オープンソースドライバーで使用しています。私の知る限り、この34MBのファームウェアには900近くの関数が含まれています。

Broadcom は、自分たちが専門家であると自負していました...

簡単に言えば、AppleのGPUファームウェアは約400KBです。Appleのディスプレイコントローラも、RPCが複雑に絡み合った複雑な構造をしていますが、サイズは約7MBで、その大部分はデータテーブルです（コード部分は約1.5MBです）。

誤解しないでください。カーネル内の BLOB が少ないのは、実際には良いことです... しかし、Nvidia は、自らが主張するように「ドライバー」をオープンソース化していません。

彼らのカーネルコードベースは、少なくとも「たったの」58MBです。この点ではAMDがまだはるかに先を進んでいます。彼らはなんと、約300MBもの自動生成コンテンツをアップストリームのLinuxカーネルツリーに詰め込むことに成功しているのです…

大規模なソフトウェアプロジェクトをブラックボックス化してしまうという慣行は、近年ますます一般的になっています。2022年の報告書によると、プロプライエタリなファームウェアBLOBの範囲拡大に対する懸念が示されました。この状況は広範囲にわたる影響を及ぼし、Debianプロジェクトは30年にわたるポリシーを変更し、Debian 12からプロプライエタリなファームウェアを導入せざるを得なくなりました。