Sign in with
Sign up | Sign in

Nvidia CUDA 5.5 Now Supports ARM

By - Source: Nvidia PR | B 14 comments

In addition to revealing its plans to license Keplar GPU cores, Nvidia said on Tuesday that its new CUDA 5.5 release candidate brings the power of GPU-accelerated computing to ARM platforms. Now programmers have a robust, easy-to-use suite to develop high-performance computing platforms on both x86 CPU-based and ARM systems.

"Since developers started using CUDA in 2006, successive generations of better, exponentially faster CUDA GPUs have dramatically boosted the performance of applications on x86-based systems," said Ian Buck, general manager of GPU Computing Software at Nvidia. "With support for ARM, the new CUDA release gives developers tremendous flexibility to quickly and easily add GPU acceleration to applications on the broadest range of next-generation HPC platforms."

Nvidia said that thanks to a combination of low-power ARM-based SoCs and CUDA-enabled accelerators, ARM-based systems can now penetrate new markets that require the highest levels of energy-efficient compute performance. That means ARM-based solutions could be used in defense systems, robotics, scientific research and more.

In addition to adding support for ARM architecture, the new toolkit features Hyper-Q support across multiple MPI processes on all Linux systems, MPI Workload Prioritization, new guided performance analysis, and fast cross-compile on x86. This latter feature reduces development time for large applications by enabling developers to compile ARM code on fast x86 processers, and transfer the compiled application to ARM.

CUDA 5.5 also offers a full suite of programming tools, GPU-accelerated math libraries and documentation for both x86- and ARM-based platforms, the company said. GPU-accelerated math libraries include FFT, RNG, BLAS, sparse matrix operations, and nearly 5,000 signal- and image-processing primitives in the NVIDIA Performance Primitives (NPP) library.

Additional information about the new suite can be accessed here on Nvidia's developer website.

Display 14 Comments.
This thread is closed for comments
  • 0 Hide
    LordConrad , June 19, 2013 7:29 PM
    I hope developers choose OpenCL instead of CUDA as its not proprietary and works on GPUs from many vendors.
  • 0 Hide
    bison88 , June 19, 2013 7:53 PM
    Prepping for Maxwell I see. Can't wait.
  • 0 Hide
    agnickolov , June 19, 2013 10:04 PM
    Second article with the same typo... It's Kepler, not Keplar.

    https://en.wikipedia.org/wiki/Kepler
  • 0 Hide
    renz496 , June 19, 2013 10:12 PM
    Quote:
    I hope developers choose OpenCL instead of CUDA as its not proprietary and works on GPUs from many vendors.


    This is meant for developer who work with nvidia tegra or any derivatives that will employing any kind of ARM cpu with nvidia gpu tech. The target market most likely scientific and professional space where proprietary is not much an issue anyway.

    For software dev that intend to utilize compute stuff and want their piece of software to run on all hardware they might well be choosing OpenCL. But still the well estazblished of CUDA environment and the support nvidia can provide with their CUDA makes some dev leaning towards developing their softowares on CUDA.
  • 0 Hide
    ojas , June 20, 2013 12:26 PM
    Hardly surprised, with Logan and all coming up.
  • 0 Hide
    JPNpower , June 20, 2013 12:34 PM
    But CUDA is generally better than OpenCL with the same resourses for Nvidia cards. I have no problem either way, whichever devs can find the most performance in.
  • 0 Hide
    salgado18 , June 20, 2013 5:09 PM
    Quote:
    Quote:
    I hope developers choose OpenCL instead of CUDA as its not proprietary and works on GPUs from many vendors.


    This is meant for developer who work with nvidia tegra or any derivatives that will employing any kind of ARM cpu with nvidia gpu tech. The target market most likely scientific and professional space where proprietary is not much an issue anyway.

    For software dev that intend to utilize compute stuff and want their piece of software to run on all hardware they might well be choosing OpenCL. But still the well estazblished of CUDA environment and the support nvidia can provide with their CUDA makes some dev leaning towards developing their softowares on CUDA.


    But because CUDA only works on nVidia hardware, it's use is only academic, being used only on specific scenarios like the ones you cited. General application is out of the question, because it can only be used to help systems that have such hardware, but cannot be needed because most don't.

    What I'm saying is that, like PhysX, CUDA is only a niche technology. Because almost every computer uses Windows, almost every computer can be built usind DirectX as well as OpenGL, but because only half of the gaming market (and only this market) employs nVidia hardware, either the software must be built to work without GPU acceleration, or use the universal OpenCL.

    Don't take me wrong, I like the idea of CUDA, just not the philosophy of needing proprietary hardware to make it work.
  • 0 Hide
    bit_user , June 20, 2013 10:05 PM
    I'm actually surprised it's taken them this long, as that means no Tegra apps have been able to use CUDA. I'd have assumed CUDA-support was there since the first or second gen.
  • 0 Hide
    renz496 , June 20, 2013 11:22 PM
    Quote:
    I'm actually surprised it's taken them this long, as that means no Tegra apps have been able to use CUDA. I'd have assumed CUDA-support was there since the first or second gen.


    AFAIK CUDA needs that unified shader stuff. Even their current Tegra 4 can't use CUDA since the gpu portion still based on separate pixel shader and vertex shader. Even if nvidia want to push CUDA early on they just simply can't do it. With T5 nvidia will finally move to unified shader for their tegra. That's why they were releasing CUDA with ARM suport right now. Right now if developer are interested with ARM +CUDA they can tinker around nvidia Kayla platform. This is so that dev will know early on what kind of thing they can do when Logan (T5) comes out next year

  • 0 Hide
    renz496 , June 21, 2013 12:14 AM
    Quote:
    Quote:
    Quote:
    I hope developers choose OpenCL instead of CUDA as its not proprietary and works on GPUs from many vendors.


    This is meant for developer who work with nvidia tegra or any derivatives that will employing any kind of ARM cpu with nvidia gpu tech. The target market most likely scientific and professional space where proprietary is not much an issue anyway.

    For software dev that intend to utilize compute stuff and want their piece of software to run on all hardware they might well be choosing OpenCL. But still the well estazblished of CUDA environment and the support nvidia can provide with their CUDA makes some dev leaning towards developing their softowares on CUDA.


    But because CUDA only works on nVidia hardware, it's use is only academic, being used only on specific scenarios like the ones you cited. General application is out of the question, because it can only be used to help systems that have such hardware, but cannot be needed because most don't.

    What I'm saying is that, like PhysX, CUDA is only a niche technology. Because almost every computer uses Windows, almost every computer can be built usind DirectX as well as OpenGL, but because only half of the gaming market (and only this market) employs nVidia hardware, either the software must be built to work without GPU acceleration, or use the universal OpenCL.

    Don't take me wrong, I like the idea of CUDA, just not the philosophy of needing proprietary hardware to make it work.


    You can put DirectX into the same category as PhysX and CUDA. DirectX only work on windows while OpenGL works on both windows and Linux. About OpenCL and CUDA both have their own pro and con. With CUDA nvidia have a total control over the softwares so further development and enhancement can be done much faster. I mean just look at DirectX and OpenGL. how long is it for OpenGL takes to match the similar function that available in MS Direct X 11? The same goes with OpenCL. Of course over the time OpenCL might be able to catch up with CUDA on the same playing level of and if that's happen nvidia might need to put all their effort on OpenCL as well (nvidia was part of OpenCL development as well). But right now nvidia still can see CUDA still able to bring profit to them. As long as that is the case nvidia will keep advancing their CUDA softwares.

    Also about OpenCL. From what i can see most people are attracted to it's cross platform nature. But from what i can understand it does not work like OpenGL did. OpenCL is for compute stuff and you want to squeeze as much as possible the raw power available on the hardware. To do that you need to optimized your code to the target hardware. I believe this is the problem. If you optimized your code for specific hardware the code might not work properly or not working at all on other hardware. So with OpenCL if you want your code to work on wide range of hardware you might need to sacrifice performance optimization. If not you will have to make each code for each hardware you want it to work.

    This is what i get from my basic understanding of this matter. So if there is something i say are not true then feel free to correct me
  • 0 Hide
    bit_user , June 21, 2013 12:53 AM
    Based on my limited experience with each, I think CUDA is ahead of OpenCL in features, but OpenCL has the benefit of coming second and is more uniform and cleaner. But definitely more primitive.

    NVidia actually played a key role in developing the OpenCL standard and continues to be deeply involved in the Kronos Group and the OpenCL committee.

    Quote:
    Also about OpenCL. From what i can see most people are attracted to it's cross platform nature. But from what i can understand it does not work like OpenGL did. OpenCL is for compute stuff and you want to squeeze as much as possible the raw power available on the hardware. To do that you need to optimized your code to the target hardware. I believe this is the problem. If you optimized your code for specific hardware the code might not work properly or not working at all on other hardware. So with OpenCL if you want your code to work on wide range of hardware you might need to sacrifice performance optimization. If not you will have to make each code for each hardware you want it to work.
    This was an argument put forth by some at Google for pushing RenderScript as the supported GPU compute language for Android. However, I don't buy it and neither does this guy:

    http://www.openclblog.com/2013/03/google-and-opencl.html

    OpenCL was designed from day one to support the whole range of devices. It does let you tune your program to some specific hardware, but it also gives you tools to make it scale. As with any good tool, you can use it well or poorly.
  • 0 Hide
    bit_user , June 21, 2013 8:04 PM
    Quote:
    Quote:
    I'm actually surprised it's taken them this long, as that means no Tegra apps have been able to use CUDA. I'd have assumed CUDA-support was there since the first or second gen.


    AFAIK CUDA needs that unified shader stuff. Even their current Tegra 4 can't use CUDA since the gpu portion still based on separate pixel shader and vertex shader. Even if nvidia want to push CUDA early on they just simply can't do it. With T5 nvidia will finally move to unified shader for their tegra.
    I don't understand this point. It shouldn't require unified shaders - just that at least some of the shaders are sufficiently flexible that they can execute CUDA programs. There can still be some vertex shaders or whatever that just sit idle, during execution of CUDA or OpenCL programs.

    Now, what could be the issue is FP32 support. I think I might have read somewhere that earlier Tegra generations were limited to FP16.
  • 0 Hide
    renz496 , June 22, 2013 12:15 AM
    even if they can maybe nvidia want to standardize the usage of CUDA through unified shaders? also if i remember correctly nvidia designs CUDA with unified shaders in mind. hence when they came out with CUDA only Geforce 8000 and above will be able to use CUDA.
  • 0 Hide
    ojas , June 26, 2013 9:25 AM
    Quote:
    Quote:
    Quote:
    I'm actually surprised it's taken them this long, as that means no Tegra apps have been able to use CUDA. I'd have assumed CUDA-support was there since the first or second gen.


    AFAIK CUDA needs that unified shader stuff. Even their current Tegra 4 can't use CUDA since the gpu portion still based on separate pixel shader and vertex shader. Even if nvidia want to push CUDA early on they just simply can't do it. With T5 nvidia will finally move to unified shader for their tegra.
    I don't understand this point. It shouldn't require unified shaders - just that at least some of the shaders are sufficiently flexible that they can execute CUDA programs. There can still be some vertex shaders or whatever that just sit idle, during execution of CUDA or OpenCL programs.

    Now, what could be the issue is FP32 support. I think I might have read somewhere that earlier Tegra generations were limited to FP16.

    That's what i know about CUDA too, you need a GPU with unified "CUDA cores" (i.e. GeForcre 8000-series cards and later) for CUDA support. Which is why T4 doesn't support it, it's still split unevenly into shader+vector cores. T5 onward will feature unified GPU cores, and thus CUDA support.

    I think it's just the way CUDA is designed to run, but i really don't know more about it (other than the above, which i know merely as a fact), so i won't comment.