I think there's larger barriers to getting windows running on Apple Silicon that would need to be addressed first.
For one example, Windows ARM kernels are pretty tied to the GIC (ARM's reference interrupt controller), but Apple has its own interrupt controller. Normally on ntoskrnl this distinction would simply need hal.dll swapped out, but I've heard from those who've looked into it that the clean separation has broken down a bit and you'd have to binary patch a windows kernel now if you don't have source access.
Apple Silicon doesn't use GIC, but uses AIC (Apple Interrupt Controller).
"Apple designed their own interrupt controller, the Apple Interrupt Controller (AIC), not compatible with either of the major ARM GIC standards. And not only that: the timer interrupts - normally connected to a regular per-CPU interrupt on ARM - are instead routed to the FIQ, an abstruse architectural feature, seen more frequently in the old 32-bit ARM days. Naturally, Linux kernel did not support delivering any interrupts via the FIQ path, so we had to add that."
My next point was about how the NT kernel was designed to handle exactly this kind of change pretty cleanly, but that clean barrier has been allowed to stagnate. So way back, NT kernels for weird systems like SGI workstations that had x86 CPUs but were decidedly not PCs otherwise simply needed hal.dll swapped out with a version written by the hardware vendor to paper over those system differences like how interrupts are routed around and how to access PCI devices. That's no longer really an option however.
It would take more than a GPU Driver, or actually, drivers at all.
Windows has some behavior that is hard-coded and cannot be changed except by Microsoft. This behavior can fairly easily be bent on Linux, but Windows drivers can't bend the rules for some of these issues.
The biggest issue that immediately comes to mind is that the M1 MMU (Memory Management Unit) only can handle 16K pages. Linux can easily be built for 16K, and most programs work on 16K, but Windows currently only supports 4K on ARM. No driver can fix that - only Microsoft. Of course, if Microsoft joins the Apple Silicon train (which Apple has said they are more than welcome to do), then they probably will have official Apple documentation and not need the Asahi Linux findings.
In https://asahilinux.org/2022/03/asahi-linux-alpha-release/ it says that 4k pages work on the HW but 16k has tome advantages. Dropping 4k page size supporrt would imply a departure from arm architecture compatibility compatibility I think, it might have also nontechnical problems (ARM license).
The arm spec allows to have machines that implement any of 4KB, 16KB, or 64KB granules or any combination thereof. Apple shipped plenty of phone SoCs that didn’t support 4KB pages for the CPU (A9->A13).
Interesting - at first this didn't seem to be detailed in the popular (Wikipedia etc) or ARM web pages I could find but it seems it was about terminlogy, "translation granule" was the right one and then you can find mentions like "The granule sizes that a processor supports are IMPLEMENTATION DEFINED".
The GPU driver is an important component for desktop users, but it's just one small part of what you need to bring Linux to these machines. There's a ton of work in all kinds of other areas, down to changes in the core of the kernel. A GPU driver for Windows won't do you any good without all those other drivers.
