2.2.3

PixelFlux 2.2.3

A release that captures an NVIDIA X server through DRI3 before NvFBC, keeps the paced capture paths at their rate when an encode or a timer tick runs late, encodes the Wayland compositor's zero-copy session on its own thread, holds NvFBC at 240 frames a second, hands a still host's frame back to the portal stream, which kept KDE's cursor updates from reaching the client, and keeps VA-API's import of each recurring buffer, with fixes to live frame-rate changes on DRI3 and NvFBC and to constant-rate H.264 above level 5.2 on Intel's iHD.

Capture & Pacing

• DRI3 before NvFBC : on an NVIDIA X server both zero-copy paths serve the session, and DRI3 is now tried first. It reaches the encoder sooner and at 55-65 % of NvFBC's CPU: a 50 Hz flip to its frame in 3.48 ms against 3.86-3.95, a 240 Hz client at 16 % of a core against 27 %, 418-426 frames a second uncapped against 372-373. It also composites the cursor and the watermark on the GPU. NvFBC still serves a driver without GBM, and XShm the rest
• NvFBC at 240 frames a second : the capture asked the driver for the screen's size every 30 frames, which took about 15 ms on an NVIDIA Xorg, and streamed 210-222 frames a second of 240 with a stall every 30 frames. It now watches the root window for a resize on an X connection of its own, and holds 240 with a 99th-percentile frame gap of 5 ms where it was 18-21
• A late encode or timer tick keeps the rate : the paced paths (XShm, DRI3, the Wayland compositor) ended a window early on a late timer tick, and gave up the window a change was due for when it was taken after a long encode. A loaded session now keeps its rate: Firefox at 240 frames a second over WebSockets 221 -> 234-235, and DRI3 under Firefox's Aquarium 233-235 -> 240
• Frame callbacks on the window boundaries : a captured Wayland display answers its clients once a window, as a display's vblank would. Chrome at 240 frames a second draws 98 % of its frames within a quarter period, where it drew 76-78 %, and Firefox's rate rose from 120 to 147-152
• The zero-copy session encodes on its own thread : the compositor's GLES composite is encoded off the thread that serves clients and input. A GL client drawing as fast as it can went from 355 to 464-469 frames a second, Firefox at 240 from 147-152 to 181-195 (219-224 under the performance governor), and a frame-callback client's redraw reaches the encoder about a millisecond sooner. It costs some CPU: Chrome at 240, 32-33 % -> 37 % of a core

Encoding & Pipeline

• NVENC keeps a registration per capture buffer : NvFBC on driver 615 hands back two buffers in turn, and the encoder registered and mapped the other one on every frame. It now keeps one registration per buffer
• A cleanup a lost frame took is redone on DRI3 and NvFBC , as on the readback paths and Wayland
• VA-API keeps the surface over each recurring dmabuf : a zero-copy session imported every DRI3 or Wayland buffer anew and bound it into the GPU's address space on each submission. On an Arc A750 at 1080p and 240 frames a second, server CPU fell from 21-22 % to 16.5 % of a core and an encode from 2.9 to 2.7 ms; a repainted buffer still encodes its latest picture on radeonsi (by @thelamer)

Resilience & Fixes

• Portal host capture : a still host's frame, software or GPU, is copied and its buffer handed back to the stream, so KWin, short of buffers, no longer drops the cursor updates of a still KDE desktop (8 of 8 pointer moves reach the cursor metadata, where 3-5 did). The host pointer is placed in Selkies' display layout, and answers none where the host paints its own cursor (#61, by @sgtslaughta)
• NvFBC's grab timeout is rounded up to the frame's deadline, so a grab no longer gives up ahead of it
• Half the frame rate on Wayland apps whose frame callbacks were still in use (by @thelamer)
• A live frame-rate change reaches the encoder on DRI3 and NvFBC : a change landing while the capture waited for a frame set the pacing and left the encoder at the old rate, so a session raised from 60 to 240 frames a second coded its constant-rate target several times over (by @thelamer)
• Constant-rate H.264 above level 5.2 on Intel's iHD : at 2160p above 64 frames a second the driver's rate control was handed a maximum frame size of 0 and every picture after the key frame came out undecodable; the driver is now told 5.2 while the stream declares the level it needs (by @thelamer)
• A sweep no longer panics on a band taken back late : a cleanup band the encoder took back, reported after the next band had begun, shortened the band the sweep sizes from past zero, and a clamp panicked: the encode thread died and the stream froze on a still NVENC desktop cleaning up after a narrowing
• A compositor that falls back to software offers no dmabuf : where EGL came up on a render node but the render target could not be allocated (a virtual GPU), the compositor rendered in Pixman with linux-dmabuf still advertised, refused every dmabuf a client sent, and a nested kwin_wayland died of the protocol error (selkies-project/selkies#504). It now advertises the GPU only once its renderer is up

Build & CI

• Tests: the NvFBC frame count waits for its session, and a VA-API test feeds two recurring dmabufs repainted between frames