Yes I know GPU passthrough is possible. Almost no one does it as consumer GPUs don't normally don't support the virtualization technologies that allow multiple OSes to use one GPU. It's an enterprise feature mostly. There are projects like VirGL that work with KVM and QEMU, but they don't support Windows last I checked, and are imperfect even on Linux guests. I think only Apple Silicon and Intel integrated graphics support the right technologies you would need. Buying a second GPU is a good option, although that has it's own complexities and is obviously more expensive. Most modern consumer platforms don't have enough PCIe lanes to give two GPUs a full x16 bandwidth. There is a technology in Windows called GPU paravirtualization to make this happen with Hyper-V, but you have to be using a Hyper-V host, not a Linux based one. It's also quite finicky to make that work.

Out of interest what games are you running that don't need GPU performance? Basically any modern 3D game needs a GPU to run well. Obviously 2D games might not, though even that varies.

All of the above is far more complex than setting up a dual boot. A dual boot can be as simple as having two different drives and picking which to boot from in the UEFI or BIOS firmware. I don't understand why you think that would be less complicated than a high tech solution like virtualization.

There are basically three types of virtualization in classical thinking. Type 1, Type 2, and Type 3. KVM is none of these. With Type 1 there is no operating system running bare metal, instead only the hypervisor itself runs as bare metal. Everything else, including the management tools for the hypervisor, run in guest OSes. Hyper-V, ESXi, and anything using Xen are great examples. Type 2 is where you have virtualization software running inside a normal OS. KVM is special because it's a hypervisor running in the same CPU ring and privilege level as the full Linux kernel. It's like if a Type-1 hypervisor ran at the same time as a normal OS in the same space. This means it behaves somewhat like a Type-1 and somewhat like a Type-2. It's bare metal just like a Type-1 would be, but has to share resources with Linux processes and other parts of the Linux kernel. You could kind of say it's a type 1.5. It's not the only hypervisor these days to use that approach, and the Type 1, 2, 3 terminology kind of breaks down in modern usage anyway. Modern virtualization has gotten a bit too complex for simplifications like that to always apply. Type 3 had to be added to account for containers for example. This ends up getting weird when you have modern Linux systems that get to be a Type-1.5 hypervisor while also being a Type 3 at the same time.