It’s Time to Open Up the GPU
gpuopen.com
gpuopen.com
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.
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."
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.
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...
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...
[1]: https://github.com/autumnai/leaf
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.
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.
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.
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?
Neither CPUs nor GPUs have any remaining relevance there, given ASIC/FPGA miners.
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...
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.
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.
Video encoding on CPUs is extremely inefficient and essentially precludes on-demand encoding.
Seriously, back around the turn of the century I was pretty heavily into graphics and rendering and was frustrated by all the constraints on getting access to documentation. I finally figured out a way to pin down a vendor with all the necessary NDAs and all the necessary agreements so that I could actually get 100% access to the inner workings of the GPU. As long as I read the documents onsite at the vendor's office and brought no means to make copies. And after all of that, in discussions with the vendor's counsel, their biggest fear was that as GPUs were so competitive, and so heavily protected by IP, that they did not disclose any details to people who might see something that might be protected by some patent somewhere and defending a lawsuit, which always settled before discovery because nobody wanted to actually share their documents! It was insane.
That said, I think an open GPU is an excellent idea, however while I don't think it will get built any time soon I think just publishing all the techniques and algorithms will draw out all these lawyers and we could hopefully arrive at the 'available set' of features which one can implement. I expect though that you need a Google level VP8 kind of program for this to make progress (and Google failed there if you recall)
Google paid off MPEGLA so they wouldn't sue for anyone using VP8. That smells like success. http://arstechnica.com/information-technology/2013/03/google...
Interestingly, most console developers currently have this sort of access. If they are just targeting consoles (or better, a specific platform), they're able to get a lot done. The tricky part is if they have to target PC and consoles. They have the access they want on consoles, but can't replicate on PC.
Actually, on top of that, replicating that task on PC would mean giving developers a nightmarish mix of varying, quirky architectures to target. Realistically, what most _engine_ devs want on PC are more current and lower level access APIs (DX12 and Vulkan) and maybe even an OSS shader compiler. The compiler wouldn't be even for them to poke at. I think they'd hope that the OSS community might do a better job than the IHVs at maintaining the compiler.
This isn't what the article is about.
I've been in groups that have been on the receiving end of patent lawsuits twice. Both times the patents were transparently invalid.
The first time involves my dorm at MIT. Back before I arrived there some enterprising student had hooked up our laundry machines to the internet so we could all find out when there was a free one and when our laundry was done. The internet at large got wind of this and sadly the servers were Slashdotted in both senses of the word. Shortly after the idea appeared on Slashdot some enterprising entrepreneur filed for a patent on the idea of hooking laundry machines up to the internet and was granted it. Several years later our dorm, through MIT, was sued for patent infringement. Luckily the MIT administration had spines so they didn't get anywhere. But the patent is still in force and other universities still have to pay millions of dollars to this group to hook their laundry machines up to the internet.
The second time involved the first company I worked for out of grad school, a sensors consultancy. They had some ideas about structural health monitoring using piezoelectrics and sent their designs off to another company to be fabbed. They filed for patents on their ideas and shortly after the fab house filed for patents on those same ideas. They mostly got their patents but for some reason the fab house got one in first despite filing later causing their patent application to be denied. Then the fab house sued them and somewhere in the process there were layoffs and I lost my job.
Just because something is patented doesn't mean that it is original and non-obvious. The Patent Office doesn't actually have enough resources to do the job that has been set out for it. The number of patent applications being submitted has increased exponentially over the years but the USPO staff hasn't. You might ask why they just don't fail to grant a patent until they've examined it carefully. Well, they used to do that but the backlog got big and Congress In Its Wisdom passed a law saying that they couldn't have a backlog. You might ask why they don't raise filing fees and use the money to hire more workers. Well, Congress In Its Wisdom has decided what the fees are and has also decided that the USPO can't keep all the money it collects since there are needy people in many other Congressional districts. So that's where we are.
It would not surprise me in the least if many NVidia and AMD patents cover the same ideas in different language. But just because AMD happens to have a patent on the technique they're using doesn't mean that NVidia can't sue them with their own patent on that same technique. Legally patents have a presumption validity behind them so courts are bound to assume the USPO gave them the sort of inspection the USPO is unable except in certain complicated cases.
I also cannot conceive of many industries where the barriers to entry are higher.
The first time I got my feet wet with code, I realized that the workflow was mostly "write and pray it works". No debugging tools, huge blobs of proprietary code and total lack of consensus among manufacturers even on the most basic stuff scared me away. I ended up doing a machine learning thesis instead.
This was almost ten years ago. I can't say I've been following the graphics field closely, but my impression is that while tooling came a long way in the past ten years, the GPU is still mostly a black box for the developers who don't have access to a debug build of the driver of the graphics hardware at hand.
Such initiatives couldn't come soon enough.
Behold, history repeats itself.
I'm hoping that Vulcan will be that new competitive standard moving forward. I don't have much hope for open hardware and open drivers from market leaders (who are too concerned with losing their edge to competitors) but I would be happy with an open API that leads in performance across vendors.
When one company continually calls out for 'openness' in a marketplace over time I think people get annoyed at it, I know I do. AMD, you're nearing the point where people are just going to scoff at you and take it as whining. You can't say you want openness then build your tools specifically for your own hardware without looking like an ass. Furthermore, 3/4ths of the sample are for DX only. How open is DX again?
Nicolas Thibieroz is the Senior Manager of Worldwide Gaming Engineering at AMD...
From the middle of the article:
GPUOpen marks the beginning of a new philosophy at AMD.
Where is any of this? I find a bunch of press releases, but.. there is no code, anywhere.
(Edit: for anyone else struggling, expand the arrow on the top left. Or go directly to e.g)
http://gpuopen.com/professional-compute/
(That said, a bunch of the repositories are just binary dumps. Like, this isn't what Git is for AMD.)
So, it seems that gpuopen site is open for AMD to promote whatever they deem promotable. Not very open for this age in my opinion.
This sounds like it's more about officially documenting and supporting the kinds of things people have been reverse-engineering: https://news.ycombinator.com/item?id=10605156
And at the moment, it seems like GPU architectures within one company aren't really that much more diverse than Intel's CPU architectures over a similar time period. They're not overhauling the ISA every year.
I don't think they'll do it. I think they're going to shoot for SPIR-V being close enough that SPIR-V compilers generate code good enough that the internal compilers can gen good ISA code.
> They're not overhauling the ISA every year.
They aren't, but the changes rev to rev are more significant than you'd expect. On top of that, the big bumps are significant, such as Fermi to Kepler or Northern Islands to Southern Islands (or whatever). These are not backwards compatible with each other, unlike Intel x86 ISA.
Bonus edit: Also...I'd speculate that some IHVs would rather not expose their IL-to-ISA compiler. Not because of 'secret sauce'. But because they aren't that good, and would rather have the OSS community start fresh and do a better job.
90% of this are useless super large images.
Also webpagetest.com counted 23 javascript requests.
* They're better at graphics than that other stuff,
* Other auxiliary processors exist which beat GPUs on most kinds of that other stuff (though they aren't as accessible as GPUs),
* Most importantly, what sells GPUs is first and foremost their performance on graphics workloads. A GPU with stellar OpenCL performance but sucky OpenGL performance will be outsold by a huge margin by a GPU with the reverse characteristics.
So they're GPUs alright.