Do you need a dedicated GPU to run scrcpy?

No. scrcpy runs fine on a laptop with only integrated graphics, and a dedicated card would mostly sit idle while it does. That is the short answer to the question behind scrcpy issue 1545 on GitHub. The rest of this is the reasoning, so you can check it against your own machine.

scrcpy is a free, open source tool from Genymobile that shows your Android phone’s screen in a window on your computer and lets you control it with your mouse and keyboard. If you’re about to buy or repurpose a PC to run it, whether as a test bench or a small phone farm, it helps to know which parts of that PC do the work. Otherwise you can spend money on the wrong part.

what it is

scrcpy mirrors an Android device connected over USB or TCP/IP and lets you control it from the computer. The project README says it needs no root access and runs on Linux, Windows and macOS. It reaches the phone through adb, the Android Debug Bridge, so USB debugging has to be switched on first.

It is not an emulator. Your apps keep running on the phone. The computer shows a video of the screen and sends your input back.

A dedicated GPU, also called a discrete GPU, is a separate graphics card such as an Nvidia GeForce or an AMD Radeon RX, with its own video memory. An integrated GPU is the graphics block built into the CPU or the main chip, and it shares system RAM. Intel UHD and Iris Xe, the graphics in AMD’s Ryzen APUs, and Apple’s M-series chips are all integrated.

So the real question is whether scrcpy asks enough of the graphics side to need the first kind.

It doesn’t.

how it works

scrcpy has two halves. A small server program gets pushed to the phone over adb and started there. A client on your computer receives the video and puts it on screen. One frame goes through these stages:

The phone captures its own screen.
The phone encodes the frames, H.264 by default, using its own encoder (usually a hardware one in the chip) through Android’s MediaCodec API.
The compressed stream travels to your computer through a tunnel that adb sets up, over USB or Wi-Fi. If the split between adb’s client, server and daemon is new to you, this explainer covers it.
The client unpacks the stream and decodes it with FFmpeg.
SDL, a cross-platform library for windows, input and drawing, turns each decoded frame into a texture and draws it in a window.
Your mouse and keyboard events travel back the other way, and the server injects them into the phone as touches and key presses.

Two of those stages use video hardware on your side, decoding in step 4 and drawing in step 5, and neither asks for much.

Decoding first. The client hands the stream to FFmpeg, and as far as I know it decodes in software on the CPU rather than using a graphics card’s video decoder, such as Nvidia’s NVDEC. FFmpeg can do hardware decoding in general, but it has to be asked to, and I’m not aware of a scrcpy option that asks. That’s my understanding as of September 2026, and a new release could change it, so check the release notes for your version. Running scrcpy --version prints the FFmpeg and SDL versions your build uses.

So even if you drop a GeForce into the machine, the decode still lands on the CPU.

Drawing second. SDL asks the operating system for a renderer (Direct3D, OpenGL or Metal, depending on the platform) and uploads each decoded frame as a texture. That’s a light job for any integrated GPU. If no usable renderer exists, SDL can fall back to a software one, and scrcpy’s --render-driver option lets you pick a driver, software included.

So when are integrated graphics enough? For one phone on one desktop, nearly always. The cases where I’d look twice are a virtual machine or remote desktop session that doesn’t expose a GPU, where drawing tends to fall back to the CPU, a machine with a very old graphics driver, where switching --render-driver may help, and a wall of many scrcpy windows on one screen. Those are edge cases, and I haven’t tested any of them for this article.

The one expensive stage, encoding, happens on the phone. The options --max-size, --max-fps and -b (bit rate) shrink what the phone encodes and what your CPU has to decode. With --max-size 1024, for example, the phone scales the video down before it ever leaves the device.

why it matters

Knowing where the work lands changes what you buy and what you tune. Four places it shows up:

An old laptop or a cheap mini PC with integrated graphics is a perfectly good scrcpy machine. My view, and some people will disagree: put the money into a decent USB cable and a powered hub before any graphics card. Flaky cables cause more scrcpy trouble than weak graphics ever will.
Once one PC runs many phones, CPU cores and USB bandwidth become the limits, not the graphics card. Every phone adds a stream to decode and a window to draw. I haven’t measured how many streams a given CPU can handle, and it will vary with resolution and frame rate, so test on your own hardware. Farm projects are covered in the open source Android device farm tools roundup.
Lag hunting gets shorter. If you play or test games through scrcpy, the delay usually starts at the phone’s encoder or the link between phone and PC before it starts at the decoder. The low-latency gaming configuration walks through those settings.
Troubleshooting gets a map. A hot phone that stutters points at the encoder. Stutter over Wi-Fi with a healthy phone points at the connection. A choppy window with one CPU core pinned points at decoding.

One more case, and it’s our own product, so weigh it accordingly. Sometimes the GPU question is a stand-in for a bigger one: how do I get a real Android phone on a Singapore mobile connection in front of me without building a desk full of hardware? cloudf.one rents real Android phones in Singapore on dedicated hardware, each with a persistent Singapore mobile IP, controlled from the browser. It is Singapore only. As of September 2026 there is no self-service adb: adb and Appium reach a rented phone only through a WireGuard tunnel that we set up on request (email [email protected]), so if scrcpy is what you need, ask us before you plan around it. And as always, only test apps and devices you own or are authorised to test.

common misconceptions

Four wrong takes, corrected:

“It streams video, so it needs a graphics card.” Decoding runs on the CPU through FFmpeg, and the drawing step is one texture per frame. A dedicated card helps with other things on the same machine, like games or OBS encoding with NVENC, but scrcpy itself doesn’t need it.
“A better GPU will fix my lag.” Lag usually lives elsewhere: a weak cable or USB port, a congested Wi-Fi network if you’re on wireless adb, a bit rate too high for the link, or the phone’s encoder. Lowering resolution, frame rate and bit rate costs nothing and is quicker than a hardware purchase. The guide to scrcpy settings for lag and stuttering has the specifics.
“The computer does all the work.” The phone does the most expensive step. Old or budget phones, and the odd vendor encoder, can be the weak link. On recent scrcpy releases scrcpy --list-encoders shows what the phone offers and --video-encoder picks one, which is worth a try before you blame the PC.
“No monitor and no GPU means no scrcpy.” A headless server has no display for the window to live on, which is a different problem from having no GPU. Two leads: a virtual display such as Xvfb with SDL’s software renderer, or recording without opening a window at all (see stopping an scrcpy recording programmatically on Windows). I haven’t set up either for this article, so treat them as leads and not a recipe.

where to go from here

If this answered your question, these are the next things I’d read:

best scrcpy settings to fix lag and stuttering: the flags that change the load on both ends.
best way to stop an scrcpy recording programmatically on Windows: for when you run scrcpy without a window.
best open source Android device farm tools: for when one phone turns into ten.
best adb GUI tools: if you would rather click than type flags.

The whole archive is on the blog index.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-09-27.