I'm building Waydesk, a free, open-source remote desktop service for Debian and Ubuntu. The goal is narrow: a light, responsive RDP service where every account on a server gets its own desktop, built on Sway and Wayland.
- Standard RDP, so people connect with the client they already have (Windows App, mstsc, Remmina, FreeRDP). Nothing to install on their side.
- One complete desktop per account: a headless Sway session with a bar, dock, launcher, file manager, terminal and browser. It is assembled from Sway and a Qt shell rather than shipped as one GNOME or KDE package. Sessions persist when you disconnect.
- Aimed at shared servers: labs, courses, support desks, small teams, and service providers who run Linux servers for others, anywhere a ready desktop per person on a server you already run is easier than a laptop each.
- No GPU required, but one is used when there is one.
The usual alternatives are a full desktop environment (GNOME, KDE, Xfce) behind xrdp, or VNC. "Light" and "responsive" are claims, so I wanted numbers behind them. The question that decides whether this is practical: how many people fit on one server? And the one I most wanted to answer: does a GPU change that answer?
I tested both on rented servers by adding simulated users one at a time until the server refused one. Short version: memory decides how many fit, and the GPU did something different from what I expected. I did not compare against other remote-desktop stacks, so these numbers show what Waydesk does, not that it beats anything.
First, what limits you: memory
Every logged-in user keeps a session alive, with their programs open, whether or not they're looking at the screen. So the number that counts is how many accounts are logged in, not how many are typing.
Per user, measured:
| Kind of user | Memory each |
|---|---|
| Desktop only | about 0.4 GB |
| Plus Chromium with three pages | about 0.7 GB |
| Heavy: Chromium, a 300,000-row spreadsheet, VS Code | about 1.6 GB |
And how many fit, without a GPU:
| Server | Result |
|---|---|
| 4 GB | 5 users with a browser |
| 8 GB | 9 users with a browser, or 8 heavy users |
| 23 GB, 12 cores | 12 heavy users; the 13th was refused |
Without protection the 4 GB server crashed at five users: the kernel's out-of-memory killer shut down parts of people's desktops. Two things fixed it: a new login is turned away when too little memory is free (someone already logged in is never kicked out for a newcomer), and compressed swap (zram) squeezes idle memory about 4.5 to 1. On the 8 GB server that took heavy users from 6 to 8. The details are in the measurements.
In these runs the programs were opened and then left idle, so they are best-case numbers.
The GPU test
For this I used a dedicated Intel i7-7700 (4 cores, 8 threads) with its integrated HD 630 GPU and 64 GB of memory. The users were active, not idle. Each one had:
- Chromium on a page that scrolls by itself,
- a terminal typing and printing output,
- LibreOffice Calc with a 300,000-row sheet and VS Code, both receiving keystrokes,
- window switches every 15 to 30 seconds,
- a muted looping video for every fourth user, GIMP on a large image for every fourth, and sound for three.
The RDP clients ran on a separate cloud server in the same data centre, so decoding 20 video streams wouldn't eat the CPU I was measuring.
I ran the ramp twice: GPU on (sway rendering on the GPU, VAAPI hardware H.264 encoding, zero-copy capture) and GPU off (software rendering, OpenH264 on the CPU).
| Active heavy users | CPU, GPU on | CPU, GPU off | free memory, GPU on | free memory, GPU off |
|---|---|---|---|---|
| 1 | 23 % | 21 % | 53.4 GB | 53.6 GB |
| 10 | 47 % | 45 % | 32.7 GB | 35.8 GB |
| 20 | 50 % | 69 % | 10.7 GB | 16.6 GB |
| 24 | (22nd refused) | 94 % | 8.5 GB |
GPU on: 21 users fit, the 22nd was refused. GPU off: 24 fit, the 25th was refused. Memory ended both runs.
So the GPU did not let more people in, but it changed two other things:
- It took the load off the CPU. With the GPU, CPU use stayed near 50 % from 15 users on. Without it, it climbed 3 to 4 points per user. The capture-and-encode processes used 4.8 % of the machine with the GPU at 20 users, against 15.4 % without (about 70 % less). On a machine with more memory, that headroom should fit more users. I estimated that; I did not measure it.
- It used more memory. 2.24 GB per user against 1.95 GB, because an integrated GPU takes its buffers from system RAM. A card with its own video memory wouldn't do this, but I haven't tested one under many users.
Nothing failed in either run: no errors, no dropped frames, no out-of-memory kills.
Where the GPU clearly matters: graphics-heavy pages
I also ran a full-screen WebGL noise page for each user, which is a deliberately brutal case:
| Users | Frame rate per page (median) | GPU render engine |
|---|---|---|
| 1 | 60 | 53 % |
| 2 | 60 | 93 % |
| 3 | 47 | 100 % |
| 6 | 20.5 | 100 % |
| 12 | 17 | 100 % |
An HD 630 gives two users 60 fps, and then its render engine is the limit: the frames get shared about evenly. Lighter pages share among more people.
And without a GPU the page didn't animate at all in the browser. As Waydesk starts Chromium, it uses --disable-gpu when there is no usable render node. If your users need WebGL, a GPU isn't an optimisation but a requirement.
What happens when the GPU can't help
Two cases I checked, because they affect real deployments:
- GPU present but no hardware encoder. The session still works; the H.264 encoding falls back to OpenH264 on the CPU, and the log says so. One user on the WebGL page went from 2.9 % of the machine (VAAPI) to 12.3 % (CPU encoder). This is what an NVIDIA card looks like to VAAPI, so I wrote an NVENC encoder as well: on an RTX 4000 SFF Ada, one user ran at 61 fps with the card's encoder 4 % busy. That was one user on one card; several users on one card are not measured. It also needed NVIDIA's own 615 driver, since Debian's 550 can't give a headless sway its buffers.
-
Render node present but the GPU switched off. An OpenGL app (
glxgears) falls back to the CPU and opens; a Vulkan one (vkcube) fails to present its window. On a server with no render node at all,vkcubeopened on Mesa's software drivers. Odd, but worth knowing before you debug it.
What I'd tell someone sizing a server
- Memory first. About 0.4 to 0.5 GB per session for the desktop, plus what the programs use, plus about 1 GB for the system. Heavy users cost 1.6 to 1.85 GB.
- Add zram and size it to RAM, and refuse new sessions when the machine is full instead of degrading everyone.
- A GPU buys CPU headroom, not more users, unless you have the memory to use it. Graphics-heavy work (WebGL, video, 3D) is where it becomes necessary.
- Check your own hardware. My results were one user off between a VM and a real server.
What I didn't measure
How fast individual applications feel with and without the GPU (apart from WebGL), the delay between a click and its picture, a discrete card under many users, AMD, long runs (each ramp took about 45 minutes), and far-away clients on slow links with many users.
Waydesk is early and has had no independent review. If you want to try it, or compare your numbers with mine, the testing checklist is in issue #1. The full method, tables and raw data are in docs/MEASUREMENTS.md and docs/measure-data/.
Top comments (0)