第0章 — ネイティブ Linux

環境のしくみを理解する

Quickstart で「動いた」ことを確認しましたか？ここでは、あのとき実行したコマンドが 何をしていたのか を理解します。

この章の前提: Quickstart（ネイティブ Linux）が終わっていることを前提にしています。まだの方は先にそちらをどうぞ。

全体の構造 — 何がどこにいるのか

Quickstart で触ったものを、下から順に積み上げると次のようになります。

あなたのコード（Python）
↕ PyTorch（ROCm 版）
↕ ROCm ランタイム（HIP, rocBLAS など）
↕ カーネルドライバ（amdgpu）
🖥️ GPU ハードウェア

この章では、各層が何をしているのかと、Quickstart のコマンドがどの層を確認していたのかを見ていきます。

rocminfo — GPU が「見えている」とはどういうことか

Quickstart では rocminfo を使いました。これは ROCm のランタイムが GPU を認識しているかを確認するツール です。

💡 なぜ大事なのか: ROCm がインストールされていても、ドライバの問題やアクセス権限の不足で GPU が「見えない」ことがあります。rocminfo は「OS → ドライバ → ROCm ランタイム → GPU」の経路が通っているかを確認する最初のチェックポイントです。

rocminfo の出力で見るべきところ:

Agent の Name — GPU のアーキテクチャ名（例: gfx1100）
Agent が 0 個のとき — GPU が見えていない = ドライバか権限の問題

video / render グループ — なぜ必要なのか

groups

Quickstart で sudo usermod -aG video,render $USER を実行しました。

💡 なぜ大事なのか: Linux では GPU デバイス（/dev/kfd や /dev/dri/*）へのアクセスは、video や render グループに属するユーザーだけに許可されています。このグループに入っていないと、root 以外のユーザーは GPU を使えません。

rocminfo でエラーが出るとき、いちばん多い原因がこの権限不足です。groups コマンドで video と render が出るか確認してみてください。

Python 仮想環境（venv）— なぜ分けるのか

python3 -m venv ~/rocm-env
source ~/rocm-env/bin/activate

💡 なぜ大事なのか: Python は、同じコマンド名 python3 でもインストール先によって別のライブラリ環境を持ちます。仮想環境を使わないと、システムの Python とパッケージが混ざって「入れたはずの PyTorch が見つからない」「バージョンが違う」といった事故が起きます。

仮想環境を使うと:

システムの Python を壊さない
ROCm 版 PyTorch だけを入れた環境を作れる
うまくいかなかったら、フォルダごと消してやり直せる

torch.version.hip — ROCm 版かどうかを見分ける

python3 -c "import torch; print(torch.version.hip)"

💡 なぜ大事なのか: PyTorch には CPU 版、CUDA 版、ROCm 版があり、pip install torch だけだと CPU 版が入ることがあります。torch.version.hip がバージョン番号を返せば ROCm 版、None なら ROCm 版ではありません。

もうひとつの確認方法:

python3 -c "print(torch.cuda.is_available())"

torch.cuda という名前なのに AMD GPU？
PyTorch は歴史的に GPU API を cuda という名前にしています。ROCm 版でもこの名前はそのまま使います。名前は CUDA でも、中身は ROCm が動いています。詳しくは第1章で。

ROCm のインストール — 公式手順を使う理由

ROCm はカーネルドライバ、ランタイムライブラリ、ツール群からなる大きなソフトウェアスタックです。

💡 なぜ公式手順なのか: パッケージ間のバージョン依存が複雑なため、公式の手順通りにやるのがいちばん事故が少ないです。「便利そうなワンライナー」を見つけても、まずは公式を優先してください。

👉 AMD 公式: ROCm インストールガイド

ネイティブ Linux と Docker — 何が違うのか

この講座では、ネイティブ Linux と Docker の2つのルートを用意しています。

	ネイティブ	Docker
ROCm のインストール	自分でやる	コンテナに入っている
環境の独立性	venv で分離	コンテナ自体が分離
やり直し	venv を消して作り直す	コンテナを消して起動し直す
向いている人	Linux をそのまま使いたい	環境を汚したくない

第1章以降は、どちらのルートでも同じコードで進めます。

確認コマンドの使い分け

ここまでに出てきた 3 つの確認方法を整理します。

コマンド	確認できること	確認する層
`rocminfo`	ROCm ランタイムから GPU が見えるか	ドライバ〜ランタイム
`torch.version.hip`	PyTorch が ROCm 版かどうか	PyTorch
`torch.cuda.is_available()`	PyTorch から GPU が使えるか	PyTorch〜ランタイム〜ドライバ

rocminfo は Python なしで使えるので、まずはここから。torch.version.hip は PyTorch の種類判定。torch.cuda.is_available() は全層を通した最終チェックです。

✅ 第0章のチェックリスト

rocminfo が「ROCm のランタイムから GPU が見えるかの確認」だとわかった
video / render グループが「GPU へのアクセス権限」だとわかった
venv が「Python 環境を分離する仕組み」だとわかった
torch.version.hip が「ROCm 版 PyTorch かどうかの目安」だとわかった
torch.cuda が AMD GPU でも使う API 名だと知った

ここまで来たら、第1章に進む準備ができています。
環境の意味がわかった状態でコードを書くと、エラーが出たときの対処がずっと楽になります。

第1章へ進む →