Closed sbrugman closed 8 years ago
mnist example could work, but MaxPooling in Torch has no ceil max-pooling on CPU, only floor. Some particular networks might work, but I don't know any.
hi,
i tried to use vgg16 model, which has MaxPooling layer --> that means only cuda support (where i can choose engine ccn2/cudnn/inn). btw1, does inn have cuda support only ? btw2, i'm pretty sure max-pooling can be implemented in cpu mode using nn layers only. It can be done by concatenating nn.Padding layer with nn.MaxPooling. Am i right ?
@yossibiton most of inn modules have only cuda support. not sure about nn.Padding, the output might be different on the borders. It is very easy implement by copy-pasting nn.MaxPooling's CPU code and substituting floor with ceil. It's just we didn't want to mix cuda and cpu code in inn. Don't know where to put ceil max-pooling cpu code.
Since https://github.com/szagoruyko/loadcaffe/commit/e39087fb93cced83e2bb896038eba3a60cd16968 loadcaffe
supports CPU mode (nn
and cunn
have ceil
mode in SpatialMaxPooling
now).
If you don't have cuda working it still fails as it tries to load 'cunn' instead of 'nn'. I patched that in my fork, but it seems like 'inn' is also trying to load cuda so now it's failing on that end. In the case of 'nn' backend, only the 'LRN', 'SpatialAveragePooling', and 'SpatialStochasticPooling' layers seem to require 'inn', which for example for the VGG19 are not needed. Not sure if it's worth detecting first if those layers are there to see if 'inn' is needed or not... I did disable adding the "require 'inn'" (in addition to my patch for 'nn' instead of 'cunn') locally and have managed to load the VGG19 into CPU.
@bobbens I tried using your fork to install loadcaffe with CPU only support. To do so, I removed everything but NN in the PACKAGE_TYPE list in loadcaffe.cpp, and removed the 'cunn' and 'inn' dependencies from the loadcaffe-1.0-0.rockspec file.
Still I get a plethora of error messages when I try to build from the patched rock, starting with:
172-17-52-222:loadcaffe-master olivierhenaff$ luarocks build loadcaffe-1.0-0.rockspec Cloning into 'loadcaffe'... remote: Counting objects: 18, done. remote: Compressing objects: 100% (17/17), done. remote: Total 18 (delta 0), reused 9 (delta 0), pack-reused 0 Receiving objects: 100% (18/18), 19.41 KiB | 0 bytes/s, done. Checking connectivity... done. cmake -E make_directory build; cd build; cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH="/Users/olivierhenaff/torch/install/bin/.." -DCMAKE_INSTALL_PREFIX="/Users/olivierhenaff/torch/install/lib/luarocks/rocks/loadcaffe/1.0-0"; make
-- The C compiler identification is AppleClang 5.1.0.5030038
-- The CXX compiler identification is AppleClang 5.1.0.5030038
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found Torch7 in /Users/olivierhenaff/torch/install
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
-- Found PROTOBUF: /usr/local/lib/libprotobuf.dylib
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/luarocks_loadcaffe-1.0-0-3152/loadcaffe/build
[ 33%] Running C++ protocol buffer compiler on caffe.proto
Scanning dependencies of target loadcaffe
[ 66%] Building CXX object CMakeFiles/loadcaffe.dir/loadcaffe.cpp.o
/tmp/luarocks_loadcaffe-1.0-0-3152/loadcaffe/loadcaffe.cpp:155:17: error: no member named 'emplace_back' in
'std::vectorstd::pair<std::basic_string<char, std::basic_string
It seems as though the statement (cuda_package_type == CCN2) is showing up as true, despite the patch. Is there anything else that I must modify for this to be false?
Thanks in advance,
Olivier
@olivierhenaff For compilation I did have to install CUDA even though I don't have a CUDA-capable GPU on that system.
@bobbens Thanks for your response. I installed CUDA, and tried building your fork again with only the 'require inn' removed from the rockspec file. Still, it fails, complaining about the loadcaffe.cpp.o file. I am running this on CentOS, could that be an issue here?
Here is the error log:
[root@basilio loadcaffe-master]# luarocks build loadcaffe-1.0-0.rockspec Initialized empty Git repository in /tmp/luarocks_loadcaffe-1.0-0-9890/loadcaffe/.git/ remote: Counting objects: 18, done. remote: Compressing objects: 100% (17/17), done. remote: Total 18 (delta 0), reused 9 (delta 0), pack-reused 0 Receiving objects: 100% (18/18), 19.41 KiB, done. cmake -E make_directory build; cd build; cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH="/usr/local/bin/.." -DCMAKE_INSTALL_PREFIX="/usr/local/lib/luarocks/rocks/loadcaffe/1.0-0"; make
-- The C compiler identification is GNU 4.4.7
-- The CXX compiler identification is GNU 4.4.7
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found Torch7 in /usr/local
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found PROTOBUF: /usr/lib64/libprotobuf.so
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/luarocks_loadcaffe-1.0-0-9890/loadcaffe/build
[ 33%] Running C++ protocol buffer compiler on caffe.proto
Scanning dependencies of target loadcaffe
[ 66%] Building CXX object CMakeFiles/loadcaffe.dir/loadcaffe.cpp.o
cc1plus: error: unrecognized command line option "-std=c++11"
make[2]: * [CMakeFiles/loadcaffe.dir/loadcaffe.cpp.o] Error 1
make[1]: * [CMakeFiles/loadcaffe.dir/all] Error 2
make: *\ [all] Error 2
Error: Build error: Failed building.
@olivierhenaff your compiler is ancient, install gcc 4.8 or higher
@olivierhenaff if you are using our unfortunate clusters at NYU, which have CENTOS6, I recommend closing your nose and quickly compiling gcc 4.9 using: https://github.com/jlinoff/gcc-4.9.2-boost-1.57 And in your bashrc, setting CC, CXX, PATH and LD_LIBRARY_PATH to the appropriate things in the new and shiny gcc 4.9
Hi, I'm trying to load some models that are supposed to have support for 'nn' and so far all fail e.g.
net = loadcaffe.load('./VGG_CNN_S_deploy.prototxt', './VGG_CNN_S.caffemodel', 'nn')
Successfully loaded /home/user/bin/caffe/models/VGG_CNN_S.caffemodel
/home/user/torch/install/share/lua/5.1/trepl/init.lua:363: module 'cunn' not found:No LuaRocks module found for cunn
I'm working on system with no nvidia card, so installing cunn
is no option.
@sidec, you can remove the "require 'cunn'" and "require 'inn'" from the generated "*.prototxt.lua" file and then run the code from the line:
local model = dofile(lua_name)
@szagoruyko, perhaps the "nn" backend should not allow the use of "inn" and "cunn" - or perhaps there should be a "cpu" or "nn-cpu" backend that only allows cpu-only usage? I would be interested in making a patch if you would be satisfied with either of these solutions.
@williford There will soon be no need of inn
in loadcaffe
. Indeed, SpatialAveragePooling with ceil
mode and SpatialCrossResponseNormalization will soon be integrated to main nn
, which will make most of inn
requirements unnecessary.
@fmassa that's great news. It looks like cunn is not being used. Would it be safe to remove the lines with: ofs << "require 'cunn'\n";
?
@williford I think this can be removed, and only included when using a CUDA backend like cudnn
or ccn2
.
The thing is, only a limited subset of the available models work on current nn
branch, like VGG. AlexNet doesn't work (because it SpatialConvolution
lacks groups, and the SpatialCrossResponseNormalization
PR wasn't merged yet). So I don't know if we are really ready to remove the cunn
dependency now.
Can someone please help me with running loadcaffe in CPU only mode? Or right now, there is no way that loadcaffe would work without GPU support. Don't have CUDA installed neither cunn, cudnn inn.. as they all fail while building, trying to find one of the CUDA dependencies.
CPU support is there since https://github.com/szagoruyko/loadcaffe/pull/32
How to handle models that contains "groups" in conv layers in order to make prediction in CPU mode alone?
Is there a way to use loadcaffe CPU only? When running the MNIST example the following errors occur:
modprobe: FATAL: Module nvidia not found. /home/user/torch/install/bin/luajit: /home/user/torch/install/share/lua/5.1/trepl/init.lua:319: /home/user/torch/install/share/lua/5.1/trepl/init.lua:319: /home/user/torch/install/share/lua/5.1/trepl/init.lua:319: /home/user/torch/extra/cutorch/lib/THC/THCGeneral.c(9) : cuda runtime error : no CUDA-capable device is detected