Latest Mesa AGX Work Points To More Apple M1/M2 Similarities With PowerVR Graphics
Thanks to the work by the Asahi Linux team and their work to reverse-engineering the Apple Silicon support for Linux, including their ambitions around open-source GPU driver support, there continues to be signs of the Apple graphics carrying some lineage back to PowerVR.
Catching my attention yesterday was this Mesa merge request: asahi: Rewrite state emit code using information from the Mesa PowerVR driver. Alyssa Rosenzweig who has been leading the work on the Apple open-source Mesa Gallium3D/OpenGL driver support explained in that MR:
Looking at PowerVR's PPP definitions in tree in Mesa (src/imagination/csbgen/), we find that AGX's "tagged" data structures are actually sequences of state items prefixed by a header specifying which state follows. Rather than hardcoding the sequences in which Apple's driver chooses to bundle state, we need the XML to be flexible enough to encode or decode any valid combination of state. That means reworking the XML. While doing so, we find a number of fields that are identical between RGX and AGX, and fix the names while at it (for example, the W Clamp floating point).
Names are from the PowerVR code in Mesa where sensible.
...
This insight is now possible since earlier this year Imagination published an open-source PowerVR Vulkan driver that was merged into mainline Mesa. (Imagination has also been working on an open-source DRM kernel graphics driver too for PowerVR Rogue.) It's from looking at that PowerVR Mesa code that the latest similarities to the Apple graphics hardware were discovered. Granted, it's of limited scope and still not clear to what extent ultimately that the Apple M1/M2 graphics are derived from PowerVR IP.
Currently running (Asahi) Linux on the Apple M1/M2 means LLVMpipe CPU-based software rasterization until the open-source GPU driver effort is further along both for the Mesa code and the developing kernel Direct Rendering Manager driver.
The Apple open-source graphics driver writing and engineering work remains ongoing. The latest expressed goal is hopefully seeing OpenGL 2.1 support by the end of 2022 though it may take more time than that before the DRM kernel driver is upstreamed in the mainline kernel.