Page 16 of 29 FirstFirst ... 6141516171826 ... LastLast
Results 151 to 160 of 283

Thread: AMD Releases Open-Source UVD Video Support

  1. #151
    Join Date
    Aug 2009
    Posts
    24

    Default

    Quote Originally Posted by twriter View Post
    I'd just like to say thanks for all the positive feedback. It's great to know that our work is appreciated.

    And a big thanks to John Bridgman and all the folks at AMD who helped out. You know who you are.

    Tim
    Tim and team,
    Thanks for this great milestone.
    But as owner of rv635 (hd3650), I'm really curious to know what was the main issue in bringing up UVD1 as well. Is that due to testing and bug fixing or because of significant architecture differences? Given that UVD1 seems like a subset of UVD2, I'm really hoping for the former so there's no big IP review to go though...
    Anyways, +1 for UVD1

  2. #152
    Join Date
    Aug 2009
    Posts
    24

    Default

    One more thing: is it correct that this code drop does not support deinterlacing?

  3. #153
    Join Date
    Mar 2010
    Posts
    158

    Default

    Quote Originally Posted by bridgman View Post
    We actually expected the next round of power management IP to get approved for release before UVD, but it didn't work out that way.
    I can see a reason why releasing programming information about UVD might have been a problem due to the presence of DRM within the GPUs, and hence the likelihood of associated legal NDAs and other agreements with multimedia content rightsholders, but GPU power management? I don't understand, how could the release of programming specifications for power management be a problem in relation to IP? It is not as though AMD would be releasing the actual IP of how power management worked within the GPU.

    Also, as I understood the law, once you sold the hardware, you effectively sell with it an implied license for the purchaser to use the IP embedded within the hardware.

    http://en.wikipedia.org/wiki/Implied_license

    Implied licenses often arise where the licensee has purchased a physical embodiment of some intellectual property belonging to the licensor
    This implied license goes to anybody who purchases your hardware, it is not dependent on the operating system the purchaser chooses to run. Given this, don't AMD have a legal obligation to customers who have purchased AMD hardware and who choose to use an open source operating system? Aren't AMD obliged under the law to enable said customers to use the hardware features they have purchased?

    I don't wish to seem ungrateful, but I have purchased multiple AMD hardware GPUs, and I want them to work as fully as possible (as is my reasonable expectation and apparent right under the law), so what is the hold up? Why can't AMD release the information that would allow users of open source operating systems to use the power management features of AMD hardware they have legally purchased? Particularly as this seems to be a legal reuqirement for AMD to enable exactly such?

    It is not as though anybody is asking AMD to release the design of power management itself. Just the programming specs for it.
    Last edited by hal2k1; 04-04-2013 at 02:33 AM.

  4. #154
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,601

    Default

    Quote Originally Posted by hal2k1 View Post
    This implied license goes to anybody who purchases your hardware, it is not dependent on the operating system the purchaser chooses to run. Given this, don't AMD have a legal obligation to customers who have purchased AMD hardware and who choose to use an open source operating system? Aren't AMD obliged under the law to enable said customers to use the hardware features they have purchased?
    They do this via Catalyst. The radeon driver is pretty much a bonus, but they don't have to publish everything for it as they already have one implementation. So I'm just glad that they are doing what they are doing right now.

  5. #155
    Join Date
    Mar 2010
    Posts
    158

    Default

    Quote Originally Posted by GreatEmerald View Post
    They do this via Catalyst. The radeon driver is pretty much a bonus, but they don't have to publish everything for it as they already have one implementation. So I'm just glad that they are doing what they are doing right now.
    Doesn't answer the question. AMD have apparently "seen the light" and taken some steps towards releasing programming specifications (which is not IP, according to the law) for some features of their hardware. Kudos to AMD for doing at least that. If AMD were to release programming specifications (not IP) for all features of their hardware (with the possible allowable exception of copy protection DRM features, which would come under the DMCA), then AMD would without doubt become first choice hardware for running open source software.

    But for some inscrutable reason AMD haven't released programming specifications (not IP) for power management. I just don't understand the reasoning here. What could possibly be problematic about programming specifications (not IP) for power management?

    The open source community is not asking AMD to release IP. The open source community does not want to design competing power management hardware. All that is wanted is programming specifications.

    As I understand it, like header files in the SCO case and the Oracle case , programming specifications are simply not IP, and they are not even protectable by copyright law. I cannot imagine any way in which programming specifications for power management features of the hardware somehow "protect" material which is possibly subject to copyright (such as multimedia files).

    So once again I would ask, what could possibly be the hold up? Especially since, if AMD were to release this information, those who argue that AMD hardware is not the best choice for users of open source software would be left utterly without any remaining actual case.

  6. #156
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by hal2k1 View Post
    But for some inscrutable reason AMD haven't released programming specifications (not IP) for power management. I just don't understand the reasoning here. What could possibly be problematic about programming specifications (not IP) for power management?

    The open source community is not asking AMD to release IP. The open source community does not want to design competing power management hardware. All that is wanted is programming specifications.
    The obvious issue here is that programming specifications can never be totally separated from IP, unless the hardware was designed with some kind of isolation layer to separate the programming from the operation, so effectively the community *is* asking AMD to release IP. This was the case for all hardware blocks... power management is no different.

    Quote Originally Posted by hal2k1 View Post
    As I understand it, like header files in the SCO case and the Oracle case , programming specifications are simply not IP, and they are not even protectable by copyright law. I cannot imagine any way in which programming specifications for power management features of the hardware somehow "protect" material which is possibly subject to copyright (such as multimedia files).
    Header files and hardware design are sufficiently different that I don't think you can apply a "header file" ruling to hardware.

    I don't understand why you can't see how programming specifications could reveal information about protected IP, whether it be copyright, patent or trade secret (or any of the other mechanisms which aren't usually relevent to open source driver support).

    Quote Originally Posted by pvautrin View Post
    One more thing: is it correct that this code drop does not support deinterlacing?
    I don't think deinterlacing is done in UVD anyways; I believe it is normally done during post-processing on shaders. At first glance the deinterlacing code shouldn't care whether the decoding is done by hardware or software other than optimization possibilities.

  7. #157
    Join Date
    Sep 2011
    Posts
    703

    Default

    Quote Originally Posted by GreatEmerald View Post
    They do this via Catalyst. The radeon driver is pretty much a bonus, but they don't have to publish everything for it as they already have one implementation. So I'm just glad that they are doing what they are doing right now.
    Only true for Windows, (Mac?) and Linux

  8. #158
    Join Date
    Oct 2009
    Posts
    2,122

    Default

    Quote Originally Posted by brosis View Post
    In my country, there is no coolaid. So, if I prove you wrong, that would mean you are the one on "coolaid", so lets remove your pink glasses for good.
    First of all, please study this thread.
    Particularly, study later post where one user confirms how bad opensource driver performs on A8, confirming my expectations.


    AMD APUs on opensource driver are 20 times slower, so slow that hardware-level slower Intel wipes floor with them.

    This is the best fair result I can come up with:
    http://openbenchmarking.org/result/1...AR-1208249SU89

    AMD side can be improved - if you can find A8/A10 running 1920x1080, kernel 3.5 or any later radeon driver - POST.


    Because 99% of AMD radeon supporters are catalyst consumers. In that case - better straight go nvidia, proprietary too, performed good for ages.
    So much for opensource.

    But no, many AMD users use AMD just because they love two half broken drivers and consider this state of permanent breakage to be optimal [Link].
    Ok, but lets compare fairly - opensource vs opensource, should we? Radeon vs Intel on according hardware.
    By the way, its nearly IMPOSSIBLE to find A8/A10 APU on opensource radeon on openbenchmarking, 99% results are fglrx
    Donīt believe me - try!



    No, I am not confusing anything. I choose NOT AMD, because open source is Intel and AMD is closed source.
    Opensource AMD is inofficial, on not full documentation, inadequate support, inadequate performance.
    This opensource is not far from nvidia, where documentation is added and few developers are present.

    That said, I try to use only opensource. But only if its adequate in terms of software and RnD power.
    Right now, it is not adequate. But I do appreciate what is happening today with one of AMD drivers.


    As an argument to "AMD should hire 20-30 more opensource developers, which Intel already has" - yes, they can try.
    "MURDERFY" - thats LOL.


    On Intel its automatic. As it should be, no?


    Answered by link above. Performance is below Intel.


    I purchased already 3 Intel systems to run with opensource driver. They run bug-free, cool, out of the box and have good 3D. Like it should be, no, amd-fan?
    Hope this answers "ahead" and "in ALL my wants".


    Prove it then.
    If you have AMD machine, do tests: Lightsmark, Xonotic (High) and OpenArena 0.8.8. Profile: 1920x1080.
    Post profile result the result here so we can compare it to profile above, that covers HD2000,2500, 3000 and 4000.

    Can use any kernel you want - I recommend 13.04, updated, with xorg-edgers, or oibaf, or stock - at your will. Because its fast and reliable result.

    I have access to two Intel machines with specified configuration, one HD2000, other is HD3000.
    I can test too and submit profile to compare to your configuration.
    blahblahblahblah.

    I **HAVE** an A8, in my laptop, which has DUAL GPU. The A8 integrated performs SO WELL, that I completely disable the second chip. TOTALLY NOT NEEDED.

  9. #159
    Join Date
    Oct 2009
    Posts
    2,122

    Default

    Quote Originally Posted by Nille View Post
    This has nothing todo with the Video Acceleration. Its only an Overlay.
    Yes, its an overlay. The question, however, remains valid. Can it *apply* the overlay? Because you don't want to be doing complex post processing of the video in the CPU.

  10. #160
    Join Date
    Oct 2009
    Posts
    2,122

    Default

    Quote Originally Posted by Nille View Post
    On Old UVD and UVD+ Cards and BD Disk didn't run smooth, so its more an hardware limitation.
    Huh? The hell are you on about. This video acceleration that was just released, will decode non-3d bluray. PERIOD.
    UVD1 and + aren't supported, therefore there IS no hardware limitation.

    Regarding 3d-bd, I think somewhere back, it was said to be uvd3? I don't know or care about it though, so it may not play on uvd3 hardware due to *software* limitation. Or maybe it will work. Don't know, don't care.

Posting Permissions

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