Announcement

Collapse
No announcement yet.

Open-Source AMD Fusion Driver For Ontario Released

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

  • #21
    Originally posted by glisse View Post
    Didn't know they were in this business too.

    And where can i get opensource driver and documentation of their chipset ?
    Ok i found the source.

    That being said hw sharing doesn't mean you can provide documentation for it, haven't looked closely but broadcom likely either well separated drm part of the chipset from decoding one or simply removed any drm support from it.

    On AMD GPU it seems that UVD is tightly linked to drm and as a result of that UVD info is considered sensitive (once again DRM hold because of obscurity ...)

    Comment


    • #22
      Diversification (within reason) is a good business practice
      Broadcom released the sources on their website, but there is much more going on in Jarod Wilson's GIT. Support up to 970012 actually ships with bone stock Fedora -- meaning, of course, that Fedora has the ability to playback h264 out of the box as long as you have a broadcom chip. The 970015 support didn't arrive quite in time for F14, but should be in F15.

      Now from what I can tell, Broadcom has two separate drivers -- the no-DRM open source drivers, and then the "only through OEM" binary drivers. So presumably, the DRM risks are managed by not putting that stuff in the driver.

      And yes, of course I understand that sharing doesn't mean that you can just release everything, but my hope is that enough similarities remain between the crystalhd and uvd hardware that maybe the broadcom driver could be "enhanced" to also support uvd.

      Clearly, broadcom has planned things out well enough that they are confident that they are safe... and for broadcom, that really says a lot -- they aren't exactly known for being open source friendly, so the risk must be extremely well taken care of for them to go out of their way and release an open source driver.

      Comment


      • #23
        Now in some ways, the UVD might actually be safer to manage than crystalhd. The main downside to crystalhd that I can see, is that it is a lone piece of hardware sitting on the PCIe bus, so you send the h264 over to the 97001x via the PCIe bus, take it back to the CPU in big ugly raw full insane bitrate 1080p, and then shove that back down the PCIe bus to the video card. The first problem is that you're basically giving out the keys to the lamborghini -- if DRM is broken there, it is trivial to use it to rip DRM off of videos. Second problem is obviously having lots of noise running across the PCIe bus multiple times. With UVD, it would just go down the PCIe bus as compressed h264, and from there goes straight out to the monitor (after letting the GPU have its way with it).

        Comment


        • #24
          And sorry for being snippy yesterday... forgot my wallet when I went to work, so ended up not eating. Starvation makes DH into a real jackass.

          Comment


          • #25
            Originally posted by droidhacker View Post
            Now in some ways, the UVD might actually be safer to manage than crystalhd. The main downside to crystalhd that I can see, is that it is a lone piece of hardware sitting on the PCIe bus, so you send the h264 over to the 97001x via the PCIe bus, take it back to the CPU in big ugly raw full insane bitrate 1080p, and then shove that back down the PCIe bus to the video card.
            Correct me if I'm wrong, but can't PCIe devices communicate with each other without going through the CPU or system memory? PCIe essentially works like a network of interconnected nodes, not just a bag of links between the CPU and each device.

            Comment


            • #26
              Originally posted by droidhacker View Post
              Now in some ways, the UVD might actually be safer to manage than crystalhd. The main downside to crystalhd that I can see, is that it is a lone piece of hardware sitting on the PCIe bus, so you send the h264 over to the 97001x via the PCIe bus, take it back to the CPU in big ugly raw full insane bitrate 1080p, and then shove that back down the PCIe bus to the video card. The first problem is that you're basically giving out the keys to the lamborghini -- if DRM is broken there, it is trivial to use it to rip DRM off of videos. Second problem is obviously having lots of noise running across the PCIe bus multiple times. With UVD, it would just go down the PCIe bus as compressed h264, and from there goes straight out to the monitor (after letting the GPU have its way with it).
              Unless the CrystalHD chip can send decoded data back in encrypted form then it might not even be possible to use it with DRM in a PC (as opposed to an embedded application in a closed box without a user-accessible bus) so there may not be a PC DRM implementation to put at risk. Just a guess...
              Test signature

              Comment


              • #27
                Now from what I can tell, Broadcom has two separate drivers -- the no-DRM open source drivers, and then the "only through OEM" binary drivers. So presumably, the DRM risks are managed by not putting that stuff in the driver.

                And yes, of course I understand that sharing doesn't mean that you can just release everything, but my hope is that enough similarities remain between the crystalhd and uvd hardware that maybe the broadcom driver could be "enhanced" to also support uvd.
                Well, i think that exactly this is going to be hard. As bridgman mentioned repeatedly, the DRM and content decoding seem to be tightly entangled in UVD, at least tightly enough to make their legal department be sceptical about it.
                Extrapolating from this, my guess would be that any documentation or OSS code (or two-driver model a la Broadcom) for UVD would be a long way down the road, if at all.

                Therefore, it might be a smarter idea to leverage gallium to create something shader-based. This might end up consuming more power (electrical and computing), but looks like it'd be easier to develop, applicable to all gallium-supporting devices, and, most importantly, woudln't require additional documentation from anyone. I think this is an easier and quicker (to implement) solution, which has drawbacks - i'm willing to live with those, because other things outweigh them (for me, everyone of course has own and probably differing priorities).

                Native UVD support would be great, but due to corporate lawyers/management being the limiting factor here, any UVD support in a reasonable timeframe would probably need to be based on reverse-engineering, which in my experience turns out to be more 'hackish' most of the time.
                But hey, if anybody actually accomplished this, i wouldn't complain - as long as video plays smoothly, i'm happy.

                p.s.: Yes, hunger can make people do strange things - shows the influence of the body on the mind once more

                Comment


                • #28
                  A shader-based approach also has the advantage of being able to support new formats like vp8 by just updating the driver while fixed function hardware is limited to a certain number of formats.

                  Comment


                  • #29
                    Originally posted by bridgman View Post
                    Unless the CrystalHD chip can send decoded data back in encrypted form then it might not even be possible to use it with DRM in a PC (as opposed to an embedded application in a closed box without a user-accessible bus) so there may not be a PC DRM implementation to put at risk. Just a guess...
                    It probably does send it back encrypted, but it may not be a strict requirement with the ms signed drivers nonsense.

                    Comment


                    • #30
                      Originally posted by wirrbeltier View Post
                      my guess would be that any documentation or OSS code (or two-driver model a la Broadcom) for UVD
                      It wouldn't be the same driver anyway, since the DRM driver is fglrx. The question therefore, is HOW different is UVD from crystalhd? WHY can't AMD just do the same thing? Can crystalhd be enhanced to support UVD without too absurd of a rewrite?

                      Comment

                      Working...
                      X