Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 46

Thread: Open-Source AMD Fusion Driver For Ontario Released

  1. #21

    Default

    Quote Originally Posted by glisse View Post
    Broadcom isn't in the same situation they aren't tie with DRM content protection agreement, broadcom is doing wifi stuff mostly, nothings such as GPU. The content mafia is all about picture & music, they don't care about wifi.
    Never heard of the Crystal HD DSP? http://www.broadcom.com/products/fea...crystal_hd.php Very popular with netbook and SFF system users as it adds full video decode offloading to proprietary formats like H.264 and VC-1.

  2. #22
    Join Date
    May 2007
    Posts
    231

    Default

    Quote Originally Posted by droidhacker View Post
    BCM970010, BCM970012, BCM970015 -- based on Xilleon, which they got from AMD, which is also the predecessor to UVD. SAME STUFF, EXACTLY THE SAME ISSUES.

    Broadcom chips are even baked into TV's, DVR's, and BD players ***FOR*** image decoding and processing.

    They most definitely ARE involved (sucked in to) DRM content protection agreements.


    Of course, if you'd read this thread, you would know that already, since this is now the SECOND time I've explained it.
    Didn't know they were in this business too.

    And where can i get opensource driver and documentation of their chipset ?

  3. #23
    Join Date
    May 2007
    Posts
    231

    Default

    Quote 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 ...)

  4. #24
    Join Date
    Oct 2009
    Posts
    2,064

    Default

    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.

  5. #25
    Join Date
    Oct 2009
    Posts
    2,064

    Default

    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).

  6. #26
    Join Date
    Oct 2009
    Posts
    2,064

    Default

    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.

  7. #27
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote 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.

  8. #28
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote 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...

  9. #29
    Join Date
    Jun 2009
    Location
    NL
    Posts
    24

    Default

    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

  10. #30
    Join Date
    Dec 2007
    Posts
    2,329

    Default

    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •