KhronosGroup / SYCL-Docs

SYCL Open Source Specification

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Should the reduce and scan group algorithms support marray/vec?

jzc opened this issue · comments

From 4.17.4. Group algorithms library:

All group functions are supported for the fundamental scalar types supported by SYCL (see Table 184) and instances of the SYCL vec and marray classes.

However, not all the specifications of the group functions adhere to this rule. Specifically, the reduce and scan algorithms do not allow for vec and marray, e.g. 4.17.4.5. reduce:

template <typename Group, typename Ptr, typename BinaryOperation>
std::iterator_traits<Ptr>::value_type
joint_reduce(Group g, Ptr first, Ptr last, BinaryOperation binary_op); // (1)

[...]
Constraints: Available only if sycl::is_group_v<std::decay_t> is true, Ptr is a pointer to a fundamental type, and BinaryOperation is a SYCL function object type.

However, this could be argued to be fine (although in my opinion, confusing) because of the following statement in 4.17.4:

Any restrictions from the standard algorithms library apply. Some of the functions in the SYCL algorithms library introduce additional restrictions in order to maximize portability across different devices and to minimize the chances of encountering unexpected behavior.

Should the reduce and scan specifications be amended to allow for vec and marray?

I stumbled across this same issue yesterday. I think this is an oversight, and something that needs clarification.

We originally prototyped the group algorithms as part of a DPC++ extension, and that extension says:

Functions with arguments of type vec<T,N> are applied component-wise: they are semantically equivalent to N calls to a scalar function of type T.

(Note that the extension doesn't mention marray only because marray didn't exist at the time.)

Somewhere along the way, this text got dropped. We kept the part about supporting vec and marray, but lost the explanation of how these types behave. I propose that we restore text like this. The component-wise behavior is intuitive, because all the operators (e.g., +) for vec and marray are defined to be component-wise.