Live data from Hacker News

Dissecting the Apple M1 GPU, Part III

rosenzweig.io

21–30 of 131 posts

Re: Dissecting the Apple M1 GPU, Part III

#21
This 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

Re: Dissecting the Apple M1 GPU, Part III

#22

Unrelated - All this work is done by an 18 year old. Absolutely incredible. Some people are simply built differently and admittedly, it makes me jealous.

Something 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

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

Re: Dissecting the Apple M1 GPU, Part III

#23

Unrelated - All this work is done by an 18 year old. Absolutely incredible. Some people are simply built differently and admittedly, it makes me jealous.

Wow. That's shocking.

I would like to know how it came to pass. Are her parents CS professors??

Re: Dissecting the Apple M1 GPU, Part III

#24

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.

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

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

Re: Dissecting the Apple M1 GPU, Part III

#26
post #16

Earlier quoted context omitted.

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

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.

Re: Dissecting the Apple M1 GPU, Part III

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

Re: Dissecting the Apple M1 GPU, Part III

#28

Unrelated - All this work is done by an 18 year old. Absolutely incredible. Some people are simply built differently and admittedly, it makes me jealous.

Something 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

[deleted]

Re: Dissecting the Apple M1 GPU, Part III

#29

Earlier quoted context omitted.

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

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

I find such lock-in to be hostile and not something to be excused with practicality. It's like saying ActiveX is practical, don't blame you know who for not supporting HTML, or something the like.

Re: Dissecting the Apple M1 GPU, Part III

#30
post #16
post #14

Earlier quoted context omitted.

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

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

They aren't "sabotaging" anything, they are making a perfectly normal design trade-off to implement some features in shaders instead of as fixed-function hardware. By your definition, every modern GPU built in the last decade is "sabotaging" OpenGL 1.x support, because fixed-function vertex and pixel processing hasn't been a thing in that long and it's all done in shaders now, even if you use the legacy APIs.

Alyssa clearly explained how avoiding fixed-function hardware means they can cram more shaders in which means they can increase performance; we have no idea, at this stage, whether this ends up being a net gain or a net loss for, say a Vulkan app. And we probably never will, because we don't have an "AGX-but-it-has-this-stuff-and-fewer-shader-cores-in-the-same-silicon-area" to compare with. And it doesn't matter. In the end OpenGL and Vulkan apps will run fine.

If we ever end up with empirical evidence that these design choices significantly hurt real-world OpenGL and Vulkan workloads in ways which cannot be worked around, you can start complaining about Apple. Until then, there is absolutely no indication that this will be a problem, never mind zero evidence for your conspiracy theory that it was a deliberate attempt by Apple to sabotage other APIs.

Post reply on HN