Improve check for compatibility of vector size and subgroup size in SYCL

[masterleinad]

Blocked by intel/llvm#5071.

[masterleinad]

This should work now. @brian-kelley Can you give this a try in view of #4573?

[masterleinad]

Retest this please.

[brian-kelley]

@masterleinad Yes, this does catch the vector size being too big.

[masterleinad]

Retest this please.

[masterleinad]

Retest this please.

[brian-kelley]

@masterleinad Is "subgroup size" equivalent to team size for Kokkos? Is this PR expected to catch issues with team size being too big? Coincidentally, the same kernel that had the local atomics issue now hangs because policy.team_size_recommended() returns 1024 which I guess is too big. Reducing it to 256 makes it work fine. If that is unrelated to this PR, does that deserve its own issue? The policy uses vector_length 1.

[masterleinad]

@masterleinad Is "subgroup size" equivalent to team size for Kokkos? Is this PR expected to catch issues with team size being too big? Coincidentally, the same kernel that had the local atomics issue now hangs because policy.team_size_recommended() returns 1024 which I guess is too big. Reducing it to 256 makes it work fine. If that is unrelated to this PR, does that deserve its own issue? The policy uses vector_length 1.

"group size" is equivalent to team size and subgroup size is related to vector size. I haven't seen a kernel hanging because of the team size/subgroup size being too large; normally there is some kind of error coming from the runtime. Anyway, please open a separate issue!

[masterleinad]

This seems to finally work with storing the kernel obtained from the runtime in a static variable and also doing another warm-up round in the test making sure that obtaining the kernel is not counted when testing for the kernel execution to be asynchronous.

[dalg24]

Format looks weird