32 ms·

For what it's worth, AMD has been working on a CUDA compatibility solution for at least a year now. Announcement[0] and Progress[1] [0] http://www.anandtech.co

• dogma1138 10y ago
  It only works for the basic functionality they can't interop the "operational" CUDA features.
  • slizard 10y ago
    > can't interop the "operational" CUDA features What exactly do you that mean?
    • dogma1138 10y ago
      DMA, networking, storage and direct i/o, virtualization etc.
      • slizard 10y ago
        The tricky, but fun parts. It's certainly not trivial to port those, but I'm not too worried about it as long as there is solid runtime support in ROCm. More fun work for perf engineers like me. ;) Massive amount of boilerplate, heavy APIs or crappy software stack are more dangerous IMO than having to drop in replacements for NVIDIA-specific optimizations of GPU-to-NIC or GPU-to-GPU communication.
        • dogma1138 10y ago
          Not only not trivial to port those but they are constantly will have to play catch up and be at the mercy of NVIDIA in regards to spec. AMD is in a catch 22, support CUDA and be effectively in a constant catch up position, not support it and continue to be ignored by the market at large simply because the momentum NVIDIA has managed to achieve with CUDA over the years.
          • slizard 10y ago
            NVIDIA is playing catch-up with themselves and the shifting market too! Just look at the Maxwell-based Tesla cards that came out of the blue (as if they were an afterthought); I bet Facebook, Baidu, Google, etc. told NVIDIA that Kepler was shit for their use-cases and they did not want to wait for Pascal. Or look at the bizarre Pascal product line where the GP100 does support half precision, but the others don't, not even the P4 or P40. Strange, isn't it? Things are changing so quickly that it isn't hard at all to find footing as long as you have something useful to offer. At the same time, I agree, a robust software stack is an advantage, but for the likes of Google or Baidu even that is not so big of a deal (Google wrote their own CUDA compiler!).
            • dogma1138 10y ago
              Not sure if Maxwell came out of the blue, Maxwell 1 was designed for mobile, embedded and tesla, Maxwell 2 came out most likely because Pascal at large was delayed. As for the half precision, it's pretty much the same thing NVIDIA been doing since Kepler dumping FP64 and FP16, especially FP16 due to the silicon costs. NVIDIA came out with the Titan and Titan Black with baller FP16 performance and no one seem to care, the Titan X then dropped it and people bought it like it was cupcakes, I'm pretty sure they have pretty good market research that states most people can live without it and those who can't can pay through the nose. As for Google and Baidu while they are huge I'm not sure how "important" they are, Google can pretty much design their own hardware at this point, and as you mentioned they don't really use the software ecosystem that much as they can write everything from scratch even the driver if need be. What CUDA gives is a huge ecosystem for 3rd parties and more importantly a lock on developers since that's "all they know", it's not that different than how MSFT got a lock on the IT industry through sysadmins that only knew Windows and even now with Dev Ops and everyone and their mother running Linux they are still an important player. If the majority of the commercial software is CUDA based, if most researchers and developers are exposed more to CUDA and are more experienced with it NVIDIA has a lock on the market. I'm not entirely sure how much big of a client or how good of a client Google will be they can demand pretty steep discounts and they are a heartbeat away from building their own hardware probably anyhow. NVIDIA doesn't want to be locked to 2-3 huge contracts that pretty much dictate how their hardware and software should look like, that's what put AMD in a bind with the console contracts dictating how their GPU's are going to look for a few generations now.
• slizard 10y ago
  Additionally, here's an example of how Caffe was porting using HIP [1]. To be honest, if the approach really does work, you might see a very quick increase in the number of applications ported. All in all, given how elegant HIP is and that HCC seems to make GPUs more approachable than CUDA (and less silly than OpenACC), there is a great potential for AMD to gain some traction. My greatest concern is the quality and robustness of their software stack, their overly optimistic view (at least from the outside), and their relationship with the rest of the OSS world, especially given the conflicts that they seems to be running into with upstream contrib [2]. [1] https://www.youtube.com/watch?v=I7AfQ730Zwc https://www.youtube.com/watch?v=I7AfQ730Zwc [2] https://news.ycombinator.com/item?id=13136426 https://news.ycombinator.com/item?id=13136426
  • jsheard 10y ago
    The catch, which AMD are quick to gloss over, is that Caffes performance on Nvidia hardware largely comes from its use of Nvidia's proprietary cuDNN kernels. AMDs HIP port is using the "fallback" open-source CUDA kernels, which are nowhere near as fast as the hand-optimized cuDNN code.
  • mikepavone 10y ago
    Things got a bit heated in the LKML thread, but if you read the more recent messages things have cooled down significantly. It's unclear whether they will ultimately be able to achieve all their goals while also getting the code into an upstreamable state, but they do seem committed to working out the issues with upstream.
  • bryanlarsen 10y ago
    That's a better relationship than nvidia's. https://www.wired.com/2012/06/torvalds-nvidia-linux/ https://www.wired.com/2012/06/torvalds-nvidia-linux/