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

71–80 of 131 posts

Re: Dissecting the Apple M1 GPU, Part III

#71

Post by CyberRabbi »

marcan_42 wrote: post #70
CyberRabbi wrote: post #66

Earlier quoted context omitted.

Excellent write up. Thank you > iOS apps should be FairPlay encrypted AIUI, and presumably that goes through the SEP to only authorize decryption when booted in secure mode. Wow is it really possible that iOS apps are encrypted with a private key that is stored within all SEP devices and it hasn’t been cracked yet? If so that’s incredible and would explain why a workaround for using iOS apps with SIP disabled hasn’t…

This is the standard content protection mechanism on pretty much every DRM download/streaming/whatever system in the world. Each app/movie/whatever is encrypted with a per-app key (so you can stick it in a CDN). Then each device has some kind of private certificate or key. When the user buys/rents content, you send the content key encrypted with the device key. This is how pretty much every game console, streaming se…

> There are global keys, which are used for system software. iOS used to be encrypted as a whole

Ah yes indeed. I remember this from my jail breaking days. Just never was aware that app packages were encrypted.

Re: Dissecting the Apple M1 GPU, Part III

#72

Post by CyberRabbi »

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…

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

Re: Dissecting the Apple M1 GPU, Part III

#73

Post by shmerl »

marcan_42 wrote: post #65
shmerl wrote: post #54

Earlier quoted context omitted.

The article points out that their API matches the hardware and it's the only API they care about: > Their only properly supported API is their own Metal, which they may shape to fit the hardware rather than contorting the hardware to match the API. Meaning they don't care to take Vulkan into account when making their GPU. If it would happen to work well - good. If not - tough luck. So it's not just about macOS, it's…

Your argument is equivalent to criticizing ARM for putting in instructions to optimize Javascript into their architecture, as if that "sabotages" every other programming language. Or Intel for putting in instructions to optimize AES into their architecture, as if that "sabotages" Salsa20. It doesn't make any sense. Of course Apple optimizes Metal for their GPUs and their GPUs for Metal. None of that is hostile toward…

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.

Re: Dissecting the Apple M1 GPU, Part III

#74

Post by e_proxus »

stefan_ wrote: post #8
lights0123 wrote: post #3

This 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%…

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

Re: Dissecting the Apple M1 GPU, Part III

#75

Post by hrydgard »

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.

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

Re: Dissecting the Apple M1 GPU, Part III

#76

Post by saagarjha »

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.

In a few months Apple is going to release a successor to the M1 processor, and then maybe in a year or two another revision after that. Apple would like your code to be optimized for that processor as well, in addition to the M1. The way Apple does this is by wrapping their hardware in a high-level API that knows how to use the hardware it is running on, rather than exposing architectural details and having developers hardcode assumptions into their code until the end of time.

Re: Dissecting the Apple M1 GPU, Part III

#77

Post by anentropic »

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

Re: Dissecting the Apple M1 GPU, Part III

#78

Post by coldtea »

refulgentis wrote: post #49
marcan_42 wrote: post #43

Earlier quoted context omitted.

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

This pales in comparison to the rhetoric when OS X came out - you see that rhetoric survive today at opensource.apple.com, it's there, just, not in the spirit of the freedom that was promised.

Since then, RedHat has been turned into a profit machine and is now owned by IBM and SUN has folded...

Re: Dissecting the Apple M1 GPU, Part III

#79

Post by M277 »

gfxgirl wrote: post #69

That'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 th…

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

Re: Dissecting the Apple M1 GPU, Part III

#80

Post by saagarjha »

marcan_42 wrote: post #58
CyberRabbi wrote: post #53

Earlier quoted context omitted.

I acknowledge that it’s possible to run unsigned code at “ring 0” on M1 MacBooks but the existence of the DRM restrictions leads me to believe that certain DRM-relevant hardware is not accessible unless a signed OS is running. I’m not exactly sure how the attestation works from software to hardware but I have to guess that it exists, otherwise it would be relatively trivial to load a kext that enables 4K DRM with SIP…

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 argument is not convincing to me. We have control of the exception levels, which we can check the existence of from the public ISA, but that doesn't mean Apple hasn't added any new stuff elsewhere that can touch the CPU in ways that are not yet known (and, to be entirely fair: I don't even think we know we have control of the exception levels. We have EL2 execution, but GXF exists, and even if we know how to navigate through it who can really say for sure what it does to the processor state?). I think the right argument here is "Apple has no reason to add stupidity to their processor (and many reasons to not add this garbage) so it likely does not exist" and leave it at that, rather than trying to draw up technical reasons why it seems more open.

Post reply on HN