Dissecting the Apple M1 GPU, Part IV

https://rosenzweig.io/blog/asahi-gpu-part-4.html

by caution • 5 years ago

379 117 5 years ago

_x5tx• 5 years ago

That’s an impressive amount of progress already. Congrats on the work. I’m waiting apple’s next silicon to jump to arm, and hopefully by then I’m going to be able to run linux on it.

tambourine_man2• 5 years ago

Natively, it's gonna take a long time, I'd wager. Virtualization works pretty well today, however.

floatboth6• 5 years ago

Pretty much all the things except the GPU are working in Corellium's quick'n'dirty "demo" Linux port. And you see how amazingly quickly the GPU driver is coming along… So not that long of a time after all (I'm surprised too).

Engineering-MD• 5 years ago

So, given the current trend in progress, when will we have truly usable linux on M1?

mekster• 5 years ago

Would server vendors start putting out M1 in data centers once Linux truly runs on it?

Doesn't opening up driver specification also let M1 start ruling in the server spaces?

blinkingled2• 5 years ago

Servers/Datacenters aren't just about being able to run Linux though. How are they going to do firmware updates? Apple can break stuff as there is no contract there like there is with x86 server vendors who test all their updates to make sure Windows and Linux runs. Besides there's the whole issue of configuration/systems management, remote access and bulk chip availability.

kingsuper20• 5 years ago

My guess is that part of their perceived income flow implies that the MacOS is running on it. Music purchases, surveillance marketing, app purchases, dunno.

If they had the extra volume potential, it would be cool to see an extra cost M1 computer that boots and runs Linux with no fuss.

floatboth6• 5 years ago

Why would a datacenter want a (weird, tiny, embedded) M1 when they can get an 80-core, 8-channel, 128-lane Ampere Altra – which is actually designed to be standards compliant and even has an open source firmware option?

(Even a future "large" Apple SoC is unlikely to be datacenter large…)

Jasper_2• 5 years ago

Well-written apps generally require primitive restart, and it’s almost free for apps that don’t need it.

I'm really surprised that primitive restart is forced on in Metal, but they also have a hardware bit for it! Primitive restart makes your whole pipeline slower, because you can't just chunk your index list when building your vertex packets to send to the work distributors; the possibility of a primitive restart index means you have to linearly scan for it. Though I'm not a hardware guy -- maybe the degenerate tris thing makes it just as annoying in practice.

I'd guess that the limitation to force primitive restart on in Metal came from another IHV limitation (maybe old PVR chips?)

That said, you really shouldn't be using tristrips in 2021 anyway, they have poor locality, and are hard to optimize. Index buffers solve the problems that tristrips wanted to solve to begin with.

IME, a well-written app should just ignore tristrips / restartable topologies, and just use straight tri-lists.

atq21192• 5 years ago

In theory you could do parallel scan tricks to implement primitive restart at full speed, but obviously it's going to cost you and it complicates the index fetch immensely since it effectively ends up being split into two parts.

Most likely, Apple simply doesn't build GPUs big enough to run into that problem, but it makes you wonder what they're doing on their hardware with AMD GPUs.

varispeed3• 5 years ago

Hopefully one day companies like Apple will be forced to disclose documentation to the devices they sell so that consumers can make the full use of them and won't have to waste time on reverse engineering.

enos_feedler• 5 years ago

that would put a lot of obligation on the vendor to honor some kind of contract they don't need to do today. They can change anything they want with zero cost today.

NoSorryCannot• 5 years ago

Does documentation necessarily create such an obligation? That would jeopardize most open-source projects, most of which explicitly promise no warranty.

gpm5• 5 years ago

They could change what they want afterwards too presumably, they'd just need to publish the new documentation along side it.

ddingus• 5 years ago

Zero cost to them perhaps. However, those costs often prove quite high for others.

Right now increasing numbers of things are, "works until it doesn't" and that imposes risks and costs to everyone.

Perhaps those get high enough to warrant legislative solutions.

_ph_4• 5 years ago

No, this applies only to APIs, which are documented as such. The users of such APIs might have a certain expectation of long-term support. This is talking about documentation of the device which is sold, the software equivalent of providing schematics to eletrical devices. Which for a long time was quite common. You could buy stereo amplifiers with complete schematics. They don't create an obligation that future products have the same schematics, their purpose is solely for the repair of the device sold.

gspr4• 5 years ago

that would put a lot of obligation on the vendor to honor some kind of contract they don't need to do today. They can change anything they want with zero cost today.

So why can't we just allow them to keep making those changes, but still have to document them? I'm sure they document them internally anyway.

meibo• 5 years ago

Then you'll probably get a link to a zip on the very bottom of the "legal >> open source" section of their website with badly auto-generated API docs without any comments or context, knowing big closed-source software orgs.

pthariensflame• 5 years ago

That’s more or less what they currently do: https://opensource.apple.com/

troutmskreplica• 5 years ago

Under what legal principle would this be based on, and why haven’t we already seen this happen over say the last 50 years of consumer electronics?

notafraudster• 5 years ago

I mean, we also haven't seen it in the last 150 years of consumer mechanical parts either!

gpm5• 5 years ago

Eh, lots of potential future legal principles.

Right to repair. Hasn't happened because it's not a right yet.

Alternatively maybe anti trust, since using your monopoly on hardware to get a monopoly on software which is the essence of anti trust anyways. Hasn't happened because anti trust enforcement is really weak. Probably also doesn't force documentation.

Alternatively copyright and patent misuse, which is using your government granted monopoly on creating the exact hardware (copyright), or some of the features in the hardware (patents) to get a monopoly in an adjacent area (running software on that hardware) voiding the copyrights and patents. Hasn't happened because while the law exists (in common law) the courts apply it very conservatively. Also probably doesn't get documentation, just the right to run things on it.

Alternatively an interpretation of the quid quo pro of intellectual property (i.e. you disclose something in exchange for a temporary monopoly) being interpreted more strongly, such that you have to disclose the details of the internals to get intellectual property rights. Hasn't happened yet because today the quid quo pro isn't interpreted that strongly.

varispeed3• 5 years ago

Until the early 90s probably you could get documentation for every device sold - schematics, calibration procedures, BOMs, technical drawings and so on. That ended when companies from countries with less strict IP laws started copying the products that sell. Governments didn't do much to protect businesses and such secrecy is now the effect of this.

inopinatus• 5 years ago

Reading documentation? Where's the fun in that?

Or to put it less insolently: I've learned my craft by reverse engineering; as a auto-didactic tool it's a primary learning tool, definitely beats reading the manual.

kevingadd2• 5 years ago

They'd just abuse patents to stop you from doing it anyway.

eointierney• 5 years ago

So well written, so engaging, such love in the labour.

"We’re looking for conspicuous gaps in our understanding of the hardware, like looking for black holes by observing the absence of light."

Gorgeous

simondotau4• 5 years ago

Seconded. Despite being a genuinely challenging and complicated process with countless moving parts, it was written to be as approachable as possible. They didn't feel a need to "prove" how hard the work is by writing from deep within the weeds.

GeekyBear• 5 years ago

I have also enjoyed reading these progress reports.

dapids2• 5 years ago

Word of warning, stay away from the metal shader bitcode (AIR), or they are gonna sue ya, they did a couple academics for publishing on it.

Jasper_2• 5 years ago

That whole stack is conveniently avoided in this research, because they're going from NIR straight to the GPU machine code, without touching AIR.

dapids2• 5 years ago

Ah, very clever, will have see what the future brings. I would assume apple would not be too pleased though, with either approach.

2OEH8eoCRo0• 5 years ago

On what grounds do they sue? You can't talk about hardware you bought?

chrisseaton3• 5 years ago

Did you agree to not reverse engineer the tech stack? If so, they can sue you for breaking that agreement.

kevingadd2• 5 years ago

Anyone with enough money for expensive lawyers can sue you into oblivion. Sony being on the wrong end w/Bleem (and eventually losing) didn't stop them from running that company into the ground by outspending them.

You won't win a legal fight against Apple unless you have more money than they're willing to spend.

bronxbomber92• 5 years ago

Do you have references to the incident(s) or published work(s)?

theunamedguy• 5 years ago

A big shoutout to Alyssa here. For those of you who don't know, she is doing this work as a college student.

atq21192• 5 years ago

College students are just as smart as graduates and they tend to have much more time on their hands.

So yeah, this is cool work, kudos and everything, but the fact that a college student is doing it is the least surprising part of it if you really think about it.

viktorcode• 5 years ago

She's brilliant. Here's hoping she'll leave her mark on software industry.

KirillPanov2• 5 years ago

Alyssa is a hero for her work on Panfrost, which gave us open-source 3D graphics on ARM Mali GPUs. I am eternally grateful for this; the Samsung Kevin I use is the only blobless laptop currently in production, and now it has 3D accelerated graphics thanks to her work!

But part of me is sad to see her working on such closed hardware now.

Does anybody think Linux on the M1 will ever be able to touch the internal SSD? Apple has been locking that down with proprietary controllers and signed firmware since their Intel days (i.e. T1 chip). Are people really going to drag around their shiny new macbooks with an external USB-C dongle hanging off of it because that's required in order to run Linux?

I worry that the endgame here is Linux becoming Just Another MacOS App. Apple is quite happy for Linux to be a MacOS app running in their VM. Elite developers will buy Macbooks and run Linux in a VM because "we'll have Linux on the bare metal soon, it's just temporary" and that will just keep getting pushed back and pushed back and pushed back...

58028641• 5 years ago

Hector Martin believes it will be possible. https://twitter.com/marcan42/status/1383964656058781703

marcan_425• 5 years ago

I don't "believe" it will be possible; I am absolutely, 100% positively certain it is possible.

mjg59• 5 years ago

Apple don't block access to their NVMe controllers at all. They do appear to have a, well, interesting approach to spec compliance, but Linux is now entirely capable of handling the SSD on all x86 Apple hardware. In the M1 case the NVMe controller isn't exposed via PCI so the existing driver won't work, but there's already in-kernel abstraction between the actual NVMe code and the PCI interface, so adding an alternative shouldn't be a problem.

The M1 systems depend on some number of blobs, but the amount of non-free code required to boot one looks like it'll end up being less than a typical x86 system requires.

floatboth6• 5 years ago

Heh, corellium did it by making a fake PCIe controller:

https://github.com/corellium/linux-m1/commit/e501cce95dfcc65... https://github.com/corellium/linux-m1/commit/08f0fcce76579a5...

kzrdude• 5 years ago

(Starry-eyed idealism.)

Her work on this closed hardware might define it for the future - practicalities matter. If Linux de-facto runs and even better, if it's in wise use, that makes the hardware more open and it might help bend this new platform towards openness. Getting in this early might be a benefit there too.

marcan_425• 5 years ago

Please, please, please drop the internal SSD myth.

That isn't true, and has never been true, ever. That is a complete bullshit story made up by a YouTuber who saw that the SSD didn't show up under Linux back when the T2 Macs were released (because it didn't have a compatible driver) and decided that must mean Apple were "blocking Linux".

All internal Mac SSDs work fine under Linux these days and have for years. I have a local branch with preparatory work to bring up the M1 SSDs already (requires some driver refactoring to do it properly).

_ph_4• 5 years ago

Great work and even more surprising: a great writeup (writing that as someone who always struggles to document my own work). This really gives me hope to have an usable, native Linux on the M1 machines.

I really wished Apple would see, how much benefit this would bring to their platform. Their new hardware is really exciting, the first ARM on the desktop, which doesn't just compete, but in many aspects beat current x86 chips. A lot of the Linux and tech enthusiast crowd would love to jump onto Apple Silicon. And while they might not bring huge profits by themselves, these are the people who do come up with great new technologies. Better give them a home on Apple devices. It doesn't need a complete and formal documentation of every aspect, just supporting those projects with a little bit of information would go a long way. A single engineer who would answer questions by those developers might be sufficient. So come on, Apple, do it! :)

dannyw3• 5 years ago

This is a company that actively fights right to repair and implements software DRM to lock out non-Apple authorised replacements.

Don't hold your breath. Apple's stance by actions is the opposite.

_ph_4• 5 years ago

I am not holding my breath, just stressing how nice it would be and how beneficial it could be for Apple themselves.

w0utert• 5 years ago

> This is a company that actively fights right to repair and implements software DRM to lock out non-Apple authorised replacements.

But they do all these things for obvious reasons. Reasons you and I may not agree with or be happy about, but still obvious reasons. In the case of repair/replacement it's just because they want you to use expensive replacement parts, they want to lure you into their Apple stores, and they don't want any liability/accountability for repairs with 'unofficial' parts.

I don't see how providing specifications about how their GPU's work so someone can make a Linux driver out of it hurts their commercial interests or liability though. Yes people may screw up their system if they install Linux on a Mac and it doesn't boot anymore, but as long as you can still take it into an Apple store and they can restore it to MacOS, why would Apple actively fight the extremely small minority of people who want to do that? And even if more people (developers/enthusiasts) would buy M1 hardware and immediately slap Linux on it, why would they care about that? They still made the sale, and these people will still walk around with a machine with a big fat Apple logo on it?

They previously spent a lot of effort accomodating people who wanted to run Windows on Macs using Boot Camp, so why would they be worried about people running Linux on M1 macs?

Edit: I can imagine Apple want to protect their IP and hence don't want to disclose anything about out it, period. Much like NVidia and most other GPU manufacturers do. But if AMD and Intel can be OSS-friendly, Apple could be too, apparently IP protection does not have to be a deal-breaker.

Aaargh20318• 5 years ago

the first ARM on the desktop, which doesn't just compete, but in many aspects beat current x86 chips

I think the first ARM on the desktop title goes to the Acorn Archimedes (https://en.wikipedia.org/wiki/Acorn_Archimedes). It kicked ass back then as well:

A mid-1987 Personal Computer World preview of the Archimedes based on the "A500 Development System" expressed enthusiasm about the computer's performance, that it "felt like the fastest computer I have ever used, by a considerable margin"

_ph_4• 5 years ago

Well, in this millenium :). And while I remember the Archimedes well, this was another day and age and unfortunately it failed to gain much traction back then. A lot of bad tech could have been avoided, if it had become main stream. I fondly remember the times, when there were plenty of competing processor architectures, almost every one more interesting than the x86 architecture.

monopoledance• 5 years ago

As a Linux person, I have to say my iPad almost got me into becoming also an Apple person. Let's be real, Apple would not lose a single penny to inviting the Linux crowd directly, however, some of those Linux people will become Apple people. There are two reasons to not open up, for the future outlook:

1. Why tho?

2. MacOS increasing lock-down makes even Linux attractive to a wider customer base, and therefore threatening their huge, carefree software extortion business.

Personally I think, they do number 2 on their customer base. I think not opening up to Linux is an indirect admission to their unfair competition game. I think Linux support would very much limit how much they can push their DRM, subscription, software extortion and expropriation mischief. It would allow for consumer choices.

oceanplexian• 5 years ago

I don’t think they care, unfortunately. Apple sells billions of devices to non-techies. The user base that might run Linux or do development on Apple machines is a small fraction like 0.001% or less. The reasons behind preventing you from installing Linux is likely more a consequence of preventing device theft or software piracy.

Dissecting the Apple M1 GPU, Part IV

Related Stories