Dear D users,

I'd like to announce DerelictCUDA, dynamic bindings to the CUDA library.
https://github.com/derelictorg/derelictcuda

For now, only the CUDA Driver API is exposed, providing most of the warp control.

For a visual explanation of the different APIs in CUDA, see http://stackoverflow.com/questions/242894/cuda-driver-api-vs-cuda-runtime

More APIs could be implemented if the interest happens to be non-null.

On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote:
> More APIs could be implemented if the interest happens to be non-null.

Interest non-null, this is awesome.

On 10/17/14, 7:58 AM, Tofu Ninja wrote:
> On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote:
>> More APIs could be implemented if the interest happens to be non-null.
>
> Interest non-null, this is awesome.

Let it ride!

http://www.reddit.com/r/programming/comments/2jiv21/derelictcuda_dynamic_bindings_to_the_cuda_library/

https://twitter.com/D_Programming/status/523135615521415171


Andrei

On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote:
> Dear D users,
>
> I'd like to announce DerelictCUDA, dynamic bindings to the CUDA library.
> https://github.com/derelictorg/derelictcuda
>
> For now, only the CUDA Driver API is exposed, providing most of the warp control.
>
> For a visual explanation of the different APIs in CUDA, see http://stackoverflow.com/questions/242894/cuda-driver-api-vs-cuda-runtime
>
> More APIs could be implemented if the interest happens to be non-null.

Any chance of getting some math libraries like MAGMA?

https://developer.nvidia.com/gpu-accelerated-libraries

By the way, this is awesome work.

On Friday, 17 October 2014 at 17:19:00 UTC, bachmeier wrote:
> On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote:
>> Dear D users,
>>
>> I'd like to announce DerelictCUDA, dynamic bindings to the CUDA library.
>> https://github.com/derelictorg/derelictcuda
>>
>> For now, only the CUDA Driver API is exposed, providing most of the warp control.
>>
>> For a visual explanation of the different APIs in CUDA, see http://stackoverflow.com/questions/242894/cuda-driver-api-vs-cuda-runtime
>>
>> More APIs could be implemented if the interest happens to be non-null.
>
> Any chance of getting some math libraries like MAGMA?
>

These APIs rely on the Runtime API, I need to see if this API can be implemente first.

> https://developer.nvidia.com/gpu-accelerated-libraries
>
> By the way, this is awesome work.

Thanks, but honestly it is incomplete and wasn't much effort.
I think we need some place (could be just a NG thread?) to express users needs for library/bindings. Else we don't really know what is missing.

On 10/18/2014 05:49 AM, ponce wrote:
> I think we need some place (could be just a NG thread?) to express users needs for library/bindings. Else we don't really know what is missing.
> 

A wiki page might be better, so that it can be modified in place and always be up to date with requests and results.

-- 
Paul O'Neil
Github / IRC: todayman

On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote:
> Dear D users,
>
> I'd like to announce DerelictCUDA, dynamic bindings to the CUDA library.
> https://github.com/derelictorg/derelictcuda
>
> For now, only the CUDA Driver API is exposed, providing most of the warp control.
>
> For a visual explanation of the different APIs in CUDA, see http://stackoverflow.com/questions/242894/cuda-driver-api-vs-cuda-runtime
>
> More APIs could be implemented if the interest happens to be non-null.

CUDA Runtime API added.

On Tuesday, 21 October 2014 at 08:31:03 UTC, ponce wrote:
> On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote:
>> Dear D users,
>>
>> I'd like to announce DerelictCUDA, dynamic bindings to the CUDA library.
>> https://github.com/derelictorg/derelictcuda
>>
>> For now, only the CUDA Driver API is exposed, providing most of the warp control.
>>
>> For a visual explanation of the different APIs in CUDA, see http://stackoverflow.com/questions/242894/cuda-driver-api-vs-cuda-runtime
>>
>> More APIs could be implemented if the interest happens to be non-null.
>
> CUDA Runtime API added.

This is great! I know that C++ uses <<< and >>> to enclose kernel calls and thus create the link between CPU and GPU code when NVCC rips things apart. How is this done in your bindings?

On Sunday, 26 October 2014 at 05:31:52 UTC, Dmitri Nesteruk wrote:
> This is great! I know that C++ uses <<< and >>> to enclose kernel calls and thus create the link between CPU and GPU code when NVCC rips things apart. How is this done in your bindings?

It's just the driver api, its not CUDA code in D.

Also I think you are mistaking where the <<< >>> are actually used. The <<< >>> are used in CUDA code, not in C++ code. While CUDA is a variation on C++, it is still not C++ and has to pass through a special parser that splits out the host code and the gpu code to be compiled.

On Sunday, 26 October 2014 at 05:31:52 UTC, Dmitri Nesteruk wrote:
> On Tuesday, 21 October 2014 at 08:31:03 UTC, ponce wrote:
>> On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote:
>>> Dear D users,
>>>
>>> I'd like to announce DerelictCUDA, dynamic bindings to the CUDA library.
>>> https://github.com/derelictorg/derelictcuda
>>>
>>> For now, only the CUDA Driver API is exposed, providing most of the warp control.
>>>
>>> For a visual explanation of the different APIs in CUDA, see http://stackoverflow.com/questions/242894/cuda-driver-api-vs-cuda-runtime
>>>
>>> More APIs could be implemented if the interest happens to be non-null.
>>
>> CUDA Runtime API added.
>
> This is great! I know that C++ uses <<< and >>> to enclose kernel calls and thus create the link between CPU and GPU code when NVCC rips things apart. How is this done in your bindings?

The kernel launch syntax can only be used in CUDA when compiling for both device and host through nvcc. This isn't possible to have such with D code since nvcc won't take it. You have to compile the kernels separately, load them, and then use cudaLaunch or cuKernelLaunch instead (I suggest using string imports with PTX outputs or fatbin).

This makes CUDA programming arguably less practical than with C++, but combined host+device code tend to complicate build