Dissecting the Apple M1 GPU, Part III

#1

Post by marcodiego » Mon, Apr 19, 2021, 12:42 AM UTC

Dissecting the Apple M1 GPU, Part III
rosenzweig.io

Re: Dissecting the Apple M1 GPU, Part III

#2

Post by ogre_codes » Mon, Apr 19, 2021, 1:38 AM UTC

So much for "It'll take years before we get the GPU working". Obviously this is far from a full implementation but seems like progress has been quick. Hopefully the power management stuff will be equally quick.

Re: Dissecting the Apple M1 GPU, Part III

#3

Post by lights0123 » Mon, Apr 19, 2021, 1:43 AM UTC

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% the speed of Intel's OpenGL driver[1], so why not completely ignore anything but Vulkan? On the Windows side, dxvk (DirectX to Vulkan) already is much faster (in most cases) than Microsoft's DX9-11 implementation, so it's completely feasible that Zink could become faster than most vendors' OpenGL implementation.

I have no knowledge of low-level graphics, so I don't know the ease of implementing the two APIs. I could envision, however, that because this GPU was never designed for OpenGL, there may be some small optimizations that could be made if Vulkan was skipped.

[0]: https://www.phoronix.com/forums/forum/phoronix/latest-phoron...

[1]: https://www.phoronix.com/scan.php?page=news_item&px=Zink-95-...

Re: Dissecting the Apple M1 GPU, Part III

#4

Post by quotemstr » Mon, Apr 19, 2021, 1:46 AM UTC

> our driver should follow Linux’s best practices like upstream development. That includes using the New Intermediate Representation (NIR) in Mesa, the home for open source graphics drivers. NIR is a lightweight library for shader compilers, with a GLSL frontend

I remember when building everything on LLVM bytecode was best practice. It wouldn't be the Linux ecosystem without continual reinvention of the wheel, would it?

Re: Dissecting the Apple M1 GPU, Part III

#5

Post by dralley » Mon, Apr 19, 2021, 1:48 AM UTC

quotemstr wrote: post #4

> our driver should follow Linux’s best practices like upstream development. That includes using the New Intermediate Representation (NIR) in Mesa, the home for open source graphics drivers. NIR is a lightweight library for shader compilers, with a GLSL frontend I remember when building everything on LLVM bytecode was best practice. It wouldn't be the Linux ecosystem without continual reinvention of the wheel, would…

The blog post she links to explains exactly why it's not a "reinvention of the wheel".

Re: Dissecting the Apple M1 GPU, Part III

#6

Post by _qxjp » Mon, Apr 19, 2021, 1:49 AM UTC

ogre_codes wrote: post #2

So much for "It'll take years before we get the GPU working". Obviously this is far from a full implementation but seems like progress has been quick. Hopefully the power management stuff will be equally quick.

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.

Re: Dissecting the Apple M1 GPU, Part III

#7

Post by marcan_42 » Mon, Apr 19, 2021, 1:59 AM UTC

_qxjp wrote: post #6

ogre_codes wrote: post #2

So much for "It'll take years before we get the GPU working". Obviously this is far from a full implementation but seems like progress has been quick. Hopefully the power management stuff will be equally quick.

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 going to work on it next.

Re: Dissecting the Apple M1 GPU, Part III

#8

Post by stefan_ » Mon, Apr 19, 2021, 2:05 AM UTC

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.

Re: Dissecting the Apple M1 GPU, Part III

#9

Post by shmerl » Mon, Apr 19, 2021, 2:18 AM UTC

Very interesting analysis!

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

Apple being Apple. They just can't play nice with standards.

Re: Dissecting the Apple M1 GPU, Part III

#10

Post by jacquesm » Mon, Apr 19, 2021, 2:31 AM UTC

_qxjp wrote: post #6

ogre_codes wrote: post #2

So much for "It'll take years before we get the GPU working". Obviously this is far from a full implementation but seems like progress has been quick. Hopefully the power management stuff will be equally quick.

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.

Nonsense. Last you heard was 5 years ago or so. And even then it could be done, just a bit more work rather than a default install.