iWin32 Posted July 21 Share Posted July 21 The ability to run macOS in a VM on x86 non-Apple hardware has nearly always been possible since Apple transitioned to Intel in 2005. While the days of running such a virtual machine are numbered due to Apple’s transition to Apple Silicon, it is still possible to spin up VMWare, VirtualBox, KVM, or even Hyper-V to run the latest version of macOS in a virtual machine. However, you are unable to run macOS with the full experience on any machine, virtualized or bare metal, if graphics acceleration is NOT working. On bare-metal, this required having a compatible GPU, and if the GPU was dedicated, you might be able to use passthrough (i.e., VT-D) to get full graphics acceleration working. But this isn’t always the case if you’re goal is to run a macOS virtual machine on a REAL, Intel-based Mac. Apple has provided an API for guest operating systems, starting on macOS Big Sur, to enable graphics acceleration on a virtual machine running on top of macOS Big Sur or later through paravirtualized graphics. Basically, Apple has developed a proprietary, low-level, hardware-accelerated 3D Graphics and Compute Shaders API called Metal. Metal only works on select GPUs, mainly integrated and discrete GPUs that are found on real Macs, and building a Hackintosh or running a macOS VM on a non-Apple system would generally require having the same kind of GPU installed (and passthrough enabled for a VM if virtualized). Apple has also provided a paravirtualized graphics acceleration API that essentially passes on a Metal graphics command or instruction to the hypervisor through a virtualized GPU visible to the guest, and the hypervisor then executes that same command or instruction on the host GPU. This obviously requires the host operating system to have the Metal API available, thereby limiting this to only hosts running macOS. But both VMWare Fusion and Parallels Desktop have, to my knowledge, implemented this in their software and run macOS guests with graphics acceleration. Yet, there may be a workaround that could be developed that would allow any virtualization software on any host OS to run macOS with Metal graphics acceleration using this API. I could be wrong about this, and if so, please let me know. From my understanding, because of how the paravirtualized graphics API was developed, there’s no way for the guest operating system to tell that the underlying host OS is NOT macOS. This means that if we could combine virtualization software with a reverse-engineered reimplementation of Apple’s Metal API that is platform-independant, we could run a macOS guest with graphics acceleration on ANY x86-64 computer with reasonable graphics compute power, regardless of the host operating system or GPU used in a system. One idea as to how this could work is to combine KVM/QEMU with Darling. Darling has designed a binary-compatible re-implementation of the Metal API, a Wine-like compatibility layer for running macOS programs on Linux. It relies on Indium, an open-source re-implementation of Metal that runs on top of Vulkan, so it already is platform-independent and could, in theory, run on non-Linux OSes with the aid of porting. If done right, you could spin up a KVM virtual machine on ANY x86 computer running Linux with a capable graphics card, and install macOS with full (or at least partial) graphics acceleration. And over time, the need for GPU passthrough would be a thing of the past! Now, as I said in my old courtlandOS thread (before ravynOS, formerly airyxOS came on the scene), I’m not a developer or coder by any stretch of the imagination, but I figured I would start this thread to see if any developers want to help create this. One question bound to come up is how ethical developing this would be considering Apple’s EULA? Granted, I doubt Hackintosh developers are going to have as many qualms as other developers would, but I could see the use case of running a macOS VM on a real Intel Mac running Linux, Windows, or another non-Apple operating system. As Apple allows virtualizing macOS on Apple hardware, this use case shows the project isn’t inherently used just to violate Apple’s EULA. And the other question: Why call it the Alchemy Project? One, I find it helpful to name things so it sounds real when creating something, and two, the ancient concept of alchemy is converting one kind of metal (usually a common one like copper) to a rarer metal (like gold). So it’s a play on the name of the Metal API, running Metal acceleration on a different graphics API. Anyway, this thread is just getting started to lay out the idea. Is anyone interested in developing this? (Mods, feel free to move this thread if it doesn't belong here or fits somewhere else better.) Link to comment Share on other sites More sharing options...
Recommended Posts