Page 6 of 13 FirstFirst ... 45678 ... LastLast
Results 51 to 60 of 123

Thread: Digging Deeper Into AMD's UVD Code Drop

  1. #51
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,939

    Default

    Quote Originally Posted by hal2k1 View Post

    Google's Chrome browser includes a falsh player embedded within it, this player is not a plugin.

    I don't know if this player can or cannot use hardware based video decoding.
    The flash player for chrome IS a plugin. This is why with Chromium you're usually stuck with the same plugin firefox gets, but you can actually pass chromium the pass to the chrome libflashplayer.so and it will use it. Its not embedded inside the chrome binary.

    Also it does support hardware decode.

  2. #52
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,939

    Default

    Quote Originally Posted by droidhacker View Post
    This thread is not about blob shit.
    Hey, He's the one who brought it up, not me.

    Speaking of which though... Bridgman, Christian, why DOES the Catalyst release lag behind on xorg updates? It seriously can't be THAT hard to recompile for the new ABI and push a driver x.x.1 driver update. Quite frankly the fact Nvidia updates for new Xorg immediately is what made my last purchase be for an Nvidia card, so AMD IS losing at least some money over it. (If I made my decision on that fact, I'm sure others have as well)

  3. #53
    Join Date
    Mar 2012
    Posts
    122

    Default

    Quote Originally Posted by bridgman View Post
    Just to be clear, you're saying that microcode permanently stored on the chip is "better" than the same microcode loaded at boot, right ? I realize this is a commonly held position but nobody has ever been able to rationalize it other than by saying "Stallman says" or "if the driver doesn't have to load it then we don't care if it's non-free".

    I understand the concern about hiding what coulda/shoulda been driver code in complex firmware executed on the chip, but if that were the issue then ROM-resident microcode would be as big a concern as RAM-resident microcode. In fact we see the opposite -- CPUs which make heavy use of ROM-resident microcode are regarded as being "more free" than CPUs which only use microcode for a small portion of the instruction set but which include a CAM for patching the on-chip microcode.
    I think someone as smart as yourself should be able to understand the typical "everything should be opensourced" argument, especially when we're refering to hardware.

    What you'll never understand, much like myself, is why these people are incapable of being pragmatic over the issue. The same people argue that Nvidia is a superior project because they refused to allow their open source development to use their blobs. These people are clearly shills and if they're not they're downright stupid and crazy.

    I for one am glad I'll be able to make use of UVD soon and I will continue buying AMD because I feel it's the best all-round choice if we're wanting more performance than intel offers.
    Last edited by ownagefool; 04-06-2013 at 12:19 PM.

  4. #54
    Join Date
    Feb 2012
    Posts
    9

    Default

    Quote Originally Posted by oibaf View Post
    There are also practical concerns: Debian doesn't provide non-free firmware (they are provided in the non-free repository which is not officially part of Debian).
    And it works just great. No practical concerns here.
    It's interesting to see so much resistance to actual progress.

  5. #55
    Join Date
    Jan 2013
    Posts
    1,090

    Default

    Quote Originally Posted by enio View Post
    And it works just great. No practical concerns here.
    It's interesting to see so much resistance to actual progress.
    To what progress? Firmware is software. Firmware blob is no way different as closed source software.

    If this software runs in hardware, is different from if that's loaded runtime.
    If firmware is already present in hardware, there is nothing that software stack should do and can forget about it.

    If hardware explicitly needs live firmware blob loading, that means distribution must find way to distribute it.
    But most of the time the blob has proprietary license.
    It is not much different from flash or closed source drivers.

    It is very risky to distribute closed source in repository due to unfree restricting license.

    Also, firmware can also include killswitches, backdoors and DRM. Don't forget that!

  6. #56
    Join Date
    Jul 2008
    Location
    Berlin, Germany
    Posts
    858

    Default

    Quote Originally Posted by bridgman View Post
    Just to be clear, you're saying that microcode permanently stored on the chip is "better" than the same microcode loaded at boot, right ? I realize this is a commonly held position but nobody has ever been able to rationalize it other than by saying "Stallman says" or "if the driver doesn't have to load it then we don't care if it's non-free".
    You can say what you want about Mr. Stallman, but at least his position is consistent. If the manufacturer/vendor has the ability to change firmware but refuses to give this privilege to the user, then that is an unfair advantage and unethical according to the FSF. In my opinion one real bad thing is that the license of the radeon ucode forbids reverse engineering. So even if one has the resources and motivation to write a free replacement for the firmware, one would not be allowed to.

    Another issue is that such firmware can be used to restrict users' access to the hardware. Then you can sell updates to unlock additional functions. IBM has been doing this in their CPUs for a long time, Intel has recently started to. Even more recently, Raspberry Pi (an incredibly closed piece of sheer joy) has become infamous for its SoC giving piecemeal access to selected I/O ports and capabilities.

    If the firmware is built-in and not replaceable, then you can't make different firmware versions and sell them to different users. All the functions must be unlocked from day one.

  7. #57
    Join Date
    Sep 2010
    Posts
    731

    Default

    Quote Originally Posted by chithanh View Post
    You can say what you want about Mr. Stallman, but at least his position is consistent. If the manufacturer/vendor has the ability to change firmware but refuses to give this privilege to the user, then that is an unfair advantage and unethical according to the FSF. In my opinion one real bad thing is that the license of the radeon ucode forbids reverse engineering. So even if one has the resources and motivation to write a free replacement for the firmware, one would not be allowed to.

    Another issue is that such firmware can be used to restrict users' access to the hardware. Then you can sell updates to unlock additional functions. IBM has been doing this in their CPUs for a long time, Intel has recently started to. Even more recently, Raspberry Pi (an incredibly closed piece of sheer joy) has become infamous for its SoC giving piecemeal access to selected I/O ports and capabilities.

    If the firmware is built-in and not replaceable, then you can't make different firmware versions and sell them to different users. All the functions must be unlocked from day one.
    In EU you can reverse engineer as long as you have valid cause. Assuring inter-op is valid cause. Than you just can not reuse copyrighted material. Any contrary causes are not binding. That is you still have valid license. Eg. in EU you can run OSX on any hardware you like even though its license forbid it.

  8. #58
    Join Date
    Jul 2008
    Location
    Berlin, Germany
    Posts
    858

    Default

    In the EU maybe, but you cannot use that software elsewhere, or people are afraid of it. The acx100/acx1xx wifi driver is a prime example of this.

    Sometimes you have to work around such prohibitions, e.g. by employing clean-room methods. That increases the cost and required manpower, and serves as deterrent to reverse engineering.

  9. #59
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,574

    Default

    Quote Originally Posted by chithanh View Post
    Another issue is that such firmware can be used to restrict users' access to the hardware. Then you can sell updates to unlock additional functions. IBM has been doing this in their CPUs for a long time, Intel has recently started to.
    Quote Originally Posted by chithanh View Post
    If the firmware is built-in and not replaceable, then you can't make different firmware versions and sell them to different users. All the functions must be unlocked from day one.
    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.
    Last edited by bridgman; 04-08-2013 at 11:10 AM.

  10. #60
    Join Date
    Jul 2008
    Location
    Berlin, Germany
    Posts
    858

    Default

    Indeed, what AMD is doing is maybe closer to the Raspberry Pi approach. There is public firmware which unlocks the stuff Broadcom wants everybody to use, and non-public firmware with more functions which those get who are special friends with Broadcom. The part of the drivers which runs on the CPU itself is free software.

    I understand that AMD also limits functions in drivers (like deep color previously available only to workstation cards, or Tahiti ECC now). Similar to what HP alledgedly does for the speed of their scanners.

Posting Permissions

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