Adds test for the non_uniform_groups oneAPI extension

[steffenlarsen]

This commit adds tests for the sycl_ext_oneapi_non_uniform_groups extension in accordance with the test plan currently in review here: #866

[dm-vodopyanov]

Should there be a negative test?

Preconditions: `PartitionSize` must be less than or equal to the result of `group.get_max_local_range()`. `group.get_local_linear_range()` must be evenly divisible by `PartitionSize`.

[steffenlarsen]

Same as in #875 (comment).

[AlexeySachkov]

Please note that this cannot be a compile-time check and behavior is undefined if that precondition is not met. Unless the extensions specification is clarified, we can't have a meaningful test for that, at least in CTS

[dm-vodopyanov]

Should this be checked?

Each call to `get_opportunistic_group()` returns a different group.

[steffenlarsen]

That is a good question. @Pennycook - What is the intention here? Do the groups have common by-value semantics and if so, does this make the guarantee that get_opportunistic_group() != get_opportunistic_group(), which in turn means the groups will never have the same members values?

[Pennycook]

That is a very good question.

The intention of the wording was really to say that the members may be different, and that in cases where the members are different, the group objects may be different. Without thinking of any specific implementation: if the group members are different, the representation (e.g., as a mask) will probably be different; even if the group members are the same, I can imagine situations where the different group objects would still have dedicated scratchpad memory or barriers.

I think the simplest thing to do for now is to guarantee that equality returns false. It's probably more useful to have a comparison that is always useless than to try and define the cases in which equality should/could return true. I'd prefer not to provide a comparison operator at all, but I've heard suggestions recently that this would break a lot of things.

[gmlueck]

I think the simplest thing to do for now is to guarantee that equality returns false. It's probably more useful to have a comparison that is always useless than to try and define the cases in which equality should/could return true. I'd prefer not to provide a comparison operator at all, but I've heard suggestions recently that this would break a lot of things.

Are you saying that opportunistic_group needs to have a comparison operator? If you are saying that things would break if there is no comparison operator, it seems surprising that those things wouldn't also break if the comparison operator always returned false.

Are you saying that the comparison operator would return false even when comparing an object with a copy? For example:

opportunistic_group og1 = /*...*/;
opportunistic_group og2 = og1;
bool same = (og1 == og2);  // returns false?

[Pennycook]

Are you saying that opportunistic_group needs to have a comparison operator? If you are saying that things would break if there is no comparison operator, it seems surprising that those things wouldn't also break if the comparison operator always returned false.

I don't have complete information here. This came up in a discussion we were having about some of the other types (e.g., nd_item), and my takeaway was that that if we were to remove certain operators then the classes wouldn't play nicely with certain type traits. I might have gotten the wrong end of the stick.

Are you saying that the comparison operator would return false even when comparing an object with a copy? For example:

opportunistic_group og1 = /*...*/;
opportunistic_group og2 = og1;
bool same = (og1 == og2);  // returns false?

Yes, that's what I was suggesting.

I'm also open to defining a real comparison operator for groups, but I don't know what the criteria should be. I can see an argument that it should be based on which work-items are in the group (which would allow comparisons across groups of different types) but can also think of cases where that could lead to surprising results (e.g., just because two groups have the same work-items in them doesn't necessarily mean they can be used interchangably).

[steffenlarsen]

If this is an open issue for groups in general, could we leave it out of these tests for now and address it for all groups when it has been discussed and consensus has been reached on how it should work?

[keryell]

Interesting discussion about defining group equality and usability. Related to also whether we can use them in another work-group or kernel by storing them into an intermediate buffer.
To clarify for SYCL Next. :-)

[AlexeySachkov]

Please note that this cannot be a compile-time check and behavior is undefined if that precondition is not met. Unless the extensions specification is clarified, we can't have a meaningful test for that, at least in CTS

[AlexeySachkov]

We could parametrize the test on the partition size and check a few different values. There are some corner cases like partition size = 1 (still a power of two! :)) and partition size = sub-group size.

I would maybe leave a TODO to expand the testing in that direction: with reqd_sub_group_size attribute it should be doable to achieve, but will require more checks to make the test portable

[dm-vodopyanov]

LGTM!