digitalmars.D.announce - DCompute is now in the master branch of LDC
- Nicholas Wilson (18/18) May 29 2017 Hi all,
- rikki cattermole (4/23) May 29 2017 Can someone please write up a post e.g. for the D blog to act as the
- Nicholas Wilson (13/39) May 29 2017 I promised Mike a blog post at dconf, but I'd prefer this to be
- rikki cattermole (2/40) May 29 2017 Ok so announce only within D community atm. Good to know :)
- Walter Bright (5/24) May 29 2017 Congratulations! This is great work, and a great contribution.
- Nicholas Wilson (8/37) May 29 2017 Thanks, I called it dcompute because naming things is right up
- Walter Bright (19/28) May 29 2017 From https://github.com/libmir/dcompute :
- Nicholas Wilson (10/40) May 29 2017 Well the GitHub project description is "Native execution of D on
- Walter Bright (6/10) May 29 2017 Good. Making the content google-friendly is also extremely important. Ba...
- Nicholas Wilson (13/24) May 29 2017 I suspect that this will have less of an effect dcompute as
- Brad Anderson (11/16) May 29 2017 For what it's worth, I see "Compute" used all the time to refer
- Manu via Digitalmars-d-announce (5/21) May 30 2017 I kinda wanted to add a +1 here too; I read 'compute' used as a noun(-is...
- Nicholas Wilson (5/7) May 30 2017 Ah, isn't English wonderful. I guess Walter is suffering the
- Walter Bright (15/19) May 30 2017 Just to clarify, I find that "Compute" is not evocative of "GPU". I read...
- Jack Stouffer (2/10) May 30 2017 This was literally what happened to me when I saw the headline.
- H. S. Teoh via Digitalmars-d-announce (8/22) May 30 2017 I confess the first conversation was also my reaction when I saw the
- Patrick Schluter (2/25) May 30 2017 Same with me.
- Daniel Kozak via Digitalmars-d-announce (6/19) May 30 2017 Same for me. I was thinking about mir or about some big computation. I
- Jonathan M Davis via Digitalmars-d-announce (13/24) May 30 2017 The same thing happened to me when dcompute was brought up at dconf.
- Guillaume Piolat (10/14) May 31 2017 As someone who has done OpenGL, OpenCL and CUDA programming, I
- Wulfklaue (10/23) May 31 2017 Same here ...
- Andrei Alexandrescu (10/24) May 31 2017 I'm in the same camp, and I have a passing familiarity with the domain.
- Manu via Digitalmars-d-announce (13/33) Jun 13 2017 I'm becoming suspicious that people who don't interact with this technol...
- ParticlePeter (12/32) May 31 2017 D-GPU is very misleading to people who use the GPU for its
- Jonathan M Davis via Digitalmars-d-announce (7/43) May 31 2017 Something like d-compute-gpu or d-gpu-compute maybe?
- Daniel Kozak via Digitalmars-d-announce (2/46) May 31 2017 Why not just gpu-compute or GPUcompute
- Patrick Schluter (2/15) May 31 2017 D-GPGPU is explicit.
- Nicholas Wilson (18/38) May 31 2017 OK, I get that a portion of the community seems to think that
- bachmeier (10/14) May 31 2017 It would be a mistake to judge that on the basis of those posting
- Jonathan M Davis via Digitalmars-d-announce (8/12) May 31 2017 That may be true, but given how this was supposed to be a thread on some
- Andrei Alexandrescu (3/19) May 31 2017 You're right. Congratulations Nicholas for this great work and I wish it...
- Nicholas Wilson (4/6) May 31 2017 And nothing increases chances of success like contributions!
- bachmeier (2/5) May 31 2017 https://www.xkcd.com/386/
- Wulfklaue (37/41) May 31 2017 People who GPU program are indeed a small group. But you do NOT
- Nicholas Wilson (10/28) May 31 2017 So you don't post either of those titles and instead post "D has
- Andrei Alexandrescu (2/21) May 31 2017 "D has the invariant qualifier: It means immutable".
- Nicholas Wilson (7/34) May 31 2017 While that statement holds and is the whole story,
- Manu via Digitalmars-d-announce (3/11) Jun 13 2017 Oops, sorry! Just caught up >_<
- Manu via Digitalmars-d-announce (11/31) Jun 13 2017 See, I would have a very different conversation:
- solidstate1991 (15/24) Jun 15 2017 Also "D-GPU" implies that it's only for GPUs. Granted, there's a
- Nicholas Wilson (12/19) Jun 15 2017 Sounds cool! (BTW are you ZILtoid1991 on GitHub?)
- piotrklos (2/20) May 30 2017 +1
- Atila Neves (2/18) May 30 2017 +1
- Patrick Schluter (4/23) May 30 2017 -1
- bioinfornatics (8/26) Jun 19 2017 Hi,
- Nicholas Wilson (15/44) Jun 19 2017 The library enables you to launch kernels written with the
- bioinfornatics (7/25) Apr 18 2018 I take a look at dcompute example and find any example how to
- Nicholas Wilson (6/36) Apr 18 2018 From what I understand It should "just work" if you have an FPGA
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
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/ldcCan 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
On Monday, 29 May 2017 at 09:39:53 UTC, rikki cattermole wrote:On 29/05/2017 10:33 AM, Nicholas Wilson wrote: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.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/ldcCan 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
On 29/05/2017 10:52 AM, Nicholas Wilson wrote:On Monday, 29 May 2017 at 09:39:53 UTC, rikki cattermole wrote:Ok so announce only within D community atm. Good to know :)On 29/05/2017 10:33 AM, Nicholas Wilson wrote: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.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/ldcCan 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
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/ldcCongratulations! 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
On Monday, 29 May 2017 at 20:36:26 UTC, Walter Bright wrote:On 5/29/2017 2:33 AM, Nicholas Wilson wrote: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.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/ldcCongratulations! 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
On 5/29/2017 3:52 PM, Nicholas Wilson wrote: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')."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.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
On Tuesday, 30 May 2017 at 00:12:51 UTC, Walter Bright wrote:On 5/29/2017 3:52 PM, Nicholas Wilson wrote:OK, I should probably reword that.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')."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.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-topicsThe 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
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-topicsGood. 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
On Tuesday, 30 May 2017 at 02:46:12 UTC, Walter Bright wrote:On 5/29/2017 6:10 PM, Nicholas Wilson wrote: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.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-topicsGood. 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
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
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: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 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 30 2017
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
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
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
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 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 -- CompuManI 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
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:Same with me.On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote: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. TI 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
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: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.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
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: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 DavisI 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
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
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: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...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 31 2017
On 5/30/17 3:23 PM, Jack Stouffer wrote:On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote: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. AndreiI 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 31 2017
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: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?On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote: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 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.
Jun 13 2017
On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:On 5/30/2017 5:12 AM, Nicholas Wilson 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.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 31 2017
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: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 DavisOn 5/30/2017 5:12 AM, Nicholas Wilson 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.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 31 2017
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:Why not just gpu-compute or GPUcomputeOn Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote: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 DavisOn 5/30/2017 5:12 AM, Nicholas Wilson 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.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 31 2017
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-GPGPU is explicit.[...]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
On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:On 5/30/2017 5:12 AM, Nicholas Wilson wrote: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. NicAh, 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 31 2017
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 sheddingMarketing is only bike shedding if you don't care how many people make use of your work.
May 31 2017
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: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 DavisBut can we please reduce the bike sheddingMarketing is only bike shedding if you don't care how many people make use of your work.
May 31 2017
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:You're right. Congratulations Nicholas for this great work and I wish it succeeds by any name he chooses for it. -- AndreiOn Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson wrote: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 DavisBut can we please reduce the bike sheddingMarketing is only bike shedding if you don't care how many people make use of your work.
May 31 2017
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. -- AndreiAnd nothing increases chances of success like contributions! (subtle hint)
May 31 2017
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 Davishttps://www.xkcd.com/386/
May 31 2017
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
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:So you don't post either of those titles and instead post "D has DCompute: Native heterogeneous computing on GPUs and more, hassle free!"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?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
On 5/31/17 7:28 PM, Nicholas Wilson wrote:On Wednesday, 31 May 2017 at 22:15:33 UTC, Wulfklaue wrote:"D has the invariant qualifier: It means immutable".On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson wrote:So you don't post either of those titles and instead post "D has DCompute: Native heterogeneous computing on GPUs and more, hassle free!"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?
May 31 2017
On Thursday, 1 June 2017 at 01:42:16 UTC, Andrei Alexandrescu wrote:On 5/31/17 7:28 PM, Nicholas Wilson wrote:While that statement holds and is the whole story,On Wednesday, 31 May 2017 at 22:15:33 UTC, Wulfklaue wrote:"D has the invariant qualifier: It means immutable".On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson wrote:So you don't post either of those titles and instead post "D has DCompute: Native heterogeneous computing on GPUs and more, hassle free!"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?D has DCompute: It means you can program GPUs with itis not the whole story and is misleading in a marketing sense, but one that undersells dcompute, not oversells it. whereasD 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
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:Oops, sorry! Just caught up >_<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.
Jun 13 2017
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: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! ;)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.
Jun 13 2017
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
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
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:+1May 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 30 2017
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:+1On Monday, 29 May 2017 at 20:36:26 UTC, Walter Bright wrote:+1[...]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 30 2017
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:-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.On Tuesday, 30 May 2017 at 06:00:57 UTC, Brad Anderson wrote:+1On Monday, 29 May 2017 at 20:36:26 UTC, Walter Bright wrote:+1[...]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 30 2017
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/ldcHi, 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
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: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.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/ldcHi, 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 ?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
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: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[...]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.
Apr 18 2018
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: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.On Monday, 19 June 2017 at 08:24:09 UTC, bioinfornatics wrote: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[...]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.
Apr 18 2018