Apple Vulkan Driver "HoneyKrisp" Lands Many Fixes & Features

[Ladis]

Microsoft standardized the booting process on ARM - uses UEFI like x86. UEFI runs a bytecode to initialize PCIe cards, so the "BIOS" of each card has one universal code runnable on all CPU archs with UEFI (no need to flash BIOS with a version for that CPU arch). However every HW vendor can choose whatever boot process they want, it's not mandatory like in the world of devices wanted to run Windows.

About drivers, Apple doesn't need to write them for Windows. Users can run Windows, including older 3D AAA games, in the virtualization - where drivers are written by the virtualization software's company. Microsoft can't write the drivers, because it has no documentation for the HW. However the Linux community is writing them, so someone can port them to Windows. E.g. the newer S3 Virge GPU's driver for Windows is ported the MESA driver from Linux. Thanks to that, I can run OpenGL and 3D in a window (originaly the GPU supported only Direct3D and only fullscren). However, Linux users may use macOS, but they loathe and avoid Windows.

[dragon321]

First, you are talking about ARMv7. This is about ARMv8, which actually uses ACPI and UEFI.

Second, have you ever read the ARM architecture reference manual? I have

ARM platforms have a number of so called architectural peripherals, like the interrupt controller or timers or even the MMU. They are all described in part B of the ARM (well, the GIC has its separate doc). And it so happens that the Apple Silicon does its own unique thing for some of those. So a generic run-of-the-mill UEFI/ACPI-capable ARMv8/AArch64 OS won’t even boot on Apple Silicon, and it isn’t about drivers for any peripherals.

Nothing changed in ARMv8, you are probably talking about SBBR which indeed requires UEFI but it's still optional and not mandatory to manufacturers. You can use it in your board but in the same time you can also not use it. It's not even close to being "generic" like UEFI and ACPI are on x86.

[Blzut3]

They need to write drivers just like they used to do with Boot Camp.

I'm not familiar with all the drivers involved with Windows on an x86 Mac, but with the x86 machine most of the drivers were already written by the third party hardware vendors. Writing drivers for the ARM Macs would be a much larger job particularly because of the GPU.

Remember that it was Microsoft who ported Windows 10 IoT Core to the Raspberry Pi 2. That some hardware drivers were missing didn't change that it was first Microsoft's responsibility to port their closed-source OS to that platform.

Some hardware drivers being notably the GPU driver. Maybe excusable for embedded, not that I really could figure out who the Windows port was for given the driver situation. For a Mac it would be even more useless in that state. From what I can see unless Apple indicates they want to support Windows there's no reason for Microsoft to spend any time on this. If Apple can't be bothered to write a Vulkan driver for macOS I doubt they're going to write DirectX 12 and Vulkan drivers for Windows to make it a worthwhile exercise.

Given that I'm sure Apple has contacts at Microsoft expecting Microsoft to do bring up work just in case Apple might perhaps desire to support Windows is a bit silly. There's obviously some interest from third parties as linked in this thread is efforts to get enough UEFI implemented to boot Windows. Maybe if the AppleWOA efforts conclude they're blocked.

Perhaps worth noting that Windows NT 4 recently got ported to PowerPC Macs which was also blocked by firmware differences for the longest time.

Can this Mesa driver send a command stream to the macOS proprietary driver? That would be quite interesting for adoption, I think. As far as I know, this is how Alyssa was doing the early reverse engineering work, before the DRM driver. I'm wondering if that's still possible.

From following what has been said, the answer seems to be not practically. The problem is that the interface changes between macOS versions (including minor ones) so it's not practical for a third party to support that. Mesa is licensed liberally so Apple could use the work if they wanted. I suppose based on that a troll driver for EOL versions of macOS could be doable, but would be a bit of a wasted effort.

Source: https://social.treehouse.systems/@As...64879305301735

[anda_skoa]

Microsoft can't write the drivers, because it has no documentation for the HW. However the Linux community is writing them

Does that mean that the Linux community got the documentation for the HW or that these engineers are just so much than Microsoft's better that they can do it with out?

[M@yeulC]

Does that mean that the Linux community got the documentation for the HW or that these engineers are just so much than Microsoft's better that they can do it with out?

Just that they can move more freely:
1. they are motivated enough
2. They don't have to make it financially viable
3. Microsoft may not want to do too much reversed engineering of Apple products for legal reasons

Of course, that only works if you have both skills and motivation. But with these two, you can pretty much port anything to anything else. Microsoft would need a valid reason to pay they best engineers to work on that topic (it would probably be cheaper to just pay Apple for the data).

[Ladis]

Just that they can move more freely:
1. they are motivated enough
2. They don't have to make it financially viable
3. Microsoft may not want to do too much reversed engineering of Apple products for legal reasons

Of course, that only works if you have both skills and motivation. But with these two, you can pretty much port anything to anything else. Microsoft would need a valid reason to pay they best engineers to work on that topic (it would probably be cheaper to just pay Apple for the data).

Also Microsoft would have to support everything they publicly release. So a hobby project needing some tuning from the user is fine, but unacceptable for MS to release. Without the official documentation, they can never be sure it will work well.

[chithanh]

Assuming they write a bootloader (which is not difficult, Asahi has already done so, Microsoft could too) then it'd become relevant.

No. A bootloader which can load and execute the kernel is an important prerequisite, but the kernel needs to run too.
And as Linux did before the Asahi project, it would stop right at the non-standard interrupt controller (GIC).

Is Apple going to suddenly contribute the needed drivers to support their hardware after the fact?

That is moot because Windows does not boot to a point where any Apple-provided drivers can be loaded.

Maybe a community project could spring up at some point but besides that I really don't see how ARM Macs will ever gain support.

The community project is called AppleWOA, and it aims to run a modified version of m1n1 which emulates a standard ARM GIC and some UEFI bits from their Project Mu fork, because they cannot change Windows to support booting directly on Apple hardware, and Microsoft is not interested.

Some hardware drivers being notably the GPU driver. Maybe excusable for embedded, not that I really could figure out who the Windows port was for given the driver situation. For a Mac it would be even more useless in that state.

Absolutely not. For one, Raspberry Pi support reached a state where writing drivers would make a difference. Windows is not there for Apple hardware so far.

The other part which is not true is that you need a GPU driver or else it will be useless. Asahi did not have a GPU driver for the first year or so, and it was already usable for normal desktop tasks because the CPU was so fast. In fact it was faster at software rendering than some ARM devices with slow GPUs (think Mali 400) at hardware rendering.

From what I can see unless Apple indicates they want to support Windows there's no reason for Microsoft to spend any time on this. If Apple can't be bothered to write a Vulkan driver for macOS I doubt they're going to write DirectX 12 and Vulkan drivers for Windows to make it a worthwhile exercise.

Given that I'm sure Apple has contacts at Microsoft expecting Microsoft to do bring up work just in case Apple might perhaps desire to support Windows is a bit silly. There's obviously some interest from third parties as linked in this thread is efforts to get enough UEFI implemented to boot Windows. Maybe if the AppleWOA efforts conclude they're blocked.

Microsoft official support is running Windows inside virtualization on Apple hardware. AppleWOA main roadblocks that they have to work around are inside the Windows kernel, not lack of drivers.