FYI @gmlueck

I certainly think that the attributes should accept any integer value that can be represented in a size_t.

I suppose the behavior for even larger values is debatable. One option is to allow any C++ integer literal. At runtime the implementation would see if the device supports the requested work-group / sub-group size. This would almost certainly be "no" for any value that is larger than size_t, so you would get a runtime exception when trying to submit the kernel.

Were you asking about values that are no bigger than size_t, or were you asking about the weird case where values are legal integer literals that are bigger than size_t?

Just the case where values that can fit in size_t. I just wanted to double check because the spec says that arguments are to be integral constant expressions, which from one point of view, this doesn't say what type the argument should be, although from another point of view, this means every integral type should be supported (i.e. the type doesn't matter, just the actual number represented, as long as the value fits in some integral type).

I didn't think about that weird case, but from that cppreference page, it says that literals that can't fit inside any integer type make the program ill-formed, so I don't think that's an issue.

I didn't think about that weird case, but from that cppreference page, it says that literals that can't fit inside any integer type make the program ill-formed, so I don't think that's an issue.

Yes, but there could be integer types that are larger than size_t.

I don't think that we should consider integer types which are larger than size_t. The reason for that is to make the spec consistent: all queries related to properties set by those attributes return size_t and therefore I don't think that it makes sense to allow a value bigger than size_t. Why do we allow to write a kernel, which can't be launched by any conformant device?

info::device::max_work_item_sizes<N> returns range<N>; info::device::max_work_group_size returns size_t; info::device::sub_group_sizes returns std::vector<size_t>

Yes, I think that makes sense too. We should change the spec wording from:

Each argument must be an integral constant expression.

To:

Each argument must be an integral constant expression that is representable by size_t.

Except for reqd_sub_group_size, which should change to:

Each argument must be an integral constant expression that is representable by uint32_t.

This is because the APIs for sub-group size all return uint32_t.

Except for reqd_sub_group_size, which should change to:

Each argument must be an integral constant expression that is representable by uint32_t.

This is because the APIs for sub-group size all return uint32_t.

Max number of sub-groups in a work-group is defined as uint32_t, but sub-group sizes are defined as size_t

The sub_group::get_local_linear_id function returns a uint32_t, for example.

The sub_group::get_local_linear_id function returns a uint32_t, for example.

Oh, I see. Should we also consider updating info::device::sub_group_sizes query then?