Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    moilami
    Senior Member

  • moilami
    replied
    Originally posted by MoonMoon View Post
    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.
    What is so hard to understand in that? When you can't change the software, it would be more or less in vain to study the software because you could not improve the software and share the improved software, much less change the software alltogether. Hence the software you can't change is in practise hardware.

    Leave a comment:

  • MoonMoon
    Senior Member

  • MoonMoon
    replied
    Originally posted by bridgman View Post
    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.

    Leave a comment:

  • bridgman
    AMD Linux

  • bridgman
    replied
    Originally posted by grok View Post
    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).

    Originally posted by grok View Post
    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.

    Leave a comment:

  • grok
    Senior Member

  • grok
    replied
    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)

    Leave a comment:

  • boltronics
    Senior Member

  • boltronics
    replied
    Originally posted by bridgman View Post
    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.


    Originally posted by bridgman View Post
    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.


    Originally posted by bridgman View Post
    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/1...l-capabilities
    http://hardware.slashdot.org/story/1...s-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/ker...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.
    boltronics
    Senior Member
    Last edited by boltronics; 29 April 2015, 11:37 AM. Reason: Fixed a spelling mistake.

    Leave a comment:

  • bridgman
    AMD Linux

  • bridgman
    replied
    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.
    bridgman
    AMD Linux
    Last edited by bridgman; 29 April 2015, 09:52 AM.

    Leave a comment:

  • boltronics
    Senior Member

  • boltronics
    replied
    Originally posted by moilami View Post
    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.

    Leave a comment:

  • smitty3268
    Senior Member

  • smitty3268
    replied
    Originally posted by MoonMoon View Post
    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.

    Leave a comment:

  • moilami
    Senior Member

  • moilami
    replied
    Originally posted by boltronics View Post
    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.

    Leave a comment:

  • MoonMoon
    Senior Member

  • MoonMoon
    replied
    Originally posted by torsionbar28 View Post
    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.

    Leave a comment:

Working...
X