Apple M1 Mesa Code Begins To Run glmark2

[pWe00Iri3e7Z9lHOX2Qx]

> biggest blocker remaining is getting the Apple M1 3D graphics working.

I'd want sound/wifi/vpu/sleep working first.

Indeed. All the Apple M1 related posts are a bit misleading. I'd say the biggest remaining blocker is that most things don't work. It's not like we are close to writing your favorite Linux distro ISO to a USB drive and getting everything working out of the box. Progress yes. Almost there, no.

[dragon321]

If they manage to write a Vulkan driver for Linux, I wonder if that means that we can eventually get a Vulkan driver for macOS as well?

Technically it probably would be possible but I doubt it will anybody will work on that. First of all it's difficult technically. macOS uses more complex kernel drivers compared to Linux where drivers are resoponsible mostly for memory management and scheduling and Mesa handles 3D state. On macOS kernel extension is reponsible to some extent of handling 3D state and it's aware about graphical stuff. Second issue is that there is probably no really big interest in native Vulkan on macOS. Especially due to fact it would probably require user to manually install it.

Great archivement!

Yet, I'm wondering: Is it easier to write an OpenGL driver or an Vulkan driver? Especially since Zink progressed that nicely?

OpenGL is more complicated API in terms of driver development but Mesa architecture lets you reuse a lot of work. You don't have to implement OpenGL for each driver, Mesa OpenGL implementation is common and uses Gallium API that is lower level and less complicated API than OpenGL. So you implement Gallium interface in your driver and you can use Mesa OpenGL state tracker. So I guess if you can have both API natively supported then why not?

[OneTimeShot]

Second issue is that there is probably no really big interest in native Vulkan on macOS. Especially due to fact it would probably require user to manually install it.

Any application compiled for Mac can just include MoltenVK which is the official Khronos Vulkan SDK for Mac. It's pretty mature now.

[dragon321]

Any application compiled for Mac can just include MoltenVK which is the official Khronos Vulkan SDK for Mac. It's pretty mature now.

Yes but with MoltenVK problem is it's not and probably won't implement full Vulkan like native drivers. Metal doesn't support everything that Vulkan does. But obviously you are right. It's pretty mature right now and implement Vulkan to the extent enough for many projects. The fact Valve uses it in their games shows it's pretty capable as well. It's also way more convenient for users - developer simply packs MoltenVK runtime with application and user don't need to to any special things to run it.

[M1kkko]

Second issue is that there is probably no really big interest in native Vulkan on macOS. Especially due to fact it would probably require user to manually install it.

Assuming that the first issue can be fixed (ie. such a driver is possible to implement by a third party and someone has time and interest to develop it), the second issue should be no big deal. For example, the Steam client could take care of installing the driver for games that can make use of native Vulkan.

[numacross]

The best part of this project is how badly it must chaff Apples hide.

To be honest I don't think they really care. Apple could easily disable running all third party operating system if they wanted to, just like on iOS devices.

[dragon321]

Assuming that the first issue can be fixed (ie. such a driver is possible to implement by a third party and someone has time and interest to develop it), the second issue should be no big deal. For example, the Steam client could take care of installing the driver for games that can make use of native Vulkan.

Users probably wouldn't want to replace Apple drivers with some third party drivers with Vulkan support. Keeping driver and implementing Vulkan on top of it is not perfect idea either - it's proprietary and documentation is not available to third party developers so implementation would sometimes break after driver change and that would require additional RE work to figure out.

The best part of this project is how badly it must chaff Apples hide.

Not at all it seems. Apple Silicon hardware boot process is pretty similar to iOS devices. They could relatively easy block running unsigned code or require signed firmware for hardware like Nvidia does for their GPUs. They are not doing any of these things. Even more, in some update they made booting Linux easier by adding raw image mode that doesn't require Mach-O.

It seems that Apple don't really care if you want to run Linux on their machines. I'm guessing that the fact they are making money on hardware would be some reason.

[scottishduck]

The best part of this project is how badly it must chaff Apples hide.

Seeing as apple fixed a firmware bug to make the asahi Linux installer work, I’m thinking probably not.