Fork: 0
ikko / glx-docker-headless-gpu
Transfer to URL with SHA Find file
Newer
Older
glx-docker-headless-gpu / README.md
@ikko ikko on 23 Apr 2021 13 KB Update README.md
Raw Blame History

Run Carla and ROS-Bridge in docker container on KVM hosted Server by using GPU passthrough technique

OpenGLやGLXなどを使って画面表示を行うアプリケーションを、画面のないheadlessサーバー上で、しかもDocker内で動かす方法

具体的には、Carlaの環境の構築を目的にしている。

ホストの要件

Nvidia GPUカード1枚が認識できるDockerサーバー

ヘッドレスでの使用を想定しており、例えば、ＧＰＵ付きノートＰＣでの使用は、今のところできない。

ＧＰＵ付きノートでdocker container上でＧＰＵを使い画面描画をしようとすると、ノート上の画面表示に使用してるＧＰＵと重複してしまうため、画面がフリーズしてしまう。 フリーズは画面のみなので、ssh経由では入れるが、使い物にならなくなる。 もし、ノートＰＣで動かしたい場合には、carla0910を使うとよい。 Docker上で動かす場合には、元のcuda-toolkitのバージョンを合わせる必要があるので注意。

下記のマシンでは、Cuda toolkitのバージョンは、リビジョンが違っても動作しないみたいなので、合わせる必要がある。

Dockerfileでは、11.2.2のドライバーをインストールしている。

novnc経由で研究室内で使えるのは、

192.168.100.201:6080

192.168.100.211:6080

192.168.100.221:6080

の3台のみ。

Update: support noVNC

  • noVNCを使用したブラウザからのアクセスは、ポート6080を使用。一般には、vnc.htmlをアクセスし、パスワードを入れれば入れるが、エラーが出る場合（多分、ブラウザのキャッシュの関係だと思う。）もあり、 この場合、vnc_lite.htmlからアクセスするとできる。 ・また、VNC経由の場合には、ポート7000を使用。変更は、run.shをいじれえば、任意のポート番号に変更可能。

Buildするには:

./build.sh

Runするには:

./run.sh

Method

研究室サーバーは、すべて２枚グラフィックカードの構成

  • Nvidia GPUカード２枚
  • Nvidia GPU１枚＋ＣＰＵ内臓グラフィックチップ 基本、１枚目は、ローカルのディスプレイ用に使用。

研究室サーバは、基本、ミニマムインストール＋KVMのインストール GPU passthrough機能を使い、KVMクライアント上で、ＧＰＵを使えるようにする。 ＫＶＭクライアントの設定でＧＰＵを使えるようにする。（ＫＶＭクライアントは、どのバージョン、ＯＳでもインストール可能）

なお、nvidia-smiで表示されるバージョンと、Dockerfileに書かれているスクリプトのバージョンは、合わせる必要がある。

バージョンが上がった場合には、cuda-install-kitのインストールの仕方に合わせDockerfile、build.shを修正する。

1. 研究室サーバーでGPU対応のKVMクライアントへのセットアップ

KVMクライアントへGPUのドライバとnvidia-docker2をインストールする。

sshログインしてnvidia-smiを実行して、GPUが検出されることと、入っているドライババージョンを確認

2. container立ち上げ

X11サーバーとアプリケーションの入ったdocker containerをビルド、立ち上げる。

run.shがdocker内で実行される。

ホストマシンに一度ログインして、nvidia-xconfig --query-gpu-infoを実行し、BUSIDを控えておく。

（startup.sh内で処理済み）

何をしているか

2つの要素が組み合わさってできている。

  • (A) headless GPU server上でGLXアプリを動かす
    GPUを使える仮想ディスプレイを作る。ソフトウェアレンダリングで十分な場合は、xorg xvfb x11vncなどで仮想ディスプレイ環境を作れるが、GPUを使いたい場合はNVIDIAドライバの機能を使う必要がある。
  • (B) docker上でX11サーバーを動かす ポピュラーなDISPLAY /tmp/.X11-unixを共有する方法ではなく、Xorgをコンテナ内で動かす方法。
  • (A+B) headless GPU server上のdocker上でX11サーバーとGLXアプリを動かす 上の2つを合わせれば完成。

順番に解説する。

(A) run GLX apps on headless NVIDIA GPU server

これに関しては解説がいろいろある。

大まかな手順としては

  • Xorg, Nvidia Driverのインストール
  • XorgがGPUを使うようにconfを編集

nvidia-xconfigを使うと、headless環境で仮想displayを使うためのXorg向けの設定を出力できる。しかしコマンド自体のオプションのマニュアルが不足しているので、release noteを読んで確認する必要がある。

(B) X on Docker

X11 GUIアプリケーションをdocker内で動かしたい時、いくつか選択肢がある。

  1. hostのx11 socketの共有 or hostで建てているx serverのアドレスを環境変数DISPLAYで渡す docker run時に-e DISPLAY=$DISPLAYとか-v /tmp/.X11-unix:/tmp/.X11-unixとかを指定するのはこちらのアプローチ。やり方については検索すると出てくるので割愛。 x11 clientだけをcontainer内で動かし、host上で動いているx11 serverに接続して描画してもらう。dockerからは描画命令だけが来るので、例えばGPUを使って実際に描画するのはx11 server側、つまりcontainer外になる。それ以前に、デスクトップ環境を作っていないサーバー上で動かす場合、そのhost上でまずX11サーバーをセットアップする必要がある。 この方法でも、「ローカルのデスクトップ環境上で動かすが、ホストの環境を汚さないためにdocker内でGUIアプリを使いたい」場合や、「サーバーだけど直にX11をセットアップするのを厭わない」場合は十分。
  2. docker内にx11 serverも建てる x11 client, server共にdocker内で動いている。このままでは画面が見えないが、VNCやスクリーンショットの形で出力する。この場合は、実際に描画処理をしているのもコンテナになる。
    • kubernetesやECSなどのコンテナベースのサービスを使っていて、Dockerコンテナの外側の環境に触れない場合
    • host上にX11サーバーをセットアップするのが面倒/できない場合だと、コンテナ内で完結する2の方法を取らざるを得なくなる。例えば DockerでXサーバを動かしてGUIを直接表示する - くんすとの備忘録 はこのアプローチを取っている。基本的にはコンテナ内にXserverとXclientを両方インストールし実行する。

(A+B) GPU-enabled X server on Docker

普通のXアプリなら上の手順で良いが、OpenGLなどグラフィック用途でGPUを使うアプリケーションの場合、

  1. hostのx11 socket共有 NVIDIA Docker で HW accelerated な OpenGL(GLX) を動かす(2019 年版) - Qiita でも触れられているように、 nvidia/opengl - Docker Hub などを使う方法がある。繰り返しになるがこの場合だとレンダリングしているのはホスト側になる。
  2. docker内にx11 serverも建てる この場合の手順について書かれた文章はほとんど見つけることができなかった。今回はこれをやりたい。 コンテナ内にインストールされたXserverがGPUを扱えるように、X用のドライバをインストールする必要がある。

グラフィック系ドライバのdocker内へのインストール

docker内でNVIDIA GPUを扱いたいときは、nvidia-docker2を使うのが普通。これはホストのGPUのデバイスファイルとそのドライバをコンテナと共有し、GPUをコンテナ内側でも使えるようにする技術だが、公式にはCUDA系やOpenGLの一部のみをサポートしていて、グラフィック系のGLX・Xorgからのレンダリング・vulkan等に対応していない( https://github.com/NVIDIA/nvidia-docker/issues/631 )ため、XorgがNVIDIA-GPUを使うためのドライバやGLXのextensionはコンテナと共有されない。

なので、nvidia-docker2の機能でGPUのデバイスファイルを使えるようにし、ドライバはコンテナ内部で1からインストールすることでGLXをコンテナ内で使えるようにできた。

コンテナ内部でドライバをインストールするDockerfileとして、公式の nvidia/driver - Docker Hub とその解説wiki Driver containers (Beta) · NVIDIA/nvidia-docker Wiki) がある。これはNVIDIAのドライバを公式からダウンロードして、インストールスクリプトを実行しているDockerfileだが、前述のようにX系のドライバをインストールを省略している。 https://gitlab.com/nvidia/driver/blob/master/ubuntu16.04/Dockerfile#L43 を見ると

                       --x-prefix=/tmp/null \
                       --x-module-path=/tmp/null \
                       --x-library-path=/tmp/null \
                       --x-sysconfig-path=/tmp/null \

そこでXorgをインストールした後、ドライバインストール時にこのオプションをきちんと設定して、X用のグラフィックドライバをインストールさせる。これが終われば、ホストのGPUサーバー上でXorgを動かすのと全く同様に、dockerコンテナ内でXorgを(GPU込みで)動かすことができるようになる。

あとは(A)と同じで、(A)のコマンドで作ったxorg.confをコンテナ内に設置して、Xorg &でサーバーを走らせれば動く。

各種ソフトウェア

xorg

X11サーバーの1つの実装。

Xorg :0とするとサーバーが立ち上がる。

例えばx11-appsを入れてDISPLAY=:0 xeyesとすると目玉のテストアプリケーションが立ち上がる。

UbuntuでNVIDIAのディスプレイドライバが動作しない場合のチェック項目 - Qiita が参考になる。

lspci | grep NVIDIA

  • 設定ファイル /etc/X11/xorg.conf
  • ログファイル /var/log/Xorg.0.log
  • /usr/lib/xorg/modules/drivers ドライバ
  • /usr/lib/xorg/modules/extensions glxのエクステンションなど

テスト用X11アプリ

  • xeyes Xサーバーが動いているか？
  • glxgears, glxinfo GLXが使えるか？
  • vulkan-smoketest vulkanが使えるか？

x11vnc

起動しているx11 serverの画面をそのままvncで飛ばすソフトウェア。実際のdisplayが繋がっている場合はその画面が、仮想displayの場合はその中身が転送される。

ずっと起動しておく -forever

ポート変更 x11vnc -rfbport 5566

virtualGL

実際にアプリケーションを表示したいXサーバーのアドレスを:0、GPUにアクセスできるXサーバーのアドレスを:1とする。

DISPLAY=:0 VGL_DISPLAY=:1 vglrun glxgears

とした場合、アプリケーションのレンダリング命令が:1に行き、そのレンダリング結果が画像としてキャプチャされ、:0に送られる。これは通常通り

DISPLAY=:0 glxgears

とした時に、GPUにアクセスできないXサーバー(例えばこれはssh -Xで転送されたクライアントのXサーバーなど)側にレンダリング命令が来てGPUを活用できない状況をパフォーマンス面で改善できるが、実際に:0から見える結果は全く同じになる。

xvfb

仮想ディスプレイを作るソフト。 ただしGPUは使わない。ソフトレンダリングのみならこれで十分。

nvidia-xconfig

Xサーバーがnvidia gpuを使えるように

nvidia-xconfig --query-gpu-info

X周りの要素技術についてのまとめ

おっさんエンジニアの実験室: 12月 2016