[SYCL][DOC] Add sycl_ext_oneapi_user_defined_reductions specification

[AlexeySachkov]

No description provided.

[Pennycook]

Thanks for writing this up. I have a few small suggestions.

One question I had that doesn't really fit anywhere is whether we want to tie this to reductions. It occurred to me while reviewing that we could extend the scan functions in exactly the same way. I don't think we have to add those functions now, but I'm wondering if we should call this something like user_defined_group_algorithms so we can add more algorithms later, or if we should introduce separate extensions like user_defined_scans.

[AlexeySachkov]

One question I had that doesn't really fit anywhere is whether we want to tie this to reductions. It occurred to me while reviewing that we could extend the scan functions in exactly the same way. I don't think we have to add those functions now, but I'm wondering if we should call this something like user_defined_group_algorithms so we can add more algorithms later, or if we should introduce separate extensions like user_defined_scans.

I think that depends on whether or not we will be able to group all functions which could be extended like this under a single umbrella name and whether or not we want to allow implementations to support only some of them but not all.

Let's maybe get more opinions on the matter, tagging @gmlueck, @rolandschulz

[dm-vodopyanov]

One question I had that doesn't really fit anywhere is whether we want to tie this to reductions. It occurred to me while reviewing that we could extend the scan functions in exactly the same way. I don't think we have to add those functions now, but I'm wondering if we should call this something like user_defined_group_algorithms so we can add more algorithms later, or if we should introduce separate extensions like user_defined_scans.

I think that depends on whether or not we will be able to group all functions which could be extended like this under a single umbrella name and whether or not we want to allow implementations to support only some of them but not all.

Let's maybe get more opinions on the matter, tagging @gmlueck, @rolandschulz

@gmlueck, @rolandschulz, could you please comment on this?

[gmlueck]

One question I had that doesn't really fit anywhere is whether we want to tie this to reductions. It occurred to me while reviewing that we could extend the scan functions in exactly the same way. I don't think we have to add those functions now, but I'm wondering if we should call this something like user_defined_group_algorithms so we can add more algorithms later, or if we should introduce separate extensions like user_defined_scans.

I think that depends on whether or not we will be able to group all functions which could be extended like this under a single umbrella name and whether or not we want to allow implementations to support only some of them but not all.

Let's maybe get more opinions on the matter, tagging @gmlueck, @rolandschulz

I think we want to have a single extension that covers both reduce and scan. I presume our goal is to get this adopted into SYCL-Next, and I don't think the Khronos WG will adopt user-define functions for reduce without also adopting them for scan. It would seem make the API very inconsistent to do so.

[dm-vodopyanov]

@gmlueck and @Pennycook - could you please review again?