[Feature Request] Support GPU Programming

[AhmedAbuelnour]

Why there is no built-in support to work with GPUs?
I think it would be a great feature to be added to the language, it will enable to take advantage of the GPU power in a native way.

[tannergooding]

I don't think this is a good language feature. I think this should be an API added to the framework/runtime instead (which, I believe, would be a requirement for it to be a language feature in the first place as well).

[tannergooding]

Doing a quick search on CoreFX and CoreCLR, it looks like there have been a few discussions related to GPU Compute, but nothing concreate in the forms of an API proposal.

[jnm2]

http://www.aleagpu.com

[AhmedAbuelnour]

@tannergooding yeah it sounds more reasonable to add APIs to the framework, i just didn't know what to write in the title :)

[AhmedAbuelnour]

@jnm2 i just wanted it to be natively supported in the .NET , i just don't know why there is no APIs in the .NET for GPUs

[jnm2]

@A7medRamadan Genuine question: are you unable to accomplish a specific scenario with the existing third party libraries? Or is there a specific scenario which can only become more efficient by having the C# language understand it natively?

[AhmedAbuelnour]

@jnm2 i don't want to do anything with it right nowadays, i just wanted it to be as an available option for built-in in the .NET.
and i have tried aleagpu and it wasn't that efficient, then i had to move to do what i wanted in the C language.
So what i wanted then was to see a built-in support for GPU in the .NET

That is it.

[gafter]

/cc @khyperia You did some work on this a while ago.

[khyperia]

There are multiple open questions in your proposal:

• What do you mean by "built-in support"? Host-side bindings to a GPU framework in the core .net libraries? Support for compiling C# to a particular GPU IL? Support for compiling .net IL to a particular GPU IL?
• What advantages do you see that "built-in support" would have over a 3rd party library? Why do you think the support being in the core libraries resolve your issue that "aleagpu [...] wasn't that efficient"?
• What are the plans this proposal with choosing a particular GPU framework (e.g. CUDA, OpenCL), and what is the justification for that decision and resulting backcompat lock-in consequences?
• Fast GPU code requires complex/advanced concepts like pinned memory and asynchronous memory copies. What is this proposals plan on how to handle topics like those?

Keep in mind that I would certainly love to see more support in the .net world for GPU programming, I am simply curious about what exactly you are proposing 😄

[qrli]

Although GPU was/is hot, it is never a stable target like CPU. The architecture and performance characters evolve fast. You may do some wonderful GPU code which runs super on your machine, while it may be slower than CPU or even produce wrong result on others' computers.

To make proper use of GPU, you have to learn the low-levels of GPU, which are different than CPU. That requires special constraints and features in the language, thus CUDA, OpenCL, etc. It is possible to embed that into C#, similar to asm in C. But that's still two languages. There are also projects to make use of LINQ and translate it to GPU code, which works for simple case but gives you none the low-level features to get real performance boost. There is also efforts like C++/AMP, which didn't get popular at all. And OpenACC was merged into OpenMP, which looks like the best way, but people are still using CUDA/OpenCL for the real work. That being said, the major uses case are still to run on known GPU models (even known driver versions) so that you get expected performance. No guarantee it will run faster on any machine.

It is not people refuse it. It is just because there is no obviously good solution to make it part of the language.