Shared Intel UHD 770 under full load: a 20-minute GPU stress test

On a GPU VPS, the integrated Intel UHD 770 is shared between several servers. The question a buyer should ask is not “does it work when I’m alone?” but “what happens when every server on the GPU hits it at the same time?”. On 2026-11-01 we ran exactly that: multiple servers loading the same shared GPU at the same time, for 20 minutes, until it was saturated. Short answer:

0 failed jobs and 0 GPU hangs on every server, no GPU reset on the host.
With the GPU saturated, each transcoding server still ran at about 1.3× real time for 1080p H.264 encoding and for 4K HEVC → 1080p H.264, and about 0.7× real time for 4K AV1 → 1080p HEVC.

Test setup

Item	Value
Host CPU / GPU	Intel Core i5-13500, integrated Intel UHD 770
Hypervisor	Proxmox VE 9.2, kernel 7.0.14-pve
GPU virtualization	Intel i915 GPU virtualization driver (out-of-tree module), GuC submission, CCS enabled
Test servers	Debian 13, 2 vCPU, 4 GB RAM each, cloned from our production template
Guest kernel / driver	Linux 7.3, same i915 out-of-tree module, CCS enabled (`ccs0` visible)
Vulkan setting in guests	`ANV_SPARSE=0`
GPU priority	identical on every server (our Perf 1 setting)
Duration	20 minutes, all servers started together

Each server ran the same script with a different profile: loadtest_gpu.sh <profile> 1200. The script loops a job until 1,200 seconds have elapsed and logs ok or FAIL for each cycle.

The four workloads

Workload	What one cycle does
H.264 1080p encode	Encode 60 s of 1080p30 video to H.264 with VAAPI (classic encoder, not `low_power`), 8 Mbit/s
4K HEVC → 1080p transcode	Decode a 30 s 4K HEVC 10-bit clip on the GPU, `scale_vaapi` to 1080p, encode to H.264 at 8 Mbit/s (a typical Plex/Jellyfin transcode)
AV1 4K → HEVC 1080p	Decode 30 s of 4K AV1 on the GPU, scale to 1080p, encode to HEVC at 6 Mbit/s
Vulkan/OpenCL loop	`vulkaninfo` + `clinfo` + `gpu-check` (VAAPI, Vulkan, OpenCL, OpenVINO) in a loop

The core commands, if you want to reproduce them on your own server:

R=/dev/dri/renderD128

# H.264: 1080p30 synthetic source -> H.264 VAAPI
ffmpeg -vaapi_device $R -f lavfi -i testsrc2=size=1920x1080:rate=30 -t 60 \
  -vf format=nv12,hwupload -c:v h264_vaapi -b:v 8M -f null -

# Plex-style: build a 4K HEVC Main10 source once, then transcode it to 1080p H.264
ffmpeg -vaapi_device $R -f lavfi -i testsrc2=size=3840x2160:rate=30 -t 30 \
  -vf format=p010,hwupload -c:v hevc_vaapi -profile:v main10 -b:v 40M -y src.mkv
ffmpeg -vaapi_device $R -hwaccel vaapi -hwaccel_output_format vaapi -i src.mkv \
  -vf scale_vaapi=w=1920:h=1080:format=nv12 -c:v h264_vaapi -b:v 8M -f null -

# AV1: 10 s 4K AV1 source (CPU encode, SVT-AV1), looped 3 times per cycle
ffmpeg -f lavfi -i testsrc2=size=3840x2160:rate=30 -t 10 \
  -c:v libsvtav1 -preset 12 -y src.mkv
ffmpeg -vaapi_device $R -hwaccel vaapi -hwaccel_output_format vaapi -stream_loop 2 \
  -i src.mkv -vf scale_vaapi=w=1920:h=1080 -c:v hevc_vaapi -b:v 6M -f null -

The UHD 770 decodes AV1 but cannot encode it, which is why the AV1 source is created on the CPU and the output is HEVC.

Results

All numbers below were measured per server while the GPU was saturated by every test server at once.

Workload	Successful cycles per server (20 min)	Time per cycle	Speed vs real time
H.264 1080p30 encode	26	~46 s for 60 s of video	~1.3×
4K HEVC 10-bit → 1080p H.264	49–55	~22–24 s for 30 s of video	~1.3×
AV1 4K → HEVC 1080p	28	~43 s for 30 s of video	~0.7×
Vulkan/OpenCL loop	238	n/a	n/a

The cycle counts and speeds agree: 26 cycles × 60 s is 1,560 s of video encoded in 1,200 s, and 28 AV1 cycles × 30 s is 840 s of video in 1,200 s. Two servers running the same 4K transcode did 49 and 55 cycles, so throughput is not perfectly equal between servers doing the same job.

How “0 hangs” was checked, on every server after the run:

journalctl -k -b | grep -iE "gpu hang|context reset|reset.*engine|guc.*fail"

The output was empty everywhere. On the host, the kernel log had no GPU HANG, no GT reset and no “wedged” GPU. The only “reset” lines were the normal PCI device resets when each test server started.

What this means if you rent a server on a shared UHD 770

Isolation held. Continuous transcodes on several servers plus a Vulkan/OpenCL loop did not crash anyone’s GPU context, and nothing reached the host.
Even with the GPU saturated, one server still transcodes faster than real time for 1080p H.264 and for 4K HEVC → 1080p. That is enough for one live stream per server even when every neighbour is busy.
AV1 4K sources are the heavy case: at ~0.7× they do not keep up in real time when the GPU is saturated. If you serve AV1 4K files to clients that need a transcode, expect buffering under heavy neighbour load.
The whole GPU is finite. In this test and in an earlier 20-minute run on another UHD 770 host, a saturated GPU delivered in the order of 2 to 3 real-time 4K transcodes in total per GPU, across all servers. When the GPU is idle, a single server goes much faster: our Jellyfin & Plex article measured 12× real time for 4K HDR → 1080p with the low-power encoder.

In practice: for a personal or family media server, a few concurrent 1080p transcodes are realistic; for a service that must guarantee many simultaneous 4K transcodes, one shared iGPU is the wrong tool.

The lesson behind “0 hangs”: the i915 CCS setting must match

Earlier test rounds did show GPU hangs on the render engine inside the guests. The cause was not the kernel version nor the load: it was the i915 CCS (compute command streamer) setting differing between the host and the guests. Recent versions of the out-of-tree i915 module disable CCS by default on this GPU generation, while older guest drivers assume it is on. A mismatch made either 3D/Vulkan or VAAPI encoding hang, depending on the combination. With CCS enabled on both the host and every guest, the hangs disappeared, and this 20-minute run is the confirmation.

If you virtualize an Intel iGPU yourself, check it on both sides:

cat /sys/module/i915/parameters/xelp_enable_ccs   # Y on host AND guests
ls /sys/class/drm/card*/engine/ | grep ccs        # ccs0 should be listed

Second lesson: Vulkan sparse binding in Mesa’s ANV driver triggered a GPU hang per vulkaninfo run in a guest, so our servers ship with ANV_SPARSE=0. Containers (Docker, k3s) have their own environment and need it set separately.

Limits of this test

Synthetic input. Sources are generated with ffmpeg’s testsrc2 pattern, not real films. Real content, HDR tone mapping, audio and subtitles add work.
20 minutes. It shows the absence of hangs under sustained load, not months of uptime.
Equal GPU priority. Every test server used our Perf 1 setting. Perf 2 and Perf 3 plans get a larger share of the GPU when everyone is loading it; this test did not measure that split.
Small test servers. They had 2 vCPU and 4 GB RAM; the AV1 source was encoded on the CPU once, before the loop.
One GPU generation. Results apply to the UHD 770 (Alder Lake / Raptor Lake iGPU) with the drivers listed above.

Try it

Our servers run on this exact stack, hosted in Germany: a UHD 770 GPU inside the VM with VAAPI, Vulkan and OpenCL preinstalled, root SSH, dedicated IPv6. Plans from €14.99 excl. VAT/month (Perf 1), €29.99 (Perf 2) and €44.99 (Perf 3), flat price.