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