"Hardware vendors being unwilling to make the drivers they write open source" is a pretty fundamental reason.
Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option. The open source community is not, for example, going to make their own high performance gpus.
I would not say that is a fundamental reason. They have been willing to do it when the proper incentives are there. The incentive to keeping it closed source is primarily part of a strategy to sabotage their competitors, which I hope is not a behavior that anyone here is complicit in. Please don't work for hardware companies that do this, there are plenty of companies out there that know how to spend their money in other ways.
>Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers?
Neither of those are good options because even in the second case, there are still vast swaths of code that upstream is not going to touch out of fear of breaking things, the end result being that you still get stuck with unfixable kernel and driver bugs.
>The open source community is not, for example, going to make their own high performance gpus.
The open source community includes a lot of companies. The high-performance GPU companies are welcome to join this community any time they like.
This claim is wrong. It’s not about sabotaging competitors, it’s about being afraid that your competitors would steal your IP they gives you an advantage.
Every Nvidia and Intel competitor (AMD) is probably already reverse engineering their binary drivers and binary libraries trying to steal their IP, so Intel and Nvidia’s fears are imo justified.
If NVIDIA or Intel could easily protect their open source code from being stolen from AMD, the story would be different. But you can’t prevent somebody from reading even GPL code, being “inspired” by it, and writing something different enough that does the same thing with the same ideas. Like just look at the LLVM project were people look at what GCC code does every now and then for “inspiration”.
> Every Nvidia and Intel competitor (AMD) is probably already reverse engineering their binary drivers and binary libraries trying to steal their IP, so Intel and Nvidia’s fears are imo justified.
If NVIDIA or Intel could easily protect their open source code from being stolen from AMD, the story would be different.
Intel's GPU drivers are free software, they even contribute them themselves, same goes for AMD.
I think NVIDIA's different because they have the Apple mentality of them being the real innovators, (regardless of fact) and building their internal culture on secrecy, closeness even to other teams within the company etc. I think they consider it as part of their 'coolness factor', together with the CEO being on stage dressed like a rock star from the 80s.
The fact that they benefit from Linux massively and that having an open driver would win them massive goodwill is not directly measurable in terms of their balance sheet, at least in the short term, plus it would remove some of the secrecy.
They do so by using different teams, and their open source variants always lag behind what their closed source drivers are capable of doing across Windows, Apple and game consoles.
The drivers are decent enough nonetheless. I think having an open driver done by a different team and maybe a bit less optimized is still preferable to not having an official open driver at all.
I used to enjoy my OpenGL 4.1 driver on Radeon HD 6250, which was still short of OpenGL 4.4/DX 11 on Windows, but still quite ok I guess, all it does now with open source drivers is OpenGL 3.3.
So no that isn't decent enough, and I only keep it like this, because it is just a little travel laptop that I keep on using until it eventually dies.
Why even mention a fairly ancient GPU when AMD has really only gotten their act together fairly recently with amdgpu, but that supports Vulkan as I would expect.
I don't get this constant obsession with mentioning how 8 years ago this and this on Linux sucked. Yes, it did, things improved considerably since then.
If you're only willing to run Linux on ancient, underpowered hardware and then complain about the experience, be my guest, but I think you'd be better served by a Mac.
There's a whole class of people who run Linux on shitty little laptops and then compare the experience to their brand new iMac. I guess somewhere there's still the mentality that since one's not paying for Linux, it's not for my serious hardware, only second hand.
As much as I'd have liked for AMD to get their shit together sooner, I am glad they eventually did and are improving amdgpu at a decent speed.
Having worked for a GPU company, it's not even about stealing IP. It's about giving ammo to your competitors for suing you. If you publish the source code to your drivers then let's say Nvidia can read through them and find a few similarities in your hardware to something they have patented, and then sue you for IP infringement. They can't do this without some evidence that there might be a similarity, but weak evidence is enough. So they basically send you a set of 100 patents that they say you violate, and then it's your job to spend your legal resources to show how you don't violate those patents. It might be easy to show this for say 90 of those patents, but there can be a few which require considerable work, and if you're a small company you don't have the resources to fight off lawsuits all the time. So open sourcing your drivers opens you up to a lot of potential attacks, with very little upside. More specifically, it opens up the companies that buy GPU IP from you to attacks. Nvidia on the other hand has the resources to keep throwing accusations at you and see what sticks and force you to burn cash on legal resources.
That is an assumption. I think the simpler case is it's more work and exposes potential security vulnerabilities they don't care to patch or maintain. Function > all.
The incentive to keeping it closed source is primarily part of a strategy to sabotage their competitors, which I hope is not a behavior that anyone here is complicit in.
I can't figure out what you mean by "sabotage their competitors". The term sabotage indicates that they are performing actions to actively harm their competitors, how is that related to keeping your source, which cointains your IP, private?
The open source community includes a lot of companies. The high-performance GPU companies are welcome to join this community any time they like.
It is nice to hear that they are welcome :p. Which they would even feel more so, if there were actual incentives being offered rather than trying to make their life artificial difficult.
> The open source community is not, for example, going to make their own high performance gpus.
I think we should lower the entry threshold first. The open source and free GPU project was the first thing that came to my mind when I saw http://llhd.io/. After all, one of the main problems with OpenHardware projects is the closed FPGA ecosystem.
It's pretty amazing how far the open source FPGA tooling has come in the last few years. I'd even go so far as to say some parts of the open source ecosystem have surpassed the commercial tools.
Still a long way to go of course, but I'm pretty positive about the direction things are heading.
Plus, better isolation between driver code and other kernel code (which Fuchsia seems to bring; correct me if I'm wrong) would be good for everyone, since you can be relatively assured that running vendor-provided driver blobs is safe.
"Isolation" of driver code that can talk to on-SoC hardware is just not very meaningful. You can only have real driver isolation if it's enforced on the hardware side via some IOMMU mechanism (or by keeping the hardware isolated on the USB bus, etc.), otherwise you're just adding pointless overhead for no real benefit.
It's desirable, but typically hardware devices have DMA-capable buses that can read / write to arbitrary physical memory. So a buggy or malicious WiFi driver may be able to use the WiFi DMA hardware to write into the GPU driver's memory, and no pure software mechanism can stop it from doing so.
IOMMUs solve this problem by giving hardware devices their own virtual address spaces.
> Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option
A phone in which the kernel never needs to be updated, like with the seL4 microkernel.
Most BIOS are also closed source. If I used a microkernel primitive enough not to require changes, I could live with not updating the kernel unless there is a security bug.
A third solution could be to require device manufacturers to share their source code with a trusted third party (such as google/certification authority). This third party will make sure that the driver does not include any harmful code and provide signed binaries. Binaries could also be updated for newer versions that way, even if the original manufacturer loses interest/goes bankrupt. If the IP gets stolen, the device manufacturer could sue this third party, therefore business people will also feel secure.
It is not ideal, but I could be able to live with this solution.
Doesn’t look that good to me. The Vortex is not a GPU. They call it GPGPU, meant purely for running OpenCL kernels, doesn’t have a graphics pipeline at all, which is kinda important part of a GPU.
They use compute shaders for triangles that cover 1 pixel as rasterization always does 2x2 due to derivative calculations etc so there is overhead. For larger triangles they do go trough the rasterization pipeline as usual because it is so much faster.
Another crucial thing is texture mapper. That thing is really fast and usable even in the compute pipeline. Image support is (was?) largely optional in OpenCL.
Also I remember the last time people talked about this. PS3 was not originally supposed to have a GPU at all because the Cell processor was so powerful. In the end they had to ram in an actual GPU. While the Cell was just fine for vertex processing it did choke terribly in rasterization due to lack of TMU and dedicated HW rasterizer.
EDIT: I also want to emphasize the difference of target markets. On AMD one can go to the Nanite path for some of the rasterization. One must remember that it is a non battery powered device.
Memory bandwidth is really power hungry. For mobile, the likely target market for the Vortex and similar, one really wants to do tile based rendering. Ideally the way IMG does it. Even though theoretical flops of modern mobile GPU’s is higher than some old discrete ones their memory bandwidths are way lower, so no running Crysis on modern mobile even though flops would indicate it would match a good discrete GPU back in the days.
Sorry, walk me through this. There was a competitive field of GPUs. Somehow the companies were able to produce hardware. Are you saying that someone controlled the defining patents, and all of the competitors were forced to license from them?
Currently the GPU market consists of companies that have been working on GPUs for decades. Companies that are starting right now have failed to design GPUs. This includes very big players, like Intel, Apple and Huawei. This is likely because all the important ways to produce GPUs have been patented, and there's only so many ways to create an efficient GPU. Even if you try to create your own GPU by poaching engineers from existing GPU companies (like Apple tried), those engieers are only familiar with methods that were already patented and you have no way around this even if you have Apple's tremendous resources to throw at the problem. So the only way to create an open source GPU is to use patents that already expired. Such a GPU might be 15-20 years behind current technology, but that's still a GPU.
"Hardware vendors being unwilling to make the drivers they write open source" is a pretty fundamental reason.
Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option. The open source community is not, for example, going to make their own high performance gpus.