Hacker News Reader

Comment by cs702 | Hacker News Reader

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.

TensorFlow, Torch, Theano, CNTK, CAFFE, and every other deep learning framework out there works out of the box with NVIDIA hardware via the CUDA stack, but not with AMD hardware, e.g., via the OpenCL stack.

Which is a shame, because the entire NVIDIA hardware + software stack is closed.

It would be great to see this new project succeed, and maybe even force NVIDIA to open source key or all components its stack down the road.

To the team at AMD running this project: if you are reading this, step one is to get built-in support into all major deep learning and machine learning frameworks.

View on HN

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-2...

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.

Which is probably why the open source driver is pretty good. radeon is light years ahead of nouveau.

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.

And likely all of it had to be vetted by lawyers before being released, to avoid lawsuits from third parties.

this is really unfair, they have documented their gpus extensively + provided developers for open drivers. They are currently in the process of integrating all the features from the closed drivers into the open ones.

Have you tried the open AMD radeon drivers lately?

I have not. Care to give us some insite? It's kind of an expensive experiment. It's not like trying out emacs for a week. Unfortunately, I know that an nvidea will work, so I buy that even though it's not open

Huge improvement over what they used to be, and these days I get way better performance with it than fglrx.

I can confirm that radeon gives much better performance than it did even a year ago. Anecdotally, I used to get a maximum on 30 fps on a 2003 first person shooter game. Now I can easily get 125 stable with the latest drivers, or at least 71 fps in maps that are foggy, smoky etc.

Poke around the site and look at the code on Github, with what looks like ISC/BSD licenses.

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

[2]: https://github.com/autumnai/collenchyma

[3]: https://developer.nvidia.com/cudnn

I think SPIR-V + Vulkan would be the better path to follow, considering that NV doesn't really care that much about OpenCL.

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.

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.

Yep. ANSI and ISO emerged because it was mutually beneficial for all. Just like the Khronos group. It's also important that following the standards should be voluntary so innovation can flourish without being hindered by the committee. With the hope that the good ideas will make it back into the open standards.

Yea, reminds me of the original Altair and IBM PC and how both was cloned with profit margins on the boxes falling over time. Unfortunately I think ANSI/ISO and other standard committees was probably poorly suited to setting standards in this area. The right way back then would probably be to design a reference system and release schematics and other design information.

> The right way back then would probably be to design a reference system and release schematics and other design information.

The interesting choice is to release a fully open design with a solid implementation for your own hardware but also one for the competitor's hardware that meets every part of the spec but you've spent no effort to optimize.

Then everyone starts with your API because it gives support for the largest variety of hardware out of the gate and only supports the competing proprietary API if the project has the resources and the performance difference can justify it.

Which puts the competing hardware vendor in a tough spot. Either they do the work to optimize the open API implementation for their hardware, essentially guaranteeing that the open API wins, or they don't and users of software that supports only the open API start to avoid their hardware.

This doesn't happen for the same reason that open source developers have such a difficult time implementing open standards for closed, proprietary hardware - how do you add support for a low-level protocol to a competitor's product when their product is essentially a black box?

Create an abstraction layer on top of their public API. This is the part where you don't really care if the performance is great.

I am not talking about APIs.

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?

AMD is still better for bitcoin mining but that's a matter of integer versus floating point processing power.

> AMD is still better for bitcoin mining

Neither CPUs nor GPUs have any remaining relevance there, given ASIC/FPGA miners.

Even FPGAs and older-process ASICs are unusable for Bitcoin today. The network hashpower just broke 1 exahash/second

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...

The power/monetary cost of 1 megahash is going to be different in Australia than it is in China.

That's why I said "bounds".

They're still better for integer ops like password cracking. And they're competitive for gaming.

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...

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."

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.

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.

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.

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.

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.

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.

> 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-Syste...

+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).

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.

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.

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.

Reply on news.ycombinator.com