Live data from Hacker News

Dissecting the Apple M1 GPU, Part III

rosenzweig.io

111–120 of 131 posts

Re: Dissecting the Apple M1 GPU, Part III

#111
post #27

I'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.

Apple's official graphics API is Metal. There is plenty of documentation for that. Apple considers Metal a commercial advantage over OpenGL / Vulkan. That is; they want developers to develop against Metal.

Re: Dissecting the Apple M1 GPU, Part III

#112

Earlier quoted context omitted.

Yep. 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 interfa…

> 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.

A network on chip protocol. Probably something ACE5 compatible, but Apple hasn't been public about those bits AFAIK.

Re: Dissecting the Apple M1 GPU, Part III

#114

Earlier quoted context omitted.

> 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.

A network on chip protocol. Probably something ACE5 compatible, but Apple hasn't been public about those bits AFAIK.

Yes. 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.

Re: Dissecting the Apple M1 GPU, Part III

#115

Earlier quoted context omitted.

Why should they support vulkan? what does apple get out of that apart from less well optimised compute and shader code, using more battery and producing more heat for the same output. (the reason it would be less well optimised is Vulkan is an API designed by a group to be the best compromise of many GPU vendors. If apple wanted to support vulkan without it being worse than Metal they would either need to add so many…

AGX (and SGX) aren't the only TBDR architecture. ARM Mali GPUs are also TBDR, are in plenty of phones, and run Vulkan just fine.

Adding to this, that whole render pass concept in the Vulkan API was the TBDR vendors being very active contributors to the API. More explicitly describing the data flow there allows TBDR arch's to work on multiple parts of modern render graphs simultaneously and keep their tiles filled with work in places where the other synchronization methods wouldn't (or would require the kind of divination on the part of the driver that Vulkan is trying to avoid).

Re: Dissecting the Apple M1 GPU, Part III

#116

Earlier quoted context omitted.

A network on chip protocol. Probably something ACE5 compatible, but Apple hasn't been public about those bits AFAIK.

Yes. 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…

Ah, 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.

Re: Dissecting the Apple M1 GPU, Part III

#117
post #105
post #87

Earlier quoted context omitted.

And keeps forgeting no one in the games industry, or console vendors for that matter, cares about his conspiracy theories.

Yup, I doubt he has experience working in the games industry. Many engines support multiple graphics APIs and there's often only 1-2 employees implementing/maintaining them so speaking about vendor lock-in is not a strong argument.

How is that a counter argument to anything? The need to support multiple APIs is not free. It's a tax on everything else.

Re: Dissecting the Apple M1 GPU, Part III

#118
post #104
post #73

Earlier quoted context omitted.

I'm not sure what Turing completeness argument has to do with anything. Turing machine is also Turing complete. You are going to make GPUs like that. We are talking about a simple fact - Apple don't care to collaborate on Vulkan, neither when designing their GPUs nor for their OS. I see no point to further argue about facts. And I see criticism of that as completely valid.

Supporting both Vulkan and Metal in a game engine is not a huge task. I work in the games industry, my job is to implement and maintain graphics backends to a renderer engine, so I can speak from experience.

Huge or not, duplication of effort is a tax. And no, it's not trivial as you claim. Especially when some engine wasn't designed from the ground up to address these differences.

Re: Dissecting the Apple M1 GPU, Part III

#119
post #117
post #105

Earlier quoted context omitted.

Yup, I doubt he has experience working in the games industry. Many engines support multiple graphics APIs and there's often only 1-2 employees implementing/maintaining them so speaking about vendor lock-in is not a strong argument.

How is that a counter argument to anything? The need to support multiple APIs is not free. It's a tax on everything else.

You're right that it's not free. But compared to the whole game engine codebase size the renderer backend is usually not big.

Re: Dissecting the Apple M1 GPU, Part III

#120
This 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.... : table 15, compute capabilities 7.0

Post reply on HN