Nouveau: NVIDIA's New Hardware Is "VERY Open-Source Unfriendly"

[SystemCrasher]

If I buy Intel where AMD is an option while also protesting say, the occupation of the West Bank and the siege of Gaza, that would have my left hand fighting my right hand. That's because of Intel's facilities in Israel.

As one of my friends once told, "humans are bunch of shortsighted monkeys".

Some dumbass people are happily putting their money into dubious schemes by using oversimplified equations, without bothering self to compute couple steps further what would happen next, how their actions could affect global processes and if they will like stuff which follows next. Then such people are surprised to learn future happens to be not what they like to see. Hmmph.

Buying Nvidia? Because you do not care about your freedom? Okay. But then it will be really wrong to complain when you're locked out of your own computer, so it starts working for someone else without your consent. You haven't valued your freedom and nobody else needed your freedom, too! So it has been taken away. Just because they can and it can give room to squeeze some extra bucks.

It is also wrong to complain when Nvidia knows better how many monitors you need and eventually cuts off "unneeded" extra monitors support in new driver, etc. But if someone silly enough to be ok with this, I can admit, they tend to face fate they deserve. There is only one issue: I do not want same miserable fate...

[MoonMoon]

Al Gore, is that you? Sorry, but proven-false global warming junk science makes for a poor argument, lol.

You should try to get your information from reliable sources, not Fox News.

[moilami]

I just don't understand why AMD can't open up their microcode! If not all of it, then at least enough of it so that basic expected functionality is available when people want to run 100% free software operating systems such as Guix, Trisquel or Debian main. If nVidia already has their microcode effectively open, what does AMD have to lose?

I'm a regular at a local monthly free software meet-up, and it seems everyone is running either Intel, or old Nvidia hardware. thinkpenguin.com are the same - no AMD GPU hardware available for purchase, and it's all because of this silly microcode issue.

So AMD, why not open the microcode, gain some hardware sales and increase the AMD fan-base? I fail to see the harm, and it would make a lot of people very happy.

[smitty3268]

You should try to get your information from reliable sources, not Fox News.

It's rather telling that one side of this debate is always referencing politicians, and the other is always referencing actual science.

Not that they don't have some good points, but you can never convince someone science is real if they are determined from the start that it's all some political attack. It was a smart line of defense by the energy companies to make it into one.

[boltronics]

Heh. Well, I suppose it is interesting that they are a major US company (suspicious by default!), and yet they insist on this non-free microcode for their hardware to work correctly - all the while trying to demonstrate how they are friendly to free software.

I would love to hear some kind of response from bridgeman or another AMD employee explaining why the microcode is still necessary and freeing it isn't (AFAIK) a priority.

[bridgman]

The microcode is still necessary because it is a common and convenient way to design hardware. Nearly all of the CPU and GPU hardware available today uses non-free microcode -- the only thing different about AMD is that we load relatively more of the microcode into RAM on the chip at power-up rather than burning it into permanent ROM or having BIOS load it from flash ROM.

Microcode is part of the hardware design, and freeing it is not a priority for the same reason that freeing the rest of the hardware design is not a priority.

IMO the root problem here is that a reasonable concern (the ability to change HW microcode without user knowledge or approval) has led to an unreasonable conclusion (soft-loaded HW microcode is evil and must be removed or freed). Having the driver soft-load microcode from files is no different from having BIOS soft-load microcode from the flash ROM image, but the former is "bad" while the latter is considered OK.

As I understand it, there are a few core arguments that come up:

1. Evil companies might sneak in a microcode update which removes or breaks existing functionality without your knowledge. Given that we are talking about an open source OS and open source kernel driver, this should be handled by controlling updates to the microcode files (eg maintaining checksums for each ucode file and warning user if they change).

2. Evil companies might update the microcode to add new features you like, "forcing" you to accept the update, while at the same time removing or breaking functionality we need. In this case I think the answer is to not take the update if it has undesirable side-effects -- hardware with burned-in microcode can't be updated at all, so there is no disadvantage relative to devices with hardwired microcode.

(by the way I'm not a big fan of disabling CPU microcode updates just because they *might* contain something bad -- new microcode files get a fair amount of test coverage before being included in a distro release so risk of breakage seems really low)

3. Evil companies (or third parties) might include back-doors in the microcode which steal your information. OK, but this is an equal concern whether the microcode is burned into HW or soft-loaded at startup. The key thing here IMO is controlling & validating the updates, not prohibiting them or prohibiting soft-loaded microcode. Saying that soft-loaded microcode must be free while recommending HW with large amounts of hard-wired microcode (eg Loongson CPUs) seems to be missing the point IMO.

[boltronics]

The microcode is still necessary because it is a common and convenient way to design hardware. Nearly all of the CPU and GPU hardware available today uses non-free microcode -- the only thing different about AMD is that we load relatively more of the microcode into RAM on the chip at power-up rather than burning it into permanent ROM or having BIOS load it from flash ROM.

Yes, that represents one of the significant concerns. In the case of Intel CPU microcode, for example, this can be stored and loaded from the BIOS at power-on, all without requiring distribution with the operating system. This is a huge win from a marketing perspective - Debian, Trisquel, Guix, etc. can advertise a distribution that is 100% free software - it doesn't add any more over what your computer already has. It would largely solve the problem if AMD could do something similar for its line-up of APUs - then only PCIe GPU cards would remain.

Microcode is part of the hardware design, and freeing it is not a priority for the same reason that freeing the rest of the hardware design is not a priority.

I don't think I can agree that hardware design (which cannot be replaced) and microcode can be lumped together like that when referring to free software, but if I'm reading in between the lines correctly, the hardware team is responsible for the dependency of microcode distributed this way, and not the driver team? I imagine the hardware design people don't concern themselves with free software issues nearly as much as the driver development team might.

As I understand it, there are a few core arguments that come up:

Actually, you're missing one of the core arguments; that being that the hardware vendor has more ability to control your hardware after the sale. In theory, if the microcode is open and we can see how it works, we can control the functionality of the hardware, just as much as the hardware vendor would be able to through an update. Now if the microcode was permanently burned into ROM and could not be changed, this wouldn't be a problem - the manufacturer would be unable to issue a proprietary microcode update that rivals anything the user could create, because there is no facility to replace it.

One example of a problem this has caused in recent years was when Intel started selling microcode unlock keys to boost the performance of some of their hardware.

http://hardware.slashdot.org/story/10/09/19/0050203/intel-wants-to-charge-50-to-unlock-your-cpus-full-capabilities

http://hardware.slashdot.org/story/11/08/14/1515221/intel-to-offer-cpu-upgrades-via-software

So distributing the microcode as free software potentially protects the end user from such scams.

One last concern I wanted to make was related to the current microcode licensing. I believe this is the license:

http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.radeon

Since the free software community already knows how to generate microcode of your closest GPU competitor, why is AMD against reverse engineering AMD microcode? It's one thing to not release the code as a matter of priority, but another to actively prevent people from using what is already available to do something about the problem.

In any case, thank-you for your insights. I didn't expect anything, so really appreciate it.

[grok]

Thanks guys, I didn't expect to read something so interesting and on-topic.

I wonder what if a GPU vendor stored firmware/microcode on a "huge" flash chip (say 2MB, 4MB) on the graphics card. Or make room for many iterations of it to work with current driver, older driver, yet older driver etc.
Now it seems like it's GPU vendor's job to distribute the microcode but that seems quite impractical (will we ask grandma user to boot in DOS or a specific iso image provided so as to flash the firmware, etc.)

If a fixed microcode is unacceptable because updates are needed for stability, performance, major bugfixes etc. then I don't think an APU would be better off than a PCIe card, you also get a middleman (motherboard vendor) which might be not responsive enough (or "evil" big OEM company doesn't give you updates, acts as an additional middleman)

[bridgman]

I wonder what if a GPU vendor stored firmware/microcode on a "huge" flash chip (say 2MB, 4MB) on the graphics card. Or make room for many iterations of it to work with current driver, older driver, yet older driver etc.

We discussed this with board vendors and FSF, but neither of us were able to convince a board vendor to spend the extra $$ for larger flash ROM and added support burden (see next point).

Now it seems like it's GPU vendor's job to distribute the microcode but that seems quite impractical (will we ask grandma user to boot in DOS or a specific iso image provided so as to flash the firmware, etc.)

If a fixed microcode is unacceptable because updates are needed for stability, performance, major bugfixes etc. then I don't think an APU would be better off than a PCIe card, you also get a middleman (motherboard vendor) which might be not responsive enough (or "evil" big OEM company doesn't give you updates, acts as an additional middleman)

Exactly. We still feel that distributing microcode ourselves (as files) was better than relying on OEMs to create and distribute updated ROM images for every device they had ever made. ROM images are not generic -- they're different for every card/system -- so we can't generate or distribute them ourselves.

The problem here IMO is that somewhere along the way someone decided that microcode in a file was "non-free software" but the same microcode in a flash ROM or burned into the chip was "hardware". HW microcode doesn't become "software" just by being copied into a file.

[MoonMoon]

The problem here IMO is that somewhere along the way someone decided that microcode in a file was "non-free software" but the same microcode in a flash ROM or burned into the chip was "hardware". HW microcode doesn't become "software" just by being copied into a file.

That someone was Richard M. Stallman, and I never understood why either. He is basically saying that software becomes hardware when it is unchangeable by the user, which is IMHO a very weird view, especially when one sees his views about tivoization, which is basically software tied to the hardware.