Hacker News new | ask | show | jobs
by robert_foss 3371 days ago
In the GPU space it is impossible to not infringe on the IP of other vendors.

In fact it is the major reason GPU vendors give for not having an open source driver. I have spoken to the CTO (Jem Davies) of ARM about the GPU drivers and open sourcing them more than once. And every time I've gotten the reply: "No, we can't, it opens us up to IP infringement suits."

Full disclosure: I used to work in the ARM GPU division.

6 comments

One should keep in mind, this is true of basicly any software whatsoever. It ALL infringes on patents, nearly without exception.

There is always legal risk in open sourcing code. Infact there is legal risk from pretty much any action whatsoever. Good, responsible companies don't let that become a barrier to doing the right thing.

If ARM really cared, GPU stuff would be open source. The fact it isn't pretty strong indication they don't. Don't just accept it when lawyers say no.

After all AMD and Intel both have full open source graphics stacks, and the world hasnt exploded yet.

Should also be noted, keeping stuff closed source is not very strong protection against reverse engineering, if it was DRM would actually work, and it never really has, dispite decades of effort. So its doubtful that keeping stuff closed is much protection against patent lawsuits.

GPUs are hardware, not software. The patent situation there is much clearer. Critical hardware features of GPUs belong to different companies and the licenses for using those features often include highly restrictive licences for the code that drives them, or contractual obligations to use and not publish such code because doing so would reveal internal details of the hardware implementation of those features, which are trade secrets. Many drivers also load proprietary microcode into the CPU. AMD's 'Open Source' drivers do this.

Put simply, the GPU vendors do not actually own all the rights to their own driver software. AMD had a project to improve the state of their drivers on Linux, but the approach they took was to try and rewrite and open source the code implementing the public API to the closed binary blobs inside the drivers, to make it easier to maintain the stability of the drivers across kernel versions. Open sourcing the blobs wasn't possible for AMD because the code in them just doesn't belong to AMD.

>Don't just accept it when lawyers say no.

Which lawyers though? It's not necessarily ARM lawyers that are the problem. You'd need to get agreement from the dozens of patent holders of various bits of the technology, most of whom are unknown as their identities are confidential.

Good, responsible companies don't let that become a barrier to doing the right thing.

Despite what Stallman would have you believe, open sourcing your own code is neither right nor wrong. It's just a choice.

Its most definitely a quantifiable, collective wrong when that choice leads to a total security disaster like the embedded ARM situation. It might not be so bad if they bothered to update their drivers, but they dont even let other people try to do so.
Open source software has plenty of high profile security disasters too. Pretending otherwise is either ignorant or disengenuous.
Unluckily this is true. But there is a central difference: If such a security bug occurs in an open source software, you can in principle look for the bug source yourself to fix it to secure your computer to against attacks. If it is closed source, this is hardly possible or often such a self-defense is even illegal.
In theory yes, but just to take one well known example, the HeartBleed SSL bug was introduced in 2012 but wasn't found until 2014.
Open sourcing commercial products like hardware architecture and algorithms to the public is not exactly an easy thing to do.

There are millions of registered patents and the chances that your clean-slate ideas were already invented and patented are really high.

Open sourcing means exposing patent infringements to the public (even if you are not really aware that you are infringing anything), which means that you need to invest on a strong legal team in order to go through all possible patents and to deal with all possible litigations you might face.

In order words, open source requires much more than ideals, it also requires butt loads of money.

Why has open source been so successful on the CPU then? Branch prediction, say, is no less a patent minefield than GPU framebuffer tiling. Yet gcc and LLVM have no trouble shopping optimizers.

This is an excuse, basically. They just don't want to because they fear revenue lost to compatible implementations.

Those are compilers. What open source CPU is there?
Uh... the GPU drivers we're talking about in this subthread are precisely "compilers" for the shader architecture (and configuration generators for the texture units and framebuffer layouts, etc...). In fact for architectures other than NVIDIA's the hardware-facing part of the linux driver already is open source.

The only secrets left are the bits responsible for turning OpenGL (or Vulkan now, I guess) calls into programs to run on the GPU.

Wouldn't it be fair to say that GPU architectures (at least thus far) tend to change a helluva faster than CPU ones?

I can think of AMD adopting and then ditching VLIW for one.

OpenSPARC T1 and T2 are open source and don't have out-of-order execution.
That's completely different, there is interest to expose your CPU architecture in order to help people write better compilers and better programs.

But on a GPU, the whole interaction between the GPU and the application is abstracted by APIs like OpenGL and Vulkan and you own the driver, you own the compiler, you own the implementation and you own the architecture. So companies tend to protect their "secrets" since they own the whole product.

If you are asking me why is it different... Ask these patent trolls instead:

- https://techcrunch.com/2014/09/04/nvidia-sues-samsung-and-qu...

- http://www.anandtech.com/show/11101/amd-files-patent-complai...

It's not an excuse, it's the sad reality.

And there is no interest in exposing your GPU architecture in order to help people write better compilers and programs?

Just as on a GPU, the whole interaction between the CPU and the application is abstracted by APIs[1] like C and Python.

[1] Yeah, we don't call them APIs. But then we don't call GLSL a "API" either. They're all languages.

> If ARM really cared, GPU stuff would be open source. The fact it isn't pretty strong indication they don't. Don't just accept it when lawyers say no.

Easy for you to say, harder when millions to hundreds of millions are at stake.

Its always easier to be an armchair critic, but I bet there are more than hundreds of millions waiting for whoever can de-crappify the embedded ARM driver ecosystem.

Especially when this crap is at the root of why virtually every embedded linux product has serious security flaws that never get fixed. You cant update the kernel if you cant update the drivers.

If there is a reason on why ARM's GPU drivers are not updated on your device, it's hardly ARM's fault. ARM doesn't ship the SoC or the device directly to you, it ships it to the OEM. And it's the OEM who states the agreements.

If you want to blame someone, starting by blaming the OEM.

ARM still writes the drivers for the chip and then dosent update or open them up. Not much OEMs can do about that.
But ARM cannot, and won't, officially support the OEM's devices and start releasing updates for them. The process is a bit more complex than you might be imagining.
ARM has a reference design which includes drivers. The OEM is responsible for the final design and validation. ARM cannot take responsibility for validating 1000s of implementations that vary in both hardware and software configurations and validate them for billions of devices. Neither can the FOSS community. For the handful of boards which are popular enough to have sufficient tracking for the FOSS community to take the wheel if an open source driver was available the OEM has sufficient incentive to support their platform. For the other 4,999,999,990 LowHo NiHao industries unbranded boards it wouldn't matter in the first place.
> but I bet there are more than hundreds of millions waiting for whoever can de-crappify the embedded ARM driver ecosystem.

Hyperbole much? 7 billion people on the planet, and "more than hundreds of millions" of them are waiting with bated breath for the "de-crappification of the embedded ARM driver ecosystem"?!?

I think you'll find the hundreds of millions in question were dollars, not people.
You're almost certainly right. Oops!
First off, that problem already exists in the hardware, the damage is already done (as i stated in my blog entry http://libv.livejournal.com/26635.html under "the patent excuse").

There was another big smoking gun recently, at linaros conference in budapest. Here finally some truth was spoken at 9:40 into the video: https://www.youtube.com/watch?v=dPjSm_98rgo&t=580s

Like IMG, ARM is not selling just the hardware design, it is also selling driver development services. When the driver is open source, and competitive, everyone can sell such services, and there's a lot less of those services to sell. ARM has revenue depending on this.

This is one good thing about the IMG revenue coming from Apple, it was mostly licensing costs, not services. If IMG had been selling services on top, their revenue would've been reduced by 75%+ instead of "just" ~50%.

Can we ever fix this system and get a better balance of rewarding innovation vs. accepting patent abuse?

How about this for a litmus test. Present a problem to new 4 year college graduates that they haven't heard the answer before. If x% of come back with a solution, that solution is obvious enough to be consider invalidating the patent.

Or let validity be judged by independent groups of practioners who weigh the novelty and also the impediment of a patent to world progress.

As those who've written patents already know, they are not even decent scientific or technical documentation. They're mostly a bunch of jargon and phrases meant to tic off legal checkboxes. No one would ever write a document that way if the sole purpose was to explain something.

Yes, that is why pretty much All GPU markers have deal cross licensed with each other.

The story from last year was that Apple's price for IMG acquisition weren't high enough, and Apple asked if they could buy ONLY the graphics portion. Which resulted in a NO from IMG.

Compared to ARM, some estimate Apple is paying $10M for the ISA and roughly $0.1 for each Ax SoC. So that is ~30M per year, ( There will be other cost for processor other then Ax, such as the Motion Processor etc ) Compared to paying roughly $80M USD for the Graphics alone, which Apple doesn't even use their design, nor their services ( Software Drivers ) they provide. So what likely happen was Apple wanted to pay far less, ( $20M? ), but their New CEO wanted them to pay for more.

My guess is that in the end Img will relent and license whatever Apple wanted for a price. If not, I am not sure how Apple will deal with old games that wont work with their new GPU which does support PVRTC.

I have heard that ARM has not been too pleased with IMG buying MIPS and competing directly with ARM.

Perhaps ARM would license their GPU patents to Apple and provide some IP protection.

Apple could also license patents from AMD. They don't compete directly.

AMD sold their mobile division to Qualcomm; Adreno is just Radeon with the letters rearranged. They may not be able to get involved in mobile.
> In the GPU space it is impossible to not infringe on the IP of other vendors.

It's high time to reform the corrupted and broken patent system. Yes, I know, like having non-corrupted politicians, this is not going to happen.