Announcement

Collapse
No announcement yet.

Mixing open and closed source

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

  • Originally posted by bridgman View Post
    1. If we're ever going to play protected video (DVDs, HD/BD) then we have to protect the decoded bitmaps all the way to the frame buffer, and we can't do that in an open driver.
    Not trying to be difficult... but what compels you to have to do that?

    The DCMA certainly doesn't cover that level of detail... so what gives? If the content providers want to dictate DRM to everyone, tell them to engineer it themselves.

    Comment


    • It's the AACS license, I believe, but I will confirm that. It's been a while since I had to read through all the licenses.
      Test signature

      Comment


      • First of all, thank you for speaking directly on these forums bridgman. The fact that AMD/ATi released documentation alone made me switch from nVidia.

        As far as implementations go, I think I might've seen my idea briefly mentioned, but I was wondering if it appeared viable at all.

        The idea is that when ATi develops drivers for the *nix platform they should just develop for the open-source RadeonHD driver as the unifying driver, but any implementation that must remain closed-source (playback of DRM content) can be written seperately as a closed-source "add-on" to some extent that would override the RadeonHD's implementation as much as needed for that function. Maybe a closed source library of some sorts?

        That way all resources and effort are put into a single open-source driver, but it allows for proprietary licenses and code to be used and stay proprietary. Again, not sure how realistic this sounds as I am not a hardware programmer.

        Comment


        • Driver modules/add-ons

          Originally posted by efiniti View Post
          The idea is that when ATi develops drivers for the *nix platform they should just develop for the open-source RadeonHD driver as the unifying driver, but any implementation that must remain closed-source (playback of DRM content) can be written seperately as a closed-source "add-on" to some extent that would override the RadeonHD's implementation as much as needed for that function. Maybe a closed source library of some sorts?

          That way all resources and effort are put into a single open-source driver, but it allows for proprietary licenses and code to be used and stay proprietary. Again, not sure how realistic this sounds as I am not a hardware programmer.

          Great idea! AMD/ATI has this idea already and it's employees are thinking about it:

          This sounds great and it's an option we do consider, but so far it's not looking that good. Might be possible to have some of the display driver code relying on open source, but most of the acceleration stack (drm, xv*, opengl) will need to be closed source in the future for a couple of reasons :

          1. If we're ever going to play protected video (DVDs, HD/BD) then we have to protect the decoded bitmaps all the way to the frame buffer, and we can't do that in an open driver.

          2. For workstation business we invest a lot of money in performance-related driver work and wouldn't want to open source that because some of that work *is* useful to competitors.

          Since we're not playing protected video today we could convert to use more open source in the short term, but by the time we finished that it would probably be time to start converting back

          IMO the best strategy is to have open AND closed drivers and use each one where it fits best.
          - Posted by John Bridgman, AMD/ATI employee working on fglrx & documentation http://www.phoronix.com/forums/showp...13&postcount=1
          Last edited by bogdanbiv; 23 February 2008, 01:55 PM.

          Comment


          • My opinion about DRM

            Lets me summarize the situation:

            1 - Media industry & Microsoft is pushing hard for the DRM, This also forces OEMs to push AMD into closed source drivers, plus the arguments that DRM will be cracked don't count because the media industry is blind, and will still demand a closed source driver - I understand that, and probably only user education can help to fix that.


            2 - Linux users mostly don't need DRM, but there is a group of 'workstation' users who don't care about/need it.

            3 - It is very hard to create an closed DRMed driver on top of free driver, because the media content has to be protected up to the point it reaches the screen.


            This means that fglx will remain a separate driver,
            Obviously I don't like this, and probably most linux users don't like this too, but in case this happens I suggest to prioritize the open source driver, for example add as much features as possible to open source driver.

            At the same time the closed driver should just be maintained by fixing bugs - for users that absolutely need DRM.

            On the other hand, the fact that closed driver is performance tuned, and that you don't want to disclose that - I am fine with that. I think that it is worth to buy a faster card, to run a free driver.
            Plus the performance will improve as time passes, both on hardware and software front.

            Thus I suggest that if you absolutely need to keep a separate closed driver, then you should 'freeze' it.

            Big corporate users are anyway using 3~4 years old distributions.

            Comment


            • Question from a gamer (mid/high end sales)

              Hello All,

              I have read all the posts and have a few questions I'm really not sure about now.

              Does the DRM for HD/whateverproduct slow down gaming in general and in linux specifically for just being there?

              I'm your Mid/High end buyer, the gaming person who cares little for the tech stuff but really paid/paying for the FPS on my toy.

              Am I paying for a slower product for DRM HD/whateverproduct that I dont use?

              GPL and the Closed source driver issue to me is not a part of this unless Im getting slower FPS for my buck because of T.V. people.

              If this is true and the FPS is lagging trying to wade through all this DRM junk, can I turn it off or make it not use it at all?

              If it can't be turned off, and this is a question for the AMD/ATI person who is very good at what he does from reading these posts, can you just build another low end card for people wanting T.V. on there pc and get them away from me and my FPS?

              You can sell it like " Dedicated to your veiwing pleasure, the only thing it does it does the BEST! " and then sell it separately or a mix with a mother board style and make it it's own DRM market with it's own DRM headache?

              I read from previous articles that you had to have DRM for a WHQL certificate, can you just do what Intel does and have it there and not use it, keep it out of the way of everybody for open source and then release a whole new product line for T.V people only thats just a DRM scheme on pci that only effects them?

              You can also make the DRM that has to be on the PCIe just junk code so it will never effect your DRM code on your T.V. card. Who would even know, it's DRM. lol

              Thanks everyone for reading, and hope it makes sense in some way. I'm not a tech person just someone who buys stuff to play with and wants the most for the money.

              Comment


              • Good questions.

                DRM (specifically the content of high-def video on HD/BD media via encryption/decryption) is only a factor when playing back that video. No effect on performance or behaviour for any other function.

                We have to have that circuitry in the chip for other OSes, but we don't use it in the Linux driver at all. Even if we were to use the HW decoder to accelerate playback of non-protected high-def video in the future there would be no need to enable the DRM-related circuitry.

                IFF, in the future, the market decides that legal playback of HD/BD disks is required, either for an OEM Linux sku or an individual system upgrade, we would need a driver which made use of the circuitry to help protect the HD/BD content all the way to the screen. Even then, no effect on performance.
                Test signature

                Comment


                • Bluray support is a waste.

                  I'd rather see all the efforts put into making a open source driver with all the 3d support working and stable and then a closed source drive that is setup to play BluRay. You could in theory with agreement from all the submitters us the open-source via dual license to produce closed sourced format thats modified to play DRM and have the special workstation tweaks...

                  Comment


                  • Hi all.

                    Allow me to leave the political/moral discussion that seems to have evovled here and get back to what is important to Joe "Linux-using" Sixpack - getting most out of his card.

                    bridgman, if you're still here, I have some thoughts/ questions:
                    • How tightly is the DRM functionality bound to other UVD (h264 acceleration seems to be the "most wanted") functions - that is, even if disclosinng docs would compromise DRM, would the source code itself compromise it as well?
                    • If the source wouldn't compromise DRM, would it be possible to have the missing xv-* functionality added to the opensource driver through DAAMIT developers, OR outside parties under NDA agreements?
                    • worst-case scenario - none of the above is possible. Let's say someone REs the closed driver (either windows or fglrx) and writes a patch for the opensource driver which would bring the xv-* functionality - would this patch be accepted into the driver? What I'm worried about is yet more fragmentation, should the "patched" driver become succesful (don't believe me? look at via vs. unichrome vs. openchrome - not entirely the same thing - the code was there, but it was ripped out - but close enough)


                    Originally posted by bridgman
                    Just that getting the most performance from a graphics card takes a lot of hard work and a lot of coding -- more than anyone in the open source community is willing to step up and do.
                    I think you're underestimating the opensource community (look at the hand-optimized assembly code in Linux). The reason noone's doing any wild tweaking now is because there's practically no need to do so (scratch the itch, remember?). However, as soon as there are high-performance games/3D apps for linux, which are WIDELY used, people will get cracking at the radeonhd or whatever driver to see if they can come close/beat fglrx.

                    Comment


                    • Originally posted by myxal View Post
                      Let's say someone REs the closed driver (either windows or fglrx) and writes a patch for the opensource driver which would bring the xv-* functionality - would this patch be accepted into the driver?
                      They just added TexturedVideo acceleration for many of the recent cards (R300, R400, R500, RS690) to the xf86-video-ati driver ("radeon"), so Xv should be working on many of the previously "broken" cards in some fashion in the next release. How well it works remains to be seen, of course.

                      Comment

                      Working...
                      X