www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DCompute is now in the master branch of LDC

reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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
May 29 2017
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
May 29 2017
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
May 29 2017
parent rikki cattermole <rikki cattermole.co.nz> writes:
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 :)
May 29 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 29 2017
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
May 29 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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"
May 29 2017
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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
May 29 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 29 2017
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
May 29 2017
prev sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Monday, 29 May 2017 at 20:36:26 UTC, Walter Bright wrote:

 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.


For what it's worth, I see "Compute" used all the time to refer 
to this stuff. OpenCL stands for Open Computing Language and 
you'll see it reference "compute devices" frequently in 
documentation about it. CUDA (originally) stood for Compute 
Unified Device Architecture.

We're all in the business of computation but the hardware 
accelerated processing people seem pretty keen on using "compute" 
to describe what they do. DCompute would fit right in and its 
purpose would be clear to anyone in that particular field, I 
think.
May 29 2017
next sibling parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 30 May 2017 at 16:00, Brad Anderson via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 On Monday, 29 May 2017 at 20:36:26 UTC, Walter Bright wrote:


 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.


 For what it's worth, I see "Compute" used all the time to refer to this
 stuff. OpenCL stands for Open Computing Language and you'll see it
 reference "compute devices" frequently in documentation about it. CUDA
 (originally) stood for Compute Unified Device Architecture.

 We're all in the business of computation but the hardware accelerated
 processing people seem pretty keen on using "compute" to describe what they
 do. DCompute would fit right in and its purpose would be clear to anyone in
 that particular field, I think.


I kinda wanted to add a +1 here too; I read 'compute' used as a noun(-ish)
as a synonym for GPGPU these days... I think the industry is more-or-less
agreed on that.
May 30 2017
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 30 May 2017 at 08:16:06 UTC, Manu wrote:

 I kinda wanted to add a +1 here too; I read 'compute' used as a 
 noun(-ish)


Ah, isn't English wonderful. I guess Walter is suffering the 
inverse of the Calvin & Hobbes "Verbing nouns weirds the 
language", nouning verbs does weird the language, but only to 
those who aren't used to that particular nouning of the verb.
May 30 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/30/2017 5:12 AM, Nicholas Wilson wrote:

 Ah, isn't English wonderful. I guess Walter is suffering the inverse of the 
 Calvin & Hobbes "Verbing nouns weirds the language", nouning verbs does weird 
 the language, but only to those who aren't used to that particular nouning of 
 the verb.


Just to clarify, I find that "Compute" is not evocative of "GPU". I read "CUDA 
by Example" a couple years ago, and even downloaded the CUDA SDK and 
compiled/ran a simple program on a graphics card. But I never noticed that 
"Compute" had anything specific to do with GPU programming.

I fear the conversation will go like this, like it has for me:

  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!

instead of:

  N: D-GPU
  W: Cool! I can use D to program GPUs!

The problem with the first conversation is W may just move on to the next topic 
rather than investigate what DCompute is.
May 30 2017
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 I fear the conversation will go like this, like it has for me:

  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!

 instead of:

  N: D-GPU
  W: Cool! I can use D to program GPUs!


This was literally what happened to me when I saw the headline.
May 30 2017
next sibling parent reply "H. S. Teoh via Digitalmars-d-announce" writes:
On Tue, May 30, 2017 at 07:23:42PM +0000, Jack Stouffer via
Digitalmars-d-announce wrote:

 On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 I fear the conversation will go like this, like it has for me:
 
  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!
 
 instead of:
 
  N: D-GPU
  W: Cool! I can use D to program GPUs!


 
 This was literally what happened to me when I saw the headline.


I confess the first conversation was also my reaction when I saw the
name "DCompute".  I thought, "oh, this is some kind of scientific
computation library, right? That comes with a set of standard numerical
algorithms?".  Programming GPUs did not occur to me at all.


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan
May 30 2017
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 30 May 2017 at 19:32:11 UTC, H. S. Teoh wrote:

 On Tue, May 30, 2017 at 07:23:42PM +0000, Jack Stouffer via 
 Digitalmars-d-announce wrote:

 On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 I fear the conversation will go like this, like it has for 
 me:
 
  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!
 
 instead of:
 
  N: D-GPU
  W: Cool! I can use D to program GPUs!


 
 This was literally what happened to me when I saw the headline.


 I confess the first conversation was also my reaction when I 
 saw the name "DCompute".  I thought, "oh, this is some kind of 
 scientific computation library, right? That comes with a set of 
 standard numerical algorithms?".  Programming GPUs did not 
 occur to me at all.


 T


Same with me.
May 30 2017
prev sibling next sibling parent Daniel Kozak via Digitalmars-d-announce writes:
Dne 30.5.2017 v 21:23 Jack Stouffer via Digitalmars-d-announce napsal(a):


 On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 I fear the conversation will go like this, like it has for me:

  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!

 instead of:

  N: D-GPU
  W: Cool! I can use D to program GPUs!


 This was literally what happened to me when I saw the headline.


Same for me. I was thinking about mir or about some big computation. I 
understand, there are people who are able to match compute with GPU, 
CUDA, OpenCL ..., but this does not change anything about wrong name.
It is nice to know, that there are people who will find this, but there 
will be plenty of us who will not.
May 30 2017
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Tuesday, May 30, 2017 19:23:42 Jack Stouffer via Digitalmars-d-announce 
wrote:

 On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 I fear the conversation will go like this, like it has for me:
  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!

 instead of:
  N: D-GPU
  W: Cool! I can use D to program GPUs!


 This was literally what happened to me when I saw the headline.


The same thing happened to me when dcompute was brought up at dconf.
Personally, "compute" just seems like a synonym for calculate that implies
that a computer was used. So, compute seems incredibly generic to me and has
no connection whatsoever to GPUs - but then again, I don't do GPU
programming at all. It wouldn't surprise me if what this comes down to is
that folks who regularly do GPU programming would think that compute likely
referred to the GPU, whereas those who don't wouldn't, but I don't know.
However, I would think having GPU in the name would connect with more people
than compute would, since it would also mean something to those who aren't
intimately familiar with the domain, whereas compute likely doesn't.

- Jonathan M Davis
May 30 2017
parent Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 30 May 2017 at 21:02:31 UTC, Jonathan M Davis wrote:

 It wouldn't surprise me if what this comes down to is that 
 folks who regularly do GPU programming would think that compute 
 likely referred to the GPU, whereas those who don't wouldn't, 
 but I don't know.



As someone who has done OpenGL, OpenCL and CUDA programming, I 
find the term "Compute" (especially with a capital) very adequate 
and related to GPU programming.

- Compute shaders
- OpenCL (Open Computing Language)

Compute APIs are not so much about the GPU that they are about 
reifying tasks and using multiple levels of memory explicitely 
(not all memory considered equal), so mentionning "GPU" feels a 
bit 2010 now that much more devices run OpenCL.
May 31 2017
prev sibling next sibling parent Wulfklaue <wulfklaue wulfklaue.com> writes:
On Tuesday, 30 May 2017 at 19:23:42 UTC, Jack Stouffer wrote:

 On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 I fear the conversation will go like this, like it has for me:

  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!

 instead of:

  N: D-GPU
  W: Cool! I can use D to program GPUs!


 This was literally what happened to me when I saw the headline.


Same here ...

DCompute may be a established term in that specific community but 
most other people do not pay attention to it. Yet, its a massive 
feature for any programming language, that is frankly being 
obscured by its naming.

While D-GPU may not be the most accurate term, as people may 
assume its about graphical programming, marketing and accuracy 
are not exactly the same. But that can be solved with later 
having D-DirectX, D-OpenGL...
May 31 2017
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/30/17 3:23 PM, Jack Stouffer wrote:

 On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 I fear the conversation will go like this, like it has for me:

  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!

 instead of:

  N: D-GPU
  W: Cool! I can use D to program GPUs!


 
 This was literally what happened to me when I saw the headline.


I'm in the same camp, and I have a passing familiarity with the domain. 
Worse, only one day after the talk I'd already forgotten and thought 
DCompute does what DHDL does.

It seems there are two paths - either choose an unrelated name and push 
it as a brand (e.g. Amazon, Google, and in our community Phobos or 
Vibe), or choose a name that immediately establishes the library as "the 
D approach to GPGPUs". The name "DCompute" is in an unfortunate corner 
of the branding space.


Andrei
May 31 2017
prev sibling parent Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 31 May 2017 at 05:32, H. S. Teoh via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 On Tue, May 30, 2017 at 07:23:42PM +0000, Jack Stouffer via
 Digitalmars-d-announce wrote:

 On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 I fear the conversation will go like this, like it has for me:

  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!

 instead of:

  N: D-GPU
  W: Cool! I can use D to program GPUs!


 This was literally what happened to me when I saw the headline.


 I confess the first conversation was also my reaction when I saw the
 name "DCompute".  I thought, "oh, this is some kind of scientific
 computation library, right? That comes with a set of standard numerical
 algorithms?".  Programming GPUs did not occur to me at all.


I'm becoming suspicious that people who don't interact with this technology
just don't know the terminology deployed in the field.
I think this is natural, and part of learning anything new.
But if it's not possible to select terminology that is intuitive to both
parties, *surely* the users/consumers of some technology should be first
priority in terms of not confusing them with industry-non-standard
terminology?
Users who are unfamiliar have already demonstrated that they likely have no
specific interest in a field (or they'd be aware of the conventional
terminology at least), and why would you cater to that crowd as the expense
of the actual users?
Jun 13 2017
prev sibling next sibling parent reply ParticlePeter <ParticlePeter gmx.de> writes:
On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 On 5/30/2017 5:12 AM, Nicholas Wilson wrote:

 Ah, isn't English wonderful. I guess Walter is suffering the 
 inverse of the Calvin & Hobbes "Verbing nouns weirds the 
 language", nouning verbs does weird the language, but only to 
 those who aren't used to that particular nouning of the verb.


 Just to clarify, I find that "Compute" is not evocative of 
 "GPU". I read "CUDA by Example" a couple years ago, and even 
 downloaded the CUDA SDK and compiled/ran a simple program on a 
 graphics card. But I never noticed that "Compute" had anything 
 specific to do with GPU programming.

 I fear the conversation will go like this, like it has for me:

  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!

 instead of:

  N: D-GPU
  W: Cool! I can use D to program GPUs!

 The problem with the first conversation is W may just move on 
 to the next topic rather than investigate what DCompute is.


D-GPU is very misleading to people who use the GPU for its 
original purpose, which is graphics programming. One could assume 
D-GPU being an alternative to Vulkan, OpenGL, DirectX.

The term 'compute' is well established with the community of 
people using the gpu for, well, compute purpose. You need to ask 
your self if you want to attract people who understand that term 
and are willing to use or try it with D, or if you want to inform 
a broader spectrum of people that 'D' can now do some (whatever) 
stuff on the 'GPU'.

So +1 for DCompute, but if you insist you should definitely 
narrow it down to D-GPGPU.
May 31 2017
next sibling parent Jonathan M Davis via Digitalmars-d-announce writes:
On Wednesday, May 31, 2017 09:07:16 ParticlePeter via Digitalmars-d-announce 
wrote:

 On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 On 5/30/2017 5:12 AM, Nicholas Wilson wrote:

 Ah, isn't English wonderful. I guess Walter is suffering the
 inverse of the Calvin & Hobbes "Verbing nouns weirds the
 language", nouning verbs does weird the language, but only to
 those who aren't used to that particular nouning of the verb.


 Just to clarify, I find that "Compute" is not evocative of
 "GPU". I read "CUDA by Example" a couple years ago, and even
 downloaded the CUDA SDK and compiled/ran a simple program on a
 graphics card. But I never noticed that "Compute" had anything
 specific to do with GPU programming.

 I fear the conversation will go like this, like it has for me:
  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!

 instead of:
  N: D-GPU
  W: Cool! I can use D to program GPUs!

 The problem with the first conversation is W may just move on
 to the next topic rather than investigate what DCompute is.


 D-GPU is very misleading to people who use the GPU for its
 original purpose, which is graphics programming. One could assume
 D-GPU being an alternative to Vulkan, OpenGL, DirectX.

 The term 'compute' is well established with the community of
 people using the gpu for, well, compute purpose. You need to ask
 your self if you want to attract people who understand that term
 and are willing to use or try it with D, or if you want to inform
 a broader spectrum of people that 'D' can now do some (whatever)
 stuff on the 'GPU'.

 So +1 for DCompute, but if you insist you should definitely
 narrow it down to D-GPGPU.


Something like d-compute-gpu or d-gpu-compute maybe?

I don't know. Maybe dcompute is fine, but it's clear that for a number of
folks, it's a pretty meaningless name. On the other hand, I don't know how
many of such folks would even be interestend in using it.

- Jonathan M Davis
May 31 2017
prev sibling next sibling parent Daniel Kozak via Digitalmars-d-announce writes:
Dne 31.5.2017 v 12:01 Jonathan M Davis via Digitalmars-d-announce napsal(a):

 On Wednesday, May 31, 2017 09:07:16 ParticlePeter via Digitalmars-d-announce
 wrote:

 On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 On 5/30/2017 5:12 AM, Nicholas Wilson wrote:

 Ah, isn't English wonderful. I guess Walter is suffering the
 inverse of the Calvin & Hobbes "Verbing nouns weirds the
 language", nouning verbs does weird the language, but only to
 those who aren't used to that particular nouning of the verb.


 Just to clarify, I find that "Compute" is not evocative of
 "GPU". I read "CUDA by Example" a couple years ago, and even
 downloaded the CUDA SDK and compiled/ran a simple program on a
 graphics card. But I never noticed that "Compute" had anything
 specific to do with GPU programming.

 I fear the conversation will go like this, like it has for me:
   N: DCompute
   W: What's DCompute?
   N: Enables GPU programming with D
   W: Cool!

 instead of:
   N: D-GPU
   W: Cool! I can use D to program GPUs!

 The problem with the first conversation is W may just move on
 to the next topic rather than investigate what DCompute is.


 D-GPU is very misleading to people who use the GPU for its
 original purpose, which is graphics programming. One could assume
 D-GPU being an alternative to Vulkan, OpenGL, DirectX.

 The term 'compute' is well established with the community of
 people using the gpu for, well, compute purpose. You need to ask
 your self if you want to attract people who understand that term
 and are willing to use or try it with D, or if you want to inform
 a broader spectrum of people that 'D' can now do some (whatever)
 stuff on the 'GPU'.

 So +1 for DCompute, but if you insist you should definitely
 narrow it down to D-GPGPU.


 Something like d-compute-gpu or d-gpu-compute maybe?

 I don't know. Maybe dcompute is fine, but it's clear that for a number of
 folks, it's a pretty meaningless name. On the other hand, I don't know how
 many of such folks would even be interestend in using it.

 - Jonathan M Davis


Why not just gpu-compute or GPUcompute
May 31 2017
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 31 May 2017 at 09:07:16 UTC, ParticlePeter wrote:

 On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 [...]


 D-GPU is very misleading to people who use the GPU for its 
 original purpose, which is graphics programming. One could 
 assume D-GPU being an alternative to Vulkan, OpenGL, DirectX.

 The term 'compute' is well established with the community of 
 people using the gpu for, well, compute purpose. You need to 
 ask your self if you want to attract people who understand that 
 term and are willing to use or try it with D, or if you want to 
 inform a broader spectrum of people that 'D' can now do some 
 (whatever) stuff on the 'GPU'.

 So +1 for DCompute, but if you insist you should definitely 
 narrow it down to D-GPGPU.


D-GPGPU is explicit.
May 31 2017
prev sibling next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

 On 5/30/2017 5:12 AM, Nicholas Wilson wrote:

 Ah, isn't English wonderful. I guess Walter is suffering the 
 inverse of the Calvin & Hobbes "Verbing nouns weirds the 
 language", nouning verbs does weird the language, but only to 
 those who aren't used to that particular nouning of the verb.


 Just to clarify, I find that "Compute" is not evocative of 
 "GPU". I read "CUDA by Example" a couple years ago, and even 
 downloaded the CUDA SDK and compiled/ran a simple program on a 
 graphics card. But I never noticed that "Compute" had anything 
 specific to do with GPU programming.

 I fear the conversation will go like this, like it has for me:

  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!

 instead of:

  N: D-GPU
  W: Cool! I can use D to program GPUs!

 The problem with the first conversation is W may just move on 
 to the next topic rather than investigate what DCompute is.


OK, I get that a portion of the community seems to think that 
dcompute is either too generic, is too easily passed over by the 
fact that it doesn't mention GPUs or otherwise could be named 
better.
I am more inclined to be persuaded by the fact that everybody 
that has actually done GPU programming has said that it makes 
sense to them.

But can we please reduce the bike shedding, that was not the 
point of this announcement, which was to bring together people 
interested in contributing to either the runtime libraries, LDC 
or LLVM and become familiar with goals, expected route of 
development and infrastructure.

Perhaps there will be scope for renaming if/when this also 
includes graphics when either OpenCL is merged into the Vulkan 
API or Petar Kirov gets Vulkan SPIRV generation going on LLVM, 
but for now the name stays.

Nic
May 31 2017
next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson wrote:


 I am more inclined to be persuaded by the fact that everybody 
 that has actually done GPU programming has said that it makes 
 sense to them.


It would be a mistake to judge that on the basis of those posting 
in this forum. I've done some GPU work, but "compute" doesn't 
mean anything to me. The R task view for HPC lists a bunch of GPU 
packages, none of which use "compute" in the name: 
https://cran.r-project.org/web/views/HighPerformanceComputing.html

I've also used PyCUDA and PyOpenCL, and am aware of PyMagma, none 
of which refer to "compute".


 But can we please reduce the bike shedding


Marketing is only bike shedding if you don't care how many people 
make use of your work.
May 31 2017
parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Wednesday, May 31, 2017 18:55:14 bachmeier via Digitalmars-d-announce 
wrote:

 On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson wrote:

 But can we please reduce the bike shedding


 Marketing is only bike shedding if you don't care how many people
 make use of your work.


That may be true, but given how this was supposed to be a thread on some
great news about this cool library, having most of the posts be about the
name has got to be frustrating.

Yes, the name matters, but this thread has been pretty thoroughly derailed
from its original purpose.

- Jonathan M Davis
May 31 2017
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/31/17 6:03 PM, Jonathan M Davis via Digitalmars-d-announce wrote:

 On Wednesday, May 31, 2017 18:55:14 bachmeier via Digitalmars-d-announce
 wrote:

 On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson wrote:

 But can we please reduce the bike shedding


 Marketing is only bike shedding if you don't care how many people
 make use of your work.


 
 That may be true, but given how this was supposed to be a thread on some
 great news about this cool library, having most of the posts be about the
 name has got to be frustrating.
 
 Yes, the name matters, but this thread has been pretty thoroughly derailed
 from its original purpose.
 
 - Jonathan M Davis


You're right. Congratulations Nicholas for this great work and I wish it 
succeeds by any name he chooses for it. -- Andrei
May 31 2017
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 1 June 2017 at 01:45:24 UTC, Andrei Alexandrescu 
wrote:

 You're right. Congratulations Nicholas for this great work and 
 I wish it succeeds by any name he chooses for it. -- Andrei


And nothing increases chances of success like contributions! 
(subtle hint)
May 31 2017
prev sibling parent bachmeier <no spam.net> writes:
On Wednesday, 31 May 2017 at 22:03:25 UTC, Jonathan M Davis wrote:


 Yes, the name matters, but this thread has been pretty 
 thoroughly derailed from its original purpose.

 - Jonathan M Davis


https://www.xkcd.com/386/
May 31 2017
prev sibling parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson wrote:

 Perhaps there will be scope for renaming if/when this also 
 includes graphics when either OpenCL is merged into the Vulkan 
 API or Petar Kirov gets Vulkan SPIRV generation going on LLVM, 
 but for now the name stays.


People who GPU program are indeed a small group. But you do NOT 
entice other people to try it, when they do not even know a 
language has this feature set. And this comes down to marketing.

Lets post "D has DCompute" or "D has D-GPU"... on Reddit, 
ycombinator and other forum or news site.

What do you think people will more likely click on?

The people who are used to Compute, will still click on the GPU 
link.

The people who are unfamiliar with Compute will still click on 
the GPU link, because its such a familiar term to them.

And so what if people start a big discussion about the name. If 
only 10% of those people come to the D site from a either 
language, its a instant success. Positive or negative marketing 
is a win-win in this case.

And GPU does not mean directly DirectX, OpenGL in people there 
minds. GPU people think about there graphical card because that 
is exactly what the term means.

I have no dog in this discussion but as somebody just learning D 
it seems like a total wasted opportunity.

Reading past topics D on those sites, it seems D has been 
fighting the whole GC stigma for years. D its GC marketing is 
bad. While other languages ( some even with GC like Go ) simply 
sail past, thanks to people pushing its virtues, when in reality 
D its GC actually performs better in specific tests. Marketing... 
 From my view D has been mostly sitting on its behind for years, 
hoping for word-to-mouth to do the trick. While other languages 
used there big parents name as a cheap talking point memo ( 
Apple, Google, Mozilla ... ).

And this is exactly why D has such difficulty being accepted 
outside its own community. People being too stubborn to recognize 
a marketing opportunity. My apologies for that comment but its 
true. D does not have the big name recognition and has a even 
"old" stigma these days.

My advice to Walter is to hire a actual marketing person that can 
help focus resources and ideas. Hell, even a name change, a new 
look, ... who knows.
May 31 2017
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 31 May 2017 at 22:15:33 UTC, Wulfklaue wrote:

 On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson 
 wrote:

 Perhaps there will be scope for renaming if/when this also 
 includes graphics when either OpenCL is merged into the Vulkan 
 API or Petar Kirov gets Vulkan SPIRV generation going on LLVM, 
 but for now the name stays.


 People who GPU program are indeed a small group. But you do NOT 
 entice other people to try it, when they do not even know a 
 language has this feature set. And this comes down to marketing.

 Lets post "D has DCompute" or "D has D-GPU"... on Reddit, 
 ycombinator and other forum or news site.

 What do you think people will more likely click on?


So you don't post either of those titles and instead post "D has 
DCompute: Native heterogeneous computing on GPUs and more, hassle 
free!"


 And so what if people start a big discussion about the name. If 
 only 10% of those people come to the D site from a either 
 language, its a instant success. Positive or negative marketing 
 is a win-win in this case.


For this discussion it is not the case, I haven't seen any new 
names.
So (everybody) please discontinue derailing this thread.


 My advice to Walter is to hire a actual marketing person that 
 can help focus resources and ideas.


Perhaps that is a good idea,  but it is not for me to decide. For 
my part in marketing I plan to give a talk/workshop at IWOCL just 
after DConf next may.
May 31 2017
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/31/17 7:28 PM, Nicholas Wilson wrote:

 On Wednesday, 31 May 2017 at 22:15:33 UTC, Wulfklaue wrote:

 On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson wrote:

 Perhaps there will be scope for renaming if/when this also includes 
 graphics when either OpenCL is merged into the Vulkan API or Petar 
 Kirov gets Vulkan SPIRV generation going on LLVM, but for now the 
 name stays.


 People who GPU program are indeed a small group. But you do NOT entice 
 other people to try it, when they do not even know a language has this 
 feature set. And this comes down to marketing.

 Lets post "D has DCompute" or "D has D-GPU"... on Reddit, ycombinator 
 and other forum or news site.

 What do you think people will more likely click on?


 
 So you don't post either of those titles and instead post "D has 
 DCompute: Native heterogeneous computing on GPUs and more, hassle free!"


"D has the invariant qualifier: It means immutable".
May 31 2017
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 1 June 2017 at 01:42:16 UTC, Andrei Alexandrescu 
wrote:

 On 5/31/17 7:28 PM, Nicholas Wilson wrote:

 On Wednesday, 31 May 2017 at 22:15:33 UTC, Wulfklaue wrote:

 On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson 
 wrote:

 Perhaps there will be scope for renaming if/when this also 
 includes graphics when either OpenCL is merged into the 
 Vulkan API or Petar Kirov gets Vulkan SPIRV generation going 
 on LLVM, but for now the name stays.


 People who GPU program are indeed a small group. But you do 
 NOT entice other people to try it, when they do not even know 
 a language has this feature set. And this comes down to 
 marketing.

 Lets post "D has DCompute" or "D has D-GPU"... on Reddit, 
 ycombinator and other forum or news site.

 What do you think people will more likely click on?


 
 So you don't post either of those titles and instead post "D 
 has DCompute: Native heterogeneous computing on GPUs and more, 
 hassle free!"


 "D has the invariant qualifier: It means immutable".


While that statement holds and is the whole story,


 D has DCompute: It means you can program GPUs with it


is not the whole story and is misleading in a marketing sense, 
but one that undersells dcompute, not oversells it.

whereas


 D has DCompute: Native heterogeneous computing on GPUs and 
 more, hassle free!


does tell the whole story and sells dcompute as it is.
May 31 2017
prev sibling parent Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 1 June 2017 at 09:28, Nicholas Wilson via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 On Wednesday, 31 May 2017 at 22:15:33 UTC, Wulfklaue wrote:


 And so what if people start a big discussion about the name. If only 10%
 of those people come to the D site from a either language, its a instant
 success. Positive or negative marketing is a win-win in this case.


 For this discussion it is not the case, I haven't seen any new names.
 So (everybody) please discontinue derailing this thread.



Oops, sorry! Just caught up >_<
Jun 13 2017
prev sibling parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 31 May 2017 at 04:06, Walter Bright via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 On 5/30/2017 5:12 AM, Nicholas Wilson wrote:


 Ah, isn't English wonderful. I guess Walter is suffering the inverse of
 the Calvin & Hobbes "Verbing nouns weirds the language", nouning verbs does
 weird the language, but only to those who aren't used to that particular
 nouning of the verb.


 Just to clarify, I find that "Compute" is not evocative of "GPU". I read
 "CUDA by Example" a couple years ago, and even downloaded the CUDA SDK and
 compiled/ran a simple program on a graphics card. But I never noticed that
 "Compute" had anything specific to do with GPU programming.

 I fear the conversation will go like this, like it has for me:

  N: DCompute
  W: What's DCompute?
  N: Enables GPU programming with D
  W: Cool!

 instead of:

  N: D-GPU
  W: Cool! I can use D to program GPUs!

 The problem with the first conversation is W may just move on to the next
 topic rather than investigate what DCompute is.



See, I would have a very different conversation:

 N: DCompute
 M: Awesome, I've been waiting!

instead of:

 N: D-GPU
 M: What's that... is it, like, a rendering library?
 N: No, it's a 'compute' library.
 M: Ohhh, awesome! I've been waiting!

;)
Jun 13 2017
parent reply solidstate1991 <laszloszeremi outlook.com> writes:
On Wednesday, 14 June 2017 at 05:43:01 UTC, Manu wrote:

 See, I would have a very different conversation:

  N: DCompute
  M: Awesome, I've been waiting!

 instead of:

  N: D-GPU
  M: What's that... is it, like, a rendering library?
  N: No, it's a 'compute' library.
  M: Ohhh, awesome! I've been waiting!

 ;)


Also "D-GPU" implies that it's only for GPUs. Granted, there's a 
lot of similarities (early 3D accelerators in arcade cabinets 
were often built from multiple DSPs, GPUs always have VLIW and 
FMA capabilities, FPGAs can function as either as DSP or GPU with 
limitations, etc), but we still need some distinction. Even CPUs 
have OpenCL capabilities (my good old Athlon 64 x2 supports up to 
1.1).

Other than I'm planning to using DCompute to implement "GPU 
blitter" (as I couldn't find any hardware acceleration API for 
raster graphics besides the long obsolete DirectDraw), but I'm 
also thinking on if I could implement some physical modelling 
audio engine, that would compile reverberation in real time for a 
virtual room, enabling it to be used in games (game audio haven't 
advanced as much as graphics unfortunately).
Jun 15 2017
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 16 June 2017 at 01:19:56 UTC, solidstate1991 wrote:

 Other than I'm planning to using DCompute to implement "GPU 
 blitter" (as I couldn't find any hardware acceleration API for 
 raster graphics besides the long obsolete DirectDraw), but I'm 
 also thinking on if I could implement some physical modelling 
 audio engine, that would compile reverberation in real time for 
 a virtual room, enabling it to be used in games (game audio 
 haven't advanced as much as graphics unfortunately).


Sounds cool! (BTW are you ZILtoid1991 on GitHub?)

Do let me know what features (support for images etc.) you need 
to do the projects you are working on. There is a lot to be done, 
but most of the features I am looking to add can be developed 
independently. Of course collaboration will accelerate 
development.

Also, I am looking for people who would be interested talking at 
IWOCL, the international workshop on OpenCL, about the user 
experience of dcompute (productivity, optimisation, debugging, 
API intuition/ease of use) in Edinburgh, May 15-17 next year, if 
anyone that has interesting projects they have made progress on.
Jun 15 2017
prev sibling parent reply piotrklos <poliklosio happypizza.com> writes:
On Tuesday, 30 May 2017 at 06:00:57 UTC, Brad Anderson wrote:

 On Monday, 29 May 2017 at 20:36:26 UTC, Walter Bright wrote:

 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.


 For what it's worth, I see "Compute" used all the time to refer 
 to this stuff. OpenCL stands for Open Computing Language and 
 you'll see it reference "compute devices" frequently in 
 documentation about it. CUDA (originally) stood for Compute 
 Unified Device Architecture.

 We're all in the business of computation but the hardware 
 accelerated processing people seem pretty keen on using 
 "compute" to describe what they do. DCompute would fit right in 
 and its purpose would be clear to anyone in that particular 
 field, I think.


+1
May 30 2017
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 30 May 2017 at 12:21:02 UTC, piotrklos wrote:

 On Tuesday, 30 May 2017 at 06:00:57 UTC, Brad Anderson wrote:

 On Monday, 29 May 2017 at 20:36:26 UTC, Walter Bright wrote:

 [...]


 For what it's worth, I see "Compute" used all the time to 
 refer to this stuff. OpenCL stands for Open Computing Language 
 and you'll see it reference "compute devices" frequently in 
 documentation about it. CUDA (originally) stood for Compute 
 Unified Device Architecture.

 We're all in the business of computation but the hardware 
 accelerated processing people seem pretty keen on using 
 "compute" to describe what they do. DCompute would fit right 
 in and its purpose would be clear to anyone in that particular 
 field, I think.


 +1


+1
May 30 2017
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 30 May 2017 at 14:25:12 UTC, Atila Neves wrote:

 On Tuesday, 30 May 2017 at 12:21:02 UTC, piotrklos wrote:

 On Tuesday, 30 May 2017 at 06:00:57 UTC, Brad Anderson wrote:

 On Monday, 29 May 2017 at 20:36:26 UTC, Walter Bright wrote:

 [...]


 For what it's worth, I see "Compute" used all the time to 
 refer to this stuff. OpenCL stands for Open Computing 
 Language and you'll see it reference "compute devices" 
 frequently in documentation about it. CUDA (originally) stood 
 for Compute Unified Device Architecture.

 We're all in the business of computation but the hardware 
 accelerated processing people seem pretty keen on using 
 "compute" to describe what they do. DCompute would fit right 
 in and its purpose would be clear to anyone in that 
 particular field, I think.


 +1


 +1


-1

When I see compute I think also at mir glas, BLAS, GEMM stuff, 
i.e. HPC stuff. There is often GPGPU involved but not necessarily.
May 30 2017
prev sibling parent reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Monday, 29 May 2017 at 09:33:05 UTC, 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


Hi,

I would like to know :
  - what we can do with the library name "dcompute" ?
Does this means that I can wrote In Dlang a piece of code and 
execute it on the GPU ?

  - where can I find some example ?

Thanks
Jun 19 2017
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 19 June 2017 at 08:24:09 UTC, bioinfornatics wrote:

 On Monday, 29 May 2017 at 09:33:05 UTC, 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


 Hi,

 I would like to know :
  - what we can do with the library name "dcompute" ?


The library enables you to launch kernels written with the 
accompanying complier extensions (the focus of this 
announcement). It also provides the intrinsics to enable writing 
the kernels.

 Does this means that I can wrote In Dlang a piece of code and 
 execute it on the GPU ?


Yes, with some restrictions: recursion is prohibited, as are 
classes exceptions, the keyword 'synchronized' global variables 
(for now) and probably some others that I'm forgetting.

  - where can I find some example ?


There are some examples on the wiki 
(https://github.com/libmir/dcompute/wiki), although they are 
likely incomplete and slightly out of date. I will be updating 
and greatly improving them as development progresses (continuing 
about halfway through July).

If you have any questions feel free to ask them on 
https://gitter.im/libmir/public.
Jun 19 2017
parent reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Monday, 19 June 2017 at 12:46:16 UTC, Nicholas Wilson wrote:

 On Monday, 19 June 2017 at 08:24:09 UTC, bioinfornatics wrote:

  [...]


 The library enables you to launch kernels written with the 
 accompanying complier extensions (the focus of this 
 announcement). It also provides the intrinsics to enable 
 writing the kernels.

 [...]


 Yes, with some restrictions: recursion is prohibited, as are 
 classes exceptions, the keyword 'synchronized' global variables 
 (for now) and probably some others that I'm forgetting.

  [...]


 There are some examples on the wiki 
 (https://github.com/libmir/dcompute/wiki), although they are 
 likely incomplete and slightly out of date. I will be updating 
 and greatly improving them as development progresses 
 (continuing about halfway through July).

 If you have any questions feel free to ask them on 
 https://gitter.im/libmir/public.


I take a look at dcompute example and find any example how to 
interact with FPGAs!
Could we have a tutorial how to build a D program in order to 
works with FPGA ?

Thanks,

Best regards
Apr 18 2018
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 18 April 2018 at 07:10:12 UTC, bioinfornatics wrote:

 On Monday, 19 June 2017 at 12:46:16 UTC, Nicholas Wilson wrote:

 On Monday, 19 June 2017 at 08:24:09 UTC, bioinfornatics wrote:

  [...]


 The library enables you to launch kernels written with the 
 accompanying complier extensions (the focus of this 
 announcement). It also provides the intrinsics to enable 
 writing the kernels.

 [...]


 Yes, with some restrictions: recursion is prohibited, as are 
 classes exceptions, the keyword 'synchronized' global 
 variables (for now) and probably some others that I'm 
 forgetting.

  [...]


 There are some examples on the wiki 
 (https://github.com/libmir/dcompute/wiki), although they are 
 likely incomplete and slightly out of date. I will be updating 
 and greatly improving them as development progresses 
 (continuing about halfway through July).

 If you have any questions feel free to ask them on 
 https://gitter.im/libmir/public.


 I take a look at dcompute example and find any example how to 
 interact with FPGAs!
 Could we have a tutorial how to build a D program in order to 
 works with FPGA ?

 Thanks,

 Best regards


 From what I understand It should "just work" if you have an FPGA 
OpenCL runtime installed.

I'd love to test that but I lack both time and an FPGA to do it. 
I'll be improving dcompute significantly once I graduate and have 
the time to do so.
Apr 18 2018