AMD ROCm Going Open-Source: Will Include Software and Hardware Documentation

But isn't linux default graphics basically supporting AMD without drivers? (Open source)

I get it and I'd also like for all components of my devices to be open source. Still, the parts I really care about and have any idea of how to fix stuff in, are open source.

For nvidia devices there is (or was? It's been a while) a whole other set of horrible user-space closed-source stuff.

AMD _has_ open drivers which include not only the kernel parts but also DRM, video acceleration, and mesa/llvm backends. NVIDIA doesn't release any of this.

Are you going to claim that because both have proprietary firmware, it doesn't matter if you are forced to run proprietary software to use it?

Using Mesa is already an order of improvement of openness, and frankly, calling it "a shim which wraps firmware" is a ridiculous thing to say.

I went and checked the size of AMDs vs NVs firmware blobs and the 2 GSP firmware that are used for new NV cards in the linux-firmware package (https://archlinux.org/packages/core/any/linux-firmware as references for what I checked) result in it being the single largest folder in there (40MiB). Compare that to the largest amdgpu firmware file which is at 392KiB with the entire folder of 562 items being <20MiB.

Not to say that AMDs firmware is open source or so, it certainly isn't, but even comparing the amount that is possibly done is somewhat laughable.

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_...

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.