Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dissecting the Apple M1 GPU, Part III

rosenzweig.io

Post reply on HN
Print view View original

81–90 of 131 posts

Re: Dissecting the Apple M1 GPU, Part III

#81

Post by Rhedox »

judge2020 wrote: post #42
glial wrote: 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.

Believe 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 techni…

TBF they explicitly implemented a way to boot other kernels.

'turning the Mac into an iPhone' suggest they are locking it down, which isn't entirely true.

They could do more to help driver development though.

Re: Dissecting the Apple M1 GPU, Part III

#82

Post by vetinari »

e_proxus wrote: post #74
stefan_ wrote: post #8

Earlier quoted context omitted.

This is very much abstracted away in Mesa already, particularly if you use NIR and your driver lives in Gallium.

Does that imply a performance hit, or is it roughly equivalent to targeting Vulkan “directly”?

Think of it as HAL, on top of which state trackers implement their chosen APIs. OpenGL is one of them, there's also Gallium Nine that implement DirectX 9.

Re: Dissecting the Apple M1 GPU, Part III

#83

Post by vetinari »

marcan_42 wrote: post #7
_qxjp wrote: post #6

Earlier quoted context omitted.

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

Apple 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 g…

Maybe 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?

Re: Dissecting the Apple M1 GPU, Part III

#84

Post by makomk »

marcan_42 wrote: post #7
_qxjp wrote: post #6

Earlier quoted context omitted.

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

Apple 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 g…

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

Re: Dissecting the Apple M1 GPU, Part III

#85

Post by [deleted] »

saagarjha wrote: post #80
marcan_42 wrote: post #58

Earlier quoted context omitted.

The Secure Enclave Processor (SEP) is the part that you cannot run your own code on, and it knows what state the device was booted in. However, it doesn't get in the way of normal OS usage. It also serves as a secure element, e.g. we can use it to store SSH keys and authorize use with Touch ID, or to secure a password store, or as a U2F token, just like macOS does. This is much better than most unlocked Android devic…

> On the M1, the main CPU is owned entirely by the OS, and doesn't even implement EL3 (only EL2, the VM hypervisor level, which we boot in - we already have the Linux KVM hypervisor working on the M1), making it a much more user-controlled execution environment than almost all x86 machines and Android phones. I agree that Apple probably has less random junk running at exceptionally high privilege levels, but your arg…

[deleted]

Re: Dissecting the Apple M1 GPU, Part III

#86

Post by gmueckl »

anentropic wrote: post #77

> 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 shad…

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

Re: Dissecting the Apple M1 GPU, Part III

#87

Post by pjmlp »

BolandJ wrote: post #45
marcan_42 wrote: post #34

Earlier quoted context omitted.

You're talking about macOS. We're talking about AGX2. If you want to complain about Apple's API support in macOS, a discussion about AGX2 support for Linux is not the right venue. I am, quite honestly, getting very tired of all the off-topic gratuitous Apple bashing in articles about our Linux porting project.

Shmerl pops up on every thread mentioning Vulkan/Apple spouting conspiracy theory nonsense that every design decision is some kind of evil plan to screw over open standards. Ignore him. Keep up the great work, plenty of people really appreciate it.

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

Re: Dissecting the Apple M1 GPU, Part III

#88

Post by pjmlp »

shmerl wrote: post #26
spacedcowboy wrote: post #18

Earlier quoted context omitted.

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

They sure think lock-in is a big benefit for them, that's part of their corporate culture that I was talking about. I'm just saying that it's nasty, bad for progress and it's the wrong way to do things.

    I3DRender render = Engine::GetRender("render-name");
    render->DrawMesh(scene);
So hard, I can't believe how I can manage.

Re: Dissecting the Apple M1 GPU, Part III

#89

Post by anentropic »

gmueckl wrote: post #86
anentropic wrote: post #77

> 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 shad…

OpenGL 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 seq…

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

Re: Dissecting the Apple M1 GPU, Part III

#90

Post by kevingadd »

WhyNotHugo wrote: post #61

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

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

Post reply on HN