mitsuba-renderer / enoki

Enoki: structured vectorization and differentiation on modern processor architectures
Other
1.26k stars 94 forks source link

Treading 3D array as 4d array #43

Closed skgbanga closed 4 years ago

skgbanga commented 5 years ago

Hello,

As the documentation says, 3D arrays are treated as 4D arrays to make better used of intrinsics, but this raises an interesting problem.

Consider the following code:

  using Array = enoki::Array<float, 3>;

  Array numerator{2, 4, 8};
  Array denominator{1, 1, 1};

  auto result = numerator / denominator;
  if (std::fetestexcept(FE_INVALID)) {
    throw std::runtime_error("domain error");
  }

This throws the exception because the last number in the Register is initialized to 0, and this leads to a division by zero. Note that this is not limited to division. Any operation on the last number (things like min, max) also trigger than exception.

We do a bunch of floating point computation and like to keep the floating point exception check to verify we didn't mess up.

I was wondering what is your suggestion to handle cases like this?

wjakob commented 5 years ago

Dear @skgbanga,

that's a good point! This kind of very strict checking is probably a fairly narrow use case, but it would be good if there was a way to disable the Enoki optimization in such a case.

What I would suggest is to introduce a new enum ENOKI_DISABLE_3D_SPECIAL_CASE and wrapping the partial template overloads at the end of array_sse.h, array_avx[2].h with a corresponding #if !defined(..).

Best, Wenzel

wjakob commented 5 years ago

(Please feel free to create a PR with this change, once you have checked that it addresses your issue.)

skgbanga commented 5 years ago

@wjakob

For now, I have initialized all my enoki arrays with sensible defaults.(even the 4th element) because I do want to use that optimization.

I will submit a PR separately with your recommendation though.

wjakob commented 4 years ago

Closing this ticket.