Announcement

Collapse
No announcement yet.

Prep Work For Open-Source Radeon Compute, UVD

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

  • Prep Work For Open-Source Radeon Compute, UVD

    Phoronix: Prep Work For Open-Source Radeon Compute, UVD

    Here's some interesting work that provides support support for multiple rings to the open-source Radeon driver for supporting multiple compute rings, a-sync DMA engines, and UVD. Yes, for video decoding, but this is just prep work and there is still no UVD specifications or code...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Christian K?nig, one of the recent AMD employees hired to work on the open-source driver stack who was hired in part due to AMD porting the open-source Linux driver to Windows,
    Actually, no. We were able to add Christian and Tom to the open source graphics team because our embedded business unit wanted to see further improvements in the upstream open source drivers and was willing to help fund the work. The port to WEC7 was done by a different development team inside AMD.

    With the WEC7 open-source driver, accelerated video decoding support becomes a bit more pressing.
    Mmm... on balance probably have to disagree with this one as well. The need for accelerated video decoding is pretty much the same no matter what OS is used.

    I guess you could say "we can support additional customers once we have WEC7 support and so in that sense there may be more customers asking for accelerated video decode" and in that case I would agree, but there's nothing specific about WEC7 which brings any greater need for decode accel.
    Last edited by bridgman; 29 October 2011, 11:20 AM.
    Test signature

    Comment


    • #3
      Originally posted by bridgman View Post
      Actually, no. We were able to add Christian and Tom to the open source graphics team because our embedded business unit wanted to see further improvements in the upstream open source drivers and was willing to help fund the work. The port to WEC7 was done by a different development team inside AMD.
      But... what about the self-referential links? There's only two of them anyway now, what're you gonna do about that?

      Comment


      • #4
        What are you referring to when you say "there's only two of them now anyways" ? Self referential links ? Drivers ? Teams working on the open drivers ?

        There are 4 developers in the team working on upstream open source drivers - Alex, Michel, Christian and Tom.
        Test signature

        Comment


        • #5
          Originally posted by bridgman View Post
          What are you referring to when you say "there's only two of them now anyways" ? Self referential links ? Drivers ? Teams working on the open drivers ?

          There are 4 developers in the team working on upstream open source drivers - Alex, Michel, Christian and Tom.
          I think it was a dig at Phoronix's habit of filling articles with links to previous Phoronix articles instead of original sources. It was meant to sarcastically imply that what you say can't be true since this article is "proven" by the existence of the previous ones.

          At least that's what I got out of it.

          Comment


          • #6
            uh.. could someone please explain why using multiple compute rings is "good" and who it will affect when ready? (aka: what is it? can i eat it? how does it taste?)

            Comment


            • #7
              "Here's some interesting work that provides support support for multiple rings to the open-source Radeon driver for supporting multiple compute rings"

              *brain explodes, too many iterations*

              Comment


              • #8
                Originally posted by jakubo View Post
                uh.. could someone please explain why using multiple compute rings is "good" and who it will affect when ready? (aka: what is it? can i eat it? how does it taste?)
                Very simple; you've got multiple layers of hardware security embedded in processing units. For example kernels space is lowest ring (or circle) (if not one above virtualization) that can only do a certain amount of stuff that it is allowed acces to. Apps run in userspace, which is a higher ring.

                Apps can't acces certain stuff so it asks the kernel to do it through an API.

                Comment


                • #9
                  Originally posted by V!NCENT View Post
                  Very simple; you've got multiple layers of hardware security embedded in processing units. For example kernels space is lowest ring (or circle) (if not one above virtualization) that can only do a certain amount of stuff that it is allowed acces to. Apps run in userspace, which is a higher ring.

                  Apps can't acces certain stuff so it asks the kernel to do it through an API.
                  Uh, I don't think this has got anything to do with this code. Sounds more like he's talking about multiple ring buffers . As for the question why this is good. Is this really important to know? I think this is probably just a boring implementation detail.

                  The right question to ask is when do we get UVD?

                  Comment


                  • #10
                    Originally posted by bridgman View Post
                    What are you referring to when you say "there's only two of them now anyways" ? Self referential links ?
                    The links. Since truth tends to take a backseat to the almighty pageviews here, as a cynic I don't expect the article to be corrected, if that means removing one of two links.

                    Comment

                    Working...
                    X