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

91–100 of 131 posts

Re: Dissecting the Apple M1 GPU, Part III

#91

Post by majjam »

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.

not op, but here are a few ive collected:

https://web.archive.org/web/20130517222528/http://www.arcsyn...

https://news.ycombinator.com/item?id=26017086

https://news.ycombinator.com/item?id=18840859

Re: Dissecting the Apple M1 GPU, Part III

#92

Post by [deleted] »

anentropic wrote: post #89
gmueckl wrote: post #86

Earlier quoted context omitted.

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, encourag…

[deleted]

Re: Dissecting the Apple M1 GPU, Part III

#93

Post by thechao »

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.

And Larrabee!!! It was the tilyest of them all!

Re: Dissecting the Apple M1 GPU, Part III

#94

Post by sharpneli »

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…

I agree with the nit.

> Simply put – Apple doesn’t need to care about Vulkan or OpenGL performance.

OpenGL and Vulkan allow an implementer to more easily make such specialized HW. But it doesn't assume it at all in any other way. If your HW is fast enough there is absolutely no need to implement specialized block for it without any performance penalty.

It's trivial to implement things like input assembler without specific HW, just issue loads. But it would be massive pain to go the other way around. Try to sniff what loads fit the pattern that could be tossed into fixed function input assembler. That's a no go.

This is the right way around to do things. As there is no performance penalty for "emulating" it, because there is nothing to emulate in the end.

Re: Dissecting the Apple M1 GPU, Part III

#95

Post by thechao »

lyssa wrote: post #12
iso8859-1 wrote: post #11

Is Collabora paying Alyssa Rosenzweig for this work?

No, this is purely a hobby project undertaken in my spare time. (The email addresses on the git commits are force-of-habit, apologies for the confusion.)

Stop talking to those backstabbin’ compilerfolk; when you’re ready to join the dark side, come to us and make GPUs.

Re: Dissecting the Apple M1 GPU, Part III

#96

Post by gsnedders »

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.

This is the whole point of Gallium, right?

Like, the classic "Intel OpenGL driver" in Mesa (i.e., i965) doesn't use Gallium and NIR, and hence has to implement each graphics API itself, whereas their modern "Iris" driver using Gallium presumably just handles NIR -> hardware?

Or does the Gallium approach still require some knowledge of higher-level constructs and some knowledge of things above NIR?

Re: Dissecting the Apple M1 GPU, Part III

#97

Post by meepmorp »

pjmlp wrote: post #88
shmerl wrote: post #26

Earlier quoted context omitted.

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.

That's not really a fair argument, though, because you know what you're talking about.

Re: Dissecting the Apple M1 GPU, Part III

#98

Post by Unklejoe »

CyberRabbi wrote: post #72
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…

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

This is unlike something like USB where you need to deal with packets directly.

Re: Dissecting the Apple M1 GPU, Part III

#99

Post by pjmlp »

meepmorp wrote: post #97
pjmlp wrote: post #88

Earlier quoted context omitted.

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

That's not really a fair argument, though, because you know what you're talking about.

Like anyone that learns 3D programming.

In any case, here in an example of such approach, https://www.ogre3d.org/

Post reply on HN