RDom::RDom(ImageParam p) { static string var_names[] = {"x$r", "y$r", "z$r", "w$r"}; std::vector<ReductionVariable> vars; for (int i = 0; i < p.dimensions(); i++) { ReductionVariable var = { p.name() + "." + var_names[i], p.min(i), p.extent(i) }; vars.push_back(var); } dom = ReductionDomain(vars); init_vars(p.name()); }
RDom::RDom(ImageParam p) { Expr min[4], extent[4]; for (int i = 0; i < 4; i++) { if (p.dimensions() > i) { min[i] = 0; extent[i] = p.extent(i); } } string names[] = {p.name() + ".x$r", p.name() + ".y$r", p.name() + ".z$r", p.name() + ".w$r"}; dom = build_domain(names[0], min[0], extent[0], names[1], min[1], extent[1], names[2], min[2], extent[2], names[3], min[3], extent[3]); RVar *vars[] = {&x, &y, &z, &w}; for (int i = 0; i < 4; i++) { if (p.dimensions() > i) { *(vars[i]) = RVar(names[i], min[i], extent[i], dom); } } }
Func build() { // Define the Func. Func brighter("brighter"); brighter(x, y, c) = input(x, y, c) + offset; // Schedule it. brighter.vectorize(x, 16); // We will compile this pipeline to handle memory layouts in // several different ways, depending on the 'layout' generator // param. if (layout == Layout::Planar) { // This pipeline as written will only work with images in // which each scanline is densely-packed single color // channel. In terms of the strides described in lesson // 10, Halide assumes and asserts that the stride in x is // one. // This constraint permits planar images, where the red, // green, and blue channels are laid out in memory like // this: // RRRRRRRR // RRRRRRRR // RRRRRRRR // RRRRRRRR // GGGGGGGG // GGGGGGGG // GGGGGGGG // GGGGGGGG // BBBBBBBB // BBBBBBBB // BBBBBBBB // BBBBBBBB // It also works with the less-commonly used line-by-line // layout, in which scanlines of red, green, and blue // alternate. // RRRRRRRR // GGGGGGGG // BBBBBBBB // RRRRRRRR // GGGGGGGG // BBBBBBBB // RRRRRRRR // GGGGGGGG // BBBBBBBB // RRRRRRRR // GGGGGGGG // BBBBBBBB } else if (layout == Layout::Interleaved) { // Another common format is 'interleaved', in which the // red, green, and blue values for each pixel occur next // to each other in memory: // RGBRGBRGBRGBRGBRGBRGBRGB // RGBRGBRGBRGBRGBRGBRGBRGB // RGBRGBRGBRGBRGBRGBRGBRGB // RGBRGBRGBRGBRGBRGBRGBRGB // In this case the stride in x is three, the stride in y // is three times the width of the image, and the stride // in c is one. We can tell Halide to assume (and assert) // that this is the case for the input and output like so: input .set_stride(0, 3) // stride in dimension 0 (x) is three .set_stride(2, 1); // stride in dimension 2 (c) is one brighter.output_buffer() .set_stride(0, 3) .set_stride(2, 1); // For interleaved layout, you may want to use a different // schedule. We'll tell Halide to additionally assume and // assert that there are three color channels, then // exploit this fact to make the loop over 'c' innermost // and unrolled. input.set_bounds(2, 0, 3); // Dimension 2 (c) starts at 0 and has extent 3. brighter.output_buffer().set_bounds(2, 0, 3); // Move the loop over color channels innermost and unroll // it. brighter.reorder(c, x, y).unroll(c); // Note that if we were dealing with an image with an // alpha channel (RGBA), then the stride in x and the // bounds of the channels dimension would both be four // instead of three. } else if (layout == Layout::Either) { // We can also remove all constraints and compile a // pipeline that will work with any memory layout. It will // probably be slow, because all vector loads become // gathers, and all vector stores become scatters. input.set_stride(0, Expr()); // Use a default-constructed // undefined Expr to mean // there is no constraint. brighter.output_buffer().set_stride(0, Expr()); } else if (layout == Layout::Specialized) { // We can accept any memory layout with good performance // by telling Halide to inspect the memory layout at // runtime, and branch to different code depending on the // strides it find. First we relax the default constraint // that stride(0) == 1: input.set_stride(0, Expr()); // Use an undefined Expr to // mean there is no // constraint. brighter.output_buffer().set_stride(0, Expr()); // The we construct boolean Exprs that detect at runtime // whether we're planar or interleaved. The conditions // should check for all the facts we want to exploit in // each case. Expr input_is_planar = (input.stride(0) == 1); Expr input_is_interleaved = (input.stride(0) == 3 && input.stride(2) == 1 && input.extent(2) == 3); Expr output_is_planar = (brighter.output_buffer().stride(0) == 1); Expr output_is_interleaved = (brighter.output_buffer().stride(0) == 3 && brighter.output_buffer().stride(2) == 1 && brighter.output_buffer().extent(2) == 3); // We can then use Func::specialize to write a schedule // that switches at runtime to specialized code based on a // boolean Expr. That code will exploit the fact that the // Expr is known to be true. brighter.specialize(input_is_planar && output_is_planar); // We've already vectorized and parallelized brighter, and // our two specializations will inherit those scheduling // directives. We can also add additional scheduling // directives that apply to a single specialization // only. We'll tell Halide to make a specialized version // of the code for interleaved layouts, and to reorder and // unroll that specialized code. brighter.specialize(input_is_interleaved && output_is_interleaved) .reorder(c, x, y).unroll(c); // We could also add specializations for if the input is // interleaved and the output is planar, and vice versa, // but two specializations is enough to demonstrate the // feature. A later tutorial will explore more creative // uses of Func::specialize. // Adding specializations can improve performance // substantially for the cases they apply to, but it also // increases the amount of code to compile and ship. If // binary sizes are a concern and the input and output // memory layouts are known, you probably want to use // set_stride and set_extent instead. } return brighter; }