Announcement

Collapse
No announcement yet.

3D Optimizations and UVD... AMD_hal.so!

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

  • #16
    Originally posted by RealNC View Post
    Does this matter? If someone reverse engineers it, it's not AMD's fault. Publishing reverse engineered specs is illegal. AMD is not the police.

    And I don't really get the "reverse engineering" paranoia. Who needs to actually do it? I can copy BD discs easily anyway. This whole UVD case is useless. It's a PHAIL in big fat letters; it doesn't protect s***t :P You're trying to keep something a secret that no one even gives a flying fsck about how it works because it's circumvented anyway :P
    if they have the legal obligation they have to keep it secret no matter what you think or hope.

    Comment


    • #17
      Originally posted by RealNC View Post
      It's the content creators who want DRM, not Microsoft. Microsoft simply allows that content to be supported in Windows by making up a standard for it. Hollywood creates the stuff, they want DRM, the consumers want the content, Microsoft allows them to have it.

      Not having DRM in FOSS is retarded. Go wait for BlueRay movies to sell in Ogg files.
      DRM is premised on the idea that there is data on a computer that the operating system prevents the user and owner of that computer from accessing, and furthermore that the operating system is hardened against "tampering" by said owner to make that data accessible.

      This is literally antithetical to the GPL--what Microsoft or another proprietary vendor considers "unauthorized tampering" is the very raison d'etre of the GPL.

      As for Microsoft claiming "we never wanted DRM but the big, bad movie studios forced us to implement it"... I bet you believe the tobacco industry's press releases too.

      Comment


      • #18
        I don't see Microsoft making DVD/BD players, the original DRM platform. The content creators would never remove DRM just for the sake of Windows. If Windows wants to offer users to watch those, it has to implement DRM. And Windows can't afford not to offer a legal way to watch protected content.

        And you're forgetting something: you're not required to accept DRM even if you're a windows user. You simply stop watching movies from BD and DVD. There, problem gone.

        Comment


        • #19
          Originally posted by Alex W. Jackson View Post
          DRM is premised on the idea that there is data on a computer that the operating system prevents the user and owner of that computer from accessing, and furthermore that the operating system is hardened against "tampering" by said owner to make that data accessible.

          This is literally antithetical to the GPL--what Microsoft or another proprietary vendor considers "unauthorized tampering" is the very raison d'etre of the GPL.
          Yes and no. A lot of BD players run embedded Linux with DRM implemented above the kernel.

          Comment


          • #20
            Originally posted by bridgman View Post
            Yes and no. A lot of BD players run embedded Linux with DRM implemented above the kernel.
            Yes, but that's an embedded system where the GPL is moot because the kernel binary is baked into a ROM. Surely you've heard of the controversy among the kernel developers over "Tivoization".

            I can't see any way a desktop Linux system where the user is able to install a modified kernel can ever meet the BD DRM "robustness" requirements.

            Comment


            • #21
              I don't think embedding the OS in ROM removes the obligation to provide source. AFAIK TIVO provides source for the kernel changes distributed with their system.

              What folks refer to as "Tivoization" is a bit different AFAIK -- that's when the software is upgradeable but a mechanism is used so that only software from the vendor (or another approved source) can be used for the replacement.

              Comment


              • #22
                Originally posted by RealNC View Post
                Not having DRM in FOSS is retarded. Go wait for BlueRay movies to sell in Ogg files.
                No, it's the entertainment industry that is retarded they need to revise their business model. Restricting consumers is not the way to go, people just go download the freaking movies in matroska files.

                Comment


                • #23
                  Originally posted by bridgman View Post
                  What folks refer to as "Tivoization" is a bit different AFAIK -- that's when the software is upgradeable but a mechanism is used so that only software from the vendor (or another approved source) can be used for the replacement.
                  Yes, that's exactly what I'm talking about. The only way I can see Linux qualifying for "authorized" BD playback is if the player software and the rest of the stack is tied to an "approved" locked-down kernel binary or a whitelist of such binaries.

                  And as far as a lot of people are concerned (including some important kernel developers and, less importantly, myself), such a system wouldn't be Linux anymore.

                  Comment


                  • #24
                    Y'know, there's a lot more of us consumers out here than there are people working in the entertainment industry. If enough people cared about this issue, we ought to be able to petition for repeal of a lot of these laws. But so far, average joes don't seem to care (or understand, or something) about how DRM infringes on their rights.

                    Comment


                    • #25
                      the whys and whatfors of DRM seem to be a side issue here,people just want to use the ASIC for HW assisted decoding/Encoding/Transcoding of their (re-)encoded HD videos at the end of the day.

                      the implication is, that the ATI UVD/UVD2 ASIC block has in fact some form of DRM inside it, and that is the reason Bridgman and ATI/AMD are having problems and not providing the headers/docs in a timely manor, were as the NV etc dont seem have this DRM inside their ASIC (or just dont reference any of that potential DRM part?)and so have a large commercial video assitance advantage here....right now.

                      if so why did this DRM block get put there instead of its own self contained block for far better security ?, is it really so hard to simply not reference any of this DRM block inside the real important UVD video decoding block headers and documentation everyone wants to see and perhaps use ?.

                      is it really so hard for the internal UVD ASIC devs and doc writer to simply make a headerfile that just references the video options we want to use as per FFMpeg patchs etc , and write their operation entry/exit points up in a PDF, and spend a day compiling their existing test code that doesn t have any conection to any DRM that may or not be inside that ASIC.


                      if not then at least get some internal ATI devs to write a full subset API, and provide working code that can replace this virtually useless UVD ASIC due to the DRM inclusion there, on the other parts of the GFx cards.....

                      put simply, if infact there is DRM inside the UVD ASIC, and so making it almost useless to external devs that want to use everything in it except that potential DRM block, then simply say so and move on, learn the lesson and dont include your DRM block in the next UVD ASIC revision (see an FPGA would have been a very good reprogramable thing here Bridgman )
                      Last edited by popper; 02-05-2009, 05:34 PM.

                      Comment


                      • #26
                        What I'm saying is "our top priority is the hardware we said we would open up", ie enough for 2d, 3d and Xv acceleration. That's getting close to being finished now, so some time over the next couple of months I hope to be able to start looking at UVD to see whether it is feasible to open up some hardware info without putting DRM at too much risk.

                        NVidia has only provided support for their hardware in a closed source driver (like us) so I don't understand your comment about NV not having DRM in their hardware. The distinction here AFAIK is simply that NVidia have made their closed source solution more broadly available than we have, and that they have provided a Windows library for decoding single frames which has been picked up for use in transcoding apps.

                        Comment


                        • #27
                          Windows library? CUDA is available for Linux too. If you use it tricky you can even run win CUDA apps with wine!

                          Comment


                          • #28
                            well OC i dont know if NV have included any DRM inside their ASIC, all people care about is NV are giving people somethng ATI could be giving too but currently dont, ATI and the OEMs sold the X1xxx, HD2xx ,HD3650,HD4xxx on the premise of real HW assisted video playback and real AVIVO GFx card HW assisted AVC Encoding etc, its all still only CPU bound and run after all this time, no apparent use of the UVD ASIC even on windows!.

                            its also been said (by the developer relations *manager of genesi)that any 3rd party devs/companies relying on ATI/AMD UVD/UVD2 plans to base a product on are mad/insane to do so.....

                            i and many others want you to do well in the HW assisted video space, OC, otherwise why would i/we be posting here, just so thats clear


                            *"Fri Jan 16, 2009 Matt Sealey,(Neko),Site Admin,Genesi, Manager, Developer Relations said:
                            There is no driver, not even in the binary ones, ATI will not give a schedule for it and may only expose it through a custom "XvBAW" API.

                            This is not going to get you playing videos right now and it would be insanity to develop a product around it.

                            We recently finished off a marketing requirements/product requirements document for something, and one of the things we agreed to cut out completely was support for an ATI graphics chip (the E2400) because there are no open-source 3D drivers for RV680 and waiting for them to get stable, or commissioning a binary driver in lieu of that, would not be cost-effective"
                            Last edited by popper; 02-05-2009, 06:35 PM.

                            Comment


                            • #29
                              Just because I disagree with you on specifics doesn't mean I don't appreciate what you are trying to do

                              Kano, the discussion is not about CUDA itself but a specific library provided for use with CUDA, called nvcuvid. That is what uses the video decode hardware to decode a frame and return the contents to the application. As far as I can see, nvcuvid is Windows only right now.

                              Comment


                              • #30
                                For linux it is vdpau.

                                Comment

                                Working...
                                X