We basically have to follow these rules,
1. The range must be none prior to execution of a gpu code block
2. The range can not be changed during execution of a gpu code
block
3. Code blocks can only receive a single range, it can however be
multidimensional
4. index keys used in a code block are immutable
5. Code blocks can only use a single key(the gpu executes many
instances in parallel each with their own unique key)
6. index's are always an unsigned integer type
7. openCL,CUDA have no access to global state
8. gpu code blocks can not allocate memory
9. gpu code blocks can not call cpu functions
10. atomics tho available on the gpu are many times slower then
on the cpu
11. separate running instances of the same code block on the gpu
can not have any interdependency on each other.
Now if we are talking about HSA, or other similar setup, then a
few of those rules don't apply or become fuzzy.
HSA, does have limited access to global state, HSA can call cpu
functions that are pure, and of course because in HSA the cpu and
gpu share the same virtual address space most of memory is open
for access.
HSA also manages memory, via the hMMU, and their is no need for
gpu memory management functions, as that is managed by the
operating system and video card drivers.
Basically, D would either need to opt out of legacy api's such as
openCL, CUDA, etc, these are mostly tied to c/c++ anyway, and
generally have ugly as sin syntax; or D would have go the route
of a full and safe gpu subset of features.
I don't think such a setup can be implemented as simply a
library, as the GPU needs compiled source.
If D where to implement gpgpu features, I would actually suggest
starting by simply adding a microthreading function syntax, for
example...
void example( aggregate in float a[] ; key , in float b[], out
float c[]) {
c[key] = a[key] + b[key];
}
By adding an aggregate keyword to the function, we can assume the
range simply using the length of a[] without adding an extra set
of brackets or something similar.
This would make access to the gpu more generic, and more
importantly, because llvm will support HSA, removes the needs for
writing more complex support into dmd as openCL and CUDA would
require, a few hints for the llvm backend would be enough to
generate the dual bytecode ELF executables.
