Work out how to make warp_size non-`const expr`

[dmcdougall]

This will enable quda to query the warp sizes of different devices from different vendors. Right now, on the AMD side we're returning 64 without prejudice. On the CUDA side we're returning 32 without prejudice.

The macro-guarded approach breaks for host-usage of this API because the #else branch is erroneously taken.

[weinbe2]

A random thought, this could be something defined at cmake configure time. This makes agreement between the host and device trivial, it'll be compile-time knowledge so the compiler can "do smart things", and it'll become a per-backend decision to just specify a number without prejudice or do something more granular.

[dmcdougall]

I had the same thought. You would be imposing the requirement that wherever (or however) you compile must be the same place that you run. The reason is because warpSize, at least for red and green teams, is a device-specific characteristic that can be probed at runtime from either the HIP or CUDA runtime.

If you wanted a more general approach, the configure-time solution isn't enough. If you're comfortable with this extra requirement (which most of your users are probably satisfying tacitly anyway) then the configure-time approach is enough.

[weinbe2]

Not necessarily, you could just have one binary each for different architectures, or one for 32 vs one for 64 in multi-arch compilations. I work with this in the context of containerization pretty frequently where I bake in separate builds for multiple architectures. It's no more complicated than cross-compiling CPU codes when you have to be careful about instruction sets and just specify things by hand instead of doing -march=native. (So, yes, not necessarily easy for the typical user, but still very precedented.)

[weinbe2]

I should add that I'm not opposed to there being a way to make the warp size non-constexpr so long as it doesn't effect performance (or something opt-in if it does) and I'm not trying to discourage it, I'm just throwing some thoughts out there as I have them.

[dmcdougall]

Not necessarily, you could just have one binary each for different architectures, or one for 32 vs one for 64 in multi-arch compilations.

Oh of course. We can build fat binaries. I'm not sure why that hadn't occurred to me earlier.

I should add that I'm not opposed to there being a way to make the warp size non-constexpr so long as it doesn't effect performance (or something opt-in if it does) and I'm not trying to discourage it, I'm just throwing some thoughts out there as I have them.

Understood. I'm not discounting or encouraging any solution in particular; the title of the issue is probably a little too strongly worded. The more ideas the better chance there is we implement the one that makes the most sense.