Hi all,

I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV.

Someone (sorry I've forgotten who!) at dconf said they'd make a docker image of the dependencies (ldc llvm), if you're reading please let me know! Or if someone else wants to do it thats good too.

I'm still quite busy until July (honours thesis), but if anyone wanting to contribute to either the runtime stuff [2](all D), LDC [3] or LLVM [1](mostly C++) I'm happy to answer any questions, providing testing and performance feedback on diverse systems is also appreciated. Feel free to drop a line at https://gitter.im/libmir/public

[1]: https://github.com/thewilsonator/llvm/tree/compute
[2]: https://github.com/libmir/dcompute
[3]: https://github.com/ldc-developers/ldc

On 29/05/2017 10:33 AM, Nicholas Wilson wrote:
> Hi all,
> 
> I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV.
> 
> Someone (sorry I've forgotten who!) at dconf said they'd make a docker image of the dependencies (ldc llvm), if you're reading please let me know! Or if someone else wants to do it thats good too.
> 
> I'm still quite busy until July (honours thesis), but if anyone wanting to contribute to either the runtime stuff [2](all D), LDC [3] or LLVM [1](mostly C++) I'm happy to answer any questions, providing testing and performance feedback on diverse systems is also appreciated. Feel free to drop a line at https://gitter.im/libmir/public
> 
> [1]: https://github.com/thewilsonator/llvm/tree/compute
> [2]: https://github.com/libmir/dcompute
> [3]: https://github.com/ldc-developers/ldc

Can someone please write up a post e.g. for the D blog to act as the official announcement (with a quick tutorial)? That way we can announce it to the wider programming community.

On Monday, 29 May 2017 at 09:39:53 UTC, rikki cattermole wrote:
> On 29/05/2017 10:33 AM, Nicholas Wilson wrote:
>> Hi all,
>> 
>> I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV.
>> 
>> Someone (sorry I've forgotten who!) at dconf said they'd make a docker image of the dependencies (ldc llvm), if you're reading please let me know! Or if someone else wants to do it thats good too.
>> 
>> I'm still quite busy until July (honours thesis), but if anyone wanting to contribute to either the runtime stuff [2](all D), LDC [3] or LLVM [1](mostly C++) I'm happy to answer any questions, providing testing and performance feedback on diverse systems is also appreciated. Feel free to drop a line at https://gitter.im/libmir/public
>> 
>> [1]: https://github.com/thewilsonator/llvm/tree/compute
>> [2]: https://github.com/libmir/dcompute
>> [3]: https://github.com/ldc-developers/ldc
>
> Can someone please write up a post e.g. for the D blog to act as the official announcement (with a quick tutorial)? That way we can announce it to the wider programming community.

I promised Mike a blog post at dconf, but I'd prefer this to be done after I hand in my thesis, so that I can:
a) concentrate on it and
b) keep the ball rolling after it is announced.

I will be working for Laeeth next semester with some time reserved for dcompute and much more time available as I'll only be doing one (or possibly two units, with a lot of time waiting for tanks to reach steady state). Plus I think if people start to get familiar with the project then the efforts will be much more coordinated once the announcement is made and therefore by perception more attractive to potential users not already familiar with D.

On 29/05/2017 10:52 AM, Nicholas Wilson wrote:
> On Monday, 29 May 2017 at 09:39:53 UTC, rikki cattermole wrote:
>> On 29/05/2017 10:33 AM, Nicholas Wilson wrote:
>>> Hi all,
>>>
>>> I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV.
>>>
>>> Someone (sorry I've forgotten who!) at dconf said they'd make a docker image of the dependencies (ldc llvm), if you're reading please let me know! Or if someone else wants to do it thats good too.
>>>
>>> I'm still quite busy until July (honours thesis), but if anyone wanting to contribute to either the runtime stuff [2](all D), LDC [3] or LLVM [1](mostly C++) I'm happy to answer any questions, providing testing and performance feedback on diverse systems is also appreciated. Feel free to drop a line at https://gitter.im/libmir/public
>>>
>>> [1]: https://github.com/thewilsonator/llvm/tree/compute
>>> [2]: https://github.com/libmir/dcompute
>>> [3]: https://github.com/ldc-developers/ldc
>>
>> Can someone please write up a post e.g. for the D blog to act as the official announcement (with a quick tutorial)? That way we can announce it to the wider programming community.
> 
> I promised Mike a blog post at dconf, but I'd prefer this to be done after I hand in my thesis, so that I can:
> a) concentrate on it and
> b) keep the ball rolling after it is announced.
> 
> I will be working for Laeeth next semester with some time reserved for dcompute and much more time available as I'll only be doing one (or possibly two units, with a lot of time waiting for tanks to reach steady state). Plus I think if people start to get familiar with the project then the efforts will be much more coordinated once the announcement is made and therefore by perception more attractive to potential users not already familiar with D.

Ok so announce only within D community atm. Good to know :)

On 5/29/2017 2:33 AM, Nicholas Wilson wrote:
> Hi all,
> 
> I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV.
> 
> Someone (sorry I've forgotten who!) at dconf said they'd make a docker image of the dependencies (ldc llvm), if you're reading please let me know! Or if someone else wants to do it thats good too.
> 
> I'm still quite busy until July (honours thesis), but if anyone wanting to contribute to either the runtime stuff [2](all D), LDC [3] or LLVM [1](mostly C++) I'm happy to answer any questions, providing testing and performance feedback on diverse systems is also appreciated. Feel free to drop a line at https://gitter.im/libmir/public
> 
> [1]: https://github.com/thewilsonator/llvm/tree/compute
> [2]: https://github.com/libmir/dcompute
> [3]: https://github.com/ldc-developers/ldc

Congratulations! This is great work, and a great contribution.

May I suggest, however, that the name DCompute is a bit generic, and provides no hint that it provides GPU programming for D.

How about calling it D-GPU ? I bet you'd get a lot more clicks on a name like that.

On Monday, 29 May 2017 at 20:36:26 UTC, Walter Bright wrote:
> On 5/29/2017 2:33 AM, Nicholas Wilson wrote:
>> Hi all,
>> 
>> I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV.
>> 
>> Someone (sorry I've forgotten who!) at dconf said they'd make a docker image of the dependencies (ldc llvm), if you're reading please let me know! Or if someone else wants to do it thats good too.
>> 
>> I'm still quite busy until July (honours thesis), but if anyone wanting to contribute to either the runtime stuff [2](all D), LDC [3] or LLVM [1](mostly C++) I'm happy to answer any questions, providing testing and performance feedback on diverse systems is also appreciated. Feel free to drop a line at https://gitter.im/libmir/public
>> 
>> [1]: https://github.com/thewilsonator/llvm/tree/compute
>> [2]: https://github.com/libmir/dcompute
>> [3]: https://github.com/ldc-developers/ldc
>
> Congratulations! This is great work, and a great contribution.
>
> May I suggest, however, that the name DCompute is a bit generic, and provides no hint that it provides GPU programming for D.
>
> How about calling it D-GPU ? I bet you'd get a lot more clicks on a name like that.

Thanks, I called it dcompute because naming things is right up there with cache invalidation.
Calling it D-GPU would be misleading because there should be no reason you can't use the generated SPIRV on DSPs, FPGAs and whatever else there is an OpenCL runtime for.

The clicks should be rectifiable with a good title and description.

On 5/29/2017 3:52 PM, Nicholas Wilson wrote:
>> How about calling it D-GPU ? I bet you'd get a lot more clicks on a name like that.
> 
> Thanks, I called it dcompute because naming things is right up there with cache invalidation.
> Calling it D-GPU would be misleading because there should be no reason you can't use the generated SPIRV on DSPs, FPGAs and whatever else there is an OpenCL runtime for.

From https://github.com/libmir/dcompute :

"This project is a set of libraries designed to work with a modified ldc to enable native execution of D on GPUs (and other more exotic target of OpenCL, hereafter just 'GPUs')."


> The clicks should be rectifiable with a good title and description.

Many years ago, D immutable types were called 'invariant'. People always asked what invariant meant, and we'd reply "invariant types are immutable" and then they'd understand.

After going through that for the thousandth time, we renamed 'invariant' to 'immutable', and the questions ceased.

The trouble is, all I usually see is simply "DCompute". I have to click on a link or do some searching to see what it is for. There's nothing to suggest that it's for me if I'm interested in using D for FPGA programming. Google isn't going to index it under "FPGA".

I'm sorry about being pushy about this, but I really want DCompute to succeed, and the current name will impair this. Having the right name and branding is extremely important.

A descriptive title could be:

"D-GPU: native D code running on GPUs, FPGAs and DSPs"

On Tuesday, 30 May 2017 at 00:12:51 UTC, Walter Bright wrote:
> On 5/29/2017 3:52 PM, Nicholas Wilson wrote:
>>> How about calling it D-GPU ? I bet you'd get a lot more clicks on a name like that.
>> 
>> Thanks, I called it dcompute because naming things is right up there with cache invalidation.
>> Calling it D-GPU would be misleading because there should be no reason you can't use the generated SPIRV on DSPs, FPGAs and whatever else there is an OpenCL runtime for.
>
> From https://github.com/libmir/dcompute :
>
> "This project is a set of libraries designed to work with a modified ldc to enable native execution of D on GPUs (and other more exotic target of OpenCL, hereafter just 'GPUs')."
>

OK, I should probably reword that.

>
>> The clicks should be rectifiable with a good title and description.
>
> Many years ago, D immutable types were called 'invariant'. People always asked what invariant meant, and we'd reply "invariant types are immutable" and then they'd understand.
>
> After going through that for the thousandth time, we renamed 'invariant' to 'immutable', and the questions ceased.
>
> The trouble is, all I usually see is simply "DCompute". I have to click on a link or do some searching to see what it is for. There's nothing to suggest that it's for me if I'm interested in using D for FPGA programming. Google isn't going to index it under "FPGA".
>
> I'm sorry about being pushy about this, but I really want DCompute to succeed, and the current name will impair this. Having the right name and branding is extremely important.
>
> A descriptive title could be:
>
> "D-GPU: native D code running on GPUs, FPGAs and DSPs"

Well the GitHub project description is "Native execution of D on GPUs" I don't want to do false advertising for features that I don't have yet but I will update to reflect this, I'll be surprised if google doesn't pick up on 'dlang fpga' along with DHDL.

there are also GitHub topics [1] which I will also properly fill out. I just done a pass over the README.md

[1]: https://github.com/blog/2309-introducing-topics

On 5/29/2017 6:10 PM, Nicholas Wilson wrote:
> there are also GitHub topics [1] which I will also properly fill out. I just done a pass over the README.md
> 
> [1]: https://github.com/blog/2309-introducing-topics

Good. Making the content google-friendly is also extremely important. Back in the early daze of D, I knew that "D" was not google-able, so I was careful to always have the phrase "D programming language" somewhere in text about D, and I'd harangue others to do the same. Since google knows about "D" now, this is less important.

On Tuesday, 30 May 2017 at 02:46:12 UTC, Walter Bright wrote:
> On 5/29/2017 6:10 PM, Nicholas Wilson wrote:
>> there are also GitHub topics [1] which I will also properly fill out. I just done a pass over the README.md
>> 
>> [1]: https://github.com/blog/2309-introducing-topics
>
> Good. Making the content google-friendly is also extremely important. Back in the early daze of D, I knew that "D" was not google-able, so I was careful to always have the phrase "D programming language" somewhere in text about D, and I'd harangue others to do the same. Since google knows about "D" now, this is less important.

I suspect that this will have less of an effect dcompute as "dcompute" is likely to have a far greater signal to noise ratio than "D" in its infancy simply due to its frequency on the web, but I take your point.

I also plan on getting the documentation up to snuff because I know the effect that will have. I have experience learning with OpenCL (less successful, confusing documentation) and CUDA (more successful, coherent documentation). Yes there are other reasons as to the relative successes of OpenCL vs CUDA, but if we are trying to take marketshare from OpenCL and CUDA of both new and experienced users of heterogenous computing good documentation will go a long way.