D and GPGPU

[luminousone via Digitalmars-d]

On Wednesday, 18 February 2015 at 15:15:21 UTC, Russel Winder 
wrote:
> It strikes me that D really ought to be able to work with GPGPU 
> – is
> there already something and I just failed to notice. This is 
> data
> parallelism but of a slightly different sort to that in 
> std.parallelism.
> std.concurrent, std.parallelism, std.gpgpu ought to be 
> harmonious
> though.
>
> The issue is to create a GPGPU kernel (usually C code with 
> bizarre data
> structures and calling conventions) set it running and then 
> pipe data in
> and collect data out – currently very slow but the next 
> generation of
> Intel chips will fix this (*). And then there is the 
> OpenCL/CUDA debate.
>
> Personally I think OpenCL, for all it's deficiencies, as it is 
> vendor
> neutral. CUDA binds you to NVIDIA. Anyway there is an NVIDIA 
> back end
> for OpenCL. With a system like PyOpenCL, the infrastructure 
> data and
> process handling is abstracted, but you still have to write the 
> kernels
> in C. They really ought to do a Python DSL for that, but… So 
> with D can
> we write D kernels and have them compiled and loaded using a 
> combination
> of CTFE, D → C translation, C ompiler call, and other magic?
>
> Is this a GSoC 2015 type thing?
>
>
> (*) It will be interesting to see how NVIDIA responds to the 
> tack Intel
> are taking on GPGPU and main memory access.

https://github.com/HSAFoundation

This is really the way to go, yea opencl and cuda exist, along 
with opengl/directx compute shaders, but pretty much every thing 
out their suffers from giant limitations.

With HSA, HSAIL bytecode is embedded directly into the elf/exe 
file, HASIL bytecode can can fully support all the features of 
c++, virtual function lookups in code, access to the stack, cache 
coherent memory access, the same virtual memory view as the 
application it runs in, etc.

HSA is implemented in the llvm backend compiler, and when it is 
used in a elf/exe file, their is a llvm based finalizer that 
generates gpu bytecode.

More importantly, it should be very easy to implement in any llvm 
supported language once all of the patches are moved up stream to 
their respective libraries/toolsets.

I believe that linux kernel 3.19 and above have the iommu 2.5 
patches, and I think amd's radeon KFD driver made it into 3.20. 
HSA will also be supported by ARM.

HSA is generic enough, that assuming Intel implements similar 
capabilities into their chips it otta be supportable their with 
or without intels direct blessing.

HSA does work with discrete gpu's and not just the embedded 
stuff, And I believe that HSA can be used to accelerate OpenCL 
2.0, via copyless cache coherent memory access.