Hyper-V GPU partitioning for CS2: a technical deep dive.
GPU-P is Microsoft's GPU partitioning interface inside Hyper-V. It splits one physical GPU into virtual partitions that VMs can use to render CS2 at usable frame rates. Below: how it actually works, why it beats DDA for a farm, what you sacrifice in raw performance, and the setup gotchas that consume a weekend if you do not know they exist. This is a technical reference, not a click-through tutorial; for the click-through, see the setup guide.
The short version.
GPU-P slices one physical GPU into time-shared partitions across multiple Hyper-V VMs. DDA assigns one whole GPU to one VM and is wrong for a farm. GPU-P is right for a farm because density is the entire point. The performance cost grows with the number of co-tenant VMs; CS2 tolerates that because the bot does not need 240 FPS. The setup gotchas that catch most people are driver branch mismatches between host and guest, VRAM quota under-allocation, and host generation differences that quietly hide GPU features from the guest. The deep walk-through for the actual setup steps lives on the setup guide; this post explains the why so the steps make sense.
What GPU partitioning actually is.
A GPU is a piece of hardware with a fixed amount of compute (shader cores, tensor units, encoder blocks) and a fixed amount of VRAM. Bare metal lets one operating system command the whole thing. Virtualization lets multiple operating systems share it. The question is how the sharing happens.
GPU partitioning (GPU-P) is Microsoft's answer inside Hyper-V. The host owns the physical GPU and runs the real driver. Each guest VM gets a virtual function: a software-defined GPU device that the guest sees as a normal display adapter. When the guest issues a draw call, the request is marshalled across the partition boundary to the host driver, executed against the physical GPU during the guest's time slice, and the result is handed back. This is a paravirtualized model, not full hardware emulation; the guest knows it is sharing, and the host driver knows it is serving multiple clients.
The shared resource is compute time on the GPU and a quota of VRAM. Compute is divided by a scheduler that round-robins across the active partitions, weighted by configuration. VRAM is partitioned at allocation time so each guest knows up front what it can map. If you over-allocate VRAM, the partition creation fails; you cannot oversubscribe GPU memory the way you can with system RAM.
This matters for CS2 because CS2 needs a real GPU to render, but the bot inside the VM does not need a full GPU. It needs enough compute to push 60-ish frames per second at low settings so the game does not stutter and break the input loop. GPU-P lets you give every VM that much, on one card, for as many partitions as your card has resources to feed.
GPU-P vs DDA: the trade-off you cannot avoid.
Hyper-V offers two GPU virtualization paths and they are not interchangeable. DDA (Discrete Device Assignment) hands a whole physical PCIe device to a single VM. The host can no longer use that device while it is assigned. The guest sees a real GPU with its real device ID and its real driver, and gets bare-metal performance minus a thin layer of PCIe virtualization overhead. DDA is the gold standard for one VM that needs maximum performance.
GPU-P is the opposite design. The host keeps the device, runs the real driver, and lends slices of the device's capacity to multiple VMs. No guest gets bare-metal performance. Every guest gets enough performance to render. The whole point is one-to-many.
For a CS2 farm the choice is not actually a choice. A farm runs many VMs and needs many partitions. You will not buy a separate physical GPU for each VM; that defeats the economics of farming entirely. DDA only works if you have one VM, in which case you do not need a farm in the first place.
The trade-off in plain terms: DDA gives you full performance for one VM. GPU-P gives you usable performance for many VMs. CS2 farming wants the many, accepts the usable, and pays for it by losing the option of running competitive frame rates inside any one VM. That sacrifice is fine because the bot is a bot; it is not aiming for headshots in a tournament.
If you are sizing a single high-stakes account that absolutely cannot share a GPU with anything else, DDA on a dedicated card is the right answer for that one VM, and the rest of your farm runs GPU-P on a separate card. That hybrid is uncommon but legitimate.
Performance: the numbers that actually matter.
Specific frame-rate numbers vary by card, by driver branch, by guest configuration, and by the version of CS2 in play. The shape of the curve is the same across setups, even if the exact values differ. Here is the shape.
One VM on a card by itself, on GPU-P, runs at a small but real discount to the same card on bare metal. Call it a single-digit percent loss to virtualization overhead. CS2 at low settings will run well above 60 FPS on any reasonable modern GPU in this configuration.
Two VMs on the same card halve the available wall-clock time per VM in the simplest case. Real-world drops are smaller than 50 percent because the scheduler is opportunistic and recovers slack when one guest is not actively rendering, but the per-VM frame rate is meaningfully lower than the one-VM case. CS2 still runs comfortably at 60-plus.
Four VMs is where the trade-off starts to feel real on mid-range hardware. Per-VM frame rate drops further, and VRAM pressure begins to matter. On a card with 8 GB of VRAM, four partitions plus the host driver's overhead leaves each guest with under 2 GB, and CS2 will fit but with margins so thin that a texture stream stall is visible.
Eight VMs is the territory where you need a card with serious VRAM (16 GB or more) and where the scheduler overhead starts taking a measurable bite out of total throughput. CS2 at the lowest possible settings can still render, but tuning matters a lot more than it does at lower densities. Check your own post-VM frame-rate numbers with the resolution and settings you actually plan to use; the framing here is relative, not absolute.
The bot does not care about high frame rates, but it does care about consistent ones. Stutter, frame drops, and long pauses break input timing and make the walkbot look mechanical to behavioral detection. Aim for stable rather than fast, and tune VM count down before tuning settings down.
Setup at a high level.
The full click-through setup is on the setup guide. This section explains the shape of it so the click-through reads as a coherent process rather than a sequence of magic incantations.
You enable Hyper-V on the host. You create a VM. You add a GPU partition to the VM with the relevant PowerShell cmdlet (the Add-VMGpuPartitionAdapter family). You copy the host's GPU driver files into the guest because the guest needs them to talk to the partition. You boot the guest, install the guest OS, point Device Manager at the copied driver files, and verify that the virtual GPU shows up without a code 43.
You repeat the partition-and-driver-copy step for each additional VM, scaling out until you hit the VRAM ceiling or the per-VM frame rate floor. Easy-GPU-PV is a community tooling that automates much of this driver-copy dance and is worth using if you are scaling beyond two or three guests; rolling the copy by hand for every VM is a way to introduce drift.
You install CS2 inside each guest, log into Steam, and test that the game launches and renders. Most failures at this stage are not GPU-P failures; they are guest networking, Steam region detection, or VRAM quota issues. The GPU-P-specific failure modes are in the next section.
You configure the bot, schedule the walkbot, and observe what the per-VM frame rate looks like under sustained load. The act of running CS2 inside the VM for an hour at a time will reveal issues that a five-minute smoke test will not, and the per-VM frame rate trend over an hour matters more than the peak in the first minute.
Common gotchas that consume your weekend.
The setup is straightforward in principle. The failure modes are where time disappears. The patterns below cover the majority of real-world debugging.
Driver branch mismatch. The host runs the real driver. The guest runs a driver that has to be compatible with the host driver's partition protocol. If you update the host driver and forget to update the guest, you get a guest that fails to render with a code 43 in Device Manager. The fix is to update both sides to the same branch and reboot. The deeper rule is to pin your driver versions and update host and all guests in lockstep, not opportunistically.
NVENC contention. NVIDIA's encoder block is shared across partitions and is queued, not time-sliced. Two guests trying to record video at the same time will see one of them stall while the other runs. CS2 farming usually does not record video, so this is mostly a non-issue, but if you have any monitoring tool that captures gameplay video from inside the guests, you will trip this and it will look like a frame-rate problem rather than an encoder problem.
Generation mismatch. If the host CPU and chipset do not support certain virtualization features that the GPU partition relies on, the partition will technically create but the guest will see a degraded device with reduced capabilities. Symptoms include the guest GPU reporting a lower compute capability than the physical card, or missing features (no hardware-accelerated certain video codecs, for example). Check the host generation against the GPU partitioning documentation before assuming the card itself is the bottleneck.
VRAM under-allocation. The default partition quota is small. CS2 will launch with a small VRAM allocation but will stutter as textures stream in and out under pressure. The fix is to raise the per-partition VRAM quota explicitly in the PowerShell setup, sized to what CS2 needs at the settings you are using, plus a margin for the guest driver's own overhead.
Host driver crash propagation. A bad host driver update can cascade across every partition because there is one shared driver instance. Test driver updates on one VM at a time before rolling them across the farm, and keep the previous driver installer in a known location for quick rollback. Driver updates are not the safe operation people assume they are in a partitioned setup.
Secure Boot and TPM. Hyper-V Generation 2 VMs want Secure Boot and a virtual TPM by default. CS2 does not care, but Windows update behavior inside the guest can change if you mis-configure either, and a guest that fails to apply updates correctly drifts out of compatibility with the host driver over time. Either lean into the Gen 2 defaults or document explicitly that you turned them off and why.
When DDA actually wins.
The whole post argues GPU-P is correct for a farm. DDA still has a real place; it is just not the farm-wide answer.
DDA is the right call when one VM has to give one account maximum performance and you have a spare physical GPU you can dedicate to it. The single-account, high-stakes scenario where you want zero virtualization tax and full GPU isolation belongs on DDA. The same applies if you are testing something at the edge of what CS2 supports (raytracing, very high resolutions) and the GPU-P scheduler overhead would distort the result.
The hybrid setup is the interesting one. A farm host with one expensive primary GPU running GPU-P for the bulk of the farm, plus one cheaper secondary GPU dedicated to a single VM via DDA for whatever workload needs full performance, is a real and legitimate design. The two paths are not exclusive on the same host as long as the GPUs are physically distinct.
Outside those cases, DDA does not buy a CS2 farm anything. It costs density, which is the thing the farm is trying to maximize. The mental model is: GPU-P is the farm answer; DDA is the exception you reach for when you have a specific reason to.
Frequently asked questions.
What is GPU-P in Hyper-V?
GPU-P (GPU Partitioning) is the Microsoft interface that lets a single physical GPU be split into virtual partitions that can be assigned to multiple Hyper-V VMs. Each partition gets a time-sliced share of compute, a quota of VRAM, and a virtual function exposed to the guest as a fully usable display adapter. CS2 inside the guest sees what looks like a normal GPU and can render at usable frame rates.
Why pick GPU-P over DDA for a CS2 farm?
DDA (Discrete Device Assignment) gives one VM exclusive ownership of a whole physical GPU. That works for one VM at a time. A farm needs four, eight, or sixteen VMs sharing the same physical card, and only GPU-P supports that one-to-many mapping. Use DDA if a single VM needs maximum performance and you have one physical GPU per VM. Use GPU-P everywhere else.
Does GPU-P cut FPS compared to bare metal?
Yes, and the cut grows as you add more VMs to the same physical GPU. A single VM on GPU-P loses a small fraction to virtualization overhead. Two VMs on the same GPU share the time slice and each lose more. By the time you are running four or eight VMs the per-VM frame rate is well below what one VM on the bare GPU would do. The trade-off is fine for CS2 farming because the bot does not need competitive frame rates, but it is not free.
What is the most common GPU-P setup failure?
Driver version mismatch between the host and the guest. GPU-P uses a paravirtualized driver model where the host driver does most of the work, and the guest needs a driver that speaks the same protocol version. If the host runs a newer driver than the guest knows how to talk to, or vice versa, the guest GPU shows up but fails to render, often with a code 43 in Device Manager. Match the driver branches on host and guest before debugging anything else.
Can CS2 detect GPU-P specifically?
Steam and CS2 read hardware identifiers at login and at runtime, and the virtual GPU exposes its own device ID and capabilities string. That is detectable as a virtualized adapter if anti-cheat code chooses to read it. The bigger risk is not GPU-P itself; it is hardware fingerprint correlation across accounts that share the same physical GPU. Isolation work happens at the VM identity layer, not at the GPU layer.
Going further.
The mental model above is the part of GPU-P that does not depend on which card you bought. The actual cmdlets, partition counts, and VRAM quotas depend on your hardware. The click-through walkthrough on the setup guide takes you from a fresh host to a working VM with a partitioned GPU. The wider context of running a multi-VM farm, including identity isolation and account-level safety, lives on CS2 multiple accounts farming. Read both before scaling past two guests.