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


        • #5
          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


          • #6
            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; 03 September 2017, 11:43 AM.

            Comment


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


              • #8
                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


                • #9
                  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


                  • #10
                    One more resason to merge DAL/DC/Display Code as soon as possible

                    Comment

                    Working...
                    X