Clarifications on sub-group support

This is generally seeking clarifications about the requirements made on a device's support for sub-groups.

In [4.6.4.2](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_device_information_descriptors), `info::device::sub_group_sizes` says that it:

``` quote
Returns a std::vector of size_t containing the set of sub-group sizes supported by the device.
````

I think the spec could use clarification about what the minimal set of sub-group sizes looks like. Can a device return an empty vector? What would that mean?

The SYCL-CTS assumes the vector is non-empty, as discussed in [SYCL-CTS/pull/797](https://github.com/KhronosGroup/SYCL-CTS/pull/797).

Furthermore, the use of "**the** set" indicates to me that this returns _all_ of the possible sub-group sizes the compiler ever generates. Is this the case? Is it incorrect if an implementation's compiler generates a kernel with a sub-group size not in turn advertised by `info::device::sub_group_sizes`? Again, the SYCL-CTS does currently mandate this.

I think the current spec wording infers that there's at least one sub-group size and that the reported set of sub-group must be complete and total, but I think this could be better clarified.

As a bit of background/context for my next questions/suggestions, our implementation (the oneAPI construction kit) is not a hardware vendor, per se: we're a compiler toolkit that hopes to support as many devices as possible.

One of our methods of supporting sub-groups for devices was OpenCL's concept of "degenerate sub-groups" - that there's one sub-group covering the entire work-group. This doesn't seem to have a home in SYCL, as `info::device::sub_group_sizes` would in effect return all possible work-group dimensions. Then, in turn, a user would feasibly "require" one of those sub-group sizes via `reqd_sub_group_size` which doesn't make any sense, either: a kernel's sub-group size becomes a property of the dynamic execution range, not the device.

Should SYCL have better support for "degenerate" sub-groups?

Another of our methods of supporting sub-groups is via whole-function vectorization. Groups of work-items run together via vectorization form a sort of sub-group. So in that sense we are also able to support any number of vectorized sub-group sizes - we're not tied to any hardware and the compiler is able to choose the best one. This again is awkward to report via `info::device::sub_group_sizes` as there's a lot of sizes, but it's not as bad as the degenerate case.

Vectorized sub-groups make sense to me via `reqd_sub_group_size` as we can force vectorization to that width, but what if the user doesn't specify one? Must the compiler then vectorize to only one of the sizes reported by `info::device::sub_group_sizes`? Is it **the** set of sizes, after all. That feels a bit limiting, but I understand that the user wants better control over sub-groups, as there are problems with how open the OpenCL spec left it.

Overall it would be nice if SYCL had better support for sub-groups that aren't tied to a specific hardware vendor, as they appear to me to currently be. I'd appreciate anyone's thoughts on this matter!

Start with SYCL 2020 section 4.6.4.2, `info::device::sub_group_sizes`, and the linked SYCL-CTS pull request 797. Review the questions about empty or complete size sets, degenerate sub-groups, vectorization, and `reqd_sub_group_size`; this issue is done when the requirements are resolved and the specification wording is clarified.

Written by the indexing model from the issue text.