Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Nope. You're focusing on NVidia and still missing the key part of the analogy, which is that if you use Intel HW (or MIPS CPUs) you get the binary microcode (yoghurt dressing) automatically and you don't have to add it yourself. If dependency on binary microcode was the problem then FSF would have to remove their recommendations for most of the hardware out there -- so it's only the "adding dressing yourself" (including microcode in the distro images) that is considered a problem.

    If you look at Intel or NVidia separately it's possible to convince yourself there is a logical explanation, but when you look at them together the logic falls down.

    Anyways, there's a reason people don't use dietary analogies when discussing technical issues.
    Last edited by bridgman; 04 May 2015, 11:04 AM.
    Test signature

    Comment


    • If meat were grown on trees

      Originally posted by chithanh View Post
      Well, analogies are always imperfect, but I think that mine is still better than yours.

      An even more accurate analogy could be:
      • A salad bar which sells two things: 1. lettuce 2. a mix of other salad ingredients and yoghurt dressing
      • A steakhouse which sells lettuce (and non-vegetarian dressing), but community members walk around the place giving you a mix of vegetables and vegan dressing (reverse engineered from the non-vegetarian dressing) to go with that lettuce. However there is a recently opened new section of the steak house which the owner has locked down so community members cannot access it (what this Phoronix article is about).


      So as a vegan you have the choice: Go eat only lettuce at the salad bar, or go to the steakhouse and enjoy a salad with a variety of ingredients.

      If we now put
      Unaccelerated graphics = lettuce
      3D acceleration, power management, etc. = other salad ingredients
      People insisting on free firmware = vegans,
      People ok with proprietary firmware = lacto-ovo vegetarians,
      FSF = the vegan association,
      AMD = salad bar owner,
      NVidia = steakhouse owner,
      Putting firmware in ROM = growing meat on trees

      Then the analogy mostly fits and explains nicely why the FSF cannot endorse AMD graphics.
      Putting firmware in ROM = growing meat on trees? Not exactly. The vegan objection to meat is based on what the animals go through to provide it(caged/tortured/killed). If meat grew on trees without animals at all, it would itself be considered vegan, comparable to fruit. In other words, this would be a complete solution to the vegan ethical objection to meat.

      By comparison, putting firmware in ROM does not help anyone understand or modify either the firmware or the underlying hardware, one of the free software issues. Installing say, iOS to s samrtphone's flash ram doesn't make it any freer or more safe than Windows on disk, after all. The advantages are limited to faster boot times if it doess not have to be read from the disk, and greater difficult of malicious replacement. If an exploit is in the unmodified original firmware, this becomes a disadvantage.

      Auditability and the ability to modify code (such as removal of unwanted Hollywood anti-features) require documented firmware or at least a public acceptance and de facto licensing of reverse engineering. If the Nvidia firmware has been reverse engineered, that would be the basis of the FSF's endorsement but due to Nvidia's practices should apply only to USED nvidia cards. This is because the endorsement is based on a community success against Nvidia, not anything Nvidia did themselves. A similar effort could reverse engineer AMD firmware, isn't there that same effort against another vendor's product that is essentially a licensed copy of r600?

      Here's another problem: endorsing Nvidia today endorses a lack of proper power management. With the global warming mess this means extra power consumption. This is like giving up meat but switching to a brand of GMO soy grown with fertilizer derived from the Canadian tar sands pits. The exception is a machine using manual or scripted control on a known good card, setting to its lowest power state for normal desktop work, medium for video, and highest for games. I ran my AMD cards that way before the PM code was released. If the Nouveau team gets automated power management working with Fermi, I will be happy to try it out with the old GTS450 I have on the shelf, a card comparable at mid-clocks on Nouveau to my HD6750 on Radeon in 2013 locked to the middle clock setting. Nouveau actually seems close to Radeon for per-clock performance, it's reverse engineering the power management that's holding tbings up. Nvidia did release some code and it helped, but with less Nvidia input to Nouveau the driver differences are probably more drastic than between Catalyst and Radeon.

      As for that locked shit coming in the future, that's like the bologna sandwitches served in DC Central Cell Block (jail). Do not eat it, sure as hell do not buy it!

      Comment


      • Originally posted by bridgman View Post
        All of our GPU markets except Linux (so >95% of our sales) have a hard requirement for robust DRM including the ability to respond quickly to a security breach. In order to do that we need to keep some part of the programming model secret, and after analysis it really came down to driver or microcode.
        Does this mean that it is technically possible to produce two microcode images - one free and unsupported, but exclusively targeted towards the free software community with none of the DRM functionality included at all, in addition to the existing proprietary one? If it were possible to produce a significantly "cut-down" version of the microcode that only enabled basic acceleration and power management functions, that may be sufficient to at least satisfy the "free operating system" component part of the problem.

        Comment


        • Originally posted by boltronics View Post
          Does this mean that it is technically possible to produce two microcode images - one free and unsupported, but exclusively targeted towards the free software community with none of the DRM functionality included at all, in addition to the existing proprietary one? If it were possible to produce a significantly "cut-down" version of the microcode that only enabled basic acceleration and power management functions, that may be sufficient to at least satisfy the "free operating system" component part of the problem.
          Sanitizing microcode is not the problem -- we would need to have different hardware as well. If we open up sanitized microcode for the Linux market then we're basically providing all the HW info required to easily reverse-engineer the un-sanitized microcode used for other markets.
          Test signature

          Comment


          • Originally posted by bridgman View Post
            Sanitizing microcode is not the problem -- we would need to have different hardware as well. If we open up sanitized microcode for the Linux market then we're basically providing all the HW info required to easily reverse-engineer the un-sanitized microcode used for other markets.
            How about only doing it for old cards?

            Comment


            • Originally posted by nanonyme View Post
              How about only doing it for old cards?
              We could potentially do it for old HW blocks where the current HW implementation (and hence microcode state bits & toolchains) was totally different, but I don't think enough time has passed for that to be viable yet -- there are "previous generation" HW blocks but most of them did not use microcode.

              For better or worse, once you move a block to a microcode-based HW design you don't need to update it as frequently from one HW generation to the next.
              Test signature

              Comment


              • Originally posted by bridgman View Post
                We could potentially do it for old HW blocks where the current HW implementation (and hence microcode state bits & toolchains) was totally different, but I don't think enough time has passed for that to be viable yet -- there are "previous generation" HW blocks but most of them did not use microcode
                For better or worse, once you move a block to a microcode-based HW design you don't need to update it as frequently from one HW generation to the next.
                Ok. Might want to consider raising the matter internally when it's a more viable option. I'm not sure whether it would bring that much money back to AMD but it would be a nice gesture to the community

                Comment


                • Originally posted by nanonyme View Post
                  Ok. Might want to consider raising the matter internally when it's a more viable option. I'm not sure whether it would bring that much money back to AMD but it would be a nice gesture to the community
                  We do revisit all the policies every couple of years but if the microcode isn't changing then I guess I don't understand how opening it would help the community at all, other than allowing a slightly broken and more-than-slightly destructive set of guidelines to continue unchanged.

                  I don't think we would open up the hardware block design so I still don't see how the microcode helps outside of the "eww, mustn't touch binary microcode in our distro but can cheerfully recommend HW with binary microcode we don't have to touch" mindset. Taking HW microcode and calling it software doesn't magically mean you can study or change it.
                  Last edited by bridgman; 05 May 2015, 01:58 PM.
                  Test signature

                  Comment


                  • Originally posted by bridgman View Post
                    We do revisit all the policies every couple of years but if the microcode isn't changing then I guess I don't understand how opening it would help the community at all, other than allowing a slightly broken and more-than-slightly destructive set of guidelines to continue unchanged.

                    I don't think we would open up the hardware block design so I still don't see how the microcode helps outside of the "eww, mustn't touch binary microcode in our distro but can cheerfully recommend HW with binary microcode we don't have to touch" mindset. Taking HW microcode and calling it software doesn't magically mean you can study or change it.
                    I'd see it more as opening it up for educational purposes. You'd end up doing it on too old hardware anyway to be useful for end-users

                    Comment


                    • Originally posted by nanonyme View Post
                      I'd see it more as opening it up for educational purposes. You'd end up doing it on too old hardware anyway to be useful for end-users
                      Jumped in the middle of the conversation so not totally sure what I was going for was clear with earlier: So fully open microcode including toolchains so it can be used by hackers and students to figure out how hardware works (and get a good impression of why it's a good idea to have the abstraction layer there)

                      Comment

                      Working...
                      X