DCompute OpenCL kernels now work
I am happy to announce that DCompute will soon[1] support the
OpenCL 2.1 runtime. I have tested it locally and it works now :)
I wasted a good deal of time wondering why it wasn't and it was a
small typo in DerelictCL trying to load OpenCL 2.2 symbols when
loading 2.1. That along with OpenCL 2.x support for DerelictCL
will be merged and tagged soon and then [1] can be merged.
Most of the hard work is now done, leaving general polish and
user feedback as the main development tasks. A unified driver
abstracting over the CUDA and OpenCL drivers is on my todo list.
Launching a kernel is as simple as
```
enum size_t N = 128;
float alpha = 5.0;
float[N] res, x,y;
foreach (i; 0 .. N)
{
x[i] = N - i;
y[i] = i * i;
}
auto platforms = Platform.getPlatforms(theAllocator);
auto platform = platforms[0]; // Assuming the 0'th platform
supports 2.1
auto devices = platform.getDevices(theAllocator);
auto ctx = Context(devices[0 ..1],null);
Program.globalProgram =
ctx.createProgram(cast(ubyte[])read("./.dub/obj/kernels_ocl200_64.spv"));
Program.globalProgram.build(devices,"");
auto queue= ctx.createQueue(devices[0]);
Buffer!(float) b_res, b_x, b_y;
b_res = ctx.createBuffer(res[], Memory.Flags.useHostPointer |
Memory.Flags.readWrite);
b_x = ctx.createBuffer(x[], Memory.Flags.useHostPointer |
Memory.Flags.readWrite);
b_y = ctx.createBuffer(y[], Memory.Flags.useHostPointer |
Memory.Flags.readWrite);
Event e = queue.enqueue!(saxpy)([N])(b_res,alpha,b_x,b_y, N);
e.wait();
foreach(i; 0 .. N)
enforce(res[i] == alpha * x[i] + y[i]);
writeln(res[]);
```
Mike, want me to do another blog post about this and the CUDA
support?
[1]: https://github.com/libmir/dcompute/pull/36
P.S: can those who answer foundat...@dlang.org please tell me
what you think of my plan to advance the development and exposure
of DCompute?
Re: compile D to asm.js using ldc --betterC and emcc
On Saturday, 7 October 2017 at 18:27:53 UTC, Suliman wrote: could you make it online? you mean build everything and commit? I've just added the binaries, I can't add the whole chain, its to big.
Re: Trial v0.4.0 and visual-trial v0.1.0 are out
On Monday, 18 September 2017 at 20:50:55 UTC, Szabo Bogdan wrote: Hi! I want to announce that I managed to release a new version of Trial, the DLang test runner. Since my last announcement, I made this changes: - new TAP and VisualTrial reporters - add -r flag to override the default reporters - add the describe command which prints a json with the discovered tests - the tests now vave source location - ars.d terminal is now part of trial... to fix some dependencies Also, I worked on a visual studio code plugin, it works on my machine... I developed it on mac os, but I will test it on windows and linux in the following weeks: https://marketplace.visualstudio.com/items?itemName=bosz.visual-trial Any feedback is appreciated! Thanks! Bogdan Cool! I will include it with the D extension bundle for vscode: https://marketplace.visualstudio.com/items?itemName=webfreak.dlang-bundle
Re: compile D to asm.js using ldc --betterC and emcc
On Saturday, 7 October 2017 at 17:31:37 UTC, cosinus wrote: I wrote a little working demo that shows how to use D inside firefox. It uses emscripten(emcc) and ldc. https://github.com/cosinus2/dlang-emscripten-demo could you make it online?
compile D to asm.js using ldc --betterC and emcc
I wrote a little working demo that shows how to use D inside firefox. It uses emscripten(emcc) and ldc. https://github.com/cosinus2/dlang-emscripten-demo
Re: Beta 2.076.1
On Saturday, 7 October 2017 at 12:45:30 UTC, Martin Nowak wrote: On Sunday, 1 October 2017 at 17:36:12 UTC, Marco Leise wrote: Other than that I'm happy with the package, as it provides the man pages, pre-built HTML documentation and a binary to bootstrap dmd on systems that lack a D compiler. (The use case being compilation from source for Gentoo Linux.) I won't reorganize the folder structure in a point release. But thanks for pointing out that this needs a fix. Would getting the sources as a separate download (or just from github) be a feasible alternative. But please consider something different than github as alternative. GitHub doesn't guarantee that it always generates the same tarball for the same commit/release, so the checksum can change and the downloaded tarball looks corrupted, though it has absolutely the same content.
Re: Beta 2.076.1
On Sunday, 1 October 2017 at 17:36:12 UTC, Marco Leise wrote: Other than that I'm happy with the package, as it provides the man pages, pre-built HTML documentation and a binary to bootstrap dmd on systems that lack a D compiler. (The use case being compilation from source for Gentoo Linux.) I won't reorganize the folder structure in a point release. But thanks for pointing out that this needs a fix. Would getting the sources as a separate download (or just from github) be a feasible alternative.
Re: Eilmer4 - a Computational Fluid Dynamics code in D
On Friday, 6 October 2017 at 22:16:09 UTC, Peter Jacobs wrote: This note is principally to say thank you to all of the people who have made the D programming language and its ecosystem. Being mechanical engineers, we are occasional but serious programmers. For a number of years, we struggled with C++ and a code base of growing complexity. In 2014, we made a serious commitment to reworking the entire code into D. In mid-2017, the new code was complete enough for general use and it is currently being used in a fourth-year course on computational fluid dynamics. The D programming language has enhanced our programming experience and, for that, we are grateful to the many people who have built the foundation upon which we build our flow simulation code. Thanks for the kind words. Indeed D seems to be at a sweet spot for scientific computation.
Re: Eilmer4 - a Computational Fluid Dynamics code in D
On Friday, 6 October 2017 at 22:16:09 UTC, Peter Jacobs wrote: Eilmer is a simulation code for studying high-speed compressible flows. Early versions were written in C and then C++. Version 4 is a complete rewrite in D, with Lua for configuration and run-time scripting. Code and documentation may be found at http://cfcfd.mechmining.uq.edu.au/eilmer/ [...] Cheers, Peter Jacobs and Rowan Gollan After reading the pdf i have a question: Is LUA scripting too complex to be replaced by, let's say, pure D code, following a compile-time interface (i.e a duck type) ? I understand that existing LUA scripts must still be supported but since D is also known for its good speed of compilation perhaps the whole thing could be recompiled from scratch for a particular set of new scripts.
