Announcement

Collapse
No announcement yet.

Work-In-Progress Porting Of GCN 1.0/1.1 UVD To AMDGPU DRM Driver

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

  • Work-In-Progress Porting Of GCN 1.0/1.1 UVD To AMDGPU DRM Driver

    Phoronix: Work-In-Progress Porting Of GCN 1.0/1.1 UVD To AMDGPU DRM Driver

    With the experimental AMDGPU DRM driver's support for GCN 1.0 "Southern Islands" and GCN 1.1 "Sea Islands" graphics processors as an alternative to the default Radeon DRM driver, one of the disadvantages of that experimental kernel driver is losing out on UVD video decoding. But a port is in the works...

    http://www.phoronix.com/scan.php?pag...UVD-AMDGPU-RFC

  • #2
    I hope he will succeed.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

    Comment


    • #3
      Originally posted by darkbasic View Post
      I hope he will succeed.
      Who doesn't?

      Comment


      • #4
        very good and very important work. so now we need to push AMD to release the needed new firmware

        and AMD why not just hire this man?
        Phantom circuit Sequence Reducer Dyslexia

        Comment


        • #5
          You shouldn't need new firmware. You can just add a header to the existing firmware. It's fully documented in the code. Or just use the firmware without the header so it can continue to be shared with radeon.

          Comment


          • #6
            Originally posted by agd5f View Post
            You shouldn't need new firmware. You can just add a header to the existing firmware. It's fully documented in the code. Or just use the firmware without the header so it can continue to be shared with radeon.
            it's better to post in the mailing list there, so he will see this.

            Comment


            • #7
              Originally posted by starshipeleven View Post
              it's better to post in the mailing list there, so he will see this.
              Trevor already knows he can copy the header. Read his message. He considered that a "new" file, whereas agd5f does not. Semantics...

              EDIT: Nvm the following part. I misunderstood.

              The point is that it would be nice if AMD modified the relevant blobs in the linux-firmware repo to include the header, because changing a blob file looks more trustworthy coming from AMD rather than obtaining the file off random hacker's Google Drive. I'm guessing AMD would do this eventually anyway, once their employee(s) (Christian Koenig probably) started working on it.
              Last edited by DanL; 09-03-2017, 11:43 AM.

              Comment


              • #8
                Originally posted by DanL View Post
                The point is that it would be nice if AMD modified the relevant blobs in the linux-firmware repo to include the header, because changing a blob file looks more trustworthy coming from AMD rather than obtaining the file off random hacker's Google Drive.
                Heh it's a header, a few kbytes at most at the beginning that contain some info read by the driver itself for loading the blob. As long as you know how big it is you can dd it off and checksum the binary with the others we have.

                Or ship a opensource tool that does the header change on known-good firmware files coming from AMD so distros can automatically deal with this.

                Really, a header is the binary equivalent of a sticker with a name, nothing more.

                Comment


                • #9
                  Originally posted by starshipeleven View Post
                  Heh it's a header, a few kbytes at most at the beginning that contain some info read by the driver itself for loading the blob. As long as you know how big it is you can dd it off and checksum the binary with the others we have.
                  Yeah, but who the heck wants to do that?

                  Comment


                  • #10
                    I don't even get the point of things like UVD. It never works and you're better off setting to software decode. IMO they should remove it and save themselves the mm². Or replace it with a quicksync equivalent. And not VCE, VCE isn't even faster than CPU encoding, and terrible quality.

                    Maybe I'm missing something.

                    Comment

                    Working...
                    X