Dissecting the Apple M1 GPU, Part III • Hacker News Board

Re: Dissecting the Apple M1 GPU, Part III

#121

Post by hishnash » Mon, Apr 19, 2021, 6:51 PM UTC

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.

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

Re: Dissecting the Apple M1 GPU, Part III

#122

Post by glial » Mon, Apr 19, 2021, 7:03 PM UTC

dev_tty01 wrote: post #51

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.

Apple is helping developers make the best software possible. They have a full suite of incredibly optimized and performant frameworks for compute, graphics, signal processing, machine learning, rendering, animation, networking, etc... That is all available via free download for writing MacOS and iOS apps. Remember, they are selling computers as a combination of hardware and software. They are not selling processors s…

That's helpful, thank you!

Re: Dissecting the Apple M1 GPU, Part III

#123

Post by thatfrenchguy » Mon, Apr 19, 2021, 7:09 PM UTC

irjustin wrote: post #13

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.

Being born in the San Francisco Bay Area and going to a "elite" public high school in a upper middle class suburb helps a little (and creates lots of other issues too :) ). Really tells you how many bright kids we're missing because they're not born in the right environment.

Re: Dissecting the Apple M1 GPU, Part III

#124

Post by astrange » Mon, Apr 19, 2021, 7:14 PM UTC

snovv_crash wrote: post #106

saagarjha wrote: post #76

Earlier quoted context omitted.

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

Abstractions are both leaky and expensive. There are a lot of things that could have much better performance if they had access to the lower level APIs.

Metal is a good fit for the M1 GPU (since the GPU was essentially designed to run it). There isn't a need for a lower level API than Metal.

Most people will not end up writing code in the optimal way though, since they also want to support discrete GPUs with their own VRAM and those have totally different memory management.

Re: Dissecting the Apple M1 GPU, Part III

#125

Post by devit » Mon, Apr 19, 2021, 7:25 PM UTC

account42 wrote: post #103

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.

Not really, none of the Vulkan drivers in Mesa are built on top of Gallium.

Yes, it works the other way: Zink is the Gallium->Vulkan translation layer, while the main Mesa code is effectively an OpenGL->Gallium translation layer.

Re: Dissecting the Apple M1 GPU, Part III

#126

Post by shmerl » Mon, Apr 19, 2021, 9:03 PM UTC

glaze wrote: post #119

shmerl wrote: post #117

Earlier quoted context omitted.

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.

It is a waste of time that could be avoided. And exists only becasue of insistence on lock-in by the likes of Apple.

Re: Dissecting the Apple M1 GPU, Part III

#127

Post by nextaccountic » Mon, Apr 19, 2021, 11:43 PM UTC

M277 wrote: post #79

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.

Here's a free book on physically based rendering

https://www.pbr-book.org/

Re: Dissecting the Apple M1 GPU, Part III

#128

Post by brokenmachine » Tue, Apr 20, 2021, 1:20 AM UTC

vetinari wrote: post #83

marcan_42 wrote: post #7

Earlier quoted context omitted.

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?

Please don't give Apple any more ideas.

Re: Dissecting the Apple M1 GPU, Part III

#129

Post by [deleted] » Thu, Apr 22, 2021, 6:48 AM UTC

vetinari wrote: post #83

marcan_42 wrote: post #7

Earlier quoted context omitted.

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?

[deleted]

Re: Dissecting the Apple M1 GPU, Part III

#130

Post by rjzzleep » Thu, Apr 22, 2021, 6:57 AM UTC

makomk wrote: post #84

marcan_42 wrote: post #7

Earlier quoted context omitted.

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

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