1. 35
  1. 14

    Panfrost is a really impressive and much needed driver and a valuable part of Mesa, and Alyssa’s work on it has been superb. This group solved one of the biggest problems between ARM and free software, and the results speak for themselves.

    1. 7

      I’m always impressed when someone succesfully reverse engineers something. Especially if it’s hardware.

      1. 4

        This makes me want to buy devices with Mali GPUs. Almost all the Pine devices use these rights? I’m sure the PostmarketOS team appreciates this as well.

        Most Android devices still use PowerVR chips though, don’t they? Are there open source drivers for those or are most of those still binary blobs?

        1. 4

          There are no FOSS drivers for powervr gpus. Imagination is notorious for largely ignoring Linux and any demands for one, which is extremely unfortunate given how many devices have these gpus.

        2. 4

          We need to stop writing drivers in such ad-hoc and low-level ways. This is the second large effort to reverse-engineer Mali, after Lima, and the primary artifacts produced by these projects are piles of C. Long-term maintainability can only come from higher-level descriptions of hardware capabilities.

          I’m a little frustrated at the tone of the article. I was required to write this sort of drivel when I was applying for grants, but by and large, the story of how I wrote a GPU driver is simple: I was angry because there wasn’t a production-quality driver, so I integrated many chunks of code and documentation from existing hard-working-but-exhausted hackers to make an iterative improvement. The ingredients here must have been quite similar. The deliberate sidelining of the Lima effort, in particular, seems rather rude; Panfrost doesn’t mark the first time that people have been upset with this ARM vendor refusing to release datasheets, and I think that most folks in the GPU-driver-authorship world are well aware of how the continual downplaying of Lima is part of the downward spiral that led to their project imploding.

          I don’t think I ever hid that r300, r500, and indeed radeonhd, from the same author as Lima, were all big influences on my work, and that honest acknowledgement of past work is the only way to avoid losing contributors in the future.

          1. 16

            I’m a little frustrated at the tone of the article. I was required to write this sort of drivel

            Is it not possible that the tone is a true, unforced reflection of the author’s enthusiasm? That’s how I read it. Maybe that’s just naive of me.

            1. 9

              Long-term maintainability can only come from higher-level descriptions of hardware capabilities.

              Is there any source you can provide indicating that this would actually work? From my understanding, creating meaningful abstractions over hardware is an extodinarily tough problem to solve. For example device trees work as a general purpose description of hardware, but still need a lot of kernel-space driver fluff to get anything talking correctly. What kind of higher level description do you think would work in this space?

              FYI: I have zero experience in graphics driver land so I don’t actually know anything about this domain. ¯\_(ツ)_/¯

              1. 1

                I read it not as “assembling a driver from common code components and interfaces in c”, but as “write a high-level description of the hardware and api, from which implementations in C or Rust or whatever can be generated”.

                But maybe we’re both reading it wrong :)

              2. 4

                Isn’t the primary artefact produced a set of instruction able to use a GPU? I would think it comes first, before the piles of C.

                Long-term maintainability can only come from higher-level descriptions of hardware capabilities.

                This seems like an extraordinary claim. “Can only come from” is a very strong statement.

                1. 4

                  GPU drivers are not required to have a single shape. Indeed, they usually have whatever shape is big and complex enough to fit their demanded API. The high-level understanding of GPUs is what allowed the entire Linux GPU driver tree to be refactored around a unified memory manager, and what allowed the VGA arbiter to be implemented. High-level descriptions, in particular datasheets, are already extremely valuable pieces of information which are essential for understanding what a driver is doing. At the same time, the modern GPU driver contains shader compilers, and those compilers are oriented around declarative APIs which deal with hardware features using high-level descriptions of capabilities.

                  Let me show you some C. This module does PCI ID analysis and looks up capabilities in a table, but it’s done imperatively. This module does very basic Gallium-to-r300 translation for state constants, but rather than a table or a relation, it is disgustingly open-coded. (I am allowed to insult my own code from a decade ago.) I won’t lie, Panfrost has tables, but this is, to me, only the slightest of signs of progress.

                  1. 3

                    Ah, I see what you mean.

                    Higher-level description means genericity, this can lead to bloated code trying to deal with the future, impairing the present. Trying to keep the proper balance of high-enough description and low-enough efficient description is a challenge.

                    Helping the maintenance effort by lending hands to refactor with a fresh mindset is my naive view of how to fight this, but I know this is falling prey to the rewrite fallacy.