Live data from Hacker News

Building a Linux GPU Driver for the M4 Mac Mini in One Month

codyho.dev

231–240 of 293 posts

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#231

Earlier quoted context omitted.

Who volunteers to be the shmuck that fights Nintendo's lawyers in court? Who's funding the defense against Apple? It's safest to err on the side of plausible deniability, any proximity to OEM software increases liability if things go wrong.

Nintendo doesn't care. There's been proprietary Nintendo SDK code in libogc (open source library for making GameCube homebrew) for years. And more recently the various decompilation process have made recreations of linked code from the SDK that compile match byte for byte. In practice the legal risk of being sued into oblivion for this is not there. If anything there would be a DMCA takedown / cease and desist.

There's also been Wii games rereleased on PC with all debug symbols that cover the Wii parts that were still compiled in. You'd get mostly type names, enums, object layouts and function signatures that way.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#232
post #152

Earlier quoted context omitted.

Probably not. Clean room RE is serious business, projects like Dolphin have to carefully vet contributors to remain legal.

Everyone says this, and then exactly zero cases are cited in support of or against this creative legal theory known as "clean room RE." No statute defines "clean room RE" and there's basically no relevant litigation establishing case law.

>No statute defines "clean room RE" and there's basically no relevant litigation establishing case law.

You seem confused here? "Clean Room RE" is simply a descriptive result of copyright law in the US, and is well established. In the US there is no "sweat of the brow doctrine", pure facts simply cannot be copyrighted at all, nor underlying methods/ideas (that's patents). And as a direct result of the latter, again unlike patents, if two people truly independently write the same thing, both get separate copyright.

"Clean room reverse engineering" is just applying that to make any legal fight much cheaper or discourage it from every being bothered with in the first place. You have an RE "dirty" team that goes through copyrighted software and makes a specification that is purely factual, ie, "function 1 takes (int16)X input and does equation ABC on it, function 2 takes (long)X & (long)Y inputs and does LMN" etc. A factual/math spec like that cannot be copyrighted, so it breaks any derivation chain. They then give that, and only that with no other communications, to the clean team. If someone with no other exposure to the software being RE'd uses that spec to write a new piece of software themselves, then by definition the result cannot have any copyright of the original. It's a brand new work based off a list of uncopyrightable facts & math/ideas (though worth noting it could still get tripped up by abomination that is software patents).

There are other ways to argue against copyright infringement successfully, but they're much more subjective, which legally speaking reads "expensive, uncertain". CRRE simply trades that for two clear binary questions: was the spec copyrightable, and did the people writing a new piece of software from that spec have any previous exposure to the original? If the answers to that are no, then all arguments about function names being similar or whatever are no longer relevant.

On the subject of LLMs, one curious twist is that proprietary software might have less effective protection then open source depending on how it all goes. A coding LLM almost certain trained on all open source software available on the web. So there's at least some argument it's tainted. But proprietary software is proprietary. If the LLM has never had any of the source code in its training input, then isn't it clean in terms of producing anything derivative of that? That'll be kinda interesting, and might leave some companies with a bit of a conundrum (or I guess pushing the patent side even harder, but that has a much more sane 20 year expiration date vs copyright).

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#233

Earlier quoted context omitted.

Right, but they are one of the biggest DMCA abusers. They killed many fan projects. They killed game renting in Japan as a concept. They killed Yuzu (a Switch emulator). And they could change their mind at any time.

>They killed Yuzu (a Switch emulator). For the record Yuzu included code for circumventing Nintendo's DRM they had on game carts. It violated the DMCA.

> For the record Yuzu included code for circumventing Nintendo's DRM they had on game carts. It violated the DMCA.

It doesn't, this is what Nintendo claimed but it's false. The community learned their lessons from the Wii emulation era and you are supposed to bring your own keys, nothing is included in the emulator.

And yes, they also wrote this lie on their DMCA takedown against Suyu (which also doesn't have any keys), so they officially lied on a DMCA takedown.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#234

Earlier quoted context omitted.

Might be one of the only use cases where LLMs are necessary to succeed. Can't imagine the pain of reverse engineering a technology of this scale and "secrecy".

Traditional hardware RE centers around heroics by a small number of very smart people, see: marcan, Alyssa Rosenzweig, Asahi Lina, etc. What they did is insanely impressive, and given how hard it was with LLMs I'm sure I would not personally be able to do this work without LLMs. That said, I'm looking forward to a world where the staring at hexdumps and traces can be delegated to LLMs and talented humans can spend th…

Asking out of genuine curiosity... Do you think the Asahi maintainers could use your work to speed up future GPU driver development? M4, M5, M6 and so on... I am assuming they wouldn't just accept your work outright, but instead could they use it to substantially speed up their development process by mapping out a lot of the GPU after which they can focus on optimization and other aspect of drivers? Do you think they will?

I don't use Asahi now but that's largely because my current Apple M series hardware is still supported. I see a day where an older unsupported Mac is running in a rack in my basement or being used by my kids as a general purpose computer.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#235

Earlier quoted context omitted.

TL;DR: 1. We want to guarantee our work is not a "derivative work" of anything Apple wrote. 2. If we look at any Apple binaries, there's no way prove that our code didn't borrow from Apple. 3. Since we didn't look at any Apple binaries, then there's no way our work can be a derivative work-- we didn't even look at their stuff.

Wouldn't using OpenAI break the cleanroom?

If using the OpenAI models to develop this taints you with Apple insider knowledge, then so is developing any macOS, iOS, Android or Windows apps around that are using any LLM.

You can't claim that some work is necessarily tainted by existing, you also have to prove which knowledge was retrieved, used and that there was no other reasonable way to know it. But unless it is actually tried in a court in all major jurisdictions, it's just speculation from all parties (including line).

One person could also claim that someone someday might leak information to them, and even though they'll ignore it, since they'll be exposed, they are tainted and can't contribute anymore. It'd be absurd.

A project is free to chose who can contribute, but they can't necessarily gatekeep others from doing their own project with different rules.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#236
post #77

Earlier quoted context omitted.

Wouldn't using OpenAI break the cleanroom?

Why would it? Unless you think OpenAI is training on Apple’s proprietary code?

They could claim that some employee one day used their model to ask a question about internal stuff and they trained on that.

It doesn't have to necessarily have to make sense to make a claim, but it doesn't necessarily bear any weight.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#237

Damn, I did exactly this already for the M3 and got it working. Was hoping to make a post about it but this kinda scoops it. Bravo!

Share your code please.

I'm currently traveling but I'll post it tomorrow. That said, you could recreate it yourself by just cloning the Asahi repos and asking Astra to make it work on the M3. I followed along with Alyssa Rosenzweig's original series of articles and tried to reproduce the milestones that she did in the same order to sanity check the work. The whole thing took about a week.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#238

Clean room is not 100% legally necessary for RE, but I would never touch an LLM to do RE work when there's even a chance the models have been trained on the thing I ultimately plan to reimplement. Furthermore, given that Asahi Linux, the biggest game in town when it comes to running Linux on Apple silicon, is trying to be cleanroom, it is incredibly rude of you to not mention LLMs until after showing a page full of L…

There's also a chance the people claiming to do clean room are cheating and took some shortcuts.

It's easy to make random claims that are impossible to prove or disprove.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#239

Earlier quoted context omitted.

Share your code please.

I'm currently traveling but I'll post it tomorrow. That said, you could recreate it yourself by just cloning the Asahi repos and asking Astra to make it work on the M3. I followed along with Alyssa Rosenzweig's original series of articles and tried to reproduce the milestones that she did in the same order to sanity check the work. The whole thing took about a week.

I’m going to try getting it going with codex and Claude code this evening.

I’ve just found that having more cousin projects to be inspired by really helps llms. Plus, you never know what future project/agent may find a gem in your project to apply somewhere else.

Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month

#240
post #178
post #141

Earlier quoted context omitted.

You can make the Linux installation on Apple Sillicon Macs pretty painless nowadays. One terminal command on macOS, reboot to Linux, run one script - voila.

Yeah, but it's unlikely such installers will be officially supported by the distributions, which was my point regarding upstreaming.

The Asahi installer can set up a standard UEFI environment on the Mac and you're off to the races from there.

The problem right now is more that you then need to use a patched kernel+mesa+others to do much with that environment. As more and more of those patches make it upstream, the process will converge to being a standard ARM64 install from the distro's point of view.

Post reply on HN