The project I've been working on for the last few months has a compute backend that is currently written MT+SIMD.  I would like to bring up a GPU variant.

If you have experience with this sort of thing, I'd love to hear from you, either within this forum or at beerconf.

In a past life I was a CUDA programmer, but I'd prefer to use something now that has at least some chance of running on most mobile devices in the future.

In addition to the CUDA fallback, I've looked at SycL, dcompute and, as suggested by Ethan a couple of beerconfs back, I looked in to the D/MLIR work.  That work is very nice but I didn't find the connection to GPUs.

Guidance from experience regarding any of the above, or other, GPU possibilities would be most welcome.

On Friday, 29 January 2021 at 16:34:25 UTC, Bruce Carneal wrote:
> The project I've been working on for the last few months has a compute backend that is currently written MT+SIMD.  I would like to bring up a GPU variant.

What you could do is ressurect DerelictCL, port it to BindBC, and write vanilla OpenCL 1.2 + OpenCL C.
Not up to date on both, but CUDA is messier than OpenCL.

I don't really know about the other possibilities, like OpenGL + compute shaders or Vulkan + compute shaders.

On Friday, 29 January 2021 at 16:34:25 UTC, Bruce Carneal wrote:
> Guidance from experience regarding any of the above, or other, GPU possibilities would be most welcome.



https://dlang.org/blog/2017/10/30/d-compute-running-d-on-the-gpu/


or Google search:

https://www.google.com/search?&q=dlang+gpu

On Friday, 29 January 2021 at 18:23:40 UTC, mw wrote:
> On Friday, 29 January 2021 at 16:34:25 UTC, Bruce Carneal wrote:
>> Guidance from experience regarding any of the above, or other, GPU possibilities would be most welcome.
>
>
>
> https://dlang.org/blog/2017/10/30/d-compute-running-d-on-the-gpu/
>
>
> or Google search:
>
> https://www.google.com/search?&q=dlang+gpu

Yes, there is a lot of readily available information on the possibilities that I listed.  And I have read/viewed much of that, including the text and video items prominent in a simple google search. (shame on me if I ever ask for something trivially available)

Current day "Guidance from *experience*..." is in another category, hence the request.

On Friday, 29 January 2021 at 17:46:05 UTC, Guillaume Piolat wrote:
> On Friday, 29 January 2021 at 16:34:25 UTC, Bruce Carneal wrote:
>> The project I've been working on for the last few months has a compute backend that is currently written MT+SIMD.  I would like to bring up a GPU variant.
>
> What you could do is ressurect DerelictCL, port it to BindBC, and write vanilla OpenCL 1.2 + OpenCL C.
> Not up to date on both, but CUDA is messier than OpenCL.
>
> I don't really know about the other possibilities, like OpenGL + compute shaders or Vulkan + compute shaders.

Thanks for the pointer to Mike's bindings.  If I run in to trouble plugging in with both dcompute and C++/SycL I'll take a look before falling back to CUDA.

I've not looked in to OpenGL compute shaders seriously either but I did look at Vulkan compute shaders.  They looked very strong with respect to future deployability but were weak in other ways so I kept them off the list.  I don't think I can warp my code to fit in to glsl or similar, at least not easily. Custom neighborhood indexing, group/sub-group scheduling control and ability to manage group local memory efficiently were the main concerns, IIRC.

On Friday, 29 January 2021 at 20:01:17 UTC, Bruce Carneal wrote:
> On Friday, 29 January 2021 at 17:46:05 UTC, Guillaume Piolat wrote:
>> On Friday, 29 January 2021 at 16:34:25 UTC, Bruce Carneal wrote:
>>> The project I've been working on for the last few months has a compute backend that is currently written MT+SIMD.  I would like to bring up a GPU variant.
>>
>> What you could do is ressurect DerelictCL, port it to BindBC, and write vanilla OpenCL 1.2 + OpenCL C.
>> Not up to date on both, but CUDA is messier than OpenCL.
>>
>> I don't really know about the other possibilities, like OpenGL + compute shaders or Vulkan + compute shaders.
>
[...]
> I've not looked in to OpenGL compute shaders seriously either but I did look at Vulkan compute shaders.  They looked very strong with respect to future deployability but were weak in other ways so I kept them off the list.  I don't think I can warp my code to fit in to glsl or similar, at least not easily. Custom neighborhood indexing, group/sub-group scheduling control and ability to manage group local memory efficiently were the main concerns, IIRC.

I took another look at Vulkan compute shaders.  They have come a long way.  Not nearly as nice as programming in D but good enough that I'll sketch out a few kernels if I can't make headway with dcompute.

Anybody with recent dcompute experience, please speak up.  The code in the repository is pretty nice but it looks unfinished or at least frozen in time.