Thread overview
D GPU execution module: A survey of requirements.
May 09, 2018
H Paterson
May 09, 2018
Henry Gouk
May 10, 2018
H Paterson
May 10, 2018
jmh530
May 10, 2018
Dmitry Olshansky
May 10, 2018
Nicholas Wilson
May 14, 2018
bioinfornatics
May 09, 2018
Dmitry Olshansky
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: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 10, 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:
>> 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

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...
May 10, 2018
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 10, 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:
>> 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
>
> Welp... It's not quite what I would have envisioned, but seems to fill the role.

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.

>
> Thanks 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 10, 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:
>> 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
>
> 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...

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.

Nic
May 14, 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:
>> 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:
>>>> 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
>>
>> 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...
>
> 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.
>
> Nic

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 luck