[Liboil] 2D convolution with Orc

[David Schleef]

On Sun, Oct 17, 2010 at 05:44:15PM +0100, jcupitt at gmail.com wrote:
> Hi all,
> 
> I've been tinkering with Orc trying to make a 2D convolution. It seems
> to me that I'll need to use loadoffb to get the scattered pixel values
> from my source array, but the 'off' part needs to be a parameter or
> constant. This means (I think) that I need to pass in the offset for
> every array element as a separate parameter.
> 
> This wouldn't be too bad for a 3x3 I guess, but for larger matrices I
> wonder if this will start to be rather slow. Is there a way to
> calculate the offset in my Orc code instead? Or perhaps I'm missing a
> much better way to do this.

This is an area I'm actively working on.  Right now, the best you can
do is about 3x3, using 3 separate source arrays and loadoff[bwl].  This,
combined with a multiplication value for each element, uses a lot of
constants, which are limited to 16 right now.  (It uses either 9+2 or
9+6, depending on how the constants get folded.)

The short term development goal is to make it possible to use lots of
constants.  (Unlimited, like a normal API.)  This get you up to about
4x4 or 5x5 before other limits before hitting other Orc limits, including
getting bored typing in all the opcodes for each element.  My goal is
to implement the 1-D 8-tap wavelet filter in schroedinger.

The longer term goal is to implement convolution as an opcode directly.
Implementing this depends on having a new "table" type for the
coefficients.  For example, a 3x3 convolution load opcode would take a
source array and a 3x3 table (either constant, or parameter), and
calculate the convolution.  This has the advantage of being able to
flexibly generate code that minimizes loads (i.e., array tiling).  And,
of course, a constant table can allow some automatic common subexpression
elimitation.

So I suppose the short answer is "soon, but not now".



David