I suggest you ...

Greatly increase support for GPU programming in C#

-Support GPU programming in C# -both general and graphical- on at least equal level with C++. On every Microsoft platform.
-Design the future versions (or successor) of DirectX with C# in mind.

2,308 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Cole shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • BR commented  ·   ·  Flag as inappropriate

    Must support OpenGL/Metal GPU programming. A directX only version does not help cross-platform scientific tools like our commercial product

  • Gavin Williams commented  ·   ·  Flag as inappropriate

    3 votes for this. I've been using SharpDX for a while now, but it should be Microsoft providing official support for DirectX using C#. DX is almost a part of the Windows Runtime now, but you haven't taken the final step to fully integrate it, we have to use very weird interop interfaces (If I understand it correctly). Just remake DirectX 11 and 12 to be part of the runtime so that it's available for C# developers. There may be some issue with such a change, but I'm not aware of any.

  • Thomas commented  ·   ·  Flag as inappropriate

    We use SlimDX (looking into moving to SharpDX for DirectX 12 support) with C# and the performance difference is negligible for us. It's frustrating Microsoft doesn't provide an official wrapper or libraries. If you do provide support, please not another XNA!!! Just DirectX please :)

  • WSLUser commented  ·   ·  Flag as inappropriate

    C++ would be better for use than C# as C++ more efficiently uses your hardware due to making no assumptions that C# makes. C# is great at user level, C++ more at kernel level (which is where access to GPU derives from).

  • Matthew Crawford commented  ·   ·  Flag as inappropriate

    This was exactly what I was wanting to find and vote for on this visit. We need native support for GPU executions.

  • Henry commented  ·   ·  Flag as inappropriate

    No, if it only supports DirectX. OpenGL based solutions are far more widespread.

  • regis commented  ·   ·  Flag as inappropriate

    Hybridizer generates cuda code from msil assemblies. It supports generics, virtual function, automatic memory management. Parallel.For is mapped to a CUDA-like loop (threadIdx.x...). It also gives full control to developer (explicit loops, intrinsic functions -- handwritten cuda functions -- explicit memory management...).
    The free version generates CUDA binaries from c# code, and is distributed as a Visual Studio Extension.


  • MouseCoder commented  ·   ·  Flag as inappropriate

    Native support for 3D graphics in .Net sounds good to me. No more interop slowdown to call down into C++.

    Libraries could be organized by shader model, and implemented using DirectX/OpenGL depending on platform. So, for example, System.Graphics.ShaderModel.SM3_0 would contain classes, structs, enums, etc., relating specifically to 3D graphics using Shader Model 3.0, and System.Graphics.ShaderModel.Generic would automatically route to the highest supported Shader Model.


  • Anil Kumar commented  ·   ·  Flag as inappropriate

    Developers can be empowered by giving them AI client apis who will in turn empower every people by building intelligent apps.

    There are lots of mid range powered laptops (& desktops) which contain mid range GPUs & CPUs. There is a huge market for GPU computing.
    New developers can easily get these mid range devices.
    These mid range GPUs will very easily trump high end CPUs in AI programming.

    I think 2 tools that Microsoft can provide are: Builtin .NET AI api in UWP (for doing high level AI) & Task Parallel Libriary (TPL) like .NET library for GPGPU (for doing low level AI).
    With a huge market & tools in ecosystem, developers will come.
    And we already have an example of a similar tool: CNTK.CPU & CNTK.GPU.

    Moreover there is less of a privacy issue when AI runs on client systems.

  • msedi commented  ·   ·  Flag as inappropriate

    I absolutely agree, but it should be kept in mind, that i should be a generic solution. OpenCL is not such a solution. There must be something that scales to every CPU and/or GPU. Having only the things for nvidia does not help at all. You need upwards and downwards solutions depending on the system you have. Creating adapted code for each GPU in nvidia to get the best performance is not generic. For hardcore/high-performance developers yes, but not for the broad mass.

  • Daniel Egloff commented  ·   ·  Flag as inappropriate

    Alea GPU version 3 currently in development will have fully automated memory management to communicate with GPU

  • Daniel Egloff commented  ·   ·  Flag as inappropriate

    With Alea GPU we offer a complete professional solution for GPU programming with .NET languages, including debugging, profiling and a growing collection of GPU primitives and libraries that integrate with our stack. It is cross platform and self contained hence does not need any further tools or compilers installed (e.g. CudaFy requires the NVIDIA CUDA C/C++ compiler installed) - fee community version - check it out here http://www.quantalea.com/

  • Ak commented  ·   ·  Flag as inappropriate

    Or just move to F# - http://fsharp.org/use/gpu/

    No need for Microsoft to be the first mover here - if you want to make a framework for doing this or contribute to the C#/F# frameworks listed on the above page your more than welcome. More contributors to open source frameworks to do this would be great - IMO C# and F# already support features that make it possible to compile/translate .NET code into GPU code (expressions, quotations)

  • Anonymous commented  ·   ·  Flag as inappropriate

    This can be done in managed way and without corrupting debuging expirience.
    Look at Cudafy:

    They support debugging via emulation, all GPu cards and CPU (OpenCL) and NVidia (CUDA).

    So basically you would write functions as usual but decorated with some attribute:

    static void SomeFunc(CLThread thread, int someParam)
    //normal C# code

  • Ben Voigt commented  ·   ·  Flag as inappropriate

    .NET is highly intertwined with a runtime, dynamic memory allocation, garbage collection. The experience on the GPU wouldn't be the same at all. You're going to have to write GPGPU code as C-with-classes anyway... wouldn't better integration of C++AMP into C# be as good as trying to create a C#-AMP?

  • Miha Markic commented  ·   ·  Flag as inappropriate

    Perhaps a good option is to use C++ AMP stuff (http://msdn.microsoft.com/en-us/library/hh265137.aspx) in a separate library and create a managed wrapper around it that communicates the minimum possible data. BTW I've made C# framework for doing GPU a while back ago. It was like you were programming in C# using a custom C# library and the generated code would be compiled for the GPGPU during compilation time. It was working but later hadn't have time to push it forward.

← Previous 1

Feedback and Knowledge Base