Announcement

Collapse
No announcement yet.

AMD Releases UVD Video Decode Support For R600 GPUs

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

  • Unjust laws should be defied

    Originally posted by Mat2 View Post
    Please remember, that it is probably necessary to buy a patent license from MPEG LA to lawfully use the UVD open source support.
    We may not like the law, but that does not mean that we could break it.

    I do not know how can I get such a license, though.
    Actually, we can defy laws aimed at keeping monopolies rich. Justification is the efforts they put into destroying alternatives they do not control. Even the US Patent office recognizes the "interoperability" issue to a limited extend. I will now explain how even in the US we so easly get away with defying software patents, as I do openly:

    Keep in mind, as an individual user, not in an office, MPEG-LA cannot find you, and cannot read your hard drive to determine what software you run your video card with. An attempt to do so would require installing malware similar to Sony's XCP rootkit and would scupper any lawsuits based on the take from that malware. The countersuits would do great harm to MPEG-LA as well. This is NOT like Hollywood's crusade against filesharing, where IP addresses are simply read from public torrents if not using a darknet.

    MPEG-LA also cannot simply get lists of Linux users from popular websites's IP logs, subpeona IP address to user records from ISP's and then get a warrant to search Linux computers for "illegal" codecs or video acceleration programs. No judge would approve the warrant. Also, it would take very few lawsuits against individual computer users over non-corporate controlled software to cause millions, maybe tens of millions of people, to decide the only way to protect themselves was to discard and destroy ALL computing devices and clear their homes of all products related to the offending industry. This may be the biggest deterrent of all.

    The biggest threat is actually trade deals like the TPP and TTIP that could make it difficult to host patent-busting and interoperability software in places like Europe. There will always be countries that refuse to sign trade deals and make more money hosting "outlaw" servers anyway, but proposed trade deals usually include Internet censorship these days, so you could in the future have to download future open codecs against future patented codecs via Tor or a descendent therof. Thus, we should try to sink future codec patents, and to sink sales of products containing patented software without which they cannot be fully used. The existing patents will expire before such a threatening regime can be put fully into place, but we've got to sink any new ones and sink these dirty trade deals. Much of the work I do with video is covering protests and disruption aimed at the people behind things like TPP and TTIP, including protests at their homes.

    Given that I have already had one encrypted computer defeat a police raid after a protest they especially disliked-and been part of a group that defeated a lawsuit from "Goldman-Sucks," over residential protests, I am not easily intimidated by threats from patent trolls. They can't read my system, can't get my legal name from ANYTHING, hell I don't even have an ISP registered to my address anywhere in the world. They can kiss my ass with their software patents...

    Comment


    • I've never HEARD of an individual user software patent lawsuit

      Originally posted by nanonyme View Post
      Or then you can ignore it like everyone is else and see if MPEG LA sues you
      I've never HEARD of an individual user software patent lawsuit, not in my entire life. Remember how GIF nearly
      sank under false rumors of demand letters to web hosts using the format? Your hard drive is not online and
      cannot be searched without illegal malware, thus no easy path for patent trolls to locate targets

      Comment


      • Originally posted by Nille_kungen View Post
        In the older log there was no RS780_uvd.bin
        The file exist at /lib/firmware/radeon
        Code:
        root@antiX1:/lib/firmware/radeon# ls -l RS780*
        -rw-r--r-- 1 root root 90164 ene 11 13:53 RS780_uvd.bin
        And dmesg | grep 780 shows:
        Code:
        4 base 000078000000 mask FFFFFC000000 write-back
        found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [ffff8800000ff780]
        init_memory_mapping: [mem 0x78000000-0x7bbfffff]
         [mem 0x78000000-0x7bbfffff] page 2M
        [drm] initializing kernel modesetting (RS780 0x1002:0x9616 0x1849:0x9616).
        [drm] Loading RS780 Microcode
        How can I know (and fix) if is a problem with the firmware?

        Comment


        • Originally posted by CGarces View Post
          The file exist at /lib/firmware/radeon
          Code:
          root@antiX1:/lib/firmware/radeon# ls -l RS780*
          -rw-r--r-- 1 root root 90164 ene 11 13:53 RS780_uvd.bin
          That is probably the wrong location. If I understand correctly, it should be in initrd. Isn't UVD officially packaged for Debian?

          Comment


          • Originally posted by OneTimeShot View Post
            That is probably the wrong location. If I understand correctly, it should be in initrd. Isn't UVD officially packaged for Debian?
            It does not need to be in initrd... firmwares are packaged, but Debian is in freeze and set of packaged firmwares are only for default 3.16 kernel usage currently... so you have to add it manually if you use newer kernel, proper location for non default (or non debian) kernels should be /lib/firmware/KERNEL_VERSION/radeon/
            Last edited by dungeon; 25 January 2015, 05:39 PM.

            Comment


            • Originally posted by dungeon View Post
              It does not need to be in initrd...
              Fair enough - I haven't used firmware with AMD chips.

              In terms of "how to check that the firmware is loading", if you move/delete the firmware files and you think are loading elsewhere, the dmesg file should definitely not show the firmware has loaded successfully message...

              Comment


              • Originally posted by OneTimeShot View Post
                Fair enough - I haven't used firmware with AMD chips.

                In terms of "how to check that the firmware is loading", if you move/delete the firmware files and you think are loading elsewhere, the dmesg file should definitely not show the firmware has loaded successfully message...
                It doesn't have to be in the initrd, but some distro's like gentoo have the option to build firmware\microcode into the intrd. genkernel specifically gives a flag to do just that. Not only that but you also have the option to build them straight into the kernel image. make menuconfig inside /usr/src/linux and you'll find the option in there.

                Comment


                • Originally posted by OneTimeShot View Post
                  Fair enough - I haven't used firmware with AMD chips.

                  In terms of "how to check that the firmware is loading", if you move/delete the firmware files and you think are loading elsewhere, the dmesg file should definitely not show the firmware has loaded successfully message...
                  Well, I have removed the firmware from /lib/firmware/[KERNEL]/radeon, and I receive an error, so now I'm sure about the right path.
                  During the boot process RS780_pfp and RS780_me are loaded, but not RS780_uvd.

                  My distribution (Antix, based on Debian), use dracut so I have try do do this...

                  dracut --install /lib/firmware/[KERNEL]/radeon/RS780_uvd.bin --force

                  But also not works.

                  I need to recompile the liquorix kernel to load de firmware?

                  Comment


                  • good news

                    I have an old ION HTPC that I need to replace and I had a spare 785G board with on board rs780 that I thought might do the job. It's close. It mostly works with VDPAU. Mostly. But my old lady and I need something _reliable_ so after a couple weeks of hassles I finally just gave up and ordered a GTX960 card (overkill, I know) so I could use those (historically at least) reliable prop VDPAU drivers.

                    That means the day after the package arrives, there will be an update making the free AMD drivers _perfect_. You're welcome, AMD users.

                    Comment


                    • Originally posted by Zapitron View Post
                      You're welcome, AMD users.
                      Oh lol, I guess AMD users story should sound like that: I had ancient crap PC with GF MX440, this nvidia card sucked hard with nouvaeu and I was not able to get proprietary driver working on that crap at all. Now I probably should go buy recent PC with AMD graphics and start counter-bitching on how it beats ancient (and virtually unsupported) nvidia card, even with opensource drivers .

                      Comment

                      Working...
                      X