11 ms·
Dissecting the Apple M1 GPU, Part III
- ogre_codes 6y agoSo much for "It'll take years before we get the GPU working". Obviously this is far from a full implementation but seems like progress has been quick. Hopefully the power management stuff will be equally quick.
- citrusui 6y agoAlso curious how far progress is on reversing the Apple NVMe SSDs. Last I heard, Linux couldn't properly install itself on modern Macs, only do liveboot.
- marcan_42 6y agoApple NVMe SSDs have worked fine for years in mainline. This is a myth that won't die. The Linux driver required two new quirks (different queue entry size, and an issue with using multiple queues IIRC). That's it. That's all it was. On the M1, NVMe is not PCIe but rather a platform device, which requires abstracting out the bus from the driver (not hard); Arnd already has a prototype implementation of this and I'm going to work on it next.
- CyberRabbi 6y agoInteresting... what bus does it use if not PCIe? At the driver level I’m guessing it just dumps NVMe packets onto shared memory and twiddle some sort of M1-specific hardware register?
- Unklejoe 6y agoYep. Generally, "platform device" means that it's just a direct physical memory map. Honestly, from a driver perspective, that's sort of what you get with PCIe as well. The physical addresses is just dynamically determined during enumeration instead. Of course, there's some boilerplate core stuff to perform mappings and handle interrupts specific to PCI, but at the end of the day, you just get a memory mapped interface. This is unlike something like USB where you need to deal with packets directly.
- CyberRabbi 6y ago> Honestly, from a driver perspective, that's sort of what you get with PCIe as well. Right, I was sort of alluding to that. I’m really just curious how the NVMe packets physically make their way to the SSD.
- monocasa 6y agoA network on chip protocol. Probably something ACE5 compatible, but Apple hasn't been public about those bits AFAIK.
- CyberRabbi 6y agoYes. It seems there is no distinct SSD on the system. The M1 SoC seems to communicate with raw flash. I tried looking up the datasheet for the flash ICs (SDRGJHI4) to see if they would leave any clues but it’s not publicly available AFAICT. This is rather interesting that Apple has custom or semi-custom IP that manages raw flash as part of their SoC. That does seem like a natural outgrowth of shipping iPhones for so many years. The specific logical signals between separate IPs on the SoC is slightly less interesting to me then. It’s likely something similar to ACE5, like you said, for sharing the memory bus.
- monocasa 6y agoAh, yeah, it's been integrated on their SoCs for quite a while. Word on the street is that it's the (internal only successor to the) Anobit IP they bought back in 2011 with an ARM core strapped to the front for the NVMe interface.
- vetinari 6y agoMaybe I'm remembering it wrong, but wasn't there an issue with a secret handshake, and if the system didn't do it in a certain time after the boot, the drive disappeared? I.e. some kind of T2-based security?
- brokenmachine 6y agoPlease don't give Apple any more ideas.
- deleted 6y ago[deleted]
- makomk 6y agoAs I understand it, Apple's NVMe were pretty wildly non-standards-compliant - they assume that tags are allocated to commands in the same way as Apple's driver does, including crashing if you use the same tag at the same time in both the admin and IO queues and only accepting a limited range of tags, and as you say they use a totally different queue entry size from the one required by the standard. Also, apparently interrupts didn't work properly or something. Oh, and it looks like the fixes only made it into mainline Linux in 5.4, less than a year and a half ago, and from there it would've taken some time to reach distros...
- rjzzleep 6y agoThere's also applespi for their input drivers. I think with macbooks you never know what protocol apple will change the next iteration. Not something I would use as a daily driver(running linux) anymore.
- jacquesm 6y agoNonsense. Last you heard was 5 years ago or so. And even then it could be done, just a bit more work rather than a default install.
- lights0123 6y agoThis is great work—I'm glad to see this being tackled with such speed. From the Phoronix comments on this post[0]: > I have an idea. Why not support exclusively Vulkan, and then do the rest using Zink (that keeps getting faster and faster)? > This way you could finish the driver in one year or two. (For context: Zink is an OpenGL to Vulkan translator integrated into Mesa) I had the same thought in my mind—Zink is 95% the speed of Intel's OpenGL driver[1], so why not completely ignore anything but Vulkan? On the Windows side, dxvk (DirectX to Vulkan) already is much faster (in most cases) than Microsoft's DX9-11 implementation, so it's completely feasible that Zink could become faster than most vendors' OpenGL implementation. I have no knowledge of low-level graphics, so I don't know the ease of implementing the two APIs. I could envision, however, that because this GPU was never designed for OpenGL, there may be some small optimizations that could be made if Vulkan was skipped. [0]: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1251581-more-progress-is-made-understanding-apple-s-m1-gpu-working-towards-an-open-driver?p=1251586#post1251586 https://www.phoronix.com/forums/forum/phoronix/latest-phoron... [1]: https://www.phoronix.com/scan.php?page=news_item&px=Zink-95-OpenGL-Performance https://www.phoronix.com/scan.php?page=news_item&px=Zink-95-...
- stefan_ 6y agoThis is very much abstracted away in Mesa already, particularly if you use NIR and your driver lives in Gallium.
- quotemstr 6y ago> our driver should follow Linux’s best practices like upstream development. That includes using the New Intermediate Representation (NIR) in Mesa, the home for open source graphics drivers. NIR is a lightweight library for shader compilers, with a GLSL frontend I remember when building everything on LLVM bytecode was best practice. It wouldn't be the Linux ecosystem without continual reinvention of the wheel, would it?
- dralley 6y agoThe blog post she links to explains exactly why it's not a "reinvention of the wheel".
- shmerl 6y agoVery interesting analysis! > Simply put – Apple doesn’t need to care about Vulkan or OpenGL performance. Apple being Apple. They just can't play nice with standards.
- zlsa 6y agoThis is the advantage of building your hardware and your software under the same roof. You can make optimizations (such as not including hardware that makes OpenGL faster, but doesn't impact Metal nearly as much.) The "standard" here is the Metal API, not the GPU hardware.
- shmerl 6y agoI don't think it's an advantage to sabotage the adoption of common API like Vulkan. It holds the progress back and I totally blame Apple for pointless NIH and lack of collaboration here. Apple are doing it out of rather sickening lock-in culture in the company and Metal is far from the only example like that.
- spacedcowboy 6y agoApple are doing it because there’s no benefit to them in doing it the way that you want them to. Apple Pay the piper, and Apple call the tune. Whether you like it or not is immaterial.
- Apocryphon 6y agoApple has every right to do that as they control their stack. And people who favor FOSS projects have every right to criticize Apple for exercising their control in a way that adversely impacts FOSS.
- macintux 6y agoSure, but comments like this attribute hostility instead of simple practicality. > ...pointless NIH and lack of collaboration here. > Apple are doing it out of rather sickening lock-in culture in the company and Metal is far from the only example like that.
- iso8859-1 6y agoIs Collabora paying Alyssa Rosenzweig for this work?
- lyssa 6y agoNo, this is purely a hobby project undertaken in my spare time. (The email addresses on the git commits are force-of-habit, apologies for the confusion.)
- irjustin 6y agoUnrelated - All this work is done by an 18 year old. Absolutely incredible. Some people are simply built differently and admittedly, it makes me jealous.
- conradev 6y agoSomething about this comment on each of Alyssa’s posts[1] rubs me the wrong way. I find her work remarkable even without the context of her age. Why mention it? Highlighting it is almost diminutive, even though I know that the comment is not intended to be that way. [1] https://news.ycombinator.com/item?id=25875552 https://news.ycombinator.com/item?id=25875552
- hombre_fatal 6y agoBecause it’s interesting and intent matters. Maybe you’re being too sensitive, and too vicariously sensitive, about a fact that’s obviously stand-out interesting.
- dylan604 6y agoYes, I am very impressed with the fact that the person with this level of skill and understanding of the task at hand is ONLY 18. How could pointing out the impressively young age be considered bad? The percentage of young people that have this level of skill in whatever aspect is very small and is a valid thing to recognize.
- deleted 6y ago[deleted]
- wwweston 6y agoPeople commenting on this are more likely thinking "holy crap what was I doing at 18? Nothing this impressive." You're right, though, people are in fact capable of strong work at many ages, including their teens, and it can be good to remember that.
- deleted 6y ago
- vesrah 6y agoPrevious part discussions, for everyone else that was interested: Part 1: https://news.ycombinator.com/item?id=25673631 https://news.ycombinator.com/item?id=25673631 Part 2: https://news.ycombinator.com/item?id=25873887 https://news.ycombinator.com/item?id=25873887
- raphlinus 6y agoThis is top-notch and very impressive work. I'm currently in the middle of tuning performance of piet-gpu for the Pixel 4[1], and I find myself relying on similar open resources from the Freedreno project. When the time comes to get this running efficiently on M1, having detailed knowledge of the hardware will be similarly invaluable - just the info on registers and occupancy is an important start. Is there a way to support the work? [1]: https://github.com/linebender/piet-gpu/issues/83 https://github.com/linebender/piet-gpu/issues/83
- marcan_42 6y agoAlyssa isn't personally taking donations for her work on this project, but she suggests you donate to the Autistic Self Advocacy Network or the Software Freedom Conservancy instead :)
- raphlinus 6y agoThanks. I've made a substantial donation to ASAN listed as being in her honor. I'm also a fan of SFC and plan to continue to support them.
- deleted 6y ago[deleted]
- glial 6y agoI'm not really a developer so maybe I'm just not understanding something, but why in the world isn't Apple making it easier for people to optimize for the M1? I would think it's in their best interest to help developers make the best software possible, by sharing information about how to leverage the architecture. It's bizarre to me that the best sources of information are posts like this.
- dylan604 6y agoWhy do you think they are not? They are helping developers developing for the macOS platform that they own,develop,support. They are not responsible for 3rd part OSes and the development on those platforms. Why would you expect anything else based on their history and track record for closed/walled ecosystems?
- judge2020 6y agoBelieve it or not, you're just purchasing rare earth materials packed very tightly into a nice box when you buy a Mac or an iPhone. The operating system is paid for on the backend by developers giving up 30% of revenue that goes through the App Store. The M1 is turning the Mac into an iPhone in exchange for an extremely fast processor and insane battery life, so they're not interested in helping you bypass the technical challenges of running other operating systems on their hardware (much like how they don't help you jailbreak iOS in order to help you install Cydia or third-party app stores).
- marcan_42 6y agoYou are drawing a false equivalency between the Mac and iPhones. iOS devices are deliberately locked so that running your own low-level software on them is not supposed to be possible, and requires breaking Apple's security. If they make no mistakes, doing it is completely impractical (the cost of an attack outside their attack model is greater than the price of the device). macOS devices are not, and Apple invested significant development effort into allowing third-party kernels on M1 Macs. The situation is very different. They are not actively supporting the development of third-party OSes, but they are actively supporting their existence. They built an entire boot policy system to allow not just this, but insecure/non-Apple-signed OSes to coexist and dual-boot on the same device next to a full-secure blessed macOS with all of their DRM stuff enabled, which is something not even open Android devices do. You can triple-boot a macOS capable of running iOS apps (only possible with secureboot enabled), a macOS running unsigned kernel modules or even your own XNU kernel build, and Linux on the same M1 Mac.
- xbar 6y agoWell written. Well done.
- aorth 6y agoI came to say the same thing. Fantastic technical writing—as if doing the reverse engineering and novel development wasn't enough! Thank you, Alyssa, if you're reading, for this gift to the community. <3
- WhyNotHugo 6y agoI’m very amused by the fact that this hardwares does not have hardware for some specialised operations that competitors do. From the article, it would seem that compensating via software was fine (performance wise). Apple’s approach seems to be seems to break the norm in fields where the norm has proven to be unnecessary complexity. Which open tip room for just more raw performance.
- hrydgard 6y agoAMD has removed exactly the same hardware, and NVIDIA doesn't benefit much from the specialized vertex fetch hardware anymore, even specialized uniform buffer stuff is getting close to marginal benefit. Hardly unique to Apple.
- kevingadd 6y agoLots of what they do on the M1 is stuff that PowerVR was doing before (and apple's older GPUs were based on PowerVR's via a licensing deal). There are other vendors who have also ditched some of this stuff. It's a smart move for Apple to double down on pruning hw features you don't think you need, but sadly you can only go all-in on it if you control the entire ecosystem.
- hishnash 6y agoAs described in the article by not having fixed function units apple can put more regular floating point math units. These units can be used in many, for example when doing compute tasks or when doing 3d tasks that do not make use of those very focused use cases. In the end if it is a big perf hit for those approaches devs will just use different solutions as they need to developer explicitly for metal anyway.
- gfxgirl 6y agoThat's very exciting! A nit: > For example, I have not encountered hardware for reading vertex attributes or uniform buffer objects. The OpenGL and Vulkan specifications assume dedicated hardware for each, so what’s the catch? That is not my understanding of those specs (as someone that's written graphics drivers). Uniform Buffer Objects are not a "hardware" thing. They're just a way to communicate uniforms faster than one uniform per API call. What happens on the backend is undefined by those specs and is not remotely tied to some hardware implementation. Vertex Attributes might have been a hardware thing long ago but. I'm pretty sure there are older references but this 9yr old 2012 book already talks about GPUs that don't have hardware based vertex attributes. https://xeolabs.com/pdfs/OpenGLInsights.pdf https://xeolabs.com/pdfs/OpenGLInsights.pdf chapter 21
- M277 6y agoThis is completely off topic, I am very sorry, but given your comment and your username -- are there any learning resources you would particularly recommend for graphics programming? I have collected a few already (however they are all beginner level), and was wondering if there are hidden gems I missed.
- majjam 6y agonot op, but here are a few ive collected: https://web.archive.org/web/20130517222528/http://www.arcsynthesis.org/gltut/ https://web.archive.org/web/20130517222528/http://www.arcsyn... https://news.ycombinator.com/item?id=26017086 https://news.ycombinator.com/item?id=26017086 https://news.ycombinator.com/item?id=18840859 https://news.ycombinator.com/item?id=18840859
- dlivingston 6y agoAn excellent starting point for anyone interested in low-level graphics programming is Sokolov’s tinyraytracer [0]. It’s also a great way to learn a new language (work through the code while porting it to $DIFFERENT_LANGUAGE). [0]: https://github.com/ssloy/tinyraytracer https://github.com/ssloy/tinyraytracer
- nextaccountic 6y ago
- anentropic 6y ago> If changing fixed-function attribute state can affect the shader, the compiler could be invoked at inopportune times during random OpenGL calls. Here, Apple has another trick: Metal requires the layout of vertex attributes to be specified when the pipeline is created, allowing the compiler to specialize formats at no additional cost. The OpenGL driver pays the price of the design decision; Metal is exempt from shader recompile tax. I've just started playing with OpenGL recently and I don't know what "changing fixed-function attribute state can affect the shader" means. Can anyone give an example of what kind of operations in the shader code might cause these unnecessary recompiles?
- gmueckl 6y agoOpenGL has a model of the hardware pipeline that is quite old. A lot of things that are expressed as OpenGL state are now actually implemented in software as part of the final compiled shader on the GPU. For example, GLSL code does not define the data format in which vertex attributes are stored in their buffers. This is set when providing the attribute pointers. The driver then has to put an appropriate decoding sequence for the buffer into the shader machine code. Similar things happen for fragment shader outputs and blending these days. This can lead to situations where you're in the middle of a frame and perform a state change that pulls a rug from under the shader instances that that driver created for you so far. So the driver has to go off and rewrite and reupload shader code for you before the actually requested command can be run. More modern interfaces now force you to clump a lot of state together into pretty big immutable state objects (e.g. pipeline objects) so that the driver has to deal with fewer surprises at inopportune times.
- anentropic 6y agoThanks for the more elaborated explanation. I think I understand now. Ideally the GLSL shader code is compiled once and sent to the GPU and used as-is to render many frames. But if you use the stateful OpenGL APIs to send instructions from the CPU side during rendering you can invalidate the shader code that was compiled. It had not occurred to me because the library I am using makes it difficult to do that, encouraging setting the state up front and running the shaders against the buffers as a single "render" call.
- mrpippy 6y agoIn case anyone isn’t aware, on Apple Silicon macOS (and recent iOS I believe), OpenGL is implemented on top of Metal.
- mrweasel 6y agoThere has to be some Apple engineers reading this wondering which feature she’ll find next, and hopefully with a big smile when she get something right.
- Firadeoclus 6y agoThis is some great work! One point I disagree with: >What’s less obvious is that we can infer the size of the machine’s register file. On one hand, if 256 registers are used, the machine can still support 384 threads, so the register file must be at least 256 half-words * 2 bytes per half-word * 384 threads = 192 KiB large. Likewise, to support 1024 threads at 104 registers requires at least 104 * 2 * 1024 = 208 KiB. If the file were any bigger, we would expect more threads to be possible at higher pressure, so we guess each threadgroup has exactly 208 KiB in its register file. >The story does not end there. From Apple’s public specifications, the M1 GPU supports 24576 = 1024 * 24 simultaneous threads. Since the table shows a maximum of 1024 threads per threadgroup, we infer 24 threadgroups may execute in parallel across the chip, each with its own register file. Putting it together, the GPU has 208 KiB * 24 = 4.875 MiB of register file! This size puts it in league with desktop GPUs. I don't think this is quite right. To compare it to Nvidia GPUs, for example, a Volta V100 has 80 Shader Multiprocessors (SM) each having a 256 KiB register file (65536 32-bit wide registers, [1]). The maximum number of resident threads per SM is 2048, the maximum number of threads per thread block is 1024. While a single thread block _can_ use the entire register file (64 registers per thread * 1024 threads per block), this is rare, and it is then no longer possible to reach the maximum number of resident threads. To reach 2048 threads on an SM requires the threads to use no more than 32 registers on average, and two or more thread blocks to share the SM's register file. Similarly, the M1 GPU may support 24576 simultaneous threads, yet there is no guarantee it can do so while each thread uses 104 registers. [1] https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#compute-capabilities https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.... : table 15, compute capabilities 7.0