One of the old adages I learnt doing CS was that you can not optimise everything - there is always a trade-off between speed and RAM (and sometimes accuracy). If you solve a problem faster then there will be a bigger problem that cannot be solved by your faster method. GPU computing seems to suffer from this scalability problem a fair bit mainly due to limited GPU Memory. In some cases there can also be issues with numerical stability. There is a fine line between Amdahl's law and Gustafson's law.
The latter is actually more fun since large problems have a patently real world feel. While playing around with large collection of aerial and terrestrial photography we found that SiftGPU seemed to be producing similar amount of key points no matter how big an image we threw at it and asked it operate at lower octaves to take advantage of the higher resolution. A bit of code inspection later I found the usual collection of magic numbers designed to prevent memory overflows ( if you have 60+GB RAM and some Teslas the magic numbers are too small). For posteriry here are the hard limits you can unsafely raise if your hardware can take a thrashing.
//hardware parameter, automatically retrieved
int GlobalParam:: _texMaxDim = 12800; //Maximum working size for SiftGPU, 3200 for packed
int GlobalParam:: _texMaxDimGL = 16384; //GPU texture limit
int GlobalParam:: _texMinDim = 16; //
int GlobalParam:: _MemCapGPU = 0;
int GlobalParam:: _FitMemoryCap = 0;
int GlobalParam:: _IsNvidia = 0; //GPU vendor
The large aerial frames were defaulting to octave 3 silently, running them at octave 0 produced 500k SIFT features per frame (yes that is ridiculously huge, but these cameras are ridiculously good). With greater number of features you can perform sparse bundle adjustment using more restrictive angle range constraints and more accuracy.
Bundle adjusment has also had a recent boost from the release of Google Ceres library. This has been suitably adapted to allow faster solution of general multi-camera problems. Asteroids seem to be on everyone's mind.
The latter is actually more fun since large problems have a patently real world feel. While playing around with large collection of aerial and terrestrial photography we found that SiftGPU seemed to be producing similar amount of key points no matter how big an image we threw at it and asked it operate at lower octaves to take advantage of the higher resolution. A bit of code inspection later I found the usual collection of magic numbers designed to prevent memory overflows ( if you have 60+GB RAM and some Teslas the magic numbers are too small). For posteriry here are the hard limits you can unsafely raise if your hardware can take a thrashing.
//hardware parameter, automatically retrieved
int GlobalParam:: _texMaxDim = 12800; //Maximum working size for SiftGPU, 3200 for packed
int GlobalParam:: _texMaxDimGL = 16384; //GPU texture limit
int GlobalParam:: _texMinDim = 16; //
int GlobalParam:: _MemCapGPU = 0;
int GlobalParam:: _FitMemoryCap = 0;
int GlobalParam:: _IsNvidia = 0; //GPU vendor
The large aerial frames were defaulting to octave 3 silently, running them at octave 0 produced 500k SIFT features per frame (yes that is ridiculously huge, but these cameras are ridiculously good). With greater number of features you can perform sparse bundle adjustment using more restrictive angle range constraints and more accuracy.
Bundle adjusment has also had a recent boost from the release of Google Ceres library. This has been suitably adapted to allow faster solution of general multi-camera problems. Asteroids seem to be on everyone's mind.
- "... for it is now clearly shown that the orbit of a heavenly body may be determined quite nearly from good observations embracing only a few days; and this without any hypothetical assumption."
- - Carl Friedrich Gauss
No comments:
Post a Comment