Re: DConf 2017 Early Bird Registration expires Monday!
On 2017-02-28 07:08, Walter Bright wrote: I had sent a confirmation email. Unfortunately, there are often problems with this, as the emails get put in the recipient's spam folder. Could we please just fix the problem. This is quite embarrassing. I reported the problem the day the registration opened, a fix was applied fairly quickly but apparently it didn't work. I don't know how to fix the problem so I cannot help. -- /Jacob Carlborg
Re: DConf 2017 Early Bird Registration expires Monday!
On 2/27/2017 3:09 AM, Dentcho Bankov wrote: So I'm in the same boat (paid with PayPal and got 404 on 13-Feb-2017). Is there a chance I could get a ticket (or some confirmation)? I had sent a confirmation email. Unfortunately, there are often problems with this, as the emails get put in the recipient's spam folder.
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Monday, 27 February 2017 at 15:41:18 UTC, Seb wrote: Is it redditable? Yes, finally :) I'm thinking it might be better to do a blog post about it and reddit that instead of posting a link to the docs or this announcement directly. Something describing the implementation and the "writeln transformation magic". Up for it?
Re: DCompute - Native heterogeneous computing for D - is here!
On Sunday, 26 February 2017 at 08:37:29 UTC, Nicholas Wilson
wrote:
DCompute is an extension to LDC capable of generating code
(with no language changes*) for NVIDIA's NVPTX for use with
CUDA, SPIRV for use with the OpenCL runtime, and of course the
host, all at the same time! It is also possible to share
implementation of algorithms across the host and device.
This will enable writing kernels in D utilising all of D's meta
programming goodness across the device divide and will allow
launching those kernels with a level of ease on par with CUDA's
<<<...>>> syntax. I hope to be giving a talk at DConf2017 about
this ;), what it enables us to do, what still needs to be done
and future plans.
DCompute supports all of OpenCL except Images and Pipes
(support is planned though).
I haven't done any test for CUDA so I'm not sure about the
extent of support for it, all of the math stuff works,
images/textures not so sure.
Many thanks to the ldc team (especially Johan) for their
guidance and patience, Ilya for reminding me that I should
upstream my work and John Colvin for his DConf2016 talk for
making me think 'surely compiler support can't be too hard'. 10
months later: here it is!
The DCompute compiler is available at the dcompute branch of
ldc [0], you will need my fork of llvm here[1] and the SPIRV
submodule that comes with it [2] as the llvm to link against.
There is also a tool for interconversion [3] (I've mucked up
the submodules a bit, sorry, just clone it into
'tools/llvm-spirv', it's not necessary anyway). The device
standard library and drivers (both WIP) are available here[4].
Please sent bug reports to their respective components,
although I'm sure I'll see them anyway regardless of where they
go.
[0]: https://github.com/ldc-developers/ldc/tree/dcompute
[1]: https://github.com/thewilsonator/llvm/tree/compute
[2]: https://github.com/thewilsonator/llvm-target-spirv
[3]: https://github.com/thewilsonator/llvm-tool-spirv
[4]: https://github.com/libmir/dcompute
* modulo one hack related to resolving intrinsics because there
is no static context (i.e. static if) for the device(s).
Basically a 'codegen time if'.
An simple example because I forgot.
```
@compute(CompileFor.deviceOnly) module example;
import ldc.attributes;
import ldc.dcomputetypes;
import dcompute.std.index;
@kernel void test(GlobalPointer!float a, GlobalPointer!float b)
{
auto idx = GlobalIndex.x;
a[idx] = a[idx] + b[idx];
}
```
then compile with `ldc -mdcompute-targets=ocl-220,cuda-500
example.d -I/path/to/dcompute`. It will produce two files,
kernels_ocl220_64.spv and kernels_cuda500_64.ptx when built in
64-bit mode and kernels_ocl220_32.spv and kernels_cuda500_32.ptx
in 32 bit mode.
Re: DCompute - Native heterogeneous computing for D - is here!
On Monday, 27 February 2017 at 23:02:43 UTC, Nicholas Wilson wrote: Interesting to write kernels in D, since a limitation of CUDA is that you need to multiply the entry points to instantiate a template differently, and a limitation of OpenCL C is that you need templates and includes in the first place. Wait you mean you have to explicitly instantiate every instance of a templated kernel? Ouch. IIRC, that entry point explosion happens in CUDA when you separate strictly host and device code. Not sure for mixed mode as I've never used that. I should first emphasise the future tense of the second half of the sentence you quoted. How does this work? DCompute (the compiler infrastructure) is currently capable of building .ptx and .spv as part of the compilation process. They can be used directly in any process pipeline you may have already. .ptx, got it. Does the host code need something like DerelictCL/CUDA to work? If you want to call the kernel, yes. The eventual goal of DCompute (the D infrastructure) is to fully wrap and unify and abstract the OpeCL/CUDA runtime libraries (most likely provided by Derelict), and have something like: Interesting. Let me know if you need more things in OpenCL bindings.
Re: DCompute - Native heterogeneous computing for D - is here!
On Monday, 27 February 2017 at 13:55:23 UTC, Guillaume Piolat wrote: On Sunday, 26 February 2017 at 08:37:29 UTC, Nicholas Wilson wrote: This will enable writing kernels in D utilising all of D's meta programming goodness across the device divide and will allow launching those kernels with a level of ease on par with CUDA's <<<...>>> syntax. Interesting to write kernels in D, since a limitation of CUDA is that you need to multiply the entry points to instantiate a template differently, and a limitation of OpenCL C is that you need templates and includes in the first place. Wait you mean you have to explicitly instantiate every instance of a templated kernel? Ouch. In D all you need do is have a reference to it somewhere, taking it's .mangleof suffices and is (part of) how the example below will achieve its elegance. I should first emphasise the future tense of the second half of the sentence you quoted. How does this work? DCompute (the compiler infrastructure) is currently capable of building .ptx and .spv as part of the compilation process. They can be used directly in any process pipeline you may have already. Does the host code need something like DerelictCL/CUDA to work? If you want to call the kernel, yes. The eventual goal of DCompute (the D infrastructure) is to fully wrap and unify and abstract the OpeCL/CUDA runtime libraries (most likely provided by Derelict), and have something like: ``` Queue q = ...; Buffer b = ...; q.enqueue!(myTemplatedKernel!(Foo,bar,baz => myTransform(baz)))(b,other, args); ``` Although, there is no need to wait until DCompute reaches that point to use it, you would just have to do the (rather painful) API bashing yourself.
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Monday, 27 February 2017 at 17:13:24 UTC, Seb wrote: A solution for the moment is to point people at the ddoc version, e.g. https://dlang.org/phobos/std_algorithm_comparison.html#.among Sure, linking only that would definitely work. — David
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Monday, 27 February 2017 at 16:49:13 UTC, David Nadlinger wrote: See e.g. https://dlang.org/library-prerelease/std/algorithm/comparison/among.html from above. This leaves quite the bad impression, as it makes the page look like an unstructured mess at first glance. What's up with the bullet point list at the top of the page? I'd understand it if they were links to the specific overloads, but just being text it seems silly to have it there. Even repeating the ditto wouldn't bother me if it was linked or something... And ddoc fails to display that sanely too, it shows the outer template, but not the inner function you'd actually use. Thankfully, the examples cover it, but IMO neither ddoc nor ddox actually do a good job on this. BTW, this is how my doc site renders that: http://dpldocs.info/experimental-docs/std.algorithm.comparison.among.1.html I also do a list of overloads, but present them as an accordian-style list of links with an argument summary so you can see at a glance what one might be which. (I'm not 100% in love with my doc here either, but I do like it better than either option on dlang.org. Y'all should start stealing my ideas.)
Re: Schema for ndslice internals
On 2017-02-26 14:13, Ilya Yaroshenko wrote: https://github.com/libmir/mir-algorithm/blob/master/README.md Schemas and other visuals are great! I'm not using ndslice at the moment, but I might; thanks in advance!
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Monday, 27 February 2017 at 16:49:13 UTC, David Nadlinger wrote: On Monday, 27 February 2017 at 15:41:18 UTC, Seb wrote: Is it redditable? Yes, finally :) Can we fix the fact that the docs are duplicated for template functions before any big announcements? See e.g. https://dlang.org/library-prerelease/std/algorithm/comparison/among.html from above. That's one of the disadvantages of running two documentation engines. Related pointers: https://github.com/dlang/dlang.org/pull/1526 (making ddox the default) https://github.com/rejectedsoftware/ddox/issues This leaves quite the bad impression, as it makes the page look like an unstructured mess at first glance. A solution for the moment is to point people at the ddoc version, e.g. https://dlang.org/phobos/std_algorithm_comparison.html#.among
Re: It's alive! D building D building D, all on Android
On Thursday, 29 December 2016 at 09:16:58 UTC, Joakim wrote: On Sunday, 15 May 2016 at 11:09:01 UTC, Joakim wrote: On Wednesday, 11 May 2016 at 19:07:10 UTC, Joakim wrote: [...] I've put up three more builds, including ldc master, which uses the latest 2.071 frontend. Once I get JNI and the sample app working, I'll make a proper announcement. I've put up the latest native and cross-compiler ldc 1.1.0 beta builds for Android, fresh from the master branch and using the 2.071 frontend: https://github.com/joakim-noah/android/releases I believe I've fixed the issue that was causing random crashes in the sample apps, a regression from porting the NDK's C wrapper to D, found by Vadim Lopatim. I've added three sample apps that demonstrate calling D code from JNI. The sample C++ Teapot app from the NDK has been ported to D and mostly works, including calling Java methods from D through JNI, but I need to track down some other touch-related bugs from the port before committing it. I'm finishing up reggae files to make building the sample apps very easy. I'd like to write up the process to build and use ldc natively on your Android mobile device, from the Termux app, on the wiki. Once those three are done, I'll create a new thread to properly announce this beta; in the meantime, nothing will change with these new beta builds, so try them out. Piping hot builds of the upcoming ldc 1.1.1 release available as both a linux/x64 -> Android/ARM cross-compiler and a native Android/ARM compiler, that you can run on your own phone or tablet: https://github.com/joakim-noah/android/releases I finally spent some time tracking down that touch bug in the sample Teapot app, think I know where it's coming from now, just need to fix it.
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Monday, 27 February 2017 at 15:41:18 UTC, Seb wrote: Is it redditable? Yes, finally :) Can we fix the fact that the docs are duplicated for template functions before any big announcements? See e.g. https://dlang.org/library-prerelease/std/algorithm/comparison/among.html from above. This leaves quite the bad impression, as it makes the page look like an unstructured mess at first glance. - David
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Monday, 27 February 2017 at 14:12:30 UTC, Mike Parker wrote: On Wednesday, 22 February 2017 at 19:14:14 UTC, Seb wrote: Okay I just couldn't let this sit on myself. So I went ahead and proposed a more "sophisticated" assert -> writeln rewrite tool that is based on Hackerpilot's excellent libdparse: https://github.com/dlang/dlang.org/pull/1582 So is everything working as advertised? Yes, thanks to a lot of support from CyberShadow [1] and Hackerpilot's immediate review of my libdparse fixes [2, 3], the new assert -> writeln logic is now live, e.g. Ddox: https://dlang.org/library-prerelease/std/algorithm/comparison/among.html Ddoc: https://dlang.org/phobos/std_algorithm_searching.html#.minElement It's based on a AST transformation of the AssertExpressions. For more details one can have a look at [4]. Is it redditable? Yes, finally :) [1] https://github.com/dlang/dlang.org/pull/1582 [2] https://github.com/Hackerpilot/libdparse/pull/128 [3] https://github.com/Hackerpilot/libdparse/pull/130 [4] https://github.com/dlang/dlang.org/blob/master/assert_writeln_magic.d
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Wednesday, 22 February 2017 at 19:14:14 UTC, Seb wrote: Okay I just couldn't let this sit on myself. So I went ahead and proposed a more "sophisticated" assert -> writeln rewrite tool that is based on Hackerpilot's excellent libdparse: https://github.com/dlang/dlang.org/pull/1582 So is everything working as advertised? Is it redditable?
Re: DCompute - Native heterogeneous computing for D - is here!
On Sunday, 26 February 2017 at 08:37:29 UTC, Nicholas Wilson wrote: This will enable writing kernels in D utilising all of D's meta programming goodness across the device divide and will allow launching those kernels with a level of ease on par with CUDA's <<<...>>> syntax. Interesting to write kernels in D, since a limitation of CUDA is that you need to multiply the entry points to instantiate a template differently, and a limitation of OpenCL C is that you need templates and includes in the first place. How does this work? Does the host code need something like DerelictCL to work?
Re: DCompute - Native heterogeneous computing for D - is here!
On Monday, 27 February 2017 at 13:19:00 UTC, Nicholas Wilson wrote: Actually I've got the submodules working so feel free to go ahead, the release is only for OSX for ldc's CI. If you could let me know when that window is I could post an AMA if I'm awake then. Direct your AMA here: https://www.reddit.com/r/programming/comments/5wgqmb/dcompute_native_heterogeneous_computing_for_d_is/
Re: DCompute - Native heterogeneous computing for D - is here!
On Monday, 27 February 2017 at 13:19:00 UTC, Nicholas Wilson wrote: Actually I've got the submodules working so feel free to go ahead, the release is only for OSX for ldc's CI. If you could let me know when that window is I could post an AMA if I'm awake then. Now is a great time.
Re: DCompute - Native heterogeneous computing for D - is here!
On Monday, 27 February 2017 at 09:13:22 UTC, Mike Parker wrote: On Monday, 27 February 2017 at 08:37:56 UTC, Nicholas Wilson wrote: On Sunday, 26 February 2017 at 08:37:29 UTC, Nicholas Wilson wrote: DCompute is an extension to LDC capable of generating code (with no language changes*) for NVIDIA's NVPTX for use with Hmm, I appear to have really mucked up the git submodules. Unfortunately I have a cold at the moment and fighting git is beyond me at the best of times but I'm completely stumped here, PRs appreciated. Once this is sorted I'll do a tag and release. Thanks for the appreciation, please let me know about your experiences/bug reports. Give the thumbs up on this and I'll put it on reddit in the next window. Actually I've got the submodules working so feel free to go ahead, the release is only for OSX for ldc's CI. If you could let me know when that window is I could post an AMA if I'm awake then.
Re: DConf 2017 Early Bird Registration expires Monday!
On Saturday, 25 February 2017 at 13:25:20 UTC, Moritz Maxeiner wrote: On Saturday, 25 February 2017 at 07:02:48 UTC, Walter Bright wrote: http://dconf.org/2017/registration.html Don't forget, it goes up to $400 after Monday. Just registered and was returned to http://dconf.org/2017/thankyou.html afterwards, which yields a 404 error. Not sure if I should laugh or cry. So I'm in the same boat (paid with PayPal and got 404 on 13-Feb-2017). Is there a chance I could get a ticket (or some confirmation)?
Re: DCompute - Native heterogeneous computing for D - is here!
On Monday, 27 February 2017 at 09:13:22 UTC, Mike Parker wrote: On Monday, 27 February 2017 at 08:37:56 UTC, Nicholas Wilson wrote: On Sunday, 26 February 2017 at 08:37:29 UTC, Nicholas Wilson wrote: DCompute is an extension to LDC capable of generating code (with no language changes*) for NVIDIA's NVPTX for use with Hmm, I appear to have really mucked up the git submodules. Unfortunately I have a cold at the moment and fighting git is beyond me at the best of times but I'm completely stumped here, PRs appreciated. Once this is sorted I'll do a tag and release. Thanks for the appreciation, please let me know about your experiences/bug reports. Give the thumbs up on this and I'll put it on reddit in the next window. Once I get the submodule stuff fixed and do a release of llvm I'll let you know. Hopefully some time tomorrow morning (UTC+8), but maybe in the afternoon.
Re: DCompute - Native heterogeneous computing for D - is here!
On Monday, 27 February 2017 at 08:37:56 UTC, Nicholas Wilson wrote: On Sunday, 26 February 2017 at 08:37:29 UTC, Nicholas Wilson wrote: DCompute is an extension to LDC capable of generating code (with no language changes*) for NVIDIA's NVPTX for use with Hmm, I appear to have really mucked up the git submodules. Unfortunately I have a cold at the moment and fighting git is beyond me at the best of times but I'm completely stumped here, PRs appreciated. Once this is sorted I'll do a tag and release. Thanks for the appreciation, please let me know about your experiences/bug reports. Give the thumbs up on this and I'll put it on reddit in the next window.
Re: DCompute - Native heterogeneous computing for D - is here!
On Sunday, 26 February 2017 at 08:37:29 UTC, Nicholas Wilson wrote: DCompute is an extension to LDC capable of generating code (with no language changes*) for NVIDIA's NVPTX for use with Hmm, I appear to have really mucked up the git submodules. Unfortunately I have a cold at the moment and fighting git is beyond me at the best of times but I'm completely stumped here, PRs appreciated. Once this is sorted I'll do a tag and release. Thanks for the appreciation, please let me know about your experiences/bug reports.
