Actually, vectorization may be one use case where edge replication is
useful, even when processing tiles. At least that's where I ran into
problems earlier today when trying very narrow tiles.

Or is there an alternative to clamping the guarantee correct vectorized
code?


On Mon, Dec 16, 2013 at 7:09 PM, Zalman Stern <notifications@github.com>wrote:

> In src/Buffer.h:
>
> > @@ -180,6 +180,15 @@ class Buffer {
> >          return contents.ptr->buf.extent[dim];
> >      }
> >
> > +    /** Set the extent of this buffer. */
> > +    void set_extent(int e0, int e1 = 0, int e2 = 0, int e3 = 0) {
> > +        assert(defined());
> > +        contents.ptr->buf.extent[0] = e0;
> > +        contents.ptr->buf.extent[1] = e1;
> > +        contents.ptr->buf.extent[2] = e2;
> > +        contents.ptr->buf.extent[3] = e3;
> > +    }
>
> This is a longer discussion, but the issue is that Halide::clamp(x, 0,
> in.width()-1) establishes an edge replication boundary condition on x.
> (Being very clear for others who may be reading that in.width() means
> in.extent(0) and we are assuming we're working with dimension 0 of in here.)
>
> When processing tiles, one does not want edge replication at the tile
> boundaries but rather one wishes to require the input tiles have enough
> padding to satisfy the requested output area. (And if that area extends off
> the edge of the image, then apply the boundary condition at the image
> edge.) It should be an error in most cases if tiled processing reads
> outside of the input tiles at coordinates that are not at the edge of the
> of the entire image.
>
> Now we can say that images, by convention, always have a 0 origin and that
> makes the 0 boundary generally the correct place to apply the boundary
> condition. However the extent (width if talking about dimension 0) is only
> correct for applying the boundary condition if we pass in the entire image.
>
> I started writing up a lot of stuff on this a long time ago and Andrew and
> Jonathan and I have talked about it more than once. With Halide as it
> stands now, the best solution is likely to pass the total image area
> (extent and possibly origin) as extra parameters to the filter. One could
> possibly also make it an implicit global using user_context or some such,
> though I'm not sure that wins anything other than allowing filter
> signatures to stay the same if adding this functionality. It is however
> clear that we should consider extending Halide to handle this cleanly.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/halide/Halide/pull/215/files#r8375279>
> .
>



-- 


Daniel Heck | Software Engineer | dheck@google.com | +49(451)37089-285

Google Germany GmbH
Maria-Goeppert-Str.3
23560 Lübeck
Deutschland

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores