D GPU execution module: A survey of requirements.
H Paterson
spam at invalid.abc
Wed May 9 23:26:19 UTC 2018
Hello,
I'm interested in writing a module for executing D code on GPUs.
I'd like to bounce some ideas off D community members to see what
this module needs do.
I'm conducting this survey in case my project becomes
sufficiently developed to be contributed to the D standard
library.
I'd appreciate if you could take the time to share your thoughts
on how a GPU execution module should work, and to critique my
ideas.
---
First, The user interface... I haven't thought about what a good
(and D style) API for GPU execution should look like, and I'd
appreciate open suggestions.
I've got a strong preference for code that encapsulates *all*
the details of GPU control, and was thinking about using D's
template system to pass individual functions to the GPU executor:
import GPUCompute;
int[] doubleArray(int[] input)
{
foreach(ref value; input)
{
value *= 2;
}
return input;
}
auto gpuDoubleArray = generateGPUFunction!doubleArray;
gpuDoubleArray([1, 2, 3]);
Can you provide feedback on this idea? What other approaches can
you think off?
I expect an initial version will only support functions for GPU
execution, but I suppose if the module becomes successful I could
expand the code to buffer and manipulate entire classes on the
GPU. (How important is GPU object execution to you?)
---
Secondly, Internal workings:
Currently, I'm thinking of using CTFE to generate OpenCL or
Vulkan compute kernels for each requested GPU function. The
module can encapsulate code to compile the compute kernels for
the native GPU at runtime, probably when either the user program
opens or the GPU execution module enters scope.
The hard part of this will be getting access to the AST that the
compiler generates for the functions. I still need to research
this, and I'd appreciate being directed to any relevant material.
I'd rather not have to import large parts of DMD into (what I
hope) will eventually be part of the D standard library, but I
think importing parts of DMD will be preferable to writing a new
parser from scratch.
Are their any alternative ideas for the general approach to the
module?
---
Thirdly, Open submissions:
How would use D GPU execution? What kind of tasks would you run;
what would your code look like? How do you want your code to look?
What do you think the minimum requirements of the module needs to
be, before it becomes useless to you?
---
Thanks for your time, and I apologize my questions are open ended
and vague: This is all pre-planning work for now, and I don't
promise it'll come to anything - even a draft or architecture
plan.
Cheers,
H Paterson.
More information about the Digitalmars-d
mailing list