A certain engineer "COMPLEX"

開発メモ136 Windows 10 Ver1803で起動しなくなったCentOS on Hyper-Vを復旧する

Introduction


Windows 10 April 2018 Update (Ver.1803) のマシンにおいて、Hyper-V上のLinux仮想マシンが起動しない現象が発生した。
こんな感じになります。

具体的に起動しないマシンは、

  1. 1803で新規に作成したマシン (世代1で作成)
  2. 1803より前の環境で作成し、1803にVHDをコピーして再作成したマシン (世代1で作成)

という条件である。
要するに世代1で作成するのが不味かったのだが、既存の資産が動いているレガシーなLinuxだとそうも言っていられない。

これが会社のマシンで起こり、自宅の環境でも再現してしまったので、解決策を模索した。

Resolution


Google先生に聞いても、この現象に遭遇している人がいなかった。
なので、自分で探すこと1週間。解決のきっかけに気づいたのは、イベントビューアを見ていたときである。

Microsoft-Windows-Hyper-V-Worker-Admin に奇妙なログが記載されていた。


仮想マシン %1 でデバイス %3 を読み込むことができません。相互にサポートされているプロトコル バージョンがありません。サーバー バージョンは %4 で、クライアント バージョンは %5 です (仮想マシン ID %2)。

どうも、問題のマシンを立ち上げた時に記録されている模様。
これを見て思ったのは、グラフィック系統のデバイスが正しく読み込まれていないから、起動時におかしな画面に陥るのでは?と推測。
だから、起動時にグラフィック表示をなくせば起動できるのでは?と予想。

試したところ、ビンゴでした。
下記のOSは CentOS 6.10 ですが、手順はどのOSでも似たようなものかと。

1. 起動

下記の画面でキーを押下して、メニューに入ります。

2. GRUB

下記のメニューが表示されたら a を押下して、カーネルの引数を編集する画面に入ります。

3. カーネル引数の編集

OSの状態によって評される文字列が異なります。
例えば、下記はOSをインストールした直後になります。

下記はOSをインストールして、初期ユーザの設定が終わった以降になります。

どちらでも共通に存在する rhgb quiet を削除し、Enterキーを押下し、ブートを再開します。

4. 無事に起動

一瞬、画面が乱れた問題になった画面が表示されますが、少し待つとブートが継続されます。

5. 永続化

ここまでの方法はその場限りで再起動すれば戻ってしまいます。
なので、GRUBの設定ファイルを編集することで設定を永続化します。
無事にログインしたら、シェルから設定ファイルを編集します。

編集ファイルを開くと下記のような状態です。

これを下記のように編集します。
わかりにくいですが、先述のように、rhgb quietを削除するだけです。

これで設定が永続化されます。

ただし、これらを行っても、たまに起動に失敗することがあります。
その時はリセットボタンで再度ブートをやり直します。

開発メモ135 OpenCVに組み込んだlibjpeg-turbo 1.5.3と2.0.0を比較

Introduction


前回の続き。

Introduction掲題そのまま。結構、このネタはそこら辺に転がっているんだけど、 計測していない エンコードだけ計測みたいなネタでげんなりしたので自分で実施し...

libjpeg-turboに2.0.0が登場しているため、1.5.3との性能を比較します。

Condition


条件は前回とほとんど変わりません。
違うのはリンクするlibjpeg-turboが2.0.0になっただけです。

  1. Intel Cire i7-8700 (3.20GHz)
  2. 32.0GB
  3. Visual Studio 2017 Update 7 (15.7)
  4. OpenCV 3.2.0 (動的リンク、world形式でビルド。IPP、CUDAは除外)
  5. libjpeg-turbo 2.0.0
  6. libjpeg-turbo.libをリンク

Test


実験も前回と同様、3種の画像、エンコードとデコードを計測します。
計測対象は下記。

  1. libjpeg-turbo 2.0.0 自家製ビルドOpenCV
  2. libjpeg-turbo 1.5.3 自家製ビルドOpenCV

また、実験ソースも前回と変わりません。
生成されたopencv_world320.dllを差し替えるだけです。

Result

実験結果は下記になります。
速度はいずれも平均速度です。

Decode

 640x3601280x7202560x1440
2.0.01.05651 ms4.67864 ms25.9939 ms
1.5.31.16508 ms5.11916 ms28.0259 ms
Improvement+10%+9%+7%

Encode

 640x3601280x7202560x1440
2.0.01.15707 ms4.3723 ms17.9123 ms
1.5.31.37863 ms5.03018 ms20.6569 ms
Improvement+19%+15%+15%

Conclusion

劇的な改善はありませんが、着実に性能が向上しています。

開発メモ134 OpenCVにlibjpeg-turboをリンクして性能比較

Introduction


掲題そのまま。
結構、このネタはそこら辺に転がっているんだけど、

  1. 計測していない
  2. エンコードだけ計測

みたいなネタでげんなりしたので自分で実施してみました。

実験ソースは下記になります

Sample source code for Demonstration, Experiment and Test - takuya-takeuchi/Demo

Condition


条件は下記になります。

  1. Intel Cire i7-8700 (3.20GHz)
  2. 32.0GB
  3. Visual Studio 2017 Update 7 (15.7)
  4. OpenCV 3.2.0 (動的リンク、world形式でビルド。IPP、CUDAは除外)
  5. libjpeg-turbo 1.5.3
  6. libjpeg-turbo.libをリンク

になります。
また、libjpeg.liblibjpeg-turbo.libのどちらをリンクするかで意見が割れていますが、ここではlibjpeg-turbo.libをリンクしました。

OpenCVのビルドのためのCMakeのコマンドは下記のようになります。

libjpeg-turbo 有効

libjpeg-turbo 無効

Test


実験は、

  1. libjpeg-turbo有効の自家製ビルドOpenCV
  2. libjpeg-turbo無効の自家製ビルドOpenCV
  3. 公式のOpenCVバイナリ

に対して比較します。
また、画像は、

  1. 640x360
  2. 1280x720
  3. 2560x1440

の3種類を用意し、それぞれのデータのデコードとエンコードを1000回繰り返します。

実験ソースは下記です。
ベースとして、下記のページを参考にさせていただきました。

Result

実験結果は下記になります。
速度はいずれも平均速度です。

Decode

 640x3601280x7202560x1440
Enable libjpeg-turbo1.16508 ms5.11916 ms28.0259 ms
Disable libjpeg-turbo2.15667 ms9.02238 ms40.7576 ms
original binary2.44517 ms10.1288 ms46.2685 ms

Encode

 640x3601280x7202560x1440
Enable libjpeg-turbo1.37863 ms5.03018 ms20.6569 ms
Disable libjpeg-turbo5.18752 ms19.4827 ms83.4678 ms
original binary5.69063 ms21.4501 ms91.6039 ms

Conclusion

エンコード性能は著しい改善を見せており、3.5-4.0倍の速度をたたき出しています。
デコードも、1.6-2.2倍の速度と良い感じです。

高々数十msの違いかもしれませんが、OpenCVのVideoCapture等でWebカメラをキャプチャした際、MotionJPEG形式ならデコード処理がそのままfpsに跳ね返ってきます。
1280X720で従来20ms要していたということは、30fpsのカメラでも事実上、1フレームに33ms+20msの53ms、つまり20fps程度しか性能が出なかったことになります。
これが5msになれば、33ms+5msの38msなら26fpsと改善できます。

Source Code

https://github.com/takuya-takeuchi/Demo/tree/master/libjpeg-turbo-decode

開発メモ132 Visual Studio 2017 15.7 に CUDA 9.2 をインストールする

Introduction


CUDA Toolkitには、Visual Studioと統合されるVisual Studio Integrationが含まれています。
しかしながら、このツール、Visual Studioのバージョンをチェックしているのか、2018/09/01現在、最新のCUDA Toolkit、cuda_9.2.148_win10.exeでもインストールに失敗します。
というのも公式にも対応しているのは、Visual Studio 2017 15.6となっており対応していないことがうかがえます。
既に、15.8の登場が控えている状況でこれは非常にまずいです。

ということでその対応。

Resolution


公式のフォーラムでもこの問題は話題になっています。
Nvidiaの対応に不満の声が。

そんな中、下記のスレッドのinstalling CUDA 9.2 with VS2017 integration worked for me this way:と言う投稿で対応策が提示されました。

要点は、

  1. cuda_9.2.88_win10.exeをWinRARとかで展開
  2. CUDAVisualStudioIntegration\CUDAVisualStudioIntegration.nviを書き換える
  3. setup.exeを実行
  4. C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\include\crt\host_config.hを書き換える

です。
私の試した手順だと、

  1. cuda_9.2.88_win10.exeを実行し、インストーラを起動して最初の画面で待機
  2. CUDAVisualStudioIntegration.nviを書き換える
  3. インストール続行
  4. C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\include\crt\host_config.hを書き換える

でOKでした。

少し具体的に書くと、

CUDAVisualStudioIntegration.nvi を書き換える

インストーラを起動してから書き換える場合は、"%TEMP%\CUDA\CUDAVisualStudioIntegration\CUDAVisualStudioIntegration.nviが書き換える対象です。
そして、テキストエディタでCUDAVisualStudioIntegration.nviを開き、下記の箇所を削除します。

host_config.h を書き換える

インストール完了後、C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\include\crt\host_config.hを書き換えます。
これを書き換えないと、CUDAを使ってコンパイルする際にエラーが出てコンパイルが停止します。
130行目付近の

を、下記のようにします。