3 ms·

No. AMD isn't going to do the right thing and will not open source firmware. What a wasted opportunity by Team Red. https://twitter.com/__tinygrad__/status/177

• cycomanic 3y ago
  I'm all for demanding as much open source as possible, but I'm not aware of any big company releasing the source for their firmware. Intel who has often been hailed as the paragon of open source is not releasing the firmware of their ( less capable) cards, nor are they releasing the microcode to their CPUs (neither is AMD). Open source drivers with closed source Firmware is still much better than the closed source mess we have with Nvidia
  • paulmd 3y ago
    Absolutely. Jeez, it’s amazing they did this much already. My first reaction was more along the lines of “he can’t keep getting away with it!!!” lol, the connection to the demands is undeniable. And yeah they probably can’t open source firmware - there’s tons of licensed proprietary shit in there too I’m sure. If that’s the framing… way to snatch rhetorical defeat from the jaws of victory. I’m serious. Take a massive W here and just accept some things cannot be changed (Dolby, fraunhofer, hdmi, Broadcom, and arm are among them). Firmware is hard. Geohot needs to scope his ambitions for his wacky parallel stack appropriately in that light. He might be able to get access to firmware/microcode if he NDA’d (which again, is insane for something to happen this rapidly already) but I’m guessing he wouldn’t like that either and would see it as the same “leash” or whatever. I get that his job is to be the rhetorical pitbull here and demand they all release it as fast as possible, but honestly I think AMD is relatively on the up-and-up here (although I’m sure there will be some disappointments where AMD won’t open some chunks). He’s winning overall here, he just needs to accept the W (and keep pushing etc). The reason this whole insane child sctick is getting graced with a response is he’s right. AMD’s gpgpu software stack has never not been turboshit, their opencl runtime (and entire software ecosystem) was turboshit too. AMD isn’t being “culturally open source” on this project, they are working major versions ahead, behind closed doors, and as a result don’t even have a mechanism to accept PRs etc. It’s “libre source available” more like - and this is not how the gpu driver team operates at all. And they’re behind and have a ton of people who want to help, but some parts of it (binary slices…) are pretty much just rotten root-and-branch. They are barely walking forward to some kind of family-level support now, I think, finally. And their software is so broken he can trivally fuzz a bunch of kernel crashes etc out of their demo code, on supported hardware (and fuzzing is another initiative they announced here). Including enterprise hardware, apparently. Like they have zero official hardware listed and this terrible binary slice thing, and they still can’t run stable. And of course there’s no vfio (there was a callout on Reddit recently too, this was announced alongside the other intiatives) and the control processor hangs so you need to hard reset it sometimes to get the gpu back. People are trying. This is obviously someone who’s trying to run them in a cluster with some uptime level etc. While they debug the ROCm software that deadlocks the kernel. Cant even just reset it and try something else, it’s a whole-ass circus just to get back to the console. https://old.reddit.com/r/Amd/comments/1bsjm5a/letter_to_amd_ongoing_amd/ https://old.reddit.com/r/Amd/comments/1bsjm5a/letter_to_amd_... fixing these problems is the motivation of asking for the firmware too, I’m sure. And he also seems to want to bypass the whole ROCm and AMD framework entirely and do his own thing. I think targeting sycl or spir-v for bytecode (PTX replacement) that is finally-optimized at runtime sounds like a way more practical mechanism, but hey, let him cook, sometimes you see an idea. it’s probably something he could do if he NDA’d up etc. notionally he could target CUDA as well with the same approach, either emit PTX or bytecode directly. Like you can’t use CUDA to build a library for something else, but emitting PTX is something that isn’t blocked, and probably can’t realistically be. It’s just another compiler with a custom software stack in some little DSL or sycl or whatever. I think he’ll bounce off it tbh, there is a lot of irreducible complexity here (firmware is perpetually patching hardware bugs among other things). I’m not denying there’s a lot of cruft and legacy bugs that probably could be cleaned out etc. it’s just going to be a “much larger than he thinks” problem. If he really wants to actually succeed, figuring out the scope of his idea is important. And again, he probably at least evaluate some of these options if he NDAs. Acting like a dork until they “read you in”, didn’t realize that worked… But if he does succeed in simplifying a bunch of the SIMT binary pipeline/intercompatiblity mess, it’d be a huge win. Or he could focus on the stuff that everyone can collaborate on, but, that’s not going to be microcode. And just like the RPi foundation - you can notionally have a core team who’s NDA’d and manages basically as thin a shim layer as you can get. But I really don’t think AMD will open microcode/firmware. But I’ve been wrong so far! He just keeps getting away with it. Those are different paths though! AMD, for their part, I think finally realizes how badly they’ve fucked up forever. JonChesterfield has always listened patiently to people bitch and I’m sure taken notes, but, they can only do what they can with what management gives them, like anyone else. I think now amd is finally ready to hear it. Employee count in financials indicates they might finally have started staffing up software engineers. They’re saying the right things about open sourcing, and the incentives align for them to deliver, and ideally quickly, because these people are building AMD’s stack for them. I’m sure some pieces can’t be opened etc but they will largely deliver here, I think. And there’s too many eyes watching at this point, and many large customers that will be very very disappointed if AMD doesn’t deliver and then goes back to wallowing in their mess with a stack that completely falls over and constantly gets in the way. That would burn them really badly in the long term - “hey, you didn’t let the community help and you messed it up internally? Gosh maybe the nvidia money pays for something” is a super easy sell and nvidia goes back to owning the market. That’s why it’s surprising - it’s a pretty direct commitment with financial consequences attached tbh. But he’s right about pretty much all of it. He’s an asshole, but he’s right. The gpgpu stuff has always been a tremendous, poorly-supported mess. Under resourced due to financial problems, yes, but context and understanding doesn’t fix kernel panics.