Page 5 of 13 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 123

Thread: Digging Deeper Into AMD's UVD Code Drop

  1. #41
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote Originally Posted by oibaf View Post
    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.
    Last edited by bridgman; 04-04-2013 at 04:49 PM.

  2. #42
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,525

    Default

    Quote Originally Posted by Ericg View Post
    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.

  3. #43
    Join Date
    Nov 2007
    Posts
    1,353

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

  4. #44

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

  5. #45
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote Originally Posted by oibaf View Post
    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 ?

    Quote Originally Posted by oibaf View Post
    It has already been discussed at long so there is no need to start over again here.
    +1 to that

  6. #46
    Join Date
    Jul 2008
    Posts
    730

    Default

    Quote Originally Posted by oibaf View Post
    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:Ha...ation_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

  7. #47
    Join Date
    Jun 2009
    Posts
    1,106

    Default

    Quote Originally Posted by bridgman View Post
    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

  8. #48
    Join Date
    Jan 2009
    Posts
    1,308

    Default

    Quote Originally Posted by bridgman View Post
    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.

  9. #49
    Join Date
    Mar 2010
    Posts
    158

    Default

    Quote Originally Posted by bridgman View Post
    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-playe...-in-chrome-25/

    I don't know if this player can or cannot use hardware based video decoding.
    Last edited by hal2k1; 04-04-2013 at 10:18 PM.

  10. #50
    Join Date
    Oct 2009
    Posts
    2,064

    Default

    Quote Originally Posted by Ericg View Post
    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.

Posting Permissions

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