Announcement

Collapse
No announcement yet.

Digging Deeper Into AMD's UVD Code Drop

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by przemoli View Post
    This is good news for all FLOSS driver users. Its no-good news for all Catalyst users :| as apps now will double down on VDPAU (not as if Catalyst alternative was good, but..)

    And we may not see Catalyst adopting VDPAU
    Too bad, so sad. Binary crap can burn in hell.

    Comment


    • #32
      So naturally, two of my three radeon systems, and the only one without enough CPU power to cut through 1080P (which also happens to be my HTPC), fall into the RS780/880 category.

      Good thing I have a crystalhd in that one, but the crystalhd is a bit flakey because the decoded video needs to be shunted back from the crystalhd, through the CPU, and out to the video card. I.e., in all of its massive rawness.

      Comment


      • #33
        Originally posted by bridgman View Post
        Good question. The UVD microcode is the same as Linux Catalyst uses and decode performance should be identical
        Maybe even on Windows, if I understand microcode stuff right?

        Comment


        • #34
          Originally posted by Deathsimple View Post
          Currently supported is everything with UVD2 and newer on it, with the only exception of RS780/RS880 which have two outstanding problems. Additional to that it used to work on RV770 and RV790, but a couple of people reported that it currently doesn't. I'm already investigating in it.

          Cheers,
          Christian.
          So just to make shure I did understand that right, in the article michael wrote something about UVD2 only gets supported, and then I looked on wikipedia and the zacate E-350 has a UVD3 unit.

          So you say that Zacate E-350 UVD3 fusion gpus is supported with this drop?

          Comment


          • #35
            Don't know what kind of drugs you're on, but same microsecond support for the latest xorg release is pretty damned good if you ask me.


            See previous response.
            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.

            Comment


            • #36
              Originally posted by blackiwid View Post
              So just to make shure I did understand that right, in the article michael wrote something about UVD2 only gets supported, and then I looked on wikipedia and the zacate E-350 has a UVD3 unit.

              So you say that Zacate E-350 UVD3 fusion gpus is supported with this drop?
              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.

              Comment


              • #37
                Originally posted by Deathsimple View Post
                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.
                Christian, why aren't you tagged as AMD LINUX like Bridgman? (*pokes Michael*)

                Comment


                • #38
                  Originally posted by Deathsimple View Post
                  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.
                  so Christian, great work from you, nice, I did not read the anouncement that that is coming a year ago. For me I was shure that gpu powerered or processed video with amd gpus will never happen. (because I thought you are not willing or allowed to open up uvd stuff because of drm)


                  So I am as much excited than I was when amd bought ati and I knew they would most likely open the specs.


                  Thats so fuckin great... thx!


                  Now its pretty obvious from what company you should buy gpus or fusion stuff, if you want new hardware. there is not any reason now to buy a intel gpu instead. Of course people that dont care about driver freedom and really want to hardcore game under linux, there is maybe nvidia still the better alternative (cant really compary nvidia blobs and catalyst to long ago that I used em).

                  And because Amd ist most of the time cheaper than intel on the same performence level, amd is in 90-99% the best solution for linux users now.

                  Oh my now linux htpc´s will become a real big thing


                  THX AGAIN for that great work

                  Comment


                  • #39
                    Originally posted by blackiwid View Post
                    so Christian, great work from you, nice, I did not read the anouncement that that is coming a year ago. For me I was shure that gpu powerered or processed video with amd gpus will never happen. (because I thought you are not willing or allowed to open up uvd stuff because of drm)


                    So I am as much excited than I was when amd bought ati and I knew they would most likely open the specs.


                    Thats so fuckin great... thx!


                    Now its pretty obvious from what company you should buy gpus or fusion stuff, if you want new hardware. there is not any reason now to buy a intel gpu instead. Of course people that dont care about driver freedom and really want to hardcore game under linux, there is maybe nvidia still the better alternative (cant really compary nvidia blobs and catalyst to long ago that I used em).

                    And because Amd ist most of the time cheaper than intel on the same performence level, amd is in 90-99% the best solution for linux users now.

                    Oh my now linux htpc´s will become a real big thing


                    THX AGAIN for that great work
                    No reason to buy an intel GPU....? Haswell should be covering the lowend of both AMD and Nvidia, maybe even low-middle. Its a fully open source driver backed by 20 paid employees plus numerous outside contributors. Its got fully working power management and video decoding / encoding it will suck less power than a discrete card and Intel isn't in financial trouble like AMD is so the odds of longer supporter are higher.

                    Oh, and Chris Wilson is doing an AMAZING job at maintaining the driver and providing basically weekly / bi weekly releases to fix bugs, unlike the ATI driver that only seems to get a release when a critical bug is fixed or a new xorg server comes out. Release early, release often.

                    Sorry AMD, I really appreciate the work going on in the driver, and I do benefit from it because my second laptop has an AMD 4000 series GPU. But all my laptops from here on out will be strictly intel with integrated graphics, desktop I'll still go discrete but I really believe that FOSS intel vs FOSS radeon.... FOSS intel wins, and a big part of that is how often Chris ships releases to fix bugs, whether they are trivial or critical.

                    Comment


                    • #40
                      Originally posted by bridgman View Post
                      Unfortunately Linux puts microcode in a folder called "firmware", which makes things confusing right from the start. The microcode that gets loaded into the chip is a binary image, just like the microcode that is permanently burned into devices. It's part of the hardware block design.

                      All of the driver code (ie everything that runs on the CPU) is open source. This is the same model as the rest of the graphics drivers.
                      Intel doesn't require firmware blob so it's better that AMD. Nouveau also has reverse engineered free firmware.

                      Comment


                      • #41
                        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, 04:49 PM.

                        Comment


                        • #42
                          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.

                          Comment


                          • #43
                            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.

                            Comment


                            • #44
                              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).

                              Comment


                              • #45
                                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 ?

                                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

                                Comment

                                Working...
                                X