It's arguable in the case of ARM/Mali but sadly, there is for NVidia.

Their driver are not merely to "communicate" with the hardware. The driver include a lot of hotfix and optimization, sometimes specific to one game/application. The driver give them a competitive advantage over their competitor. They will probably never released it for free.

They could do the same thing AMD did, which is keep their game/application API optimizations secret within a proprietary userspace stack, but also make it work with the open source Mesa/Gallium3d stack. Leave the OpenGL/Vulkan software development part to software developers (or keep doing it yourself if you think it's that important), but at least tell us how to drive your hardware.

Interestingly, amdgpu/Mesa performance seems to be higher for typical game rendering than AMD's proprietary stack. I suspect at some point in the future AMD will abandon their 'pro' proprietary stack entirely after realizing they should stick to being a hardware business.

> I suspect at some point in the future AMD will abandon their 'pro' proprietary stack entirely after realizing they should stick to being a hardware business.

John Bridgman of AMD confirmed it's their plan like 5+ years ago. The only reason they ever maintained proprietary stack on Linux is workstation users who need certified OpenGL implementation for various proprietary software.

By now the only proprietary parts of "pro" stack are OpenGL implementation and shader compiler for Vulkan / OpenCL. Everything else in "pro" package is open source already. There is still legacy OpenCL implementation, but I guess ROCm will be used for everything soon.

I whish they would go the same way that AMD did, but I doubt we will see it any time soon. The thing is, AMD/ATI lost the software war against NVidia for quite a while now. AMD didn't have much to lose by open-sourcing their driver. And the AMD proprietary driver on Linux where always a mess, whereas NVidia at least "work" (even though they just refuse to play well with the linux env...).

Now, with NVidia diving more and more into the ML / GPGPU market (which is less windows-focused), they might have more pressure to actually open-source their driver (or at least, finally make them actually integrated properly with Linux), at least for their server focused hardware. But I wouldn't bet on it any time soon.

Let's be honest, they have a dominant position on the market. And their driver, as awful as they are, work. I think a lot of things would have to change for them to have the incentive to open-source them. My only hope at this point is that, with the growing GPGPU market, they might finally start to see Linux not as a second-class citizen.

The last time that I checked AMDGPU experience is far superior that NVIDIA proprietary drivers.

Since they started to seriously open-source their driver and work with the Linux maintainer, definitely.

This is most likely due to ARMs IP-licensing scheme relying on charging customers for the hardware IP and then again charging them for the drivers that they are going to need. As far as the rumors go, they used to charge customers a 3rd time if they wanted OpenCL support.

Strictly speaking the kernel drivers for the ARM Malis are all open-source and GPL licensed (they need to be, since their customers want to ship Linux to consumers).

They are also entirely useless without the userland software that is doing all the actual work. The kernel drivers are just glorified task and memory managers.

It would be nice if they had been dual-licenced like the radeon, intel and nouveau kernel drivers.

I thought that the Lima and Panfrost projects included an open-source userland component too.

They do, the userland part is in Mesa:

https://gitlab.freedesktop.org/mesa/mesa

While the kernel driver is Open Source, they have decided to implement a driver that can _never_ be submitted upstream for Kernel inclusion.

Could you expand on this? I don't follow kernel development closely. Why can't it be upstreamed? Is there something the community can do to modify their code for inclusion?

The DRM subsystem where the graphics drivers live in Linux has a strict open source userland policy - every new kernel interface needs a corresponding real userland implementation that exercises it. So a graphics driver that is only used by a closed source userland blob has no chance of being upstreamed.

And of course just generally vendor kernel code tends to have superfluous middle layers or abuse kernel interfaces in unintended ways.

There's basically no chance that the current proprietary drivers will ever end up upstream, so if ARM / nvidia drivers were open source they would be out of tree.

Given that the most frequently cited reason that these drivers should be open source is improved user experience (less breakage when the kernel changes, easier install), what would be the advantage of an out of tree open source driver?

What is their reasoning?

I don't work for ARM Holdings, so I don't know.

However, my experience in the hardware industry leads me to believe it's something about an 'intellectual property' fetish and pearl-clutching when confronted with the idea of 'giving away code for free'.

As someone who has worked on a chip design team and had to deal with this stuff... one of the biggest reasons is patents -- software patents. They can't sue you if they can't see what you're doing. There are lots of dumb software patents out there. AMD did get hit with a couple of those, but we were able to beat them because the order of operation didn't exactly match the claims in the patent.

Often it's a mess of third party proprietary dependencies, code owned by subcontractors, etc.

e.g. when AMD open sourced AMDVLK, they had to replace the proprietary compiler it was depending on with LLVM. That was an easy one. Many projects are much more deeply intertwined with proprietary crap.

Usually the code is not important, just the specification. Data sheets and explanations of how the hardware acts will do, they can keep their secret code.

I forget where I read this, but I recall that due to patent situation it's practically impossible to build a GPU without infringing on some patent or another. By keeping drivers closed source it's possible to maintain deniability- if ARM released open source GPU drivers it would be trivial for rights-holders to look at the implementation and see what they can sue for. It's not impossible to do this with blob drivers, but harder.

I don't buy this. See: AMD and Intel both have open source drivers.

I'm not sure what there is to buy. Just because AMD or Intel managed to do this doesn't mean it's any easier or cheaper for nVidia or Arm. AMD actually has been sued before over this kind of thing. Why not just save yourself the trouble and effort of making an entirely legal and safe open source implementation when you can just keep trucking with closed source?

Maybe they are the aforementioned rights-holders :)

Nvidia's closed source kernel driver (and others) might be found illegal in court if a Linux rights holder bothered to sue. But unfortunately there is no one interested and rich enough to do it.