Page 7 of 13 FirstFirst ... 56789 ... LastLast
Results 61 to 70 of 123

Thread: Digging Deeper Into AMD's UVD Code Drop

  1. #61
    Join Date
    Feb 2009
    Posts
    370

    Default

    Quote Originally Posted by bridgman View Post
    Interesting... that means FSF is effectively demanding that the open source community have the ability to buy less functional hardware (typically at a lower price) and update it to the more functional / more expensive hardware without paying the vendor, or at least saying "if we can't have it for free then you can't sell it to anyone else".
    I think most people would agree that this practice is dishonest anyway. The important thing to note here is that the hardware is NOT less functional. The hardware is the same, and only the firmware is different between the models. I think consumers are in their right to feel ripped off by intentionally gimped firmware.

    I understand the economics for doing so, but it's kind of incompatible with Free software.

  2. #62
    Join Date
    Mar 2012
    Posts
    122

    Default

    Quote Originally Posted by bridgman View Post
    Interesting... that means FSF is effectively demanding that the open source community have the ability to buy less functional hardware (typically at a lower price) and update it to the more functional / more expensive hardware without paying the vendor, or at least saying "if we can't have it for free then you can't sell it to anyone else".

    I understand that this is conceptually similar to the "anti-Tivo-ization" provisions of GPL v3 (at least from a distance) but seems like a much more blatant "functionality grab" ("all your extra-cost features are belong to us") than I'm used to seeing.

    That said, presumably the scenario you describe would require a microcode build that was specific to a single device (with some kind of internal unique ID) to prevent the "premium microcode" from being installed on another device and that is not what we are doing.
    It's simpler than that. The argument is you sold me hardware, it's not mine, thus I can do what I want with it including hacking he firmware to unlock new features. Of course the FSF would strongly prefer you gave them the source of the original firmware to make this job easier, but the vendor may see it differently for obvious buisness reasons.

    That said if the only differentiation between a workstation card with superior colour quality and a desktop card is a few lines of code in the firmware, I dare say the effort to gouge the workstation cards sorta sucks.

  3. #63
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

    Quote Originally Posted by ownagefool View Post
    It's simpler than that. The argument is you sold me hardware, it's not mine, thus I can do what I want with it including hacking he firmware to unlock new features. Of course the FSF would strongly prefer you gave them the source of the original firmware to make this job easier, but the vendor may see it differently for obvious buisness reasons.

    That said if the only differentiation between a workstation card with superior colour quality and a desktop card is a few lines of code in the firmware, I dare say the effort to gouge the workstation cards sorta sucks.
    The whole point is that microcode is part of the hardware we sold you, whether it be ROM-resident or RAM-resident.

    Are you saying that charging extra for additional functionality/performance is somehow bad ?

  4. #64
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

    Quote Originally Posted by benmoran View Post
    I think most people would agree that this practice is dishonest anyway. The important thing to note here is that the hardware is NOT less functional. The hardware is the same, and only the firmware is different between the models. I think consumers are in their right to feel ripped off by intentionally gimped firmware.
    But it's all OK if the firmware is stored in ROM rather than RAM ?

  5. #65
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,072

    Default

    Quote Originally Posted by bridgman View Post
    But it's all OK if the firmware is stored in ROM rather than RAM ?
    Yes. Then it's the company's loss for selling the same hardware for much less profit, with no way to make it use its full potential, not mine.

    If it was updateable, then it would be my loss if I bought a Radeon and could not turn it into a FirePro, if the only difference was the updateable firmware.

  6. #66
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

    Quote Originally Posted by curaga View Post
    Yes. Then it's the company's loss for selling the same hardware for much less profit, with no way to make it use its full potential, not mine.
    OK... so let's say we store the microcode in flash on the chip and program it just before we ship.

    Charging different prices for different levels of functionality would still be "dishonest", right ? Then we pop the write protect bit and it suddenly becomes fine ?

    Quote Originally Posted by curaga View Post
    If it was updateable, then it would be my loss if I bought a Radeon and could not turn it into a FirePro, if the only difference was the updateable firmware.
    ... even if we charge for the upgrade, it would somehow be "your loss" if you were unable to upgrade for free ?

    Can you explain that one to me without using "it costs you the same" because obviously it doesn't -- there's extra development and qualification work for the additional functionality which has to be worked into the selling price somehow. If we didn't offer a range of price/functionality options then everything would have to sell for a price somewhere in between consumer and workstation SKUs.

    Do you really feel "the world would be a better place" if consumer SKU prices went up 15-20% across the board but included workstation features & functionality ?
    Last edited by bridgman; 04-08-2013 at 02:12 PM.

  7. #67
    Join Date
    Oct 2008
    Posts
    3,102

    Default

    Quote Originally Posted by bridgman View Post
    OK... so let's say we store the microcode in flash on the chip and program it just before we ship.

    Charging different prices for different levels of functionality would still be "dishonest", right ? Then we pop the write protect bit and it suddenly becomes fine ?
    It's instructive to think of this in more physical terms.

    Let's say the back of every GPU sold has a physical switch. Consumer cards have the switch defaulted to off, pro cards default to on.

    Otherwise, there is no difference, except cost.

    To use the card, you have to accept an EULA that says you aren't allowed to flip the switch.


    Now, i think a whole lot of people would simply flip that switch and ignore the EULA. And those that don't, would probably be pretty pissed off that they couldn't.

    But obviously i see the business reasons behind it.


    If there is no switch that can simply turn on the new functionality, then that's a completely different situation.
    Last edited by smitty3268; 04-08-2013 at 02:30 PM.

  8. #68
    Join Date
    Oct 2008
    Posts
    3,102

    Default

    Quote Originally Posted by bridgman View Post
    Can you explain that one to me without using "it costs you the same" because obviously it doesn't -- there's extra development and qualification work for the additional functionality which has to be worked into the selling price somehow. If we didn't offer a range of price/functionality options then everything would have to sell for a price somewhere in between consumer and workstation SKUs.

    Do you really feel "the world would be a better place" if consumer SKU prices went up 15-20% across the board but included workstation features & functionality ?
    The obvious solution here is to provide special pro drivers that include the extra functionality and testing, and consumer drivers that do not.

    And document things so that the OSS drivers can implement whatever they want. There is no extra testing that AMD has to pay for in that case, because it's 100% work done by the community.

  9. #69
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

    Quote Originally Posted by smitty3268 View Post
    The obvious solution here is to provide special pro drivers that include the extra functionality and testing, and consumer drivers that do not.
    That's what we do... pro drivers run on pro hardware, and consumer drivers run on consumer hardware.

  10. #70
    Join Date
    Oct 2008
    Posts
    3,102

    Default

    Quote Originally Posted by bridgman View Post
    That's what we do... pro drivers run on pro hardware, and consumer drivers run on consumer hardware.
    You conveniently left out the last 3rd. Allowing 3rd party developers to do whatever they want.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •