Digging Deeper Into AMD's UVD Code Drop

[Ibidem]

Thats a really good point. In the Case of AMD's OSS driver, it won't function without the firmware, so the ability to redistribute it legally is essential. What exactly is AMD stance on distributing the firmware for their cards?

From http://people.freedesktop.org/~agd5f...LICENSE.radeon

REDISTRIBUTION: Permission is hereby granted, free of any license fees,
to any person obtaining a copy of this microcode (the "Software"), to
install, reproduce, copy and distribute copies, in binary form only, of
the Software and to permit persons to whom the Software is provided to
do the same, provided that the following conditions are met:

No reverse engineering, decompilation, or disassembly of this Software
is permitted.

Redistributions must reproduce the above copyright notice, this
permission notice, and the following disclaimers and notices in the
Software documentation and/or other materials provided with the
Software.
<snip extra-long version of the standard "Don't blame us!" disclaimer>

So yes, you're free to distribute and use it. You have AMD's explicit permission.

[hfernando]

I don't see a reason why it shouldn't work out of the box.

The currently only problematic generations are RS780/RS880 and RV770/RV790.

Christian.

:c It didn't work for me. I downloaded a patched sources from git://people.freedesktop.org/~deathsimple/linux , the uvd-3.9 branch and a the patches for mesa-9.2 from the mail list.
I would report this but i don't know where. because of DRM think.
some info just in case someone can help (please):
dmesg > http://upl.io/lrq31h
glxinfo > http://upl.io/gknd2j
/usr/src/linux/.config > http://upl.io/h0r3u8
vdpauinfo > http://upl.io/3rpmbp
Xorg.0.log > http://upl.io/hssbd7

and when i play a video with mplayer2 i get http://upl.io/k3u57z
and from dmesg http://upl.io/652q1s

pd: i'm so sorry if somebody got a headache because of my english

[duby229]

Thats a really good point. In the Case of AMD's OSS driver, it won't function without the firmware, so the ability to redistribute it legally is essential. What exactly is AMD stance on distributing the firmware for their cards?

[archibald]

Nobody has yet mentioned one problem of closed-source firmware residing in ROM: bugs. If your ROM has bugs then you hardware will *always* have bugs, it will always fail certain conformance tests etc.

If it's in RAM, you can complain to the hardware vendor who can look into it and potentially fix it, sending you a firmware update that's much easier to apply (and can be applied by everybody else) than sending you a new card.

I realise that "don't make firmware with bugs" is likely to be a response, but bugs happen: we're all people and we're all fallible. I'd rather AMD were able to correct any mistakes with my graphics card's programming. I'd definitely rather the firmware was open source (in case the company doesn't devote resources to solving a problem), but on this one I'm a pragmatist: if I can freely redistribute it then I'm happy enough.

[smitty3268]

I don't think your analogy really works other than sounding good (and maybe aligning with an emotional response)... it suggests little or no extra cost for development & qualification on that extra cost feature (5th gear), which is not the case at all for most of the real world product scenarios we are discussing here.

You don't think a lot of time and money went into providing that 5th gear feature on the car? Good engines have a ton of R&D that go into them.

I don't personally mind if firmware is binary in the case where it's just initializing hardware. There are cases where it does a lot more, like that ARM GPU that has the whole GL stack running in firmware, and that is a lot tougher to describe as just "part of the hardware". Although i can even buy that, as long as it isn't updateable.

But if you are allowing something to be updated on the fly, that sounds an awful lot like software to me, and open-sourcing it gets more important. I don't think there's any good line in the sand you can draw that easily takes care of everything, you just have to decide on a case by case basis.

Firmware that artificially limits the features of a product is not something i would want to ever try to defend, and it's not a good reason to keep firmware proprietary. Unless your only concern is making money, of course, and then it's a fine reason.

[droidhacker]

Well thats what I'm trying to figure out. The conversation in this thread seems to suggest that depending on where a firmware is located it should be OSS or not. I'm arguing that it doesnt matter where it is located. If Firmware is considered to be part of the hardware design as Bridgman suggested then it doesnt need to be OSS. The point that I made was that by simply making a solder point on a 9500Pro and flashing it with a 9700Pro BIOS it BECAME a 9700Pro. Therefore the firmware can be considered hardware design. It doesnt matter where it is located.

Ok, so you're on Bridgman's side. I understand.

[droidhacker]

The correct way would be to fit the 4-speed model with an engine that can only do 4 speeds, and then sell it at the $80k. I'm probably not good at car analogies :P

"speed", in this context, has nothing to do with the rate of travel (or engine), rather the number of gear ratios offered by the transmission. More gear ratios (aka "speeds") = more efficiency and more performance, with the SAME engine.

[duby229]

... who or what are you arguing against, and what point are you trying to make?

Well thats what I'm trying to figure out. The conversation in this thread seems to suggest that depending on where a firmware is located it should be OSS or not. I'm arguing that it doesnt matter where it is located. If Firmware is considered to be part of the hardware design as Bridgman suggested then it doesnt need to be OSS. The point that I made was that by simply making a solder point on a 9500Pro and flashing it with a 9700Pro BIOS it BECAME a 9700Pro. Therefore the firmware can be considered hardware design. It doesnt matter where it is located.

[droidhacker]

Does it really matter though? ROM can be flashed as I proved when I flashed my 9500Pro with a 9700Pro BIOS. My opinion is that it doesnt matter where microcode exists.

... who or what are you arguing against, and what point are you trying to make?

[droidhacker]

Well, the funny thing is that basically nobody anywhere uses write-once-and-its-toast storage any more. Its basically always some form of EEPROM.

This discussion over where the code is stored starts to get really funny when you start using media that blurs the lines between "disk" and "ROM".... like, SSD's, NAND flash, eMMC... proving once and for all, that it simply does not matter on what the code is stored. The only thing that matters is on what the code *RUNS*.