Digging Deeper Into AMD's UVD Code Drop

[bridgman]

Intel doesn't require firmware blob so it's better that AMD. Nouveau also has reverse engineered free firmware.

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.

[GreatEmerald]

Christian, why aren't you tagged as AMD LINUX like Bridgman? (*pokes Michael*)

Or, more importantly, Tim Writer. But then it feels like Michael gave up on changing the titles, as there are some more people who are untagged and some people who are mistagged.

[duby229]

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.

Well, I think this is a sticky topic. Personally I'm not sure what to think. On the one side you have the microcode controlling the hardware so anything that is implemented in it can be exposed to the driver. On the other side the microcode is static and can't be improved. There are valid aruments for and against this method.

It is really nice to have working UVD. But it would also be really nice to have it fully open.

For now however I am fully satisfied with this solution.

[oibaf]

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.

Well, yes. The point is that firmware is software, while ROM code is hardware. Someone may agree, someone else not. It has already been discussed at long so there is no need to start over again here.

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).

[bridgman]

Well, yes. The point is that firmware is software, while ROM code is hardware. Someone may agree, someone else not.

Really ? The identical microcode turns from "software" to "hardware" simply by virtue of being stored in ROM rather than RAM ?

How about if it's stored in EEPROM/flash ?

It has already been discussed at long so there is no need to start over again here.

+1 to that

[blackiwid]

Intel doesn't require firmware blob so it's better that AMD. Nouveau also has reverse engineered free firmware.

who hinders you to reverse engineer a free firmware for the amd hardware? You cant really suggesting buying nvidia hardware, because they did not cooperate at all, and because nouvou devs had to reverse engineer the firmware because else maybe their driver would not have worked.

And you dont require that "blob" just act like the microcode in your grafics card is on a rom, dont update it, you will not get uvd, but you dont have that on nouvou drivers also not. And btw, only a few intel-gpus are able to make vdpau, most especialy the cheaper ones dont.

ok maybe I react in a to agressive tone... seems I do that sometimes... so cut it out when you read that

http://libreplanet.org/wiki/Group:Hardware/Certification_criteria

but you basicly then, go further than what fsf and rms wants... most of the time I get much hate even if I only want opensource, or from opensourcelers because I am on fsf site... but you are the first I see (and some others in this thread) that are more extreme than rms

[jrch2k8]

Really ? The identical microcode turns from "software" to "hardware" simply by virtue of being stored in ROM rather than RAM ?
How about if it's stored in EEPROM/flash ?
+1 to that

problem is ppl think firmware code is some pretty C++ code that run hidden in the evil hardware that somehow decide what the hardware can do[for example decode VP8 or HI10P] and having that code open would allow to add or remove the evil!!! AMD evil conspiracy code that disallow this(this is the problem when a non engineer try to be a smart ass).

in reality this firmware do what you used to do with some PICs and Logical Gates with a ROM chip, meaning
a.) turn on/off the device/chip part
b.) allocate memory block adresses if needed
c.) set entry point register for data stream processes
d.) reset device/chip part
e.) return some fixed bitset with internal hardware status[on/off--failure code--confirm stream reception--etc]
f.) enable/set specific register for Control[start/stream send/stream received/process/output/stop]

in the specific case of UVD is just an external chip very dumb that receive a data stream then allocate it in memory and process it using fixed hardware functions and dump an overlay/surface with the result, nothing in the firmware will modify the hardware fixed functions nor will allow you to add nothing new. At most having the firmware could teoretically allow you to set the a different block adress in VRAM but most likely UVD chip read a fixed memory block so you will only get a black surface/overlay and a sense of self trolling, even so is really unlikely without a full electronic schematic of the UVD chip that only should have very few AMD GPU Design electronic engineers.

all this meaning having the firmware is absolutely and utterly useless for anybody unless you have an 190 IQ couple of PhD in planar electronics and somehow get the internal electronic schematics of the chip

[liam]

That's the plan, with the usual caveat that until the code actually gets released there could always be some unanticipated gotcha.

Looks like Christian's commits from yesterday included SI support, so the initial GCN have UVD support already.

Understood.
Thanks for the response.

[hal2k1]

re: VDPAU, I think that was what the existing open source decode acceleration code used so we stayed with it.

re: flash, not sure. My recollection was that flash was moving away from decode acceleration support on Linux but I haven't really looked at it. Are you talking about an older version of flash maybe ?

AFAIK lightspark can use VDPAU:

http://lightspark.github.com/

It is clear, however, the lightspark has some way to go before it can be considered a reasonable implementation of flash: https://github.com/lightspark/lights...i/Site-Support

Gnash apparently uses VAAPI for hardware based video decoding:

http://wiki.gnashdev.org/Hardware_Video_decoding

Gnash development appears to have stagnated since 2011: http://www.gnashdev.org/

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

http://www.omgchrome.com/flash-player-update-lands-in-chrome-25/

I don't know if this player can or cannot use hardware based video decoding.

[droidhacker]

he's referring to Catalyst. nvidia official driver typically has same-week support of xorg servers. catalyst can lag behind by weeks or even months. in the meantime those users are stuck on the last supported release.

This thread is not about blob shit.