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

[chithanh]

why? it says that os provides filesystem service to applications, not what writing to drive implies os. every hard drive or ssd has internal controller with microcode, which does real io to/from drive

Operating systems do manage storage below filesystem level too.

That's what I said with "set how they should work at low level". The microcode tells the hardware components how to operate at all, as the complexity of modern systems does not allow to design hardware that is fully ASIC.

That the microcontroller has a single purpose doesn't make its microcode hardware.

An OS is still an OS even without networking and storage (it is a RAM-only OS, loaded in RAM by the bootloader).

Not all operating systems have all functions. Some have more, some have fewer. This does not invalidate my point.

newsflash, it's called DMA,

I think you are being intentionally obtuse here. DMA was already possible before the Radeon Pro SSG tech demo. DMA still requires the host and the device to negotiate how much data to put where.

FSF position on the matter is not realistic. Only way you can drop these proprietary blobs is if you have fully open hardware

FLOSS community produces a lot of hot air, but actually making something that is practical? Nope.

No. AMD could open source the blobs if they wanted to, but they choose not to.

Plus nobody ever claimed that the FSF position is a practical one. It is an ethical one. Also the Free Software Foundation does is not about hardware freedom, it is about software freedom.

Many times people who thought that Richard Stallman and the FSF were just paranoid extremists were taught better in the end.

https://tech.slashdot.org/story/15/03/20/2039251/oems-allowed-to-lock-secure-boot-in-windows-10-computers

http://www.phoronix.com/scan.php?page=news_item&px=Intel-Boot-Guard-Kills-Coreboot

Quoting myself from an earlier thread:

Yes, the combination of Boot Guard and forced Secure Boot is a pretty bad one. Forced secure boot means that an evil Microsoft could blacklist boot loader signatures and render Linux systems unbootable. Boot Guard ensures that defending against this by modifying or replacing UEFI becomes impossible.

The next steps on that slope are:

• Hardware vendors must include Secure Boot function.
  Critics are placated with an option to disable it and the possibility for users to install their own keys. ✓
• Secure Boot must be enabled by default ✓
• Optional Boot Guard technology is introduced to prevent firmware modification ✓
• Secure Boot can become mandatory if the hardware vendor chooses so ✓ << we are here
• Ability to install user keys in UEFI becomes optional
• Hardware vendors must enable Secure Boot permanently
• Boot Guard becomes mandatory
• Ability to install user keys in UEFI becomes forbidden

you should be punished for thinking this is even possible giving human behaviour.

you are the one who should be punished because of your push to punish people for only free speech .

The same applies to you that want to punish me because I used my free speech to say he should be punished.

I never thought I'd write this, but I think Qaridarium is on the right side of this argument here. Who are you to forbid people from wanting to end the uneven distribution of power over what their computer does.

[karolherbst]

I don't get the discussion. The original assumption by MaxToTheMax was that the fabs reach technical/physical limits and therefore scaling horizontally is not possible anymore.

well you can always add another CPU.

[karolherbst]

You're wrong. There are problems that aren't parallelizable. This has nothing to do with API design or file formats.

right, but usually those problems came from a choice you did earlier. You could try to find an example where you really can't split the task not due a decision you made earlier (like using a specific algorithm or using a special file format).

If you care about performance a lot and parallelism, you choose things so that your problem becomes parallelizable, otherwise you have to rethink your approach. And we talk about performance critical things here, not things you usually finish in a blink of an eye.

[duby229]

Uggghhh There's so much butt-hurt in this thread. Get over yourself. You made careers? Hah!

[starshipeleven]

That the microcontroller has a single purpose doesn't make its microcode hardware.

Yes but while it is software you cannot treat it as software, because it is so close to the hardware that if you opensource that you are basically opensourcing the hardware too.

So any "opensource these firmwares" translates automatically into "opensource your hardware". They cannot do that, it's a suicide.

Not all operating systems have all functions. Some have more, some have fewer. This does not invalidate my point.

All functions listed can be done also without an OS, so yes, your point is invalid.

What makes an OS is the ability to host processes, that is abstracting every function you mentioned (and more) so that programs don't need to manipulate that stuff directly, but make system calls.

I think you are being intentionally obtuse here. DMA was already possible before the Radeon Pro SSG tech demo. DMA still requires the host and the device to negotiate how much data to put where.

Which is why bridgeman said this is done by the driver. The driver runs on the CPU.

No. AMD could open source the blobs if they wanted to, but they choose not to.

Lol duh. I said why they cannot. If they opensource microcode they are pretty much opensourcing the hardware too. They cannot do that.

Plus nobody ever claimed that the FSF position is a practical one. It is an ethical one.

Don't give a shit. Hot air does not protect my freedom.

Also the Free Software Foundation does is not about hardware freedom, it is about software freedom.

Their and your failure to understand the complexities of modern world aren't my problem. You cannot have opensource microcode without opensource hardware.

THEREFORE, if they want opensource microcode they should campaign for opensource hardware, that is hardware where the company is built around making profit off different things than trade secrets.

Many times people who thought that Richard Stallman and the FSF were just paranoid extremists were taught better in the end.

Don't give a shit. Stallman's previsions being correct in the end does not protect my freedom.

I never thought I'd write this, but I think Qaridarium is on the right side of this argument here. Who are you to forbid people from wanting to end the uneven distribution of power over what their computer does.

I am just saying that the point I quoted originally goes against the basic human nature, so even THINKING that is possible without some direct divine intervention is bs.

Then I'm trolling Quaridarium because when someone calls freedom of speech and then tries to shut up people is a too fat target to miss, but that's tangential.

[starshipeleven]

I don't get the discussion. The original assumption by MaxToTheMax was that the fabs reach technical/physical limits and therefore scaling horizontally is not possible anymore.

Technically speaking, we are already there too.
Most consumer softwares can't use more than 4 cores, on ANdroid they don't even use well 2 cores.

So yeah, we are already in a situation where scaling horizontally is "not possible" (more like not useful)

[artivision]

No one asked AMD to open their Firmware. We asked for the open driver to stop depending on it. We want it to be based on an alternative open solution, probably written with C, like RadeonHD was. We don't care what happened 10 years ago nor if the AMD open dev team has the skill to do it. We just want someone from them to communicate with people like "libv" and ask for assistance for a parallel sub project. My opinion for open code is that we all should participate and learn from that, not for a corporation to control everything. That is why i like projects like projects like Gallium Nine and RADV.

[starshipeleven]

No one asked AMD to open their Firmware. We asked for the open driver to stop depending on it.

Well, no. There is people asking to open everything.

What you say is just doing stuff without AtomBIOS or something. That's neat but does not solver the fact that there are a blobs of microcode or similar to be loaded for the hardware to work at all.

[Kano]

libv

I do not fully understand what would be different today if your radeonhd DDX did not get dropped. It has certainly nothing to do with the firmware requirement for newer gfx cards. Right now the DDX is exchangeable anyway with modesetting and KMS is done by the kernel module. So even a clean approach for the DDX would not have been future proof. It is certainly sad for you that other developers got more/better information about the next development steps, but if you could choose now, would you like to work for AMD or continue to work on other projects like your lima driver?

[karolherbst]

the usercase of non-parallelism code is for example cryptography if the enemy can not perform better than the very chepest hardware then an attack on your security is impossible.

guess what, that is exactly what I meant with "algorithms". If you construct an algorithm which won't work in parallel, then yes, it doesn't work in parallel. But current research is indeed looking for hash algorithms you can run multithreaded, so "cryptography" itself doesn't really depends on being run single-core.

Also, if single core performance doesn't get better, but production cost lowers over time, then that means that parallelised crypto attacks are getting cheaper, too, which weakens cryptographic strength overall.

Also you can always crack in parallel.

That means, that if single core performance stagnates, we _need_ multithreaded crypto algorithms!