Nope, they basically open sourced their api which is kind of a worthless proposition. You would think this is malicious, trying to pretend as open source, but the whole thing is done so ineptly, it is just incompetence. Likely management has no idea what open source means and thinks releasing api code means open source and is good enough for customers to use your GPU.
More concretely, what they open sourced calls closed source functions that run on the GPU which is where all the bugs are, and causes all the crashes.
> More concretely, what they open sourced calls closed source functions that run on the GPU which is where all the bugs are, and causes all the crashes.
In particular, what they did was open source the drivers but not the firmware, and then when the firmware has bugs nobody outside the company can fix it because it's not open source.
Yes, that's a problem, but it's also a bit of an unfair dunk.
After all, your CPU almost certainly runs firmware with all the same issues. Not to mention all other GPUs from all other vendors.
Despite all of the noise-making, I don't think anybody has really convincingly made the case that the firmware quality is the main issue here, as opposed to the quality of the rest of the stack.
> After all, your CPU almost certainly runs firmware with all the same issues.
CPUs don't really have firmware in the same sense. CPUs expose basic primitives (machine instructions). Modern CPUs will translate them to micro-ops in microcode instead of executing them directly, but the mapping is relatively simple and bugs are correspondingly uncommon.
The GPU firmware is doing something complicated, and therefore buggy, but you're required to use their complicated buggy closed source code because it also doesn't directly expose simpler primitives you could use to build your own alternative to it.
> Despite all of the noise-making, I don't think anybody has really convincingly made the case that the firmware quality is the main issue here, as opposed to the quality of the rest of the stack.
The rest of the stack should be an abstraction layer that makes programmers not have to care what kind of hardware is under them, the same as they generally don't have to care if their CPU is from AMD or Samsung. But then you need the code to translate from that abstraction to the hardware, and that code needs to work. Which can either be accomplished by the vendor providing working code, or by the vendor providing sufficient documentation and source code for someone else to write working code. Providing neither of these is not effective.
What AMD should be doing at this point is both. Open source the existing firmware so that people who are trying to use their hardware right now have the ability to fix any problems they encounter themselves, while the company uses the money they now have to address their existing technical debt, which nobody reasonably expects to happen overnight. But will happen faster when it's not only the company but also the users working on solving the problem.
Their entire stack on Linux is open-source. That part isn't a problem.