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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
parent 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