6 ms·

This is an AMD project motivated by the fact that NVIDIA has become the de facto standard for GPU computation in deep learning and machine learning applications

• robbies 11y ago
  I can only speculate on this aspect (from inside the industry), but it's been plain to see that AMD has been hemorrhaging engineers (though they still have plenty of talent). This relates to your request about getting built-in support: I'm not sure AMD has the manpower to do that work, and they might be hoping the OSS community helps them with that...
  • ethbro 11y ago
    I'd be interested in what the ROI on more deeply embedding with OSS devs is vs employing someone to contribute. From what I've seen, for years the OSS GPU driver crowd's response to "opened" specifications / docs seems to have been "That's nice, but these aren't the docs we need."
    • robbies 11y ago
      Oh, they have the docs they need. That's essentially what is shared with console devs. The problem is that to get up and running is pretty Herculean with just docs. They need good sample implementations to get kickstarted.
• gravypod 11y ago
  That is and will continue to be one of the biggest concerns for the GPU market for some time now. I assume that after a few years, factories will be buying computers, cameras, and GPUs instead of people for inspection. This will be a large market, and that's what NVIDIA understood when they started making ties with different companies. AMD has a lot of catch up to do, but in my opinion they can do it.
  • Gracana 11y ago
    > factories will be buying computers, cameras, and GPUs instead of people for inspection There's a lot of this stuff on the market already. Even self-contained machine vision devices can be pretty powerful, like this[1] integrated camera+light device with built-in web server for setup and configuration and monitoring. With the built-in software, you can measure parts and verify shapes and dimensions and read labels. [1] http://www.microscan.com/en-us/Products/Machine-Vision-Systems/Vision-MINI-Xi-Smart-Camera.aspx http://www.microscan.com/en-us/Products/Machine-Vision-Syste...
• appleflaxen 11y ago
  I'm sad to say, but it's true. AMD has been claiming "this is the year we really open up" since at least 2007[1]. Well, I'm happy to hear them recommit, but I don't believe them anymore. Now that they are losing ground in the marketplace on the GPU side with deep learning, and their CPUs can't compete with intel on the performance side, their claims ring hollow. Imagine where we would be if they open sourced their drivers in 2007 like they said they would do. 1. http://arstechnica.com/gadgets/2007/05/amd-launches-the-hd-2000-series/ http://arstechnica.com/gadgets/2007/05/amd-launches-the-hd-2...
  • cylinder714 11y ago
    Poke around the site and look at the code on Github, with what looks like ISC/BSD licenses.
  • Narishma 11y ago
    I don't think they ever claimed they would open source their drivers. They've certainly released a ton of documentation for their GPUs over the years.
    • digi_owl 11y ago
      And likely all of it had to be vetted by lawyers before being released, to avoid lawsuits from third parties.
    • broodbucket 11y ago
      Which is probably why the open source driver is pretty good. radeon is light years ahead of nouveau.
      • witty_username 11y ago
        Yep, HW decode, works for games (FPS is 10-20% less, depends on game). Might even be better than the intel driver, I had a few problems with that, but I haven't had any problem with radeon.
  • Nullabillity 11y ago
• forrestthewoods 11y ago
  Step one is to produce competitive hardware. If AMD's hardware sucks then it doesn't matter if it's supported by frameworks or not.
• pjmlp 11y ago
  Maybe if Apple and Khronos cared to define OpenCL native support for C++ and Fortran since day 1, this would have turned out to be different.
  • deleted 11y ago
    [deleted]
• mjhirn 11y ago
  We are developing the Rust Machine Intelligence Framework Leaf[1] for which we created the portable High-Performance Computation Framework Collenchyma [2], which abstracts over CUDA, OpenCL and commen host CPU. Although we are ready to bring Machine Learning to OpenCL supported devices, the OpenCL ecosystem lacks the fundamental kernels, tooling and library that already exist for the CUDA ecosystem (e.g. cuDNN[3]). But we looking forward to support OpenCL, maybe SPIR-V accelerates the process. [1]: https://github.com/autumnai/leaf https://github.com/autumnai/leaf [2]: https://github.com/autumnai/collenchyma https://github.com/autumnai/collenchyma [3]: https://developer.nvidia.com/cudnn https://developer.nvidia.com/cudnn
  • robbies 11y ago
    I think SPIR-V + Vulkan would be the better path to follow, considering that NV doesn't really care that much about OpenCL.
• gnarbarian 11y ago
  I wish we could have hardware vendors compete on hardware with completely open software stacks from drivers on up. AMD is much farther down this path than Nvidia is. The downside of this is it gives the hardware manufacturers less flexibility in implementing new features because the APIs are design by committee. On one side we have design by committee (Khronos) giving us tools like OpenCL, Vulkan, and OpenGL on the other side we have things like Cuda and DirectX. Design by committee APIs will always have a few characteristics. The standards won't move as fast. The APIs will be more hardware agnostic. And they will either be slower and less feature rich (openCL vs cuda) or lower level and more difficult to use (OpenGL/Vulcan vs DirectX). Whenever we have a clear market leader they either push their own standard or Embrace Extend and Extinguish the open standards. The leader used to be 3dFx pushing glide, and Nvidia/ATI were the underdogs pushing standards that could run on eachothers hardware. The underdogs will try to push the open standards (because they must) and the leaders will push proprietary ones (because they can) and they can move faster than the committee. There's always going to be resistance toward spending money on research your competitor can take advantage of. I think Vulcan and SpirV have the potential to put a real dent in proprietary software stacks. It can provide real benefits over any proprietary stack at the moment for heterogeneous computing. (nvidia's blindspot is they will naturally always favor the GPU). I hope it doesn't end up like OpenCL did (feature poor and less performant than cuda). We're a long ways off from having open hardware and open drivers that can compete against closed stacks due to the performance arms race. But GOOD open standards get code written in them and they can win out over market leaders (like what happened with 3dfx). I think Vulkan might be the starting point for this. If it gains traction and can maintain leadership in performance open stacks will have a chance at competing. The biggest issue is that closed stacks can always benefit from innovations in open ones but not the reverse. Because of this, I don't think we'll ever see competitive open drivers from market leaders. But we can have competitive open APIs that can compete across vendors, If we can at least get back to that stage I would be happy.
  • digi_owl 11y ago
    Every company, perhaps every individual, wants to be a big fix in a small pond, rather than one of many small fish in a large pond. I seem to recall that back during the industrial revolution, every supplier of screws had their own direction and density of winding. Thus the engineers running various massive projects had to introduced and enforce various standards to get anything done at all.
• hngiszmo 11y ago
  Isn't it beautiful how OpenSource is the joker card of the underdogs? Google played it with Android against Apple, too. In 2007 I did my diploma work based on AMD GPU cause it was better. In 2011/12 AMD was the standard for Bitcoin mining, yielding twice the performance than NVIDIA. Now, buying my laptop I ended buying NVIDIA. What happened to AMD?
  • Symmetry 11y ago
    AMD is still better for bitcoin mining but that's a matter of integer versus floating point processing power.
    • JoshTriplett 11y ago
      > AMD is still better for bitcoin mining Neither CPUs nor GPUs have any remaining relevance there, given ASIC/FPGA miners.
      • dcposch 11y ago
        Even FPGAs and older-process ASICs are unusable for Bitcoin today. The network hashpower just broke 1 exahash/second
        • ethbro 11y ago
          Side question: does anyone have links on some power bounds for what the Bitcoin network is currently consuming? Understand it would be a very rough estimate, but seems like it would be possible to arrive at some kind of number given electricity prices as a ceiling and state of the art efficiency as a floor. Curious on what the magnitude is in relation to other things...
          • voltagex_ 11y ago
            The power/monetary cost of 1 megahash is going to be different in Australia than it is in China.
• nothis 11y ago
  It's a shame how Nvidia is able to close up the market, there has, traditionally, been great competition between AMD and Nvidia in that space.
  • fixermark 11y ago
    Not a shame for game developers. It's nice to have some ability to predict that the failure modes where cards diverge from specification will tend to diverge along the same paths, because they're made by the same vendor. Granted, it'd be preferable to live in a world where the drivers and hardware are open and inspectable (so you don't have to debug graphics issues as a black-box problem), but we've never lived in that world and between the likelihood of AMD's initiative taking root and a de-facto Nvidia monopoly, I'd rather have the monopoly.
  • gnarbarian 11y ago
    I think it will bite them in the ass the same way glide did for 3dfx. Vulcan/SpirV may end up as the openGL of heterogeneous computing. Nvidia has the momentum at the moment with a focus on GPGPU, but if we can get an open API that leads in performance across vendors for both CPU and GPU we'll see that competition again. We just have to hope that nvidia doesn't nerf their implementation like they did with openCL.
    • pjmlp 11y ago
      It is not only performance. NVidia was clever to see that no one wants to code GPGPU code in C, rather leverage their C++ source code and the Fortran libraries with decades of investment. So CUDA has been language agnostic from the first day. Khronos has realized their error by creating SPIR, but it might be too late already. Also the debugging experience for CUDA has always been quite good.
• yeukhon 11y ago
  +1 I rarely think closed system is bad, but I think this is one of the few exceptions I'd agree with. I own a powerful Radeon card, so it sucks I can't run CUDA there and none of the machine learning toolkits will work there (even if works, probably poor performance).
• uxcn 11y ago
  Video encoding also might also be worth putting effort toward. There are probably a lot fewer people using GPUs for video encoding than for linear algegra, but it's still something nobody is currently doing with open operating systems or otherwise really. If AMD did it, I think people would take notice. nVidia started adding APIs. Video encoding on CPUs is extremely inefficient and essentially precludes on-demand encoding.