4 ms·

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 t

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.

AnthonyMouse 3y ago
> 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.
- llm_trw 3y ago
  Worth noting that is a step up from NVidia who moved their driver to the GPU and open sourced a configuration file.
  - paulmd 3y ago
    That is an interesting way to frame the situation when AMD’s solution doesn’t even run hdmi 2.1 under Linux. and intel has a solution for this too, in fact…
    - atq2119 3y ago
      If anything, the HDMI situation is an argument to put more code into closed source firmware, not less: https://www.phoronix.com/news/HDMI-2.1-OSS-Rejected https://www.phoronix.com/news/HDMI-2.1-OSS-Rejected
- atq2119 3y ago
  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.
  - AnthonyMouse 3y ago
    > 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.
    - atq2119 3y ago
      > CPUs don't really have firmware in the same sense. How would you classify e.g. the Intel Management Engine and the firmware that runs on it?
imtringued 3y ago
You do realize that the driver is responsible for compiling your kernel into machine code for your particular GPU? Calling that an API is strange.

AnthonyMouse 3y ago

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

llm_trw 3y ago
Worth noting that is a step up from NVidia who moved their driver to the GPU and open sourced a configuration file.
- paulmd 3y ago
  That is an interesting way to frame the situation when AMD’s solution doesn’t even run hdmi 2.1 under Linux. and intel has a solution for this too, in fact…
  - atq2119 3y ago
    If anything, the HDMI situation is an argument to put more code into closed source firmware, not less: https://www.phoronix.com/news/HDMI-2.1-OSS-Rejected https://www.phoronix.com/news/HDMI-2.1-OSS-Rejected
atq2119 3y ago
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.
- AnthonyMouse 3y ago
  > 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.
  - atq2119 3y ago
    > CPUs don't really have firmware in the same sense. How would you classify e.g. the Intel Management Engine and the firmware that runs on it?

imtringued 3y ago

You do realize that the driver is responsible for compiling your kernel into machine code for your particular GPU? Calling that an API is strange.