Tried getting PCVR working with the Quest 2, unfortunately support is still a hot mess and leaves the system with a super janky flood of audio devices, in addition to legendary stutters that make it unplayable. Win11 still better for VR.
I actually still have some old servers with chips from that period, one of them is still being used as my firewall but until last year I was using others to run multiple VMs for email and web sites. Not as power-efficient but they do still work.
That’s not a guarantee on the Linux world either, but at least you do have the option of recompiling your distro to not use those options.
There’s talks from some distros to start dropping support for such old CPUs because it’s holding back newer CPUs that could run even faster by using those instructions.
Is it really that hard to include a fallback though? Obviously there’s a way to collect the information without that flag. I suppose if you didn’t want to take a performance hitting checking the flag all the time it could become a compile option (I would think anyone running that old of hardware would be willing to learn how to compile the kernel anyway), but there should be options available to keep the support available some how?
That’s pretty much exactly how it works already. You compile with -march=x86-64-v4 and it’ll use SSE and AVX all over the place.
glibc does the runtime thing, but only once on application startup where the dynamic linker will link the version of the function optimized for your CPU. But it’s a manual process on glibc’s part, the variants are written by hand.
Not every project cares enough to do it dynamically like that and it would be a nightmare that way.
The fallback is, recompile with -march=x86-64 which will only use the base set of instructions. Or -march=i486 if you want to run on absolutely ancient hardware.
Maybe this will convince more people to switch to linux.
With the work that Valve is doing on Wine, and Proton, it’s really becoming easier and easier to justify the switch.
FTFY
Almost all I play on now.
Having less personal time and rising electricity costs has made the Deck my primary gaming machine lol.
I don’t support games with DRM, so pretty much everything I play works flawlessly on it (as well as “unsupported” titles via Proton GE)
Tried getting PCVR working with the Quest 2, unfortunately support is still a hot mess and leaves the system with a super janky flood of audio devices, in addition to legendary stutters that make it unplayable. Win11 still better for VR.
Only pita setback is things like fortnite and other multi-player games insisting on only using anticheat software that isn’t Linux compatible.
I’m okay with this. I don’t support those publishers anyways. People should stop supporting them altogether.
Could be. If you’re running a core 2 duo I am fairly certain Linux will run markedly faster than Windows 10+…
I actually still have some old servers with chips from that period, one of them is still being used as my firewall but until last year I was using others to run multiple VMs for email and web sites. Not as power-efficient but they do still work.
People on the fence may be convinced. Most will just buy new computers.
I’ll be sure to inform my whole company and I am sure they will be on board
Don’t you wish… 😜
That’s not a guarantee on the Linux world either, but at least you do have the option of recompiling your distro to not use those options.
There’s talks from some distros to start dropping support for such old CPUs because it’s holding back newer CPUs that could run even faster by using those instructions.
Is it really that hard to include a fallback though? Obviously there’s a way to collect the information without that flag. I suppose if you didn’t want to take a performance hitting checking the flag all the time it could become a compile option (I would think anyone running that old of hardware would be willing to learn how to compile the kernel anyway), but there should be options available to keep the support available some how?
That’s pretty much exactly how it works already. You compile with
-march=x86-64-v4and it’ll use SSE and AVX all over the place.glibc does the runtime thing, but only once on application startup where the dynamic linker will link the version of the function optimized for your CPU. But it’s a manual process on glibc’s part, the variants are written by hand.
Not every project cares enough to do it dynamically like that and it would be a nightmare that way.
The fallback is, recompile with
-march=x86-64which will only use the base set of instructions. Or-march=i486if you want to run on absolutely ancient hardware.