digitalmars.D - D GPU execution module: A survey of requirements.
- H Paterson (63/63) May 09 2018 Hello,
- Henry Gouk (2/7) May 09 2018 Check out https://github.com/libmir/dcompute
- H Paterson (6/15) May 09 2018 Welp... It's not quite what I would have envisioned, but seems to
- jmh530 (3/8) May 09 2018 I'm sure the people who work on Dcompute (or libmir) would
- Dmitry Olshansky (7/23) May 09 2018 With most heavy lifting done (SPIRV backend, things like that)
- Nicholas Wilson (5/21) May 10 2018 It's not dead, it's just pining for the fjords^H^H^H^H
- bioinfornatics (6/30) May 14 2018 Dcompute seems really promising, unfortunately I have not yet
- Dmitry Olshansky (2/7) May 09 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.
May 09 2018
On Wednesday, 9 May 2018 at 23:26:19 UTC, H Paterson wrote: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. [...]Check out https://github.com/libmir/dcompute
May 09 2018
On Wednesday, 9 May 2018 at 23:37:14 UTC, Henry Gouk wrote:On Wednesday, 9 May 2018 at 23:26:19 UTC, H Paterson wrote:Welp... It's not quite what I would have envisioned, but seems to fill the role. Thanks for pointing Dcompute out to me - I only found it mentioned in a dead link on the D wiki. Time to find a new project...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. [...]Check out https://github.com/libmir/dcompute
May 09 2018
jmh530 <john.michael.hall gmail.com> On Thursday, 10 May 2018 at 00:10:07 UTC, H Paterson wrote:Welp... It's not quite what I would have envisioned, but seems to fill the role. Thanks for pointing Dcompute out to me - I only found it mentioned in a dead link on the D wiki. Time to find a new project...I'm sure the people who work on Dcompute (or libmir) would appreciate any help you're willing to provide.
May 09 2018
On Thursday, 10 May 2018 at 00:10:07 UTC, H Paterson wrote:On Wednesday, 9 May 2018 at 23:37:14 UTC, Henry Gouk wrote:With most heavy lifting done (SPIRV backend, things like that) you can join and contribute your vision. Last time I looked it was way better then plain OpenCL and friends but still had a long way to improve on the initial idea IMHO. That was 1 year ago though.On Wednesday, 9 May 2018 at 23:26:19 UTC, H Paterson wrote:Welp... It's not quite what I would have envisioned, but seems to fill the role.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. [...]Check out https://github.com/libmir/dcomputeThanks for pointing Dcompute out to me - I only found it mentioned in a dead link on the D wiki.Please, please, fix it! Or post the page here at the very least.Time to find a new project...
May 09 2018
On Thursday, 10 May 2018 at 00:10:07 UTC, H Paterson wrote:On Wednesday, 9 May 2018 at 23:37:14 UTC, Henry Gouk wrote:It's not dead, it's just pining for the fjords^H^H^H^H hibernating waiting for me to finish undergrad (~7 weeks). You are more than welcome to join the development. NicOn Wednesday, 9 May 2018 at 23:26:19 UTC, H Paterson wrote:Welp... It's not quite what I would have envisioned, but seems to fill the role. Thanks for pointing Dcompute out to me - I only found it mentioned in a dead link on the D wiki. Time to find a new project...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. [...]Check out https://github.com/libmir/dcompute
May 10 2018
On Thursday, 10 May 2018 at 07:25:32 UTC, Nicholas Wilson wrote:On Thursday, 10 May 2018 at 00:10:07 UTC, H Paterson wrote:Dcompute seems really promising, unfortunately I have not yet successfully build the ldc compiler using a LLVM fork with SPIRV enabled: https://github.com/libmir/dcompute/issues/46 Maybe you should try with a ldc 1.7 or less (I tried 1.8 and 1.9 ) Good luckOn Wednesday, 9 May 2018 at 23:37:14 UTC, Henry Gouk wrote:It's not dead, it's just pining for the fjords^H^H^H^H hibernating waiting for me to finish undergrad (~7 weeks). You are more than welcome to join the development. NicOn Wednesday, 9 May 2018 at 23:26:19 UTC, H Paterson wrote:Welp... It's not quite what I would have envisioned, but seems to fill the role. Thanks for pointing Dcompute out to me - I only found it mentioned in a dead link on the D wiki. Time to find a new project...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. [...]Check out https://github.com/libmir/dcompute
May 14 2018
On Wednesday, 9 May 2018 at 23:26:19 UTC, H Paterson wrote: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.What about DCompute project?[...]
May 09 2018