Producing Denser SiftGPU points - at the expense of time and RAM

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.

"... 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

Compiling OTB with CUDA - on Windows 7

I discussed some OTB-CUDA experiments that had been done with Emmanuel. The experiments tell the age old story of bandwidth pay-off versus speed. If your problem is too simple the performance gain from CUDA is not going to be much, they did one of the first tests with specifically Remote Sensing type computations of various complexity. Amdahl's law is fairly intuitive and even embarassingly parallel problems that we encounter in raster processing can not break the curse of sequential segments.

In GPGPU computing one of the core tweaks is in the kernel size and computational complexity. You don't want to be performing CPU to GPU transfers all the time for the GPU to perform a very simple operation no matter however fast, on the other hand GPU's are rather constrained in the complexity of operations they can carry out and will always need assitance from the CPU in loading data from the disk etc.

The OTB GPGPU experiment had not been extensively tested on Windows, so I decided to compile it with latest offering from Microsoft - MSVC Express 2010. As penalty for being on the bleeding edge Nvidia CUDA and OpenCL don't work on 2010, so I had to time warp back to 2008. Even then the OTB-CUDA code needs some porting due to missing timing code, may be the sample here will provide some inspiration.

AMD vs NVIDIA and some NESTing for SAR

While nVIDIA provides backward compatible OpenCL drivers. AMD in opposition to nVIDIA who supports DirectCompute even in GeForce 8 series (8400 GT and up) for a long time ago, forgets about older than HD5000 series. I managed to get OpenCL eigenvalues kernel tested on my other machine but fell flat on my laptop with a 3670 ATI.

Some work by Orfeo Toolbox guys has recorded large performance gains in non-trivial (i.e not pixel by pixel) operations using GPU options. The eigenvalue problem is typical in SAR analysis and I would like to implement it on the GPU.

Talking about SAR, first there was BEST (Basic ESA SAR Toolbox), now ESA is funding development of NEST (Next ESA SAR Toolbox). The product so far looks impressive , Java based pulling in all the goodies including NASA WorldWind. There are plans afoot to include the DORIS InSAR processor as well.

DORIS as such is very script based and difficult to use properly. Hopefully providing and easy interface will open-up more INSAR processing options.

Economics of Chip Making - cut throat market

There was a very old story I was told once about 3 chips that could be - Zilog Z80, Motorola 68000 and the pre-maturely born Intel 8086. The early release, familiar instruction set and price gave 8086 such a boost that we still have it around.
Given all the publicity about AMD - Intel rivalry it is interesting to follow what works in this arena. AMD had to split up design and manufacture, Intel might be following suit. Motorola spun off Freescale long long time ago.
Problem then as in now is the familiarity and usability of the instruction sets and the chips, the efficiency and transparecy with which silicon is exposed to the neurons. I researched some more on the new instruction set on the block, the GPGPU. I wish I could tag cloud the projects using Nvidia Cuda vs those using ATI Stream, but here is the googlebattle result , Cuda is nearly twice as much used as ATI stream.
There are some heavy-weights putting in behind Cuda, the very hot Lapack creators making MAGMA, with blessings from Mathworks and Microsoft. Microsoft itself making a GPU computing extension in Windows 7/ DX11. Not to mention GPULib from Tech-X, which has led to some very interesting experiments in remote sensing image processing. The core of all this comes down to my laptop having only an ATI Radeon and no decent GPGPU capability to play with, best of luck to AMD getting its house in order.