Apple Vulkan Driver "HoneyKrisp" Lands Many Fixes & Features

[chithanh]

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.

Usually the hardware vendor is expected to write drivers for Windows so that would be Apple. Granted, given Asahi Linux already did the

Yes, Apple also needs to write drivers but there is no point if the Windows kernel does not even boot on M1 and later.

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

On x86 Macs, the Windows kernel at least boots to a point where it can load Apple's drivers.

[ahrs]

On x86 Macs, the Windows kernel at least boots to a point where it can load Apple's drivers.

Do we know that's not true for Apple's ARM Macs? They do have an ARM version of Windows, the issue is there's no drivers for it. Maybe I'm wrong but I don't see Microsoft wanting to write GPU drivers for Macs.

[mdedetrich]

Being able to run something isn't equal to being open.

Try borking your bootloader and starting from your favorite usb sick to recover from that.

Your making a pointless distinction here. Its as possible to run any OS on a Apple sillicon mac pro in the same way as you can on x86/x64 and its not like all x86/x64 systems run coreboot.

[intelfx]

Your making a pointless distinction here. Its as possible to run any OS on a Apple sillicon mac pro in the same way as you can on x86/x64 and its not like all x86/x64 systems run coreboot.

He's indeed making a pointless distinction, but what you say is not entirely true. The Apple Silicon implementation of ARM is very different from "normal" ARM CPUs on the system level, e.g. it has its own interrupt controller instead of GIC. So a 3rd-party operating system needs to be ported to Apple Silicon on a lower level than just writing a bunch of new drivers.

[mdedetrich]

He's indeed making a pointless distinction, but what you say is not entirely true. The Apple Silicon implementation of ARM is very different from "normal" ARM CPUs on the system level, e.g. it has its own interrupt controller instead of GIC. So a 3rd-party operating system needs to be ported to Apple Silicon on a lower level than just writing a bunch of new drivers.

Yes thats true, but as far as I understand its not unusual in ARM land. From what I have read, when it comes to booting ARM is a chaotic shitstorm with no proper standard where as with x86/x64 there is a standard way to boot kernel.

Or put differently, in reality there isn't any "normal" for ARM. There is no standard and there was never an attempt to make one.

[dragon321]

Some people need Windows support and they only realise after the fact they've gone out and bought a Mac. I don't use Macs anymore and haven't for quite sometime but sympathise with these people a little. I was young and stupid once, I wouldn't buy a Mac again.

The solution for it is using virtualization. Parallels Desktop officially supports Windows on Apple Silicon Macs.

The Apple Silicon implementation of ARM is very different from "normal" ARM CPUs on the system level, e.g. it has its own interrupt controller instead of GIC. So a 3rd-party operating system needs to be ported to Apple Silicon on a lower level than just writing a bunch of new drivers.

There is no such thing as "normal ARM platform". Unlike x86, ARM boot process and peripherals configuration is not standardized. While ARM Windows requires UEFI and that is actually clever move from Microsoft, it's not standard in any way.

[intelfx]

The solution for it is using virtualization. Parallels Desktop officially supports Windows on Apple Silicon Macs.



There is no such thing as "normal ARM platform". Unlike x86, ARM boot process and peripherals configuration is not standardized. While ARM Windows requires UEFI and that is actually clever move from Microsoft, it's not standard in any way.

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.

[chithanh]

Do we know that's not true for Apple's ARM Macs? They do have an ARM version of Windows,

Yes we know it is true, because Microsoft does not even have a bootloader which is compatible with the firmware in Apple silicon Macs. There is a volunteer project underway which aims to provide the necessary UEFI support on the platform, but it is in early stages still.

This is not totally unlike the OLPC XO-1 which saw a Windows XP port despite running on Open Firmware. In order to ship Windows on it, Microsoft had to replace Open Firmware with a PC BIOS, presumably because they could not be assed to resurrect the Open Firmware support which they had in Windows NT.

the issue is there's no drivers for it. Maybe I'm wrong but I don't see Microsoft wanting to write GPU drivers for Macs.

Windows doesn't even boot to the point where GPU drivers become relevant.

[ahrs]

Windows doesn't even boot to the point where GPU drivers become relevant.

Assuming they write a bootloader (which is not difficult, Asahi has already done so, Microsoft could too) then it'd become relevant. Is Apple going to suddenly contribute the needed drivers to support their hardware after the fact? Unlikely. Apple could have written a bootloader themselves if they wanted to, it's an insult to their intelligence to suggest they're incapable of that. I don't think it's the bootloader that's blocking Windows support on these machines but rather the fact Apple doesn't want to support it and Microsoft likely doesn't either (Macs are even less relevant today then they were in the past).

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.

[M@yeulC]

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.