protonscr

Remote Play (Linux client): since Oct 13 stable, HEVC always uses "VAAPI Vulkan" and shows triangle tearing; VAAPI DRM path no longer used

steamopen Intel driversStreaming
ValveSoftware/steam-for-linux#13782 · opened 2026-10-21 by rhythmthief · updated 2026-10-26 · 2 comments · github
Rrhythmthief 2026-10-21 github

Your system information

  • Steam client: stable, streaming_client build 20261013184420. Tested with both the regular client and the SteamRT3C client.
  • Distribution: Bazzite 44.20261012.1 (Fedora 44 base), KDE Plasma Wayland (KWin 6.7.5)
  • Kernel: 7.2.9
  • CPU / GPU: Intel N100 / Alder Lake-N UHD Graphics [8086:46d1]
  • Mesa 26.2.4 (ANV), libva 2.24.1, intel-media-driver (iHD) 26.3.5
  • Host: Windows PC, wired LAN
  • Stream: 3840x2160 @ 60, HEVC, SDR

Please describe your issue in as much detail as possible:

Before the Oct 13 stable update, Remote Play on this box decoded HEVC through "VAAPI DRM hardware decoding" and the picture was clean.

Since the Oct 13 update, the performance overlay always shows "VAAPI Vulkan hardware decoding". The image has constant triangle and diagonal tearing and block artifacts. It looks like the two triangles of the video quad show different or partly written frames. It happens even at 10 Mbps, so it is not bandwidth or packet loss.

What I tried:

  • Pyrowave is off. I reset the Remote Play client settings to defaults (deleted ClientConfig in localconfig.vdf). Still VAAPI Vulkan.
  • I opted out of the SteamRT3C client (Pyrowave is now greyed out). The regular client also picks VAAPI Vulkan.
  • I launched streaming_client with --opengl, using both the SteamRT3C and the regular ubuntu12_64 client. The stream works, but VA-API is never initialized: LIBVA_MESSAGING_LEVEL=2 logs nothing. The overlay shows "libavcodec software decoding (4 threads)". That is artifact-free but stutters at 4K on this CPU.
  • SDL_VIDEO_FORCE_EGL=1 and SDL_VIDEO_DRIVER=wayland with --opengl made no difference: still software decoding.
  • HDR is off on both ends.
  • vainfo works and reports HEVC Main/Main10 VLD on iHD.

So on this hardware the only hardware decode path left is VAAPI→Vulkan, and it tears. The VAAPI DRM (EGL/dmabuf) path that used to work is no longer selected, even with --opengl.

Expected: either the VAAPI DRM path is still available (by default, or via --opengl or a setting), or the VAAPI→Vulkan path displays frames without tearing. A missing sync between VA decode and Vulkan sampling, or a tiling modifier mismatch, could explain the artifacts.

Steps for reproducing this issue:

  1. On an Intel Alder Lake-N (N100) Linux client with Mesa 26.2.4 and iHD 26.3.5, use the stable Steam client from Oct 13 or later.
  2. Stream HEVC at 4K60 from a Windows host.
  3. The overlay shows "VAAPI Vulkan hardware decoding", and the image has triangle tearing.
  4. Launch the client with --opengl. It falls back to libavcodec software decoding instead of VAAPI DRM.

The Oct 9 beta notes say "Enable Vulkan video decoding when using the SteamRT3C Linux beta". This regression appears to come from that change, which reached stable on Oct 13.

I can provide the host's streaming_log.txt (CLIENT: lines) on request.

Ddjdeath 2026-10-21 github

Can you try setting the environment variable export anv_external_memory_implicit_sync=true

VAAPI is implicitly synchronized unlike Vulkan so buffers shared from that API can be read unsynchronized in Vulkan, causing misrendering. That option comes with a performance cost.

MMazK5 2026-10-26 github

Same problem, enabling hardware decoding or hevc causes tearing/shutterings on host (intel igpu), using cpu decoding fixes the issue but it causes latency/packet loss. same problem on steam link flatpak version.

Launch options