Announcement

Collapse
No announcement yet.

Lemote's Playing With Loongson Radeon UVD

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

  • Lemote's Playing With Loongson Radeon UVD

    Phoronix: Lemote's Playing With Loongson Radeon UVD

    Many Phoronix readers seem to be infatuated by the MIPS-based Loongson systems, while the hardware is hard to find -- and even if you manage to find it in western markets, it's very expensive. For those fond of the Loongson processors and happen to have a Radeon chipset, Lemote is playing around with Radeon UVD video acceleration...

    http://www.phoronix.com/vr.php?view=MTQ1NDk

  • #2
    Seems ironic that somebody would buy a Loongson and then pair it with something that uses proprietary firmware.

    Comment


    • #3
      Originally posted by LLStarks View Post
      Seems ironic that somebody would buy a Loongson and then pair it with something that uses proprietary firmware.
      Why ? The Loongson relies heavily on proprietary CPU microcode. You just don't see it because it's in ROM rather than RAM, and either there is no patch CAM (like Intel and AMD CPUs use for microcode updates) or information on it hasn't been published.

      Same idea as putting a piece of black tape over the "ENGINE" light on your car... no see, no problem
      Last edited by bridgman; 09-05-2013, 06:58 PM.

      Comment


      • #4
        Why does RMS approve of the Loongson then? /halfsarcasm

        Comment


        • #5
          I think RMS is surprisingly "open" towards firmware things. If it happens in the firmware it's ok.
          Though a free firmware would be the icing on the cake. For now it is already a good step in the right direction.
          Generally a porting and testing of Radeon and UVD capabilities to non-x86 structures is generally interesting. As mentioned, the not so overly powerful CPUs would benefit most from an ASIC for decoding videos.

          Comment


          • #6
            Originally posted by Adarion View Post
            I think RMS is surprisingly "open" towards firmware things. If it happens in the firmware it's ok.
            Though a free firmware would be the icing on the cake. For now it is already a good step in the right direction.
            Generally a porting and testing of Radeon and UVD capabilities to non-x86 structures is generally interesting. As mentioned, the not so overly powerful CPUs would benefit most from an ASIC for decoding videos.
            So does that require Coreboot, or does it require something like making your own CPUs from the OSS licensed SPARC designs?

            Comment


            • #7
              Originally posted by Adarion View Post
              I think RMS is surprisingly "open" towards firmware things. If it happens in the firmware it's ok.
              Though a free firmware would be the icing on the cake. For now it is already a good step in the right direction.
              Generally a porting and testing of Radeon and UVD capabilities to non-x86 structures is generally interesting. As mentioned, the not so overly powerful CPUs would benefit most from an ASIC for decoding videos.
              As long as the user can access, modify and run the software, i.e. the "users' freedom" [https://www.gnu.org/philosophy/free-sw.html], RMS will support it.

              Software can be open source but not free if it's never licensed by the author for distribution or even usage of any kind other then looking at the code. Similarly, hardware can be of open design but not free if it requires signing and the master key isn't distributed.

              So, since RMS did make a stance on Tivoisation, Affero and DRMed +/- signed bioses, I wouldn't say he's completely nonchalant about the hardware.

              Comment


              • #8
                Originally posted by c117152 View Post
                As long as the user can access, modify and run the software, i.e. the "users' freedom" [https://www.gnu.org/philosophy/free-sw.html], RMS will support it.
                RMS's stance on firmware depends on whether it can be updated/changed. If so, he considers it software, and that it should be free. If not (i.e. the firmware cannot be replaced) then he considers it hardware.

                Comment


                • #9
                  Originally posted by archibald View Post
                  RMS's stance on firmware depends on whether it can be updated/changed. If so, he considers it software, and that it should be free. If not (i.e. the firmware cannot be replaced) then he considers it hardware.
                  AFAIK it's a bit more nuanced than that -- for example if we had room in the VBIOS ROM image to store the microcode images so we could load them into the GPU during BIOS start-up rather than driver start-up that would be considered "better". In fairness, that may be because it moves the microcode images from an "otherwise free" driver to an "already non-free" VBIOS.

                  The microcode would still be upgradeable via VBIOS flash, but the hardware would be considered to be open-source-friendly by most people simply because the *driver* didn't have to hold its nose and load the microcode at start-up any more.

                  I do understand (and agree with) RMS's underlying position -- it's the real-world interpretation and decision-making based on that (necessarily) abstract position that I sometimes disagree with.

                  Comment


                  • #10
                    Originally posted by bridgman View Post
                    AFAIK it's a bit more nuanced than that -- for example if we had room in the VBIOS ROM image to store the microcode images so we could load them into the GPU during BIOS start-up rather than driver start-up that would be considered "better".
                    Why not make the non-free blobs, the VBIOS images and microcode images, free?
                    Last edited by rah_; 09-07-2013, 07:39 PM.

                    Comment

                    Working...
                    X