Depends on what you precisely mean by "this". The user space part can easily be used from macOS. That's how the author first developed it without a working kernel driver.
> But wait, how can she work on the user space driver without a kernel driver to go with it? Easy, she did it on macOS! Alyssa reverse engineered the macOS GPU driver UAPI enough to allocate memory and submit her own commands to the GPU, and this way she could work on the user space part without having to worry about the kernel bit. That’s super cool! She started writing an M1 GPU OpenGL driver for Mesa, the Linux userspace graphics stack, and just a few months later she was already passing 75% of the OpenGL ES 2 conformance tests, all on macOS!
Intel did. Obviously there is more to it than just setting a different target and hitting compile but it's also not a ridiculous question because of that measure alone. It'd require enabling reduced security mode to load kexts or a custom kernel as well as a good amount of additional code for interfacing it with the macOS kernel interfaces but the majority of the code would be reused. Not trivial by any measure but also not an unreasonable approach in terms of total effort to get a working driver.
I'd be very surprised if anyone was interested in doing all that work given the security limitations and ability to just use Linux.
Edit: I forgot Metal is actually a userspace driver, you don't need to mess with the kernel side... though I can't remember if you still need to lower security to poke the right areas.
intel's linux driver is completely different from the windows driver. it also has been open since the start (well, since the start of the rewrite in 2010 or something) actually before AMD did theirs.
If you look the other way around (which is more relevant anyways), you can compile Mesa for Windows. However I'm pretty sure only the software renderer is available because Mesa is not capable of interfacing with the Windows kernel driver, as all the other drivers are coupled with Linux driver interfaces, iirc. (At least I'm quite certain this is the case for AMD.)
I'm also quite certain the proprietary NVIDIA driver shares a ton of code between Windows and Linux.
To add on, just because it's cool, there is a 3rd category in play with Mesa of layered drivers. Microsoft worked on and officially supports running OpenCL and OpenGL on devices which only have a DX12 driver via Mesa this fashion. Still all user space of course but not software rendering. More akin to MoltenVK from the blog post, except fully supported and maintained by the OS provider.
