Arm Officially Supports Panfrost Open-Source Mali GPU Driver Development | Hacker News Reader

Arm Officially Supports Panfrost Open-Source Mali GPU Driver Development

cnx-software.com

182 pointsconductor81 comments

Is this perhaps a foretelling of what is to come?

If Arm plan to drop Mali completely, to be replaced by something from Nvidia, this could be an early step to washing their hands of driver itself.

Edit: That was a bit cynical. More charitably, open sourcing the driver under these circumstances would allow the community to continue to use and support Mali even if Arm were looking to discontinue it.

Even if NVidia is going to abandon Mali, why give consumers less reason to switch and not jump ship to some hypothetical RISC-V thing? (Before one might say "well, it was already closed source".)

I want to believe this is some mid-level employee going rouge trying to salvage what they can before the inevitable rent seeking :D.

I don't get why everyone is so negative about Nvidia Arm. Is it not possible that this leads to good competition in the datacenter, and pushing prices down generally?

Nobody likes working with Nvidia, and nobody trusts Nvidia to continue licensing ARM designs and patents under the same generous licensing terms that ARM was. There's several different ARM licensees that make their own designs or repackage ARM designs in custom SoCs. Nvidia would materially benefit from, say, refusing to license designs and patents to competing silicon vendors. It would take Tegra from "that thing the Switch uses" to the only option available for smartphone vendors.

You know how everyone hates Qualcomm because they more or less pushed every other SoC vendor out of the market with aggressive patent licensing terms? Imagine that but worse.

Doing that doesn't hurt majority of the current licensees, only smaller ones.

Making Tegra competing with say Mediatek doesn't gain Nvidia much.

Stop Licensing ARM would put $40 Billion down the drain. ( Arguably it is only $12 Billion cash with stocks )

I also dont see Nintendo have problem working with Nvidia.

That doesn't mean Nvidia is good or bad. I just dont see how Nvidia's interest, ARM Interest, and most people ( including on HN ) 's interest align.

Can you please elaborate on who your "nobody" actually is?

Because the amount of partnerships nVidia has kinda makes your point suspect.

> Is it not possible that this leads to good competition in the datacenter, and pushing prices down generally?

Possible? Yes. Likely? I doubt it. Just look at nvidia's past behavior with Linux.

There's an alternate take on this where Nvidia is the only reason why there's any 3D support on Linux worth a damn....

I love how this community downvotes everyone who remembers the actual state of 3D on Linux in 2010s and goes against the smearing campaign.

> I love how this community downvotes everyone who remembers the actual state of 3D on Linux in 2010s and goes against the smearing campaign.

I have been there, on both teams. I've helped nudging one of them to their current position.

nVidia was not like this in 2010s. Their drivers were spotless, performant and specs conformant. Things went very downhill with the rise of CUDA. Since CUDA became a compute monopoly, nVidia didn't feel the need to play by the books. The undercut OpenCL agressively. Drivers' code quality went downhill. Tesla got the priority and desktop support went downhill.

I have a friend who's developing a game engine. He praised nVidia's debugging tools and utilities and swears to their drivers on any platform. Flags got ignored, code does what it wants, not what it's told to do. Commands replaced in terms of automatic optimization... It's just a black box which does something convoluted to make things work. I'm not talking about game/app/binary specific optimizations. I'm talking about standards compliant, run of the mill code.

There's nothing left of the nVidia of 2010s. They became greedy, blind, uncaring and devastating. They were the days, when the green team was the savior of 3D on the Linux Boxen. Time has moved, that ship has sailed. Red team redesigned their silicon just for open drivers. Intel started publishing well functioning open source drivers. nVidia became the dominant player in the Compute & AI segment, and they left the GPU/Desktop/OpenGL field behind.

> Just look at nvidia's past behavior with Linux.

Hmm, you mean like nVidia being the only company providing fully featured 3D support for more than 2 decades before the Linux kernel team decided they'll start demanding one-sided changes from them?

I distincly remember years and years of using Linux on desktop where nVidia was the only hope of getting the same OGL features than Windows users were getting. Even when Linux was an irrelevant blip on everyones radar.

So just because they chose to support Linux it excuses the fact they only do it on their terms? Not really. If they really supported Linux and everything it stands for, they'd merge their drivers into the mainline. If they just stopped arbitrarily limiting the progress of open source graphics drivers it would do wonders for their reputation.

They're not supporting Linux out of good will. They're doing it because it's making them money. There are probably lots of people running rendering servers out there on top of Linux. Those are nvidia's real customers.

In English saying "no competition" means either there are no competitors or the existing rivals lack the skills or resources to compete. On the other hand, having a lot of competition means the opposite: a lot of rivals that have the skills and resources to compete --> 0...n.

Merging is n-1 thus reducing competition.

Can you explain how merging two companies and thus removing a competitor leads to good competition?

ARM is not really yet a competitor because I can't just go to HP or Dell and get an ARM machine. I'd have to go out of my way, buy something from a smaller vendor, etc.

If Nvidia ARM machines become something that first-tier server vendors make available, there will indeed be competition in places there there isn't presently.

It seems like you're trying to finesse definitions until the answers come out the way you want. Why would ARM count as a competitor if there are ARM servers for sale from HP or Dell, but it doesn't count when there are ARM servers for sale from Gigabyte, and for rent on Amazon EC2? And in another comment, you're doing the same thing about what it means to have 3D graphics support.

why can't you buy one of these, for instance (not that GPUs are relevant to it)? https://buy.hpe.com/uk/en/servers/apollo-systems/apollo-80-s...

M & A leading to competition? ha ha very funny.

I think this was already planned well before the Nvidia acquisition

For context, when Alyssa Rosenzweig initially started this reverse engineering effort, she published releases via TOR out of fear of retribution from ARM. This was in response to the mysterious firing of the main person driving earlier reverse engineering efforts with clear hints at pressure from ARM. All allegedly of course, please don't sue me.

This blog post seems to discuss what you say: https://rosenzweig.io/blog/my-name-is-cafe-beverage.html

Mysterious firing of who by who?

Alyssa's blog post links to this blog post:

https://libv.livejournal.com/27461.html

I still don't understand the reluctance to get their drivers into the mainline kernel under an open source license. They have nothing to lose and so much to gain. Any SBC, Phone, Notebook will be easier to sell if it can run a mainline kernel. Android Updates will become much less of a problem and just the sheer amount of free QA work in form of bugtracker items should be well worth the effort. I do hope nvidia starts to realize this aswell and makes their drivers less closed and annoying to use on linux.

I suspect the issue is a little bit of licensing and a lot of "management" and people that think that "proprietary" is a good thing.

> Any SBC, Phone, Notebook will be easier to sell if it can run a mainline kernel.

I’m pretty sure that’s only a convincing argument to a very small market segment.

And I say that as someone who has bought a PinePhone.

Being able to run a mainline kernel means being able to receive updates indefinitely, and being able to run any Linux derivative that you want, not just Android.

When I recommend hardware, I recommend hardware that will have a long life. Lately, recommending phones and tablets has been tough, because only certain manufacturers and models guarantee software updates, and then only for a small window of time. After that, you're expected to upgrade even if your phone or tablet works perfectly fine.

Hardware that can run a mainline kernel might change that, however.

> Being able to run a mainline kernel means being able to receive updates indefinitely

I wouldn't say indefinitely. Hardware that runs Linux today, mainline or not, is not guaranteed to continue to run newer kernel releases. Drivers and even whole architectures do get dropped from the tree, though they get reverted if anyone actually notices and still cares about such support.

While indefinite sounds nice, it turns out that indefinite support is not quite what people actually want in practice, even if they exclaim otherwise. Typically, because then they're responsible for maintenance, and the common response there is "no thanks."

I'm all for getting everything upstream though!

> I wouldn't say indefinitely

I mean that indefinite updates are an ability enabled by being able to run a mainline kernel. Without a mainline kernel, there is no ability for someone to keep their hardware updated should they so choose. It's off the table entirely.

I'd say the real help would be in a new generation of cheap ARM servers. They're mostly impeded by how much variability there is in ARM processors, but having your drivers in the mainline kernel would make it far easier to sell to hardware manufacturers. I'm sure there's some incentive to keep these drivers closed source, but the potential business benefits go far beyond mobile devices.

Mainlining a driver means it will be immediately available to users of a huge number of architectures. It will be improved by other Linux kernel contributors. It will never have binary compatibility problems with the kernel, letting users update their software in peace. Maintenance costs are significantly reduced since it is no longer necessary to keep up with a free software project that receives over 20 patches an hour.

Maintaining drivers out of tree requires a few hours of testing and maybe some minor changes every two months (and that's only if you for some reason want to keep up with the main release cycle, and not just with LTS releases).

It certainly does not mean keeping up with 20 patches each hour.

People spend more time walking their dog during a week, than they would maintaining the out of tree driver every few months, if they changed to that as a hobby.

I'd guess the market for cheap IoT devices running mainline Linux is pretty big.

At this point, with Lima and Panfrost in the tree, there is no more opportunity for an official ARM driver to be merged. They are locked out.

I don’t know what that is supposed to mean. Drivers get replaced wholesale by more worthy alternatives from time to time.

> I still don't understand the reluctance to get their drivers into the mainline kernel under an open source license.

It could be market manipulation. If you have an open driver, you can use the hardware any way you want. If the only well performing or functional driver is a blob, they can decide to charge you for using specific features. Like with some enterprise use cases and etc.

Nvidia has done very well financially out of preventing use of consumer graphics cards being used in datacenters through licensing restrictions. An open source driver eats into that. And remember, Google/Amazon don't even need a complete working opensource driver - even a rough skeleton that reveals enough of the inner workings of the hardware is sufficient for them to build their own driver and save $Millions in licensing costs.

> Nvidia has done very well financially out of preventing use of consumer graphics cards being used in datacenters through licensing restrictions. An open source driver eats into that.

Yep, that's my guess exactly why they are such jerks and hinder Nouveau reclocking.

> And remember, Google/Amazon don't even need a complete working opensource driver

Google or Amazon don't need Nvidia. Google already went with AMD for Stadia, and they actually mentioned open driver as one of the major reasons.

> Google or Amazon don't need Nvidia. Google already went with AMD for Stadia, and they actually mentioned open driver as one of the major reasons.

This is complete nonsense - Stadia is a gaming platform, what does it have to do with compute power provided by nVidia's CUDA? Those are completely different, non-interchangeable, usecases provided by completely different products.

Google and Amazon have more than enough resources to avoid CUDA altogether if they wanted to. Basically, they don't need Nvidia just because of their lock-in shenanigans and if open driver is something beneficial for them.

> Google/Amazon don't even need a complete working opensource driver - even a rough skeleton that reveals enough of the inner workings of the hardware is sufficient for them to build their own driver and save $Millions in licensing costs.

Google builds their own Mali driver? That's news to me, and I work on Android's kernel team!

You can do that in hardware in most cases. Embed a unique serial number and only enable a feature if the driver passes a cryptographically signed message stating that the serial number has paid for the feature (and then sell the message data on your website).

They could, but it's a bigger hassle than slapping some artificial restriction on the blob.

It was almost exclusively out of fear of being sued by some troll for patent infringement.

This gives NVidia an go to market strategy for ARM licensees, use the "community" GPU that is bundled with your ARM license or use the "pro" GPU that costs an additional $$ and you license drivers from NVidia.

I wonder for how long this will continue, considering NVIDIA has just bought ARM.

I'm expecting this to be another Oracle/Sun acquisition, e.g. annihilates everything the old company's customers ever liked about them. So no, I don't think this FOSS contribution will continue. Nvidia is notoriously hostile to open source.

> Nvidia is notoriously hostile to open source.

I've been very critical of Nvidia and this acquisition, but I don't think this is accurate. Nvidia as a company shows a lot of evidence of a company that does not deal well with community or intercompany collaboration. But I don't believe they're actively hostile to open source.

The reason Nvidia's main graphics driver is closed source is I think merely historical. Closed source drivers were the status quo for the longest time, and the development of Nvidia's driver is built around this. Right now the thing is probably filled to the brim with hacks, (third party) intellectual property, and near zero support for the Mesa standards/architecture that came into existence way late in the driver's life. AMD's driver would also likely still be closed source for similar reasons, were it not that they decided to invest a lot of money (and lost time) to give it a fundamental rewrite - which was necessitated because their closed source driver was much worse than Nvidia's was in the first place.

There's a lot of narrative around characterizing Nvidia as 'evil' and them being actively hostile against open source, but it's just a company with its own faults (maybe moreso than others, sure) and with its own history.

The incentives around having a mainline Linux driver keep on getting stronger, and I'm actually cautiously optimistic that Nvidia knows this and will consider making the investment to make such a driver. Especially if their commitment around Linux-on-ARM has to improve as a result of this acquisition.

> Nvidia is notoriously hostile to open source.

Nvidia was the only provider of fully working OGL drivers for Linux and BSDs for decades, so this narrative is just pure FUD.

They're not "notoriously hostile" if they didn't choose to throw a wrench in their drivers and whole business just because Linux kernel people decided to trash the driver APIs one-sidedly. They're also not "hostile" because they refuse to be bullied by Linus' middle fingering into the solution that doesn't work for them.

Quite the contrary, NVidia is quite willing to contribute when it comes with money attached, like scietific computing and Hollywood studios.

Nvidia has been contributing to open source scientific computing, ml, and simulation libraries for a while now to support CUDA's adoption

The userspace vs kernelspace distinction is important here. Nvidia contributing userspace code with dependencies on their hardware and proprietary drivers is part of a lock-in strategy. Contributing open-source drivers would be a very different thing, and would undermine at least some of their product segmentation strategies.

Yet CUDA is still fully proprietary & total vendor lock-in...

Kinda surprising AMD hasn't made their own CUDA compiler and set of libraries.

They have (sort of): https://github.com/ROCm-Developer-Tools/HIP

It just isn't very good yet.

However, it features in the preparation for the Frontier supercomputer, I think, though I can't immediately find the OCLF material I saw.

I think the theory is that that's what OpenCL is, but for most people if you're building a dedicated cluster, you're buying Nvidia hardware anyway, and if you already are using the hardware for it, you might as well go native and get the best performance and library support.

OpenCL is no match for CUDA.

Stuck in pure C, printf style debugging with graphical debuggers that never properly handled everything.

CUDA, polyglot GPGPU development environment, graphical debuggers that allow for single stepping and conditional breakpoints in GPGPU code, interoperability with graphical APIs.

OTOY just replaced their rendering code in Octane Render from Vulkan to CUDA (via Optix 7).

Yet no competition was able to provice a polyglot OpenCL and IDE with graphical GPGPU debuggers.

Failure of execution from the competion is also to blame.

Yes, OpenCL finally adopted SPIR-V, when it was down and the referee started the countdown.

What's actually "open source" about what they have made themselves, as possibly opposed to modifying existing stuff? There's a significant effect of being proprietary in that people like me can't distribute packages using it for Fedora, Debian, SUSE, etc.

Not for long. Jensen has very clearly stated that the plan is to use ARM's relations to ship geforce technology (by replacing Mali).

Source on the (by replacing Mali) part? Why wouldn't the two coexist? Mali and GeForce are very different products targeting different markets, and Mali, love it or hate it, is the world's most ubiquitous GPU..

I doubt Mali will survive the purchase.

Wont it take like 18months or something to actually get the transaction done?

Nice. May benefit pinephone ,etc. aiming to become Linux-Phone .

I think Pinephone uses Lima drivers rather than Panfrost.

That said, it will certainly help the Pinebook Pro and many other SBC-based projects

Wasn't panfrost used by Puri.sm the libre 5?

No. The Librem 5 uses a Vivante GPU which uses the Etnaviv free/libre driver.

Thanks

This is good news for Pinebook Pro users.

I'm also hoping this means I can finally get working GPU drivers for my old Pine64 board. I had a couple of projects that got shelved because the graphics situation on that board was such a disaster.

That would be the Lima driver, different project. Hopefully ARM helps with that too, but Lima is a bit more mature than Panfrost and it is used for older hardware, so ARM might not think it's worth the effort.

The drivers work already.

Will it matter when its all closed source blobs because nvidia?

Let's hope Nvidia won't kill it, pushing blobs and CUDA instead, like they block Nouveau from working properly.

The article starts by saying:

"Most GPU drivers found in Arm processors are known to be closed-source making it difficult and time-consuming to fix some of the bugs since everybody needs to rely on the silicon vendor to fix those for them, and they may even decide a particular bug is not important to them, so you’d be out of luck."

Why is it then that nvidia is singled out for hatred in this regard? nvidia is an evil, baby-killing company for not open sourcing its drivers, but all the others with closed drivers (including ARM up until today) don't get hated on.

The drivers are not open source, but nvidia has released quite a few open source projects. I admit I haven't used any of them, maybe they are shit, I don't know. I just googled "nvidia open source" to find them.

https://developer.nvidia.com/open-source https://github.com/NVIDIA

For mobile GPUs the situation has always been shitty, so expectations were low.

A decade ago the situation on the desktop was different too. Nvidia was the gold standard, drivers were closed but so were AMDs, but Nvidia drivers actually worked. Intel was open, but you couldn’t use the GPUs for anything serious anyway.

Today AMD has good open drivers and Nvidia is the last one with closed drivers on the desktop.

On mobile people are much more used to a closed environment, so less are complaining.

AMD has good open drivers provided one has one of the blessed cards, otherwise it is more like it does DirectX 11 and GL 4.1, but only gets OpenGL 3.3 and be happy it works at all.

Mostly because there aren't many arm devices that target the popular linux use cases (desktops, laptops, servers). And even then servers don't generally use GPU's for anything other than AI. Nvidia on the other hand rules the laptop market for dGPUs and has a big share in Desktops.

Secondly, unlike ARM, Nvidia goes out of it's way to make it's hardware not work with open drivers. Most ARM vendors generally ignore open source drivers. Nvidia on the other hand locks down the hardware with very insidious tricks (very low default clocks that can only be reclocked to their advertised speeds by a Nvidia signed driver) to specifically block any alternate open drivers. So even if the community is determined and funded to reverse engineer and make an alternative driver, they quite literally can't.

Nvidia is singled out for hatred on desktop, because everybody else has cleaned up their act quite a bit. ARM is practically irrelevant on desktop, so the fact that ARM only has closed-source options is just not that big of a deal.

ARM is very relevant on mobile, and on that front so much is closed that basically everything deserves plenty of hate. The GPU is not a frontier there.

nVidia is collaborating on their embedded Tegra driver. Rather, they are driving its open source development. nouveau is a viable option on the desktop GPUs, if not a performant one due to the lack of re-clocking, at least it works. LIMA, Panfrost, Etnaviv, freedreno, V3D... The last bastion is powerVR, but I am afraid that this might never happen.

https://web.archive.org/web/20181112100406/https://libv.live...

This article is describing Arm collaborating on development of open source drivers for its graphics architecture - none of the other mobile GPU architecture developers are doing that so I think Arm deserves some credit for that.

> Why is it then that nvidia is singled out for hatred in this regard? nvidia is an evil, baby-killing company for not open sourcing its drivers, but all the others with closed drivers (including ARM up until today) don't get hated on.

Because they're a target of a dedicated smearing campaign from certain OSS communities who are pissed that they didn't just rewrite their drivers on their one-sided command. The kernel team rejected the nVidias API and built their own and now they expect nVidia to just bow to them.

After decades of providing fast and stable Linux 3D accelerated support.

Reply on news.ycombinator.com