Virtualization workstation with the Intel Arc Pro B50

A forum poster documented running three active virtual functions (VFs) with simulated hardware-accelerated graphics on a single Intel Arc Pro B50 GPU, using driver 32.0.101.6979 (max 12 VFs, 4 configured) and kernel 7.2.9, with Wendell of Level1Techs viewing the setup through Looking Glass alongside Linux guests. The poster traced lag in rustdesk and remmina on Hyprland to a default capture chain that copies each frame roughly 3–4 times plus one full conversion — about 14.7 MB per pass, or 1.7 GB/s of memcpy at 30 fps on 2560×1440 — and removed the GStreamer stage to pass native Wayland screencopy directly to the encoder, cutting it to 0 copies and 0 conversions. The poster said the result does not match Looking Glass performance but meets the goal for productivity.

After my adventures on local LLM hosting https://forum.level1techs.com/t/poor-er-mans-local-ai/252071 and putting it to work with OpenFromSource https://forum.level1techs.com/t/openfromsource/259444 , I finally got to come full circle. You know, OpenFromSource has more overlap with the current thread than meets the eye. First and foremost, I saw it as a natural progression on the computer hygiene concept from the first post. It also lowered the bar for me to apply the Hyprland mod from @the vgpu supplier https://forum.level1techs.com/u/the vgpu supplier . Probably too much to dive into here, but I did dedicate a full tutorial https://github.com/ingenerics/OpenFromSource.Tutorials/blob/main/tutorials/6 hyprland from source.md on aligning a legacy version of Hyprland with Debian Trixie using OpenFromSource. Behold, 3 active VFs with simulated hardware accelerated graphics. Wendell through looking-glass https://looking-glass.io/ and a couple of linux guests with light action. A single B50 providing the juice php Driver 32.0.101.6979 - max VFs = 12 - num VFs = 4 Kernel 7.2.9 - can be used to cap VF max memory When I first got remmina and rustdesk working with the headless VM, I was surprised by the lag like when typing . Especially with the host and the guest being on the same box. After a brainstorming session with my local DeepSeek https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731 , turned out the default capture chain with rustdesk on wayland looks like this: Hyprland ──zwlr screencopy──► xdph portal backend │ PipeWire Video/Source, DMA-BUF + SHM ▼ pipewiresrc gstreamer consumer │ videoconvert appsink BGRx/RGBx ▼ rustdesk encoder ──► viewer direct IP It’s generic, of course, which can definitely be a plus, but with direct IP access I just wanted to get the best performance on Hyprland without a full rewrite . Decided to surgically remove the gstreamer part… … and directly throw the native wayland screencopy over the fence. Performance benefit per frame, stock vs direct: STOCK compositor → wlroots screencopy → xdph buffer → memcpy → PipeWire buffer → pipewiresrc always-copy=true → memcpy → gstreamer → videoconvert full conversion → appsink → encoder ≈ 3–4 full-frame copies + 1 conversion/frame ≈ 14.7 MB × ~4 passes ≈ 1.7 GB/s memcpy at 30 fps on 2560×1440 DIRECT compositor renders INTO our SHM buffer → encoder = 0 copies, 0 conversion I wouldn’t go as far as saying it now performs like looking-glass, but for productivity it’s definitely what I was hoping for.