Re: using DCompute
On Friday, 28 July 2017 at 01:30:58 UTC, Nicholas Wilson wrote: Yes, although I'll have to add an attribute shim layer for the dcompute druntime symbols to be accessible for DMD. When you compile LDC will produce .ptx and .spv files in the object file directory which will be able to be used in any project. The only thing that will be more fragile is lambda kernels as they are mangled numerically (`__lambda1`, `__lambda1` and so on). I imagine that using dcompute this way with DMD for development would be popular. For instance, the GPU part might be only a small part of a project so you wouldn't want to be forced to use LDC the moment the tiniest GPU code is in it. Once you've ensured everything is working correctly, you might add something about this to the wiki, or whatever.
Re: using DCompute
On Friday, 28 July 2017 at 00:39:43 UTC, James Dean wrote: On Friday, 28 July 2017 at 00:23:35 UTC, Nicholas Wilson wrote: On Thursday, 27 July 2017 at 21:33:29 UTC, James Dean wrote: I'm interested in trying it out, says it's just for ldc. Can we simply compile it using ldc then import it and use dmd, ldc, or gdc afterwards? The ability to write kernels is limited to LDC, though there is no practical reason that, once compiled, you couldn't use resulting generated files with GDC or DMD (as long as the mangling matches, which it should). This is not a priority to get working, since the assumption is if you're trying to use the GPU to boost your computing power, then you like care enough to use LDC, as opposed to DMD (GDC is still a bit behind DMD so I don't consider it) to get good optimisations in the first place. Yes, but dmd is still good for development since LDC sometimes has problems. If you have problems please tell us! Can we compile kernels in LDC and import them in to a D project seamlessly? Basically keep an LDC project that deals with the kernels while using dmd for the bulk of the program. I mean, is it a simple import/export type of issue? Yes, although I'll have to add an attribute shim layer for the dcompute druntime symbols to be accessible for DMD. When you compile LDC will produce .ptx and .spv files in the object file directory which will be able to be used in any project. The only thing that will be more fragile is lambda kernels as they are mangled numerically (`__lambda1`, `__lambda1` and so on).
Re: using DCompute
On Friday, 28 July 2017 at 00:23:35 UTC, Nicholas Wilson wrote: On Thursday, 27 July 2017 at 21:33:29 UTC, James Dean wrote: I'm interested in trying it out, says it's just for ldc. Can we simply compile it using ldc then import it and use dmd, ldc, or gdc afterwards? The ability to write kernels is limited to LDC, though there is no practical reason that, once compiled, you couldn't use resulting generated files with GDC or DMD (as long as the mangling matches, which it should). This is not a priority to get working, since the assumption is if you're trying to use the GPU to boost your computing power, then you like care enough to use LDC, as opposed to DMD (GDC is still a bit behind DMD so I don't consider it) to get good optimisations in the first place. Yes, but dmd is still good for development since LDC sometimes has problems. Can we compile kernels in LDC and import them in to a D project seamlessly? Basically keep an LDC project that deals with the kernels while using dmd for the bulk of the program. I mean, is it a simple import/export type of issue?
Re: using DCompute
On Thursday, 27 July 2017 at 21:33:29 UTC, James Dean wrote: I'm interested in trying it out, says it's just for ldc. Can we simply compile it using ldc then import it and use dmd, ldc, or gdc afterwards? The ability to write kernels is limited to LDC, though there is no practical reason that, once compiled, you couldn't use resulting generated files with GDC or DMD (as long as the mangling matches, which it should). This is not a priority to get working, since the assumption is if you're trying to use the GPU to boost your computing power, then you like care enough to use LDC, as opposed to DMD (GDC is still a bit behind DMD so I don't consider it) to get good optimisations in the first place. --- a SPIRV capable LLVM (available here to build ldc to to support SPIRV (required for OpenCL)). or LDC built with any LLVM 3.9.1 or greater that has the NVPTX backend enabled, to support CUDA. --- Is the LDC from the download pages have these enabled? I dont think so, although future releases will likely have the NVPTX backend enabled. Also, can DCompute or any GPU stuff efficiently render stuff because it is already on the GPU or does one sort of have to jump through hoops to, say, render a buffer? There are memory sharing extensions that allow you to give access to and from OpenGL/DirectX so you shouldn't suffer a perf penalty for doing so. e.g., suppose I want to compute a 3D mathematical function and visualize it's volume. Do I go in to the GPU, do the compute, back out to cpu, then to the graphics system(opengl/directX) or can I just essentially do it all from the gpu? there should be no I/O overhead.
using DCompute
I'm interested in trying it out, says it's just for ldc. Can we simply compile it using ldc then import it and use dmd, ldc, or gdc afterwards? --- a SPIRV capable LLVM (available here to build ldc to to support SPIRV (required for OpenCL)). or LDC built with any LLVM 3.9.1 or greater that has the NVPTX backend enabled, to support CUDA. --- Is the LDC from the download pages have these enabled? Also, can DCompute or any GPU stuff efficiently render stuff because it is already on the GPU or does one sort of have to jump through hoops to, say, render a buffer? e.g., suppose I want to compute a 3D mathematical function and visualize it's volume. Do I go in to the GPU, do the compute, back out to cpu, then to the graphics system(opengl/directX) or can I just essentially do it all from the gpu?
