No, AMD Will Not Be Opening Up Its Firmware/Microcode

[phoronix]

Phoronix: No, AMD Will Not Be Opening Up Its Firmware/Microcode

This issue comes up every so often by people suggesting it or otherwise inquiring about it... No, AMD has no intentions of open-sourcing its low-level firmware / microcode for their Radeon GPUs...

http://www.phoronix.com/scan.php?page=news_item&px=No-Free-AMD-Microcode

[tigerroast]

But why not though?

[chithanh]

Given that the Radeon firmware is getting ever more complex and controlling more things, that is quite unfortunate.
As I understand it, the firmware controls the various command processors in the GPU, and with the new Radeon Pro SSG also manages storage. So it is turning into a fully-fledged operating system.
With HSA, much of your code is going to run on your GPU in the future.

I guess it is only a matter of time until this situation becomes unbearable for people who value open source software.

[starshipeleven]

But why not though?

Quoting verbatim from the mailing list:
Right... the microcode is part of the HW design; some vendors build the microcode images into the chip, while others have the BIOS or driver load them at start-up. The industry is generally moving to driver-loaded microcode, but I don't believe any vendor is planning to start opening up their hardware designs.
Thanks, John

And this is the same thing he (bridgeman) keeps repeating in this forum too.

[libv]

For display/chip init, we had it all with RadeonHD, a native C driver (C code was remarketed as legacy by the fork later on), register level documentation being made available (which stopped as soon as RadeonHD stopped), we just needed some enterprising individuals to provide a corebooted version of ASICInit() (about 200-400loc). But Redhat and a few "community members", just had to side with ATI, create a competing fork, and then implement everything the ATI way.

And now one of that same set of RadeonHD forkers has gone and done Radv, whereas he likely never would've needed to if he had not been so dead set on destroying both my work and reputation, and SuSEs reputation, while wasting a lot of resources in the process. AMD was cash strapped as it was already.

[duby229]

I want 2 cents in, sorry....

I remember having a conversation on this forum years ago, it was about complexity in display controller hardware. Then the conversation turned turned towards talking about programmable micocontrollers vs fixed function controllers. I think there comes a time when designing discreet units become less effective and while simulating them becomes more effective. It's really a function of complexity. This may seem odd to some people, but I get the feeling this is a similar conversation that needs to be talked about in similar terms.

Now talking about firmware, I think that too turns towards a conversation of complexity. Is it really realistic to think that an open source project can code for all the register level programming for every graphics card from every vender? How many man hours would it take if it were indeed possible?

[libv]

Duby, we were doing it with RadeonHD, and at very effective speed as well. We were mostly blocked by things which ATI was unable or unwilling to tell us, things which the fork (mostly) let us solve for them, and then quickly took over. Before the fork, there was a big user community as well which was very dilligent with reporting bugs (which is the first thing that vanishes when a fork happens) and with requesting support. Quite a few also added their own fixes, Christian Koenig being the best example.

[starshipeleven]

As I understand it, the firmware controls the various command processors in the GPU,

That's microcode meant to initialize them and set how they should work at low-level.

And with the new Radeon Pro SSG also manages storage. So it is turning into a fully-fledged operating system.

The ability to write stuff in a disk does not turn low-level firmwares in an operating system.

I guess it is only a matter of time until this situation becomes unbearable for people who misunderstand open source software.

fixed.
legit firmwares like these are too low-level to be seen as distinct from the hardware they run. This stuff is usually burned on ROMs or on NOR chips on the boards since decades.

But of course if it is in a chip on the board it's 100% fine, while if it is loaded on runtime it is 100% wrong.

[brent]

For display/chip init, we had it all with RadeonHD, a native C driver (C code was remarketed as legacy by the fork later on), register level documentation being made available (which stopped as soon as RadeonHD stopped), we just needed some enterprising individuals to provide a corebooted version of ASICInit() (about 200-400loc). But Redhat and a few "community members", just had to side with ATI, create a competing fork, and then implement everything the ATI way.

How is this related? RadeonHD did not replace the firmware that is being talked about here. RadeonHD only replaced the AtomBIOS code. And as far as I can tell, it was simply not seen as sustainable or worth the effort by most developers to redo all of this boring stuff. In particular because every single GPU board model can be different. VBIOS/AtomBIOS seems like the right place to abstract board differences.

[libv]

To finish that thought... I totally got how the hw designers put the R500/r600 together, and considered it a thing of beauty. And given that i was the person who came up with structured display driver development, now called modesetting, my code was also highly structured and modular. Add register level documentation, and the ability to look at the content of atomBIOS calls, this made development extremely effective and efficient as well.

We only really wasted time or got blocked on things that Mr Bridgman was unable or unwilling to tell us, something which he happily made use of, especially when the AMD account manager for SuSE got moved aside, and the account manager for redhat was also made responsible for SuSE. That's when Mr Bridgman was free to play whatever games he wanted.