第521回 ではUbuntu 18.04 LTSに最初からインストールされているコンテナ管理システムLXDについて紹介しました。今回はコンテナの中からホスト上のGPUデバイスを利用する方法を紹介しましょう。
コンテナから見えるデバイス
LXDで作成したコンテナからアクセスできるデバイスは、システムが起動するために必要なものだけに制限されています。
container$ ls /dev/
console full log net pts stderr tty
core fuse lxd null random stdin urandom
fd initctl mqueue ptmx shm stdout zero
しかしながらコンテナの中からもホスト上に見えているデバイスにアクセスできると嬉しい場合は多々あります。LXD 2.0以前でこれを行おうとするといろいろと細かい設定が必要でした。ところが、LXD 2.xの開発中にインターフェースが大きく改善され、Ubuntu 18.04 LTSに最初からインストールされているLXD 3.0においては、ほぼコマンド一発でホストの大抵のデバイスファイルを参照できるようになったのです。
設定が簡単になったデバイスの中で特に便利なのが、GPU、USB、NICでしょう。今回はこれらのデバイスのうちGPUの使い方について紹介します。なお、LXDの基本的な使い方と初期設定については第521回 を参照してください。
GPUをコンテナの中からアクセスできるようにする
LinuxにおいてユーザーランドからGPUにアクセスする際は、主に「/dev/dri
」以下のファイルを経由します。よってこのデバイスファイルへコンテナからアクセスできれば、GPUを使うツールをコンテナの中で動かせることになります。
LXDコンテナにホストのGPUデバイスを見せるには、次のコマンドを実行します。
$ lxc config device add container mygpu gpu
デバイス mygpu が container に追加されました
「container
」は任意のコンテナ名であり、「 mygpu
」は追加するデバイスに対するラベルです。
デバイスは実行中のコンテナの中でもすぐに見えるようになります。
$ lxc exec container -- ls -l /dev/dri
total 0
crw-rw---- 1 root root 226, 0 Aug 11 07:33 card0
crw-rw---- 1 root root 226, 128 Aug 11 07:33 renderD128
GPUデバイスの権限を変更する
デバイス追加時は、パーミッションに注意が必要です。一般的なビデオデバイスは、次のようにグループが「video」になるようudevが設定しています。
$ ls -l /dev/dri/
total 0
drwxr-xr-x 2 root root 120 Aug 11 06:17 by-path
crw-rw---- 1 root video 226, 0 Aug 11 06:17 card0
crw-rw---- 1 root video 226, 128 Aug 11 06:17 renderD128
一般的なユーザーはvideoグループに所属しているため[1] 、特に設定することなくGPUにアクセスできます。ところがLXDコンテナの内部ではグループもrootになっているため、このままでは管理者権限でしかアクセスできないことになります。
これを回避する方法はいくつかありますが、デバイス追加時にグループIDを指定するのが一番わかりやすいでしょう。
一旦デバイスを削除する
$ lxc config device remove container mygpu
デバイス mygpu が container から削除されました
グループIDを指定して追加する
$ lxc config device add cuda mygpu gpu \
gid=`getent group video | cut -d: -f3`
デバイス mygpu が container に追加されました
$ lxc exec cuda -- ls -l /dev/dri
total 0
crw-rw---- 1 root video 226, 0 Aug 11 06:18 card0
crw-rw---- 1 root video 226, 128 Aug 11 06:18 renderD128
無事にvideoグループに所属するようになりました。
デバイス追加時は「gid=グループID
」でデバイスファイルのグループIDを変更できます。今回はvideoグループに所属させたかったのでgetent
コマンドでvideoグループのIDを抽出し、それを指定しています。なお「uid=
」を指定することで、ユーザーIDも変更できます。
追加するGPUデバイスを指定する
複数のグラフィックカードを繋いでいたり、内蔵GPUと外付けGPUの両方が存在する場合、/dev/dri
以下には複数のGPUデバイスファイルが作成されます。このうち一部のGPUのみをLXDコンテナに展開したい場合は、id
オプションを指定します。
たとえばこのマシンは2つのGPUが認識されています。
$ ls -l /dev/dri/
total 0
drwxr-xr-x 2 root root 120 Aug 11 06:17 by-path
crw-rw---- 1 root video 226, 0 Aug 11 06:17 card0
crw-rw---- 1 root video 226, 1 Aug 11 06:17 card1
crw-rw---- 1 root video 226, 128 Aug 11 06:17 renderD128
crw-rw---- 1 root video 226, 129 Aug 11 06:17 renderD129
by-path
のほうを見ると、それぞれのGPUがどのようにPCIバスにぶら下がっているかがわかります。
$ ls -l /dev/dri/by-path/
total 0
lrwxrwxrwx 1 root root 8 Aug 11 06:17 pci-0000:00:02.0-card -> ../card1
lrwxrwxrwx 1 root root 13 Aug 11 06:17 pci-0000:00:02.0-render -> ../renderD129
lrwxrwxrwx 1 root root 8 Aug 11 06:17 pci-0000:01:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Aug 11 06:17 pci-0000:01:00.0-render -> ../renderD128
lspci
コマンドで個々のアドレスのデバイスを見てみましょう。
$ lspci -s 0000:00:02.0
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
$ lspci -s 0000:01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] (rev a1)
このことから、card0(0000:01:00.0)が外付けGPUであるGeForce GTX 1050 Tiであり、card1(0000:00:02.0)が内蔵GPUである Intel HD Graphics 530であることがわかります。
NVIDIAのGPU(card0)のみLXDコンテナの中から使いたいのであれば、次のように追加してください。
$ lxc config device add cuda mygpu gpu id=0
ちなみにCUDAなどの利用を目的とする場合、NVIDIAのドライバーが作成するデバイスファイルを読み書きすることになるので、/dev/dri
以下のグループIDの変更は不要です。
コンテナの中からVAAPIを利用する
コンテナの中からGPUデバイスにアクセスできるようになれば、コンテナの中でVAAPI やVDPAU を利用したソフトウェアを実行可能になります。VAAPI/VDPAUに対応したアプリケーションはたくさん存在しますが、まずは大抵のPCには存在するIntelの内蔵GPUのVAAPIで使えるvainfo
コマンドをインストールしてみましょう。
$ sudo apt install vainfo
試しにGPUがコンテナから見えない状態でコマンドを実行してみます。
$ vainfo
error: can't connect to X server!
error: failed to initialize display
上記のようにエラーとなりました。次にIntelの内蔵GPUをコンテナに追加した状態で実行してみます。
$ ls -l /dev/dri/
total 0
crw-rw---- 1 root video 226, 1 Aug 12 08:20 card1
crw-rw---- 1 root video 226, 1 Aug 12 08:20 controlD65
crw-rw---- 1 root video 226, 129 Aug 12 08:20 renderD129
$ vainfo
error: can't connect to X server!
error: failed to initialize display
あれ、追加してもエラーになってしまいますね。これはvainfo
コマンドが暗黙的に「/dev/dri/renderD128
」もしくは「/dev/dri/card0
」をデバイスファイルとして扱っているためです。今回の例だとこれらはVAAPIに直接には対応していないNVIDIAのGPUであり、さらにはコンテナの中からは見えないように設定していたため、うまく認識できませんでした。
明示的にデバイスファイルを指定するには、「 --display
」オプションと「--device
」オプションを指定します。
$ vainfo --display drm --device /dev/dri/card1
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 2.1.0
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
VAProfileH264ConstrainedBaseline: VAEntrypointFEI
VAProfileH264ConstrainedBaseline: VAEntrypointStats
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointEncSliceLP
VAProfileH264Main : VAEntrypointFEI
VAProfileH264Main : VAEntrypointStats
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointEncSliceLP
VAProfileH264High : VAEntrypointFEI
VAProfileH264High : VAEntrypointStats
VAProfileH264MultiviewHigh : VAEntrypointVLD
VAProfileH264MultiviewHigh : VAEntrypointEncSlice
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileH264StereoHigh : VAEntrypointEncSlice
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileVP8Version0_3 : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
無事に認識できましたね。「 VAEntrypointVLD」がデコードに対応しているフォーマットで、「 VAEntrypointEncSlice」がエンコードに対応しているフォーマットです。
ちなみに「--display
」オプションを指定しなかった場合は、WaylandやX11のディスプレイを開きに行こうとするため、サーバー環境だと「error: failed to initialize display」のようなエラーが表示されます。
次にFFmpeg を利用して、ハードウェアデコード・エンコードを行ってみます。対象ファイルは「Big Buck Bunny 」のH.264/MOVです[2] 。
[2] テスト用途としてはファイルサイズが大きすぎますが、他にちょうどいい感じのライセンス・フォーマットを持ったサンプル動画がなかったのでこれにしました。デバイスがMP4デコードに対応しているならSintel のトレイラーぐらいがちょうどいいかもしれません。4KならTears of Steel という選択肢もあります。
$ sudo apt install ffmpeg
$ wget http://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov
VAAPI対応デバイスを用いたデコード・エンコード方法については、FFmpegのドキュメント を参照してください。ここでは次のコマンドでH.264をH.265/HEVCに再エンコードしています。
$ time ffmpeg -vaapi_device /dev/dri/renderD129 -hwaccel vaapi \
-hwaccel_output_format vaapi \
-i big_buck_bunny_1080p_h264.mov \
-vf 'format=nv12|vaapi,hwupload' -c:v hevc_vaapi -c:a copy \
big_buck_bunny_1080p_h264.mp4
(中略)
Duration: 00:09:56.46, start: 0.000000, bitrate: 9725 kb/s
Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080, 9282 kb/s, 24 fps, 24 tbr, 2400 tbn, 4800 tbc (default)
(中略)
Stream #0:0(eng): Video: hevc (hevc_vaapi) (Main) (hev1 / 0x31766568), vaapi_vld, 1920x1080, q=2-31, 24 fps, 12288 tbn, 24 tbc (default)
(中略)
frame=14315 fps= 88 q=-0.0 Lsize= 225251kB time=00:09:56.45 bitrate=3093.7kbits/s speed=3.66x
video:193017kB audio:31863kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.164760%
real 2m42.887s
user 0m19.135s
sys 0m23.921s
CPU時間をほぼ使うことなく再エンコードできました。比較のためにVAAPIを使わずにエンコードしてみましょう。
$ time ffmpeg \
-i big_buck_bunny_1080p_h264.mov \
-vf 'format=nv12' -c:v hevc -c:a copy \
big_buck_bunny_1080p_h264_2.mp4
(中略)
frame=14315 fps= 22 q=-0.0 Lsize= 111046kB time=00:09:56.45 bitrate=1525.1kbits/s speed=0.897x
video:78777kB audio:31863kB subtitle:0kB other streams:0kB global headers:2kB muxing overhead: 0.366397%
x265 [info]: frame I: 155, Avg QP:23.70 kb/s: 14753.00
x265 [info]: frame P: 4384, Avg QP:28.07 kb/s: 2239.70
x265 [info]: frame B: 9776, Avg QP:34.67 kb/s: 344.90
x265 [info]: Weighted P-Frames: Y:4.1% UV:3.0%
x265 [info]: consecutive B-frames: 10.6% 23.8% 10.4% 50.1% 5.1%
encoded 14315 frames in 664.95s (21.53 fps), 1081.19 kb/s, Avg QP:32.53
real 11m5.079s
user 42m30.934s
sys 0m3.594s
実際に経過した時間は4倍強ですが、CPUの使用時間は比較にならないほど大きくなっています。また、再エンコード中にtopなどを実行すると、全力でCPUを動かしていることがわかります。
なお、複数のLXDインスタンスから同時に同じGPUに対してffmpegを実行することも可能です。よってユーザー側で排他制御を意識する必要は「基本的には」ありません。もちろん性能を考えてどれかのインスタンスで占有させたい場合は、何らかの排他の仕組みを導入するか、そもそも特定のインスタンスのみGPUを見せる必要があります。
コンテナの中からOpenCLを利用する
GPUを利用するもうひとつの例がOpenCL です。こちらもGPUがコンテナから見えるようになっていたら、同じように利用できます。
まずはOpenCL関連パッケージをインストールしておきましょう。
$ sudo apt install beignet-opencl-icd clinfo
GPUが見えない時にclinfo
を実行してもGPUが見つからないと表示されます。
$ clinfo --list
beignet-opencl-icd: no supported GPU found, this is probably the wrong opencl-icd package for this hardware
(If you have multiple ICDs installed and OpenCL works, you can ignore this message)
Platform #0: Intel Gen OCL Driver
GPUが見える時にclinfo
を実行すると、そのデバイスがリストアップされます。
$ clinfo --list
Platform #0: Intel Gen OCL Driver
`-- Device #0: Intel(R) HD Graphics Skylake Desktop GT2
LibreOffice CalcやBlender、darktableなどデスクトップアプリケーションから、仮想通貨のマイニングに至るまで、OpenCLに対応したソフトウェアはたくさん存在します。
コンテナの中からCUDAを実行する
CUDA はNVIDIA製GPUで使える、GPGPUのツールキットです。第456回 ではCUDAを使うためにいろいろなセットアップを行いましたが、これもコンテナの中に閉じ込められると便利です。第461回 で紹介したNVIDIA
Dockerを使えばLXDを使わずとも、コンテナの中に閉じ込めることは可能でした。これはNVIDIA Docker側で必要なデバイスをコンテナの中からも見えるようにセットアップしてたためです。CUDAの場合、単に「/dev/dri/
」以下を見せるだけでなく、「 /dev/nvidia0
」など他のファイルもコンテナ内部から見える必要があります。
そこでLXD 3.0 からは、NVIDIA Dockerのやり方を踏襲してnvidia-container-cli
でリストアップされる「コンテナの中でも必要なデバイス・ファイル」をコンテナの中に見せる仕組みが導入されています。これを使えばCUDAを利用なLXDコンテナをコマンド一発で作成できるのです。
あらかじめホストマシンにNVIDA製のドライバーをインストールしておいてください。手順は第454回 が参考になるでしょう。なおUbuntu 18.04 LTSではUbuntuリポジトリのNVIDIAドライバーパッケージの名前が「nvidia-XXX」から「nvidia-driver-XXX」に変わっています。Ubuntuリポジトリ版を使うなら、こちらを指定してください。
$ apt search "^nvidia-driver-[0-9]{3}$"
Sorting... Done
Full Text Search... Done
nvidia-driver-390/bionic 390.48-0ubuntu3 amd64
NVIDIA driver metapackage
またX11関連パッケージが不要なサーバー向けに依存関係を調整した「nvidia-headless-XXX」パッケージも存在します。GPGPU用途ならこちらを使うと良いでしょう。
$ apt search "^nvidia-headless-[0-9]{3}$"
Sorting... Done
Full Text Search... Done
nvidia-headless-390/bionic 390.48-0ubuntu3 amd64
NVIDIA headless metapackage
2018年8月上旬時点でUbuntuリポジトリからインストールされるNVIDIAドライバーは2018年3月28日にリリースされた390.48 です。
$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module 390.48 Thu Mar 22 00:42:57 PDT 2018
GCC version: gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)
それに対してNVIDIAから提供されているLong-lived branchの最新版は2018年7月16日にリリースされた390.77 となります。またLong-lived branchではない通常リリースの最新版は2018年8月3日にリリースされた396.51 です。
NVIDIAのドライバーは、使えるCUDAのバージョンにも影響します。CUDAの最新のリリースノート によると、CUDAのバージョンとLinux版ドライバーのバージョンは以下のような関係になっているようです。
9.0.76
>= 384.81
9.1.85
>= 390.46
9.2.88
>= 396.26
9.2.148 Update 1
>= 396.37
つまり最新のCUDA 9.2を使いたければカーネルドライバーもLong-lived branchではなく最新リリースを使う必要があります。ただしCUDA 9.2はまだUbuntu 18.04 LTS向けのリリースを提供していません 。また、9.2自体の正式リリースが2018年5月と比較的新しいので、ツールによってはまだ対応していないかもしれません。
今のタイミングであれば、ホストはUbuntu 18.04 LTSにしたとしても、LXDコンテナはGCC 5が載っているUbuntu 16.04 LTSを選択し、CUDA 9.0あたりをインストールしておくのが無難でしょう。
libnvidia-containerのインストール
次にnvidia-container-cli
コマンドを提供するlibnvidia-container をホストマシンにインストールします。これが存在しないと「Error: The NVIDIA container tools couldn't be found」が発生します。残念ながらこのコマンドはUbuntuリポジトリに存在しないので、NVIDIAのリポジトリ を追加する必要があります。ちなみにsnap版のLXDであれば、パッケージの中にnvidia-container-cli
コマンドが組み込まれています。
$ curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | \
sudo apt-key add -
$ curl -s -L https://nvidia.github.io/libnvidia-container/ubunt18.04/libnvidia-container.list | \
sudo tee /etc/apt/sources.list.d/libnvidia-container.list
$ sudo apt update
$ sudo apt install libnvidia-container-tools
nvidia-container-cli
を実行してみましょう。
$ nvidia-container-cli info
NVRM version: 390.48
CUDA version: 9.1
Device Index: 0
Device Minor: 0
Model: GeForce GTX 1050 Ti
GPU UUID: GPU-6fae1717-190c-1843-3fb8-c3d6cd190739
Bus Location: 00000000:01:00.0
Architecture: 6.1
list
サブコマンドを実行することでコンテナの中に展開するホストのファイルのリストが得られます。
$ nvidia-container-cli list
/dev/nvidiactl
/dev/nvidia-uvm
/dev/nvidia-modeset
/dev/nvidia0
/usr/bin/nvidia-smi
/usr/bin/nvidia-debugdump
/usr/bin/nvidia-persistenced
/usr/bin/nvidia-cuda-mps-control
/usr/bin/nvidia-cuda-mps-server
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.390.48
/usr/lib/x86_64-linux-gnu/libcuda.so.390.48
/usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.390.48
/usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.390.48
/usr/lib/x86_64-linux-gnu/libnvidia-fatbinaryloader.so.390.48
/usr/lib/x86_64-linux-gnu/libnvidia-compiler.so.390.48
/usr/lib/x86_64-linux-gnu/libnvidia-encode.so.390.48
/usr/lib/x86_64-linux-gnu/libnvcuvid.so.390.48
これらはすべてホストのファイルがそのままコンテナの中でも見えるようになるので、ホストとコンテナでNVIDIAドライバーやCUDAのバージョンを合わせる必要がなくなります。
具体的にどのように使っているかは「/usr/share/lxc/hooks/nvidia
」を参照してください。
コンテナの中でのNVIDIAドライバーの有効化
実際にコンテナを作るところから見ていきましょう。
$ lxc launch ubuntu:16.04 cuda
Creating cuda
Starting cuda
$ lxc config device add cuda gp107 gpu id=0
デバイス gp107 が gpu に追加されました
この状態でコンテナの中でnvidia-smi
を実行しても、そもそもコマンドが見つからずエラーになります。
$ lxc exec cuda nvidia-smi
(エラー終了)
そこでnvidia.runtime
オプションをtrue
にします。これにより次回起動時から、nvidia-container-cli
の結果に応じてホストのファイル群がコンテナの中にも展開されるのです。
$ lxc config set cuda nvidia.runtime true
$ lxc restart cuda
$ lxc exec cuda nvidia-smi
Sun Aug 12 11:26:24 2018
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.48 Driver Version: 390.48 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 105... Off | 00000000:01:00.0 Off | N/A |
| 0% 48C P0 N/A / 72W | 0MiB / 4040MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
コンテナの中でもnvidia-smi
を実行できるようになりました[3] 。
CUDAツールキットのインストール
コンテナにCUDAツールキットをインストールするにあたって、ホストからコンテナに展開されたファイルの扱いに注意が必要です。nvidia.rutime
設定はホストのファイルをそのままコンテナの中に見せる仕組みです。よってホスト上ではパッケージからインストールされたファイルであっても、コンテナ上ではそのパッケージは「インストールされていないこと」になっています。さらにファイルの書き換えはができないため、コンテナ上で同じファイルをインストールしようとするとエラーになってしまいます。
$ dpkg -S /usr/lib/x86_64-linux-gnu/libcuda.so.390.48
libnvidia-compute-390:amd64: /usr/lib/x86_64-linux-gnu/libcuda.so.390.48
たとえばlibcuda.so.309.48はlibnvidia-compute-390パッケージから提供されていますが、コンテナ上ではlibnvidia-compute-390パッケージをインストールしようとするとエラーになるのです。このためnvidia-cuda-toolkitパッケージが使えません。
コンテナの上で直接CUDA Toolkitを使いたい場合は第456回 で紹介した方法のうち、/usr/local
以下に保存されるNVIDIAのパッケージ版かスクリプト版のインストール方法を使うと良いでしょう。Ubuntu 18.04 LTSのパッケージ版のCUDAドライバーは9.1ベースなので、インストーラーも最新の9.2ではなく9.1を選んでいます。
$ sudo apt install build-essential
$ wget https://developer.nvidia.com/compute/cuda/9.1/Prod/local_installers/cuda_9.1.85_387.26_linux
$ sudo bash cuda_9.1.85_387.26_linux --no-opengl-libs
(NVIDIAドライバーのインストールは不要)
CUDA 9.1はUbuntu 18.04 LTSで使われているGCC 7以降の組み合わせはサポート外のようです。今回は16.04のコンテナを利用していますが、コンテナも18.04を使いたい場合はホストのNVIDIAドライバーのバージョンもあげて、9.2系が動くようにする必要があるでしょう。もしくはgcc-6パッケージをインストールするという手もあります[4] 。
[4] ただし18.04の場合は/usr/bin/gcc
が/usr/bin/gcc-7
へのシンボリックリンクになっている(update-alternativeシステムとは別扱いになる)ため、システム側に手を入れる必要があります。これを考えるとCUDA 9.1を使うなら16.04にしておくほうが無難です。
サンプルコードがホームディレクトリにインストールされているので、それをビルドしてみましょう。
$ cd ~/NVIDIA_CUDA-9.1_Samples/1_Utilities/bandwidthTest/
$ make
うまくビルドできたら、第456回 と同じように実行・テストしてみます。
$ ~/NVIDIA_CUDA-9.1_Samples/bin/x86_64/linux/release/deviceQuery
/root/NVIDIA_CUDA-9.1_Samples/bin/x86_64/linux/release/deviceQuery Starting...
CUDA Device Query (Runtime API) version (CUDART static linking)
Detected 1 CUDA Capable device(s)
Device 0: "GeForce GTX 1050 Ti"
CUDA Driver Version / Runtime Version 9.1 / 9.1
CUDA Capability Major/Minor version number: 6.1
Total amount of global memory: 4040 MBytes (4236312576 bytes)
( 6) Multiprocessors, (128) CUDA Cores/MP: 768 CUDA Cores
GPU Max Clock rate: 1392 MHz (1.39 GHz)
Memory Clock rate: 3504 Mhz
Memory Bus Width: 128-bit
L2 Cache Size: 1048576 bytes
Maximum Texture Dimension Size (x,y,z) 1D=(131072), 2D=(131072, 65536), 3D=(16384, 16384, 16384)
Maximum Layered 1D Texture Size, (num) layers 1D=(32768), 2048 layers
Maximum Layered 2D Texture Size, (num) layers 2D=(32768, 32768), 2048 layers
Total amount of constant memory: 65536 bytes
Total amount of shared memory per block: 49152 bytes
Total number of registers available per block: 65536
Warp size: 32
Maximum number of threads per multiprocessor: 2048
Maximum number of threads per block: 1024
Max dimension size of a thread block (x,y,z): (1024, 1024, 64)
Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535)
Maximum memory pitch: 2147483647 bytes
Texture alignment: 512 bytes
Concurrent copy and kernel execution: Yes with 2 copy engine(s)
Run time limit on kernels: No
Integrated GPU sharing Host Memory: No
Support host page-locked memory mapping: Yes
Alignment requirement for Surfaces: Yes
Device has ECC support: Disabled
Device supports Unified Addressing (UVA): Yes
Supports Cooperative Kernel Launch: Yes
Supports MultiDevice Co-op Kernel Launch: Yes
Device PCI Domain ID / Bus ID / location ID: 0 / 1 / 0
Compute Mode:
< Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) >
deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 9.1, CUDA Runtime Version = 9.1, NumDevs = 1
Result = PASS
うまく認識してくれているようですね。
実際のところ、LXDへのCUDAツールキットのインストールは若干面倒です。そこで次回以降にて、LXDの上でNVIDIA Dockerを実行することでLXDコンテナにはCUDA関連のインストールが不要になる方法を紹介する予定です。