Digging Deeper Into AMD's UVD Code Drop

[Ericg]

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.

[Ericg]

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)

[ownagefool]

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.

[enio]

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.

[brosis]

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!

[chithanh]

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.

[przemoli]

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.

[chithanh]

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.

[bridgman]

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.

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.

[chithanh]

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.