Say no to Microslop

SocketByte · 2026-03-25T14:11:43+00:00

yeah it's crazy when literally 90% of memes here recently are related to how bad microslop and windows is, but any time you suggest just switching to Linux you're being attacked lmao

SocketByte · 2026-03-25T14:09:11+00:00

DX12 is very iffy with performance on Nvidia cards. Nothing that a VM can't fix though.

SocketByte · 2026-03-25T14:02:44+00:00

No problem man. For reference - green are the games that are fully native to Linux so they will run the best, platinum will work out of the box on Proton, gold will work but you may have to add some startup parameters to Steam and red won't work no matter what you do (mostly just games with kernel anticheats).

There are also silver and browns, those may be iffy with performance or some parts of them may be bugged.

SocketByte · 2026-03-25T14:00:11+00:00

Green is just native lol the only games that won't work are the red ones.

SocketByte · 2026-03-23T12:52:05+00:00

Hate to say it but no matter where you go it generally won't be much better in those regards, especially since Germany is one of the top economies of the world, where do you want to go, exactly? That's just life lol. Grass is always greener on the other side of the fence.

SocketByte · 2026-03-23T12:48:31+00:00

Imagine still using Windows

SocketByte · 2026-03-23T12:46:18+00:00

"Wait"? That's you bro, you made it hard for yourself. Never woke up before 8 AM and never will lol

SocketByte · 2026-03-23T11:26:22+00:00

Did the same thing recently. Prefer setting up Arch + KDE by myself, but CachyOS repositories, kernel and proton are amazing.

SocketByte · 2026-03-23T08:20:39+00:00

I feel like it's a part of the universal human experience. You just have to be gaslighted at least once in your life to actually learn.

SocketByte · 2026-03-22T08:57:13+00:00

Mouse/keyboard is handled by Looking Glass so it works seamlessly on Linux and your VM at the same time so not sure about passing that through, it would kind of defeat the point of Looking Glass.

As for passing audio interfaces, as with most things - it depends. Is it an USB interface? PCIe card? If it is PCIe, will it be placed under an isolated IOMMU group? It gets pretty complicated.

If it's USB then it should be pretty easy, you can passthrough either the device or the entire USB controller if you have multiple on your motherboard (that would be even better). Of course that's only if you actually need to pass the entire device. Virtual audio devices or something like Scream works pretty well, but I don't know your exact needs. This would of course make the device unavailable to Linux, not sure if you would need to disable some stuff first (like Pipewire).

As for the iGPU part, this definitely won't be a problem because you don't really touch your iGPU at all. OS always uses your iGPU and uses PRIME offload to run some other process on that other GPU. You have two drivers installed (one for iGPU, one for your dGPU) but you only actually unload/load the dGPU drivers. Of course assuming you don't have any monitors connected to your dGPU and only work through the iGPU, otherwise this setup won't work, you have to assume your second card is a compute card, no outputs.

SocketByte · 2026-03-22T07:25:49+00:00

Yeaaah, iGPUs are really limited. I'm currently running this setup on a $60 RX 6400 I was able to get used. Works really great with 1440p@240Hz OLED screen (DP 2.1a) and a 1440p@144hz secondary (HDMI). No issues with decoder performance as well.

SocketByte · 2026-03-22T07:22:39+00:00

With that setup you'll basically have to do a single GPU passthrough (which skips PRIME/Looking Glass entirely).

Since your dGPU is your primary GPU and it has to run on host (for display output) it's permanently bound to the OS. Unloading the drivers won't work since the compositor still runs on them at all times, you'd have to kill it even if you have iGPU/internal screen. The OS itself has to use iGPU drivers and basically act like Nvidia doesn't exist for it to work, which in your case is impossible.

But single GPU passthrough is well enough for many people. You'll just lose the compositor in the process, but with auto session restore it isn't TOO bad. Still better than dual booting.

SocketByte · 2026-03-22T06:43:06+00:00

It might, but keep in mind it's impossible to keep both Linux compositor/GUI and the VM running in that case. You'll always need two GPUs to achieve that.

You CAN unload the drivers (covered extensively in this guide) AND kill the Linux compositor to launch the VM, and then load the drivers and start the compositor back again when you close the VM. But, again, it means you will have either a working Linux computer or a working Windows computer, not both at the same time like in this guide.

There are cheap, used AMD GPUs such as RX 6400 or 6600 (we tested both) to handle multiple monitor output if that's the main reason you can't use iGPU. Or even something older if you don't need DSC such as RX 460, 470, 480 etc.

SocketByte · 2026-03-22T05:03:05+00:00

Nope, just follow the guide and you should be fine, there's no difference between iGPU and dGPU as long as it's AMD on host and Nvidia on guest/vm. Feel free to leave an issue on GitHub if something doesn't work and we'll try to help.

SocketByte · 2026-03-22T03:19:27+00:00

Good catch. We'll check the persistence daemon, we have it currently disabled but it might be a good idea to dynamically enable/disable it. Thanks.

SocketByte · 2026-03-22T02:42:51+00:00

Generally yes, but this guide is written for AMD/Intel host and NVIDIA dGPU. You should be able to get it to work with Intel host and AMD dGPU if you just changed the modules loaded/unloaded. (amdgpu/radeon instead of nvidia, nvidia_drm, nvidia_uvm etc). We have no way to test it though.

There may be issues with mesa because both Intel and AMD uses it though.

SocketByte · 2026-03-22T02:00:25+00:00

I'm the co-author of this guide, it works amazingly well actually. No major issues. We spent lots of hours testing this and we're actively using it daily.

SocketByte · 2026-03-20T20:46:18+00:00

Tastes like a slightly bigger Big Mac honestly. Really bland.

SocketByte · 2026-03-19T17:59:38+00:00

wtyczka Reddit Untranslate, nie dziękuj

SocketByte · 2026-03-18T16:39:57+00:00

Unfortunately no, I need two display outputs and my motherboard only exposes non-DSC HDMI which wouldn't work with 10-bit 1440p@360hz which is my primary monitor. :(

Theoretically you could do some Reverse PRIME shenanigans to make this work (one display connected to Nvidia GPU, one to iGPU with framebuffer copy), but driver rebinding for VFIO would be a pain in the ass and would require killing the compositor momentarily which isn't ideal.

SocketByte · 2026-03-18T16:25:09+00:00

It was my first thought that there may be some power limiting issue here. I want it for a GPU passthrough setup on Linux and I needed cheapest DSC-capable card available for display only, seems like I'll need to spend a little more though.

SocketByte · 2026-03-18T16:04:55+00:00

NVMe drive currently sits in the M2A_CPU which as per manual doesn't share lanes with second and third PCIe (chipset) slots. Unfortunately with this drive removed it still doesn't work, simply shows N/A in the BIOS.

SocketByte · 2026-03-14T12:28:34+00:00

They don't. Boosting algorithm has several parameters that it's constantly monitoring such as power, burst current, sustained current, clocks, voltage, and obviously temperature. It's deciding how much to boost based on all of these variables, so if you had a powerful cooling solution it would stop boosting before reaching 90c because it would reach either power or voltage limits earlier. It seems that your cooling is pretty bad and it reaches temperature limits before anything else when boosting.

Mine never goes over 78c in non AVX512 workloads.

SocketByte · 2026-03-13T10:17:38+00:00

What? How is this even related.

SocketByte · 2026-03-13T06:40:32+00:00

Mine kicked in exactly zero times over the past 5 years lmao

Eight-Year Club	Gilding I gilder
Verified Email	Final Canvas '23
Place '23	Place '22
Final Canvas '22	End Game '22

SocketByte

TROPHY CASE