Add GPU schedule for Blur (targeted GTX 970)

[darkbuck]

Add GPU schedules based on different strategy for blur.

[abadams]

I'm a fan of improvements to the blur schedule, but I disagree with the new gpu_tile overloads. I think they do too much in one call. I'd prefer people just say .tile(x, y, xi, yi, 2, 2).gpu_tile(x, y, 8, 8) to get that kind of nested tiling. I also think that you typically want the thread axis to be the innermost (apart from the vectorization) to get dense loads. So for a 16-bit type the sort of schedule I'd use is something like:

.vectorize(x, 2)
.tile(x, y, xi, yi, 32, 2)
.tile(x, y, xo, yo, 2, 8)
.gpu(x, y, xi, yo)

That says (or at least is intended to say) that each thread does a 2x2 block of work, the work done by one thread is adjacent in y, but separated by 32x2 elements (one full cache line) in x. E.g. thread tx, ty in block 0, 0 takes care of four pairs of elements: ([2tx, 2tx+1], 2ty) ([2tx+64, 2tx+65], 2ty) ([2tx, 2tx+1], 2ty+1) ([2tx+64, 2tx+65], 2ty+1) I think that makes all the loads and stores dense across the warp.

[darkbuck]

I see your pointer to schedule innermost outwards while most CPU schedule is made outermost inwards. That will make the current GPU interface more straight-forward. That's fine as that's just short-cut and won't matter too much as long as people figure out the difference between optimal GPU and CPU schedules.

I rewrote the schedule following your point. They achieve the same code generation and performance. Shall we merge the GPU schedule example for blur?

[abadams]

Our usual convention for chaining scheduling calls across multiple lines is to not repeat the Func name:

blur_y.split(...)
    .reorder(...)
    .unroll(...)
    .gpu_tile(...);

[abadams]

Yeah, looks good. Just one style nit.

[darkbuck]

Sure, style is revised.