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

101–110 of 131 posts

Re: Dissecting the Apple M1 GPU, Part III

#101

Post by dlivingston »

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.

An excellent starting point for anyone interested in low-level graphics programming is Sokolov’s tinyraytracer [0]. It’s also a great way to learn a new language (work through the code while porting it to $DIFFERENT_LANGUAGE).

[0]: https://github.com/ssloy/tinyraytracer

Re: Dissecting the Apple M1 GPU, Part III

#102

Post by shmerl »

pjmlp wrote: post #87
BolandJ wrote: post #45

Earlier quoted context omitted.

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.

Lock-in proponents bring their kool aid. Not impressed. Gaming industry is pretty messed up when it comes to lock-in. Everyone is paying this tax.

Re: Dissecting the Apple M1 GPU, Part III

#103

Post by account42 »

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.

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

Re: Dissecting the Apple M1 GPU, Part III

#104

Post by glaze »

shmerl wrote: post #73
marcan_42 wrote: post #65

Earlier quoted context omitted.

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.

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.

Re: Dissecting the Apple M1 GPU, Part III

#105

Post by glaze »

pjmlp wrote: post #87
BolandJ wrote: post #45

Earlier quoted context omitted.

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.

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.

Re: Dissecting the Apple M1 GPU, Part III

#106

Post by snovv_crash »

saagarjha wrote: post #76
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 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.

Re: Dissecting the Apple M1 GPU, Part III

#107

Post by raphlinus »

marcan_42 wrote: post #40
raphlinus wrote: post #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…

Alyssa isn't personally taking donations for her work on this project, but she suggests you donate to the Autistic Self Advocacy Network or the Software Freedom Conservancy instead :)

Thanks. I've made a substantial donation to ASAN listed as being in her honor. I'm also a fan of SFC and plan to continue to support them.

Re: Dissecting the Apple M1 GPU, Part III

#108

Post by pjmlp »

shmerl wrote: post #102
pjmlp wrote: 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.

Lock-in proponents bring their kool aid. Not impressed. Gaming industry is pretty messed up when it comes to lock-in. Everyone is paying this tax.

I am aware of my limitations as human being in this society, speak from actual work experience, and will use any tooling that I rant about when it is on the best interests of the customers, regardless of my personal agenda.

Something to think about, or maybe not.

Re: Dissecting the Apple M1 GPU, Part III

#109

Post by CyberRabbi »

Unklejoe wrote: post #98
CyberRabbi wrote: post #72

Earlier quoted context omitted.

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?

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.

Re: Dissecting the Apple M1 GPU, Part III

#110

Post by pjmlp »

marcan_42 wrote: post #68
hishnash wrote: post #60

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.

Android developers wouldn't say phones run Vulkan just fine, unless when talking about Samsung and Google devices.

Hence why Google made it a compulsory API on Android 10, to try to tame OEMs in improving their Vulkan story, and yet it is a plain Vulkan 1.1.

Post reply on HN