Hacker News new | ask | show | jobs
by johnklos 1343 days ago
Oooh! Will 2022 be the year when a virtualization platform can finally run The Sims 2? ;)
3 comments

I was a big user of dual boot and VFIO, but thanks to the advent of Proton and the recent Wine improvements (DXVK, ...) I've found myself rebooting into Windows for gaming less and less over the course of the last few years. Sure, not everything works, but basically everything single player does with just a few hiccups.
Have you considered just not playing the games that require Windows? There are _plenty_ of really great Linux games. If not, I'd love to know why. I'm not being polemic, I'm not a gamer, but simply avoiding games that don't run on Linux seems rather easy today.
> There are _plenty_ of really great Linux games. If not, I'd love to know why.

That's simply not true, there's a handful at best. There are plenty of Proton games, though.

There aren't that many good games released every year in general, much less for Linux specifically.
I also play those, indeed, but Steam + Proton works very well for a whole lot of titles without a hitch too, so that's a bonus.
VMWare has actually a decent "forward-based" GPU virtualization support. The performance is bad (on my system, around 25% of native), but for old games, it's enough. I'm hoping that VirtualBox 7.0 will have similar performance (and support; it had 3d virtualization already, but it was very poor).
People were already playing GTA 5 at least five years ago using VFIO/PCIe Passthrough.

EDIT: Correction, it was four years ago from my few seconds of rechecking myself

Well yeah, but that requires a whole second GPU. A virtual GPU guest driver that translates to calls to the host GPU would be a godsend.

Hard to tell if that's what's advertised in these release notes, but if so, then at least older games might finally exhibit some decent performance.

You _can_ use various hooks to dynamically bind and unbind on a single GPU system but that would be another degree of difficulty for newcomers (on top of potential buginess throughout the stack).

As to the latter part of your first sentence, I believe that virtio-gl works in the manner you describe. Thought it is Linux only. I have experimented with it on Proxmox and it works well enough.

VFIO does work, but it's hacky, so it's very inconvenient unless one has plenty of time and patience.

For example, AMD GPUs don't support rebar (took a while to figure out), and they used to have (I don't know if it's been definitely solved) a problem with reset, which caused random lockups when exiting the VM.

Additionally, power saving/device ownership must be handled. Which means: either one terminates the X session each time before starting/after stopping the VM (so X will handle the power management), or they leave the card owned by the vfio driver (but this makes the card run hot while sitting doing nothing, because the vfio driver doesn't handle the power management), or they swap drivers on the fly hoping that it will work fine (on nvidia, it's not a stable strategy; no idea on AMD).

And these are just a few issues. I've experienced others in the past, and it's very frustrating and time consuming.

With all these problems, a combination of dual boot (for demanding 3d tasks) and VMWare (for light ones) is much simpler, and stable. I hope to replace VMWare with VirtualBox for the latter use case.