Announcement

Collapse
No announcement yet.

A few questions about video decode acceleration

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

  • #16
    Originally posted by Redeeman View Post
    If you have made such an agreement, you will need to keep it, but the issue is the same, AMD made this agreement, despite the fact that it would limit its users, and have ZERO positive affects whatsoever, it CERTAINLY does not protect anything.
    ATI have always been pretty outspoken about the costs and limited effectiveness of DRM, but that said if we don't offer the capabilities we can't sell our products. Same for all the other graphics vendors.

    Originally posted by Redeeman View Post
    What this means for me is: I may be able to use this feature at some point 10 years from now, when there only exists copies of the hardware in a museum.
    No worries. It actually gets a lot *harder* to find info after 10 years, so we want to do it quickly too

    The whole open source initiative has been going for less than a year. Video is next on the list after HD2xxx/3xxx 3d info, and that 3d work is very close to being finished. I expect to be able to start spending time on video hw within the next couple of months.

    Originally posted by Redeeman View Post
    Tell me _EXACTLY_ how i am unable to play "protected" contents as it is, make 100 copies, and violate the copyright by making copies to everyone.. THIS i can do, regardless of what AMD does.
    Yep. We don't put the hardware and driver support in to stop you from doing things, we put it in to satisfy requirements from our customers (as codified in Microsoft certification requirements).

    Originally posted by Redeeman View Post
    AMD giving access to hardware which users purchased changes nothing, except the fact that users can now actually use it.
    Pls see below.

    Originally posted by Redeeman View Post
    And providing information to US to make a free driver for non-winblows OS's, suddenly makes windows report that amd catalyst is not a "secure environment"?
    Yes, but indirectly.

    In order to obtain certification for our products, we are required to meet "robustness rules". If you want an example, do a Google search on "copp robustness" and click on the "view as html" link for the first hit. This is representative of the kinds of agreements we need to work within; this one happened to be easy to find and relatively short. If we comply with these requirements we receive a specific level of certification from MS, and the associated bits in the driver in turn enable the "secure environment".

    Please take a read through the document then look at the "New Circumstances" section at the end. If we provide enough information to make it easy to get around the robustness requirements, that could trigger the "New Circumstances" provision, which in turn would either force us to redesign the DRM implementation or to stop selling the product. Do a Google search for "copp revocation" if you want to understand more of the details.

    If it sounds like I'm painting MS as the bad guy here that is not my intention either. My understanding is that the content providers simply did not want DVD/HD/BD content to be playable on a general PC (unless you essentially built a dedicated DVD player into it, like the old DVD cards). MS, as I understand it, worked with other industry partners (such as Intel for HDCP) and proposed a set of rules under which the content providers would license their CSS/ACSS info to allow legal playback on PCs. If you pass the rules you get certification. We sign agreements committing us to certain levels of compliance and robustness in order to get MS certification, and PC manufacturers only purchase certified hardware.

    Whether the results protect anything is irrelevant. Content providers make rules, MS provides implementation and certification rules to satisfy the content providers, and all the graphics vendors (yes, all, not just us) have to comply with those rules in order to get certification and sell our products.
    Last edited by bridgman; 06-07-2008, 11:29 AM.

    Comment


    • #17
      I think there might be an error on the forum.Your quotes show me as the person your responding to in the post above me, but it was actually redeeman that you were quoting...

      By the way I agree with everything that redeeman says. Now my question is, why does microsofts agreement mean that you have to put drm in your linux drivers? How does MS WHQL agreement have any effect whatsoever on your linux initiatives? Thats effectively what your saying... You said that ATi's reason your putting DRM in your linux drivers is becouse MS is making you do it. I'm sorry but I gotta call shens on that...

      Like I said instead of wasting the time and money, yes money. The money to pay engineers. The money invested in documentation. The money invested in software programmers. Windows drivers dont run magically on Linux. In order to make the windows code base run on linux you had to do something to it. And that is the reason why you --shouldnt-- allow any single line of code that runs on windows in your linux code base. Now MS can dictate what can and cannot be done on linux. It's BS. In every possible sense. It's probably illegal in the US and many other nations. It's monopolistic. The bottom line is that it is just plain wrong.
      Last edited by duby229; 06-07-2008, 11:25 AM.

      Comment


      • #18
        i still dont see a problem though, decoding and content "protection" shouldnt have anything in common, in essence its two different things, so all you need to do is to have the hardware able to lock access to reading out decoded information if "protection" is also on.. now, if this is not possible with current hardware, then ati is unable to ever provide us with the information we want

        Comment


        • #19
          This argument is getting rather tiring. Let's settle it here. The newer ATI graphics chips have silicon to provide "protected output" so that heavily DRMed video pipelines on Vista can be used, which is a requirement to play some DRMed media. They can't give us specs for that, because that would enable people to override it on Windows, which would but AMD in hot water with media labels and Microsoft for producing an "insecure" environment. They can give us specs for every other part of the card that is not connected to that. AMD has to sell their cards. They can't take some kind of moral stance on DRM, and say "we won't support it," because than all the OEMs and average Joes would look at their cards as lacking an essential feature: the ability to play back DRMed media, and they would lose most of their sales.

          To put it shortly, this doesn't affect non-DRMed media, and we don't really care about stuff that is DRMed. This might make the UVD block on r600s restricted, because the DRM stuff is tied in with that, but we can still use the DCT/MC block on the r600, which is the same as on earlier cards. Now everyone stop whining about DRM. It'll be dead some day soon, but until then, the whining get annoying. Just ignore it.

          Comment


          • #20
            Originally posted by duby229 View Post
            I think there might be an error on the forum.Your quotes show me as the person your responding to in the post above me, but it was actually redeeman that you were quoting...
            D'oh !! Sorry, fixed above.

            Originally posted by duby229 View Post
            By the way I agree with everything that redeeman says. Now my question is, why does microsofts agreement mean that you have to put drm in your linux drivers? How does MS WHQL agreement have any effect whatsoever on your linux initiatives? Thats effectively what your saying... You said that ATi's reason your putting DRM in your linux drivers is becouse MS is making you do it. I'm sorry but I gotta call shens on that...
            But.. but.. .but... WE DIDN'T PUT DRM IN THE LINUX DRIVERS. THIS IS WHAT I KEEP SAYING !!! AUGGH !!!

            Originally posted by duby229 View Post
            Like I said instead of wasting the time and money, yes money. The money to pay engineers. The money invested in documentation. The money invested in software programmers. Windows drivers dont run magically on Linux. In order to make the windows code base run on linux you had to do something to it. And that is the reason why you --shouldnt-- allow any single line of code that runs on windows in your linux code base. Now MS can dictate what can and cannot be done on linux. It's BS. In every possible sense. It's probably illegal in the US and many other nations. It's monopolistic. The bottom line is that it is just plain wrong.
            We don't run "the Windows code" on Linux -- we have a big chunk of common code, then different drivers for each OS which make use of the common code in areas that make sense. The Windows DRM stuff is not in the common code, for example, it is in the Windows-specific portion of the tree..

            Are you saying we should write a completely different OpenGL driver for Linux, for example ?
            Last edited by bridgman; 06-07-2008, 11:43 AM.

            Comment


            • #21
              Originally posted by Redeeman View Post
              i still dont see a problem though, decoding and content "protection" shouldnt have anything in common, in essence its two different things, so all you need to do is to have the hardware able to lock access to reading out decoded information if "protection" is also on..
              The problem is that for performance and security reasons some of the "protection" stuff is best implemented in the same block as the decoding stuff, since in a Windows environment we need to send protected stuff into the decoder and get protected stuff out. Every vendor has the same problem.

              We are going to try to separate the two functions out in future but if the cost or performance impact is too high it may not be possible.

              Originally posted by Redeeman View Post
              now, if this is not possible with current hardware, then ati is unable to ever provide us with the information we want
              Honestly, if we took that kind of black/white approach we would not have been able to release 3d information either. What we do instead is put together a team of technical and legal experts then pick through the IP and try to draw a dotted line between "the stuff you need to write a good driver" and "the stuff that we can't release" so we can make everyone happy. For some of the blocks (2d) it's pretty easy. For others (3d) it's a lot harder but we were able to do it successfully.

              Video and power management are probably the hardest of all, but we're definitely going to release enough to make for a great user experience. I just don't know exactly where the line is going to be yet.

              Comment


              • #22
                Originally posted by TechMage89 View Post
                AMD has to sell their cards. They can't take some kind of moral stance on DRM, and say "we won't support it," because than all the OEMs and average Joes would look at their cards as lacking an essential feature: the ability to play back DRMed media, and they would lose most of their sales.
                They can continue doing what they do on windows. But saying that we linux users wouldnt be able to play back protected content is a flat out lie. Hacks are being worked on. There really is no need to provide a closed driver. The excuse that they need to provide a protected environment for linux is BS. The bottom line is that open source drivers and players --will-- be able to play back protected content in the very near future 100% transparently... If everybody is able to do everything that they want to do, how will that effect sales?

                Whether AMD or hollywood or MS likes it or not, this is how it will be.

                Comment


                • #23
                  Originally posted by bridgman View Post
                  Are you saying we should write a completely different OpenGL driver for Linux, for example ?
                  No I'm just saying that you should drop the closed driver completely, and EOL that code base for linux right now. Today. Then make one of the open source drivers the officially supported driver by AMD. Then give that open source driver, whichever one you prefer, 100% of your attention on Linux. I'm not saying that you have to devote extra resources, simply give it the same resources that you already have allocated.

                  Comment


                  • #24
                    So if I'm understanding things right, the decode-specific hardware is "tainted" by secure path stuff that can't be publicly documented, but some decoding work could still be offloaded (albeit less efficiently) to shader units. Is that about right?

                    Originally posted by duby229 View Post
                    EOL that code base for linux right now. Today.
                    That would mean EOLing it before the open drivers have the features and performance/compatibility tweaks expected by workstation customers. ATI/AMD would be stupid to do that.
                    Last edited by Ex-Cyber; 06-07-2008, 01:21 PM.

                    Comment


                    • #25
                      Originally posted by Ex-Cyber View Post
                      So if I'm understanding things right, the decode-specific hardware is "tainted" by secure path stuff that can't be publicly documented, but some decoding work could still be offloaded (albeit less efficiently) to shader units. Is that about right?

                      That would mean EOLing it before the open drivers have the features and performance/compatibility tweaks expected by workstation customers. ATI/AMD would be stupid to do that.
                      That is the same understanding that I have as well. Honestly though I think that is a decent compromise. I'd rather have the shaders decoding video then to use tainted hardware.

                      As far as EOLing the closed drivers as, the sooner they do it, the sooner they can re-allocate existing resources to the open drivers. I understand that ATi is doing the best that it can under these circumstances, but they can certainly improve the circumstances by EOling the closed drivers as soon as possible. The sooner they do it the better off they'll be.

                      Comment


                      • #26
                        Originally posted by duby229 View Post
                        But saying that we linux users wouldnt be able to play back protected content is a flat out lie.
                        I'm sure it is unintentional, but you are posting things I didn't say then calling me a liar for saying them.

                        What I said (and please go back and check my posts if you have any doubts) was that licenced (aka certified) players check to see if they are running in a secure environment, and will not play (or will constrict the quality) if that secure environment is not present.

                        Right now the certified players and secure environments only exist on Windows, at least for HD/BD. I did not say anything about not being able to play on Linux, in fact I said multiple times that the DRM hardware would *not* prevent you from being able to play protected content on Linux unless the player app and OS were working together to stop you.
                        Last edited by bridgman; 06-07-2008, 03:57 PM.

                        Comment


                        • #27
                          Originally posted by Ex-Cyber View Post
                          So if I'm understanding things right, the decode-specific hardware is "tainted" by secure path stuff that can't be publicly documented, but some decoding work could still be offloaded (albeit less efficiently) to shader units. Is that about right?
                          It's actually a bit better than that. The 6xx family has the same decode hardware as all the previous generations (IDCT/MC, primarily for MPEG2) and I'm pretty sure we will be able to open that. Some of the 6xx chips add a new decode block, the UVD, optimized for H.264 and VC-1 and I'm not sure we will be able to open *that* up.

                          What will be available with pretty high confidence is :

                          - render acceleration (scaling, colour space conversion etc..) using shaders (aka Xv)

                          - decode acceleration for MPEG2 using the dedicated IDCT block and shaders for MC, same as we use in the Windows driver (aka XvMC)

                          - decode acceleration for H.264 and VC-1, possibly using the IDCT block for IDCT, definitely using the shaders for MC, and using a mix of software and shaders for the rest

                          So, in summary, all of the decode hardware in previous generations of GPUs is carried forward to 6xx and I expect it will all be available to open source developers. The only "at risk" block is the UVD which was added to most of the 6xx chips.

                          BTW all of the decode hardwarwe from all of the HW vendors has contained protection logic for at least 8 years, and probably more. The only difference is that I'm pretty sure we can separate the decode and protection info for the IDCT/MC hardware but not so sure we can do that for UVD.
                          Last edited by bridgman; 06-07-2008, 03:56 PM.

                          Comment


                          • #28
                            Originally posted by duby229 View Post
                            No I'm just saying that you should drop the closed driver completely, and EOL that code base for linux right now. Today. Then make one of the open source drivers the officially supported driver by AMD. Then give that open source driver, whichever one you prefer, 100% of your attention on Linux. I'm not saying that you have to devote extra resources, simply give it the same resources that you already have allocated.
                            Holy mixed signals, Batman !!

                            All we heard for years was two messages :

                            1. We want the Linux driver to have all the same features and performance of the Windows driver.

                            2. We don't want you to open source fglrx and we don't want you to write the open source driver. Just give us the register specs and the community will write the driver.

                            If we EOL the closed driver and focus resources on the open source driver you are going to get a very nice open source driver but you are *not* going to get the features and performance of the Windows driver. Ever.

                            At the start of the project I talked to a lot of developers and users, and it seemed pretty clear that there were two largely non-overlapping sets of users.

                            One group felt that an open driver was what mattered, and they were quite willing to live with a "reasonable" feature and performance delta against the Windows driver as long as the driver would let them reliably run everyday tasks, including light gaming and typical (non-workstation) 3d apps. They expected the driver to work with upstream code and bleeding-edge distros.

                            The second group expected feature and performance parity with Windows (at minimum ), and primarily worked with mainstream distros, either Ubuntu for consumers or RHEL/SLED for enterprise. For this group, sharing code with other OSes is the only practical way to deal with both the high feature/performance expectations and Linux's relatively low market share as a desktop OS (available info tends to suggest around 1/2 percent, although I acknowledge it's probably higher than that).

                            Comment


                            • #29
                              Originally posted by bridgman View Post
                              Holy mixed signals, Batman !!

                              All we heard for years was two messages :

                              1. We want the Linux driver to have all the same features and performance of the Windows driver.

                              2. We don't want you to open source fglrx and we don't want you to write the open source driver. Just give us the register specs and the community will write the driver.

                              If we EOL the closed driver and focus resources on the open source driver you are going to get a very nice open source driver but you are *not* going to get the features and performance of the Windows driver. Ever.

                              At the start of the project I talked to a lot of developers and users, and it seemed pretty clear that there were two largely non-overlapping sets of users.

                              One group felt that an open driver was what mattered, and they were quite willing to live with a "reasonable" feature and performance delta against the Windows driver as long as the driver would let them reliably run everyday tasks, including light gaming and typical (non-workstation) 3d apps. They expected the driver to work with upstream code and bleeding-edge distros.

                              The second group expected feature and performance parity with Windows (at minimum ), and primarily worked with mainstream distros, either Ubuntu for consumers or RHEL/SLED for enterprise. For this group, sharing code with other OSes is the only practical way to deal with both the high feature/performance expectations and Linux's relatively low market share as a desktop OS (available info tends to suggest around 1/2 percent, although I acknowledge it's probably higher than that).
                              I dont know who you talked to at the beginning of these projects, but I can tell you for certain that the open source drivers will support all the features linux needs. The real question is, How soon or late will it be in getting to that point... I think it is clear here that there is such a thing as bloat. Some people call it Feature Creep.I'd be willing to guess that more then half of the "features" on windows are either not needed because the problem that feature was designed to solve doesnt exist on linux or it's not needed becouse it's purpose is to enhance corporate interests.

                              This is all just my one single opinion, but I'll promise you that a whole lot of people who arent responding here are shaking there heads in agreement.

                              So the bottom line is that I can live with a closed driver, but that closed driver simply cannot and never will serve any purpose better then an open driver can. In the end the open drivers will have taken longer to develop, and will perform slower... Why? Becouse ATi has wasted it's Time, Money, an Power on a closed driver that has --no-- benefit to anyone not even it's own self.

                              Comment


                              • #30
                                I dont see why performance in the open driver cannot match that of the closed.. sure, features like crappy shit drm might not be there, but who gives a rats ass? certainly not anyone actually shelling you money(except if hollywood execs are doing it?).

                                What you should do, is just focus your ressources on a free driver

                                Are you saying that the 3d performance that radeonhd eventually will get, wont be nearly as good as on windows?

                                Comment

                                Working...
                                X