DIGITS 3.0では、リポジトリを登録してインストールを実行すると、DIGITSとCaffe(caffe-nv)等の関連するいくつかのパッケージがインストールされるようになりましたが、勘違いからDIGITS 3.0と一緒にインストールされたCaffeが、動作しなくなっていました。
(2016/5/21追記)
この記事は、当初のcaffe-nv 0.14.2-1に関する記事です。以下の記事のように、アップデートされたcaffe-nv 0.14.5-2+cuda7.5は、CUDA 7.5とcuDNN 5(cuDNN v5)にリンクされています。
勘違い
ブログ記事の順番とは異なりまりますが、CUDA 7.5とDIGITS 3.0のパッケージをインストールした後、CUDA 7.5とcuDNN 4に対応したTensorFlow 0.7.1のインストールやChainer 1.7.0へのアップグレードを行っていました。
CUDA 7.5とDIGITS 3.0のパッケージをインストールした後、/usr/local/には、cuda-6.5、cuda-7.0及びcuda-7.5のディレクトリがあり、cuda-7.5ディレクトリがcudaディレクトリにシンボリックリンクされていました。また、.bashrcにも下記を記載していました。
export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH
パッケージとしてインストールしたDIGITS 3.0のCaffe(caffe-nv)も、当然CUDA 7.5とcuDNN 4に対応していると思っていました。
前回の記事「Caffe Demosをローカル環境に立ち上げてみた」では、DIGITS 3.0のCaffeで動作させたかったのですが、libcudart.so.7.0関係のエラーが出て、動作しなくなっていました。
なぜ、libcudart.so.7.5ではなくて、libcudart.so.7.0?
lddで/usr/lib/python2.7/dist-packages/caffe/_caffe.soにリンクされているライブラリを確認してみたところ、CUDA 7.5のライブラリではなく、CUDA 7.0のライブラリにリンクされていました。
DIGITS 3.0のCaffe、CUDA 7.5にリンクされていません
CUDA 7.0に関して、思い出したことがあります。/etc/ld.so.conf.d/にcuda-7-0.confがあり、何かの残骸だろうと思って、cuda-7-0.confをホームディレクトに移動していました。
cuda-7-0.confを/etc/ld.so.conf.d/に戻して、ldconfigを実行します。
$ cd /etc/ld.so.conf.d/ $ sudo mv ~/cuda-7-0.conf . $ sudo ldconfig
以下を実行して、テストを行います。
$ cd $ python >>> import caffe
エラーは、発生しなくなりました。
Caffe Demos
DIGITS 2.0の環境を利用して、VirtualenvではないCaffe Demosの環境を準備します。
requirements.txtの中身は、werkzeug,flask,tornado,numpy,pandas,pillow,pyyamlとなっています。
$ sudo pip install -r ~/digits-2.0/caffe/examples/web_demo/requirements.txt
以下を実行して、デモサーバを起動します。
$ python ~/digits-2.0/caffe/examples/web_demo/app.py -g
DIGITS 3.0のCaffeでも、デモサーバを起動することができました。