Lazy if/then/else conditional?

[ziriax]

I was skimming through this old paper about writing a ray-tracer in Halide, and they mention that Halide doesn't have a classical lazy if-then-else statement or ternary expression, because that doesn't vectorize.

Is that still the case?

[abadams]

It still doesn't have a short-circuiting ternary expression, however you can inject if statements around blocks of computation using RDom::where, to turn on and off individual update steps on an update definition as a function of some boolean expression

[ziriax]

Thanks, that works.

Is it possible to use vectorization on such an RDom? In the sense that when all intersection booleans in the vector are false, then the update is skipped, otherwise it will do the update for each ray in the vector anyway. So a bit of mix between select and scalar if/then

Is it also possible to inline the initialization in the update? E.g. in the following code:

Output<Buffer<...>> canvas;
...
canvas(x,y) = 0;
RDom r(canvas);
Expr intersected = ...
r.where(intersected);
canvas(r.x,r.y) = 1

Is it possible the schedule the init canvas(x,y)=0 to occur in the same for loop as the RDom, just before the if/then statement?

[abadams]

You can vectorize one of the pure vars in an update definition (or an rvar that obeys the same restrictions as a pure var). The code that gets generated adds vector predicates to all loads and stores.

You can't do much scheduling-wise with that update definition as you have written it. Is it possible to use Vars instead of RVars? E.g. if there's no actual reduction and you just need the RDom for the if statement, you could rewrite it as:

canvas(x, y) = 0;
RDom r(0, 1); // trivial RDom
Expr intersected = ... (some condition in x and y) ...;
r.where(intersected);
canvas(x, y) = r + 1; // This has a dummy dependency on r. r is always zero. Yes, this is a bit of a hack.

If you do that you can schedule canvas much more flexibly, e.g the following would wrap it up into a single loop nest and vectorize and parallelize it:

canvas.in().compute_root().vectorize(x, 8).parallel(y, 8);

[ziriax]

That is clever 😃 I will try that.

[ziriax]

Interestingly, this works, but is 8 times slower than not scheduling the canvas at all and just doing

canvas.update().vectorize(r.x, vector_size).parallel(r.y, 8);

My code in more detail looks like:

auto vector_size = natural_vector_size(canvas.type());
Func hit;
hit(x,y) = // intersection computation resulting in a Tuple
canvas(x,y) = 0;
RDom r(canvas);
Tuple h = hit(r.x, r.y);
r.where(h[3]);
canvas(r.x,r.y) = // sample texture using values hit, doing slow atan2, etc;
...
canvas.update().vectorize(r.x, vector_size).parallel(r.y, 8);

[ziriax]

But, when putting it all together with supersampling, your approach works perfectly. Thanks a lot, Halide rocks!

[ziriax]

@abadams When I print the loop nests when using your code, the init is not moved into the same for loop, it is still initialized separately.

E.g. the code

    Output<Buffer<uint32_t, 2>> canvas{"canvas"};
    ...
    
    Var x("x");
    Var y("y");

    RDom r(0, 1);
    r.where(x < y);
    canvas(x, y) = u32(0);
    canvas(x, y) = u32(r + 1);

    canvas.in().compute_root();
    canvas.print_loop_nest();

prints

produce canvas:
  for y:
    for x:
      canvas(...) = ...
  for y:
    for x:
      canvas(...) = ...

Also, I don't fully understand the in() call; does it merge the init and update step into a new function?

(using Halide 17 package from Ubuntu 23)

[abadams]

in() wraps an Func with a wrapper Func, so that all callers are rewritten to call that wrapper instead. It has a wart when it comes to pipeline outputs though, because they have no callers, so wrapping it in another Func isn't terribly useful. For pipeline outputs you can achieve the same effect by defining an intermediate Func like so:

Func f;
RDom r(0, 1);
r.where(x < y);
f(x, y) = u32(0);
f(x, y) = u32(r + 1);

canvas(x, y) = f(x, y);