3D games working on Apple GPU on Linux at 4K!

dada_dave

Elite Member
Posts
2,130
Reaction score
2,120
A new update from Alyssa:


Really cool stuff. A lot of performance improvements ... and more to go, but the progress is incredible. As I mentioned in another thread, the Asahi folks (beyond their own skills of course) credit the rationality of Apple's GPU design for why it was so much easier to RE and make a driver for than say open source Nvidia or AMD drivers which was the previous yardstick and why people thought it would take years if happen at all.
 

KingOfPain

Site Champ
Posts
262
Reaction score
347
That's truly impressive! I remember reading a while ago comments like: With the GPU being undocumented it'll take years to get proper drivers, if at all.
It's also interesting that the Kernel driver is written in Rust, which apparently makes it a lot more stable from the get go.
While Apple's GPU design might be a bit easier than most others, it definitely takes talented people to get this far so quickly.
 

leman

Site Champ
Posts
628
Reaction score
1,170
Frankly, I would have assumed that same. But it's a sign of strength to admit that one was wrong.

Well you know, they are not out of the woods yet šŸ˜ƒ It will be curious to see how the performance develops over time. Getting Proton and Windows games to work will be the real test. But yes, their progress has been nothing but astonishing so far, especially considering these are just a few people.
 

dada_dave

Elite Member
Posts
2,130
Reaction score
2,120
New update from Asahi Lina on a deep dive on writing the kernel driver for macOS GPUs and how it was quite different from most other kernel drivers theyā€™ve REā€™d. Some really interesting stuff here from a programming language perspective as well as optimizations and some news about other games theyā€™ve gotten working, advancing support for more OpenGL features/Vulkan, and the difficulties ahead.

 

dada_dave

Elite Member
Posts
2,130
Reaction score
2,120
Well you know, they are not out of the woods yet šŸ˜ƒ It will be curious to see how the performance develops over time. Getting Proton and Windows games to work will be the real test. But yes, their progress has been nothing but astonishing so far, especially considering these are just a few people.
Yeah in the post above Lina makes it clear that going up the chain of OpenGL variants and obviously Vulkan will be harder and there is a lot of difficult work ahead to get even OpenGL 3.2+ working.

There is still a long road ahead! The UAPI that we are using right now is still a prototype, and there are a lot of new features that need to be added or redesigned in order to support a full Vulkan driver in the future. Since Linux mandates that the UAPI needs to remain stable and backwards compatible across versions (unlike macOS), that means that the kernel driver will not be heading upstream for many months, until we have a more complete understanding of the GPU rendering parameters and have implemented all the new design features needed by Vulkan. The current UAPI also has performance limitationsā€¦ it canā€™t even run GPU rendering concurrently with CPU processing yet!

And of course there is still a lot of work to do on the userspace side, improving conformance and performance and adding support for more GL extensions and features! Some features like tesselation and geometry shaders are very tricky to implement (since they need to be partially or fully emulated), so donā€™t expect full OpenGL 3.2+ for quite a long time.

But even with those limitations, the drivers can run stable desktops today and performance is improving every week! Wayland runs beautifully smoothly on these machines now, just like the native macOS desktop! Xorg also works well with some improvements I made to the display driver a few days ago, although you can expect tearing and vsync issues due to Xorg design limitations. Wayland is really the future on new platforms! šŸ’«
 

dada_dave

Elite Member
Posts
2,130
Reaction score
2,120
Alpha release drivers out


I do wonder if all the work theyā€™ve done could be reworked to make OpenGL/Vulkan drivers for macOS? I suspect so especially for OpenGL as Alyssa started with user space drivers running on macOS. Could be useful for projects like Wine as Apple I think only supported up to OpenGL 3.2 and of course never supported Vulkan. Naturally for Vulkan there are translation layers but in theory a driver would be more performant.
 

quarkysg

Power User
Posts
69
Reaction score
45
Naturally for Vulkan there are translation layers but in theory a driver would be more performant.
Isn't any driver for Vulkan in macOS still a wrapper for Metal? If I understand correctly, macOS drivers are now user-space codes, so they cannot access the hardware directly, except for what was exposed by the Mach kernel.
 

dada_dave

Elite Member
Posts
2,130
Reaction score
2,120
Isn't any driver for Vulkan in macOS still a wrapper for Metal? If I understand correctly, macOS drivers are now user-space codes, so they cannot access the hardware directly, except for what was exposed by the Mach kernel.

All modern OSes split the graphics driver between user space and kernel. Apple does do things differently from most in terms of what the kernel handles and how because it uses RTKit and a mailbox to handle communication to the graphics card. Alyssa and Lina went over the details of this in each of their posts. Currently there is no Vulkan driver for macOS, there is simply a translation layer called MoltenVK. There is another for DirectX. Apple does ship an OpenGL driver, but if I remember my conversation with @leman right, it is indeed just a translation layer to the Metal API. This is very different from what Alyssa and co are building.
 

leman

Site Champ
Posts
628
Reaction score
1,170
Isn't any driver for Vulkan in macOS still a wrapper for Metal? If I understand correctly, macOS drivers are now user-space codes, so they cannot access the hardware directly, except for what was exposed by the Mach kernel.

@dada_dave is correct. Apple only ships a Metal driver on macOS, which certainly has both a user-space and a kernel-space component. There are no APIs to write graphics drivers. The OpenGL on macOS is simply a library which uses Metal (potentially with some undocumented features) and if you want Vulkan etc. youā€™ll have to implement them on top of Metal as well (just like MoltenVK is doing).

Fun stuff: the GPU runs itā€™s own OS on its own ARM CPU. The communication between the GPU and the driver is done vie shared memory (like many other things on Apple Silicon).
 

quarkysg

Power User
Posts
69
Reaction score
45
@dada_dave is correct. Apple only ships a Metal driver on macOS, which certainly has both a user-space and a kernel-space component. There are no APIs to write graphics drivers. The OpenGL on macOS is simply a library which uses Metal (potentially with some undocumented features) and if you want Vulkan etc. youā€™ll have to implement them on top of Metal as well (just like MoltenVK is doing).

Fun stuff: the GPU runs itā€™s own OS on its own ARM CPU. The communication between the GPU and the driver is done vie shared memory (like many other things on Apple Silicon).
I'm confused then.

If I read the comments from @dada_dave correctly, it was stated that due to the work of the Asahi Linux folks, a native Vulken driver for macOS could be a possibility.

What you are saying is that it is not possible. Am I reading it wrong?
 

dada_dave

Elite Member
Posts
2,130
Reaction score
2,120
I'm confused then.

If I read the comments from @dada_dave correctly, it was stated that due to the work of the Asahi Linux folks, a native Vulken driver for macOS could be a possibility.

What you are saying is that it is not possible. Am I reading it wrong?
So the Vulkan driver Iā€™m very not sure about because it does require more kernel level work than what OpenGL requires. However an actual native OpenGL driver up to 4.2 or whatever the last iteration was might be possible because Alyssa started her user space OpenGL driver on macOS as there was no kernel driver for Linux at the time. So at least getting OpenGL working with the macOS kernel might be possible. This would be very different from just a wrapper for the Metal API though.
 

quarkysg

Power User
Posts
69
Reaction score
45
So the Vulkan driver Iā€™m very not sure about because it does require more kernel level work than what OpenGL requires. However an actual native OpenGL driver up to 4.2 or whatever the last iteration was might be possible because Alyssa started her user space OpenGL driver on macOS as there was no kernel driver for Linux at the time. So at least getting OpenGL working with the macOS kernel might be possible. This would be very different from just a wrapper for the Metal API though.
I think I sort of get it now. Metal is just another user land driver than uses the macOS Mach kernel GPU driver. So Alyssa's OpenGL driver is running at the same level as Metal.

I always thot of Metal as THE kernel GPU driver.
 

leman

Site Champ
Posts
628
Reaction score
1,170
I'm confused then.

If I read the comments from @dada_dave correctly, it was stated that due to the work of the Asahi Linux folks, a native Vulken driver for macOS could be a possibility.

What you are saying is that it is not possible. Am I reading it wrong?

Ah, I think I understand now. Yes, Rosenzweig is/was using the kernel interface on macOS directly to develop the initial user-facing driver, but this doesn't mean that creating a general-purpose Vulkan etc. driver on macOS is feasible. She is probably using some kernel debugging interface, with security features disabled etc. Not to mention that these interfaces are private and undocumented. Would you be willing to severely compromise your machine security just to run an unstable Vulkan driver? MoltenVK will do the same but without the drawbacks.
 

dada_dave

Elite Member
Posts
2,130
Reaction score
2,120
Ah, I think I understand now. Yes, Rosenzweig is/was using the kernel interface on macOS directly to develop the initial user-facing driver, but this doesn't mean that creating a general-purpose Vulkan etc. driver on macOS is feasible. She is probably using some kernel debugging interface, with security features disabled etc. Not to mention that these interfaces are private and undocumented. Would you be willing to severely compromise your machine security just to run an unstable Vulkan driver? MoltenVK will do the same but without the drawbacks.

So I donā€™t believe (though could be wrong) that the OpenGL driver development required any security disabling or private API use. However it is the case that a Vulkan driver might. One of the reasons given for why they didnā€™t even try to start developing a Vulkan driver until OpenGL was running on Linux is indeed that Vulkan required a lot more kernel work just to get started. I believe that, unlike the initial user space OpenGL driver, the Vulkan driver is being developed on the Linux side not the Mac side. Could be wrong but thatā€™s my reading of it.

[ā¬†ļøEdited for clarity]

========

Speaking of Vulkan - apparently Ella has a cube output. So things are progressing there.

Thought I'd do a quick update on what I've been working on with AGXV for the past few weeks. The first cube demo was very very hacky code and I've been working on refactoring it into a nice clean branch to make it easier to share and for others to contribute :3. Just got a cube rendering on it. Will update more soon. Nya~!

Also apparently there is another project to invert MoltenVK and translate the Metal API to Vulkan, which is interesting. Itā€™s part of a larger project called Darling to get Mac apps running on Linux - basically Wine but for Mac->Linux (and somewhat amusingly as they point out Mac->Windows using WSL2).

[Edit: added link for Darling project and the point about WSL2]

 
Last edited:

leman

Site Champ
Posts
628
Reaction score
1,170
So I donā€™t believe (though could be wrong) that the OpenGL driver development required any security disabling or private API use.

OpenGL supports primitive types that Metal does not. Since rearranging vertex buffers behind the scenes would be extremely messy (and slow!), it is likely that Apple GPUs support these primitive types natively, just in a way that is not exposed to Metal. That's one source why I mention private APIs.

Although, I suppose that these things could be solved using Mesh shaders in Metal 3 (you'd still get altered behaviour in the vertex shaders).

However it is the case that a Vulkan driver might. One of the reasons given for why they didnā€™t even try to start developing a Vulkan driver until OpenGL was running on Linux is indeed that Vulkan required a lot more kernel work just to get started.

OpenGL drivers are usually much more complex than Vulkan drivers, but in this particular case I can imagine that their OpenGL drivers are more like a proof-of-work, with performance being a low-priority target at this point. To get a high-performing Vulkan driver they will have to reverse-engineer all of the gritty details of the GPU protocol.

But again, I am just talking out of my ass here. My familiarity with this work is only superficial.
 

dada_dave

Elite Member
Posts
2,130
Reaction score
2,120
But again, I am just talking out of my ass here. My familiarity with this work is only superficial.

Iā€™m talking even more out of my ass as my knowledge of graphics drivers at all is entirely superficial. :)

OpenGL drivers are usually much more complex than Vulkan drivers, but in this particular case I can imagine that their OpenGL drivers are more like a proof-of-work, with performance being a low-priority target at this point. To get a high-performing Vulkan driver they will have to reverse-engineer all of the gritty details of the GPU protocol.

Itā€™s bit more than just proof of work for the OpenGL drivers (though thatā€™s a big part of it) and they do seem to be optimizing them for performance in addition to adding features. Alyssa goes why they prioritized them in her blog I linked to a couple of posts ago.
 
Last edited:

dada_dave

Elite Member
Posts
2,130
Reaction score
2,120
So indeed the Asahi OpenGL drivers *could* work on macOS but ā€¦

1670928744908.png

1670928793700.png


 
Top Bottom
1 2