[DepthMap] Support AdaptiveCpp/SYCL with Apple Metal

[philippremy]

Picking up from issue #439:

I already did some initial testing when MR #2077 was developed and AliceVision generally is in a good position to make the SYCL kernels for DepthMap computation work with the experimental Apple Metal backend of AdaptiveCpp. It basically works out of the box with the only issue being the usage of double throughout several SYCL kernels. Metal Shading Language does not support 64-bit floating point numbers and AdaptiveCpp (currently) has no software emulation / automatic demotion of these, so the resulting binaries will just throw errors at runtime because the MTLCompilerService daemon fails to compile the generated MSL.

The SYCL kernels could very easily be adapted for this by just removing all usages of double. IMHO there are some questions to answer first, however:

• Is it an mathematical issue to turn these usages of double into float?
  • If no, we just have to figure out how to switch between code at generation time. There cannot be a single leftover usage of double in the resulting AIR (whether explicit or implicit) or MTLCompilerService will fail to emit machine code.
  • If yes, is that acceptable to the project (Maintainers?)
    • If yes, we can go forward with the conditional approach (see above).
    • If no, what are other options?
      • Wait for AdaptiveCpp to implement proper double handling for MSL (they list that as in-scope explicitly)?
      • Try to implement our own software emulation layer for double?

Regarding the initial question I definitively do not bring the required Math knowledge with me to answer it. I'd guess that there is/was a reason why the CUDA kernel authors used double. This is a somewhat uncommon choice on GPUs and one would probably avoid it if possible. For the final mesh output however, I did not really notice that much of a difference. Rolling our own double software emulation would not be impossible, but it certainly is a significant undertaking. We would need to implement edge cases (NaN, infinity, ±0) and rather complex functions (like sin() and cos()). Switching code for backends seems to be totally possible, IIRC there is a helper function/'lamda' in the AdaptiveCpp namespace which guards code per backend.

Note

For those who just want to test this quick-and-dirty, you essentially want to do the following in all files with SYCL code:
Turn all explicit and implicit double usages into regular float:
So this:

/* An example SYCL kernel/function */
static inline void sycl_tred2(double V[3][3], double d[3], double e[3]) { ... }
/* An example literal decimal number */
auto d = 1.0; // This is implicitly a double!
/* An example cast where a double is involved */
/* Note that this obviously applies to all casts, no matter if explicit or implicit! */
float f = (float)1.0; // The IR still contains the double value, even though it is never used as such!
float f = (float)(double)1.0f;  // The compiler might retain the intermediate double!
/* Example variable declarations */
double a, b, c;

should turn roughly into this:

/* An example SYCL kernel/function */
static inline void sycl_tred2(float V[3][3], float d[3], float e[3]) { ... }
/* An example literal decimal number */
auto d = 1.0f; // This is now explicitly a float, note the trailing f
/* An example cast where a double is involved */
/* Note that this obviously applies to all casts, no matter if explicit or implicit! */
float f = (float)1.0f; // The double has been turned into a float literal
float f = (float)1.0f;  // Remove the intermediate double cast
/* Example variable declarations */
float a, b, c;

The GCC/Clang -Wimplicit-float-conversion flag might be of help here when you think you missed something (the literals sometimes sneak their way through the code :D).