Implement mapreduce

[vchuravy]

Ported from oneAPI.jl

• Currentl limited to a static workgroupsize

[SimonDanisch]

Could these things maybe live in https://github.com/anicusan/AcceleratedKernels.jl in the future ?
Seems like they put quite a bit of effort into fast, KernelAbstraction based array operations in there ;)

[vchuravy]

Could these things maybe live in https://github.com/anicusan/AcceleratedKernels.jl in the future ?

There is a dependency ordering issue, GPUArrays is the common infrastructure and this is would be the fallback implementation for a common implementation. So GPUArrays would need to take a dependency on something like AcceleratedKernels.jl

[vchuravy]

Of course JLArrays doesn't work.. That uses the CPU backend and this is cpu=false

[SimonDanisch]

There is a dependency ordering issue

I was considering it as "leave it to AcceleratedKernels" to implement these. Well, it's a very young package, but I was wondering if it could be a path towards the future ;)

[leios]

Just to write down my current understanding of the JLArray issue:

    while d < items
        @synchronize() # legal since cpu=false

Is not valid for the CPU in KA right now due to the synchronization within a while loop. This should be fine once we have a POCL backend for KA, so the "fix" for JLArrays in this PR is to wait for POCL.

GPU execution on all vendors should still work, and Arrays should have their own implementation somewhere else. It's just that the JLArray tests will fail for a bit here.

[maleadt]

Suggested change

	# reduce_items = launch_configuration(kernel)
	reduce_items = 512
	# reduce_items = compute_items(launch_configuration(kernel))
	reduce_items = compute_items(512)

But also has to become dynamic, of course.

[maleadt]

This may be a good time to add support for grid stride loops to KA.jl and handle this with a single kernel launch + atomic writes to global memory?