Announcement

Collapse
No announcement yet.

Arm Lands Mali Gen10 "Panthor" Firmware Blob In Linux-Firmware.Git

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

  • Arm Lands Mali Gen10 "Panthor" Firmware Blob In Linux-Firmware.Git

    Phoronix: Arm Lands Mali Gen10 "Panthor" Firmware Blob In Linux-Firmware.Git

    As the first of Arm Mali firmware to be added to the linux-firmware.git repository, the Gen10 Mali "Panthor" firmware has been added as part of the effort on the new open-source Panthor DRM kernel driver currently working its way upstream...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Michael

    Typo

    "In particular, with Panthor is now a Command Stream Frontend"

    maybe "In particular, Panthor has a Command Stream Frontend"​

    Comment


    • #3
      Michael

      This is freaking awesome, please post about it: https://cyberus-technology.de/articl...public-release

      Comment


      • #4
        Originally posted by avis View Post
        Michael

        This is freaking awesome, please post about it: https://cyberus-technology.de/articl...public-release
        Nice. I don't use VirtualBox much these days, but having a KVM backend and not needing an out of tree kernel module will be great. Sometimes people need a VM that can work across Linux / Windows / macOS hosts.

        Comment


        • #5
          I am looking forward to the Rock5 (based on the rk3588 SoC with the Mali graphics) finally becoming useable on an upstream distro. The graphics and HDMI were the last major blockers for me (shame it will miss the spring release for Fedora - it is likely to be based on 6.8). Any other missing features I can live without.
          Last edited by You-; 08 February 2024, 02:57 PM.

          Comment


          • #6
            I am not sure if this is good or bad as Arm have been working in conjunction with https://www.collabora.com/news-and-b...-panfrost.html
            I expected a full blown opensource driver and know wondering does this provide Mesa Vulkan and sit with a Mesa install or is this something else?

            Comment


            • #7
              Originally posted by StuartIanNaylor View Post
              I am not sure if this is good or bad as Arm have been working in conjunction with https://www.collabora.com/news-and-b...-panfrost.html
              I expected a full blown opensource driver and know wondering does this provide Mesa Vulkan and sit with a Mesa install or is this something else?
              This is a DRM kernel driver, so completely orthogonal to Mesa; it’s the part that runs in kernelspace and Mesa (including Panfrost and PanVK) is the part that runs in userspace. The two have to know how to talk to each other (“uABI”) but that’s it; they’re separate pieces of software doing separate jobs.

              Comment


              • #8
                Huh, there's a EULA... not that it really matters, since no-one is going to actually read it.

                It would be useful to have a Free Software replacement firmware, because that would allow (alongside improved debugging, ability for bug fixes, and being able to support new capabilities) all sorts of interesting ways of looking inside the GPU, by uploading user programs at runtime to do things like track performance counters or interact with shaders.

                It seems a pity to waste such a capable 1GHz microcontroller, especially since it supports two privilege levels so user programs can be sandboxed.

                Comment


                • #9
                  Originally posted by archsway View Post
                  Huh, there's a EULA... not that it really matters, since no-one is going to actually read it.

                  It would be useful to have a Free Software replacement firmware, because that would allow (alongside improved debugging, ability for bug fixes, and being able to support new capabilities) all sorts of interesting ways of looking inside the GPU, by uploading user programs at runtime to do things like track performance counters or interact with shaders.

                  It seems a pity to waste such a capable 1GHz microcontroller, especially since it supports two privilege levels so user programs can be sandboxed.
                  I still don't understand ARM's corporate mentality. They seem to be so vehemently opposed to open source internally, despite the fact that the entire ARM ecosystem makes huge money out of Linux on their CPUs and GPUs.

                  Reading through posts like these...
                  Today, we're pleased to announce an extension of our collaboration with Arm, providing more surety and capability for Panfrost.


                  ...it all seems so backwards. There's huge efforts there by free software developers to go and reverse engineer things, only to then get the interest of ARM and have them further fund the efforts years later when they realise that this strange Linux thing exists. Would just releasing open specifications and open firmware from the outset save everyone years of time and millions of dollars doing it all the hard way?

                  Maybe I'm missing something. But this all just feels like 1990s level corporate misunderstanding of open source, and fear that it will somehow leak all your IP and prevent you making profit. And I thought we got over that at the turn of the millennium when all the current-day trillion dollar companies leveraged open source to make record breaking profits and post record breaking market caps. The world worked out that "open source" doesn't mean "anti-business", and the two ideas can co-exist happily.

                  Comment


                  • #10
                    Originally posted by elvis View Post
                    ...it all seems so backwards. There's huge efforts there by free software developers to go and reverse engineer things, only to then get the interest of ARM and have them further fund the efforts years later when they realise that this strange Linux thing exists. Would just releasing open specifications and open firmware from the outset save everyone years of time and millions of dollars doing it all the hard way?
                    Yes, it's not exactly proactive.

                    I guess maybe they are wait until the point where it doesn't really matter if they pass on some documentation because it's already mostly figured out.

                    Maybe Arm want to force device makers to license their blob driver, because waiting for a reverse-engineered replacement would take too long for a new GPU.

                    Maybe I'm missing something. But this all just feels like 1990s level corporate misunderstanding of open source, and fear that it will somehow leak all your IP and prevent you making profit. And I thought we got over that at the turn of the millennium when all the current-day trillion dollar companies leveraged open source to make record breaking profits and post record breaking market caps. The world worked out that "open source" doesn't mean "anti-business", and the two ideas can co-exist happily.
                    I notice that Rockchip's RGA3 has an "FBCD mode" that seems very much like Arm's (assumedly patented) AFBC in everything but name… But that feels odd, because if it was an unlicensed rip-off (or copy-and-paste from an AFBC codec somewhere else in the SoC) then Arm could just threaten to revoke Rockchip's license to their cores…

                    But surely most of the other IP in their GPUs would be in parts of hardware that aren't visible from software?

                    Comment

                    Working...
                    X