mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-11-14 12:53:43 +01:00
LGUG2Z
1915d6ac26
On a host whose GPU can encode H.264 (a Windows driver through d3d12 on WSL 2 does), KRDP in
the demo guest encoded on the guest's CPUs. The host side was fine (vainfo on the host lists
H.264 and HEVC EncSlice), and virgl can pass a guest's VA-API video to it, but a chain of seven
problems stood between the two. Each is a patch, and the guest takes them all:
QEMU (nix/dev/qemu-virgl-video.patch)
QEMU never asks virglrenderer for video: virglrenderer turns it on only for an embedder that
passes VIRGL_RENDERER_USE_VIDEO and a get_drm_fd callback to open the host's video device on.
The flag is defined only with VIRGL_RENDERER_UNSTABLE_APIS, which the build sets.
virglrenderer 1.3.0, four patches in this order
virglrenderer-chroma-format.patch
the guest's Mesa and virglrenderer number the chroma format of a codec differently: 4:2:0
was read as 4:2:2, and the host's encoder refused every codec it was asked for
virglrenderer-video-memory-upload.patch
the d3d12 driver has no dma-bufs: vaExportSurfaceHandle fails, nothing was uploaded and
the encoder returned an empty bitstream. The planes of the guest's picture are read back
(glReadPixels) and written to the surface through a derived image (vaDeriveImage, with
vaCreateImage and vaPutImage as a fallback)
virglrenderer-h264-packed-sps.patch
Mesa's VA-API takes the level of the stream from a packed SPS, which virglrenderer never
sent: level 0 reached UNREACHABLE in the d3d12 encoder and crashed QEMU
virglrenderer-ubo0-constants.patch
a constant buffer 0 bound as a buffer was never read by the shader, so the colour matrix
of an RGB to YUV conversion was zero and the picture was a solid green
Mesa 26.2.5 in the guest, two patches (hardware.graphics.package)
mesa-virgl-rgb-yuv-csc.patch
the graphics compositor never loaded an RGB to YUV matrix, and multiplied by the YUV to
RGB one of its initial state
mesa-virgl-fence-leak.patch
a surface kept the out-fence (a sync_file) of its last flush and the next flush stored a
new one over it: one file descriptor leaked per converted frame, 44 a second under motion,
and KRDP froze when it reached the limit of 1024, about 28 seconds in
KRDP (krdp.nix) asks for H264Baseline and the guest's driver lists Main and High, so ffmpeg's
h264_vaapi found no profile it could use: it is built with H264Main.
What was checked: a luma ramp and a colour-bar pattern encoded through the guest to the 4090
decode to the right values; the real desktop shows over RDP in Windows' own client with the
right colours; under es2gears motion the descriptors of krdpserver stay flat (3 sync_file, 78
of 1024) where they were 949 of 1024 after 28 seconds.
run-kde sets what the host needs for Mesa and for virglrenderer's libva to find the Windows
driver, on WSL 2 with the GPU on and unless it is set already: GALLIUM_DRIVER=d3d12,
LD_LIBRARY_PATH with /usr/lib/wsl/lib first, LIBVA_DRIVER_NAME=d3d12 and LIBVA_DRIVERS_PATH
(/run/opengl-driver/lib/dri, for the d3d12 video driver, which it looks for). --doctor checks
for the libraries and for that driver, and the tests have a scenario for each.
Known: the software decoder warns "illegal short term buffer state detected" on the stream; the
d3d12 encoder writes Constrained Baseline whatever profile is asked for. There is no binary
cache: the first run builds QEMU and Mesa, which takes about 20 minutes. QEMU, virglrenderer and
Mesa are the runner's and the guest's only, and the VM suites build the Mesa as well.
Not measured yet: whether it is smoother than the CPU encoder under the same load.
55 lines
2.9 KiB
Diff
55 lines
2.9 KiB
Diff
virglrenderer: read the chroma format of a video codec in the guest's numbering
|
|
|
|
The guest's Mesa (26.2.5) sends a video codec's chroma format as the number of its own
|
|
pipe_video_chroma_format, which since the enum moved to u_format.h is NONE, 400,
|
|
420, 422, 440, 444 (0 to 5). The enum of virglrenderer, generated by
|
|
u_format_table.py, is 400, 420, 422, 444, 440, NONE, so 4:2:0, which is 2, is read as
|
|
4:2:2 and VA-API's encoder, which has no 4:2:2, refuses the codec: "format 0x2 not
|
|
supported, supported formats: 0x1". The guest's encode then returns no data at all.
|
|
|
|
This reads the number as Mesa's. It is for a guest whose Mesa numbers it that way: a
|
|
guest whose Mesa still numbers it as virglrenderer does would be read wrongly.
|
|
|
|
|
|
diff --git a/src/vrend/vrend_decode.c b/src/vrend/vrend_decode.c
|
|
index 7774a25..c6eb8f2 100644
|
|
--- a/src/vrend/vrend_decode.c
|
|
+++ b/src/vrend/vrend_decode.c
|
|
@@ -1766,6 +1766,26 @@ static int vrend_decode_get_pipe_resource_layout(struct vrend_context *ctx, cons
|
|
#ifdef ENABLE_VIDEO
|
|
/* video codec related functions */
|
|
|
|
+/*
|
|
+ * The chroma format of a codec comes from the guest as the number of its own enum, and the enum
|
|
+ * of Mesa since its pipe_video_chroma_format moved to u_format.h is numbered NONE, 400, 420, 422,
|
|
+ * 440, 444 (0 to 5), where this one, which u_format_table.py generates, is 400, 420, 422, 444, 440,
|
|
+ * NONE. Taken as is, 4:2:0, which is 2, is 4:2:2 here, and the host's encoder, which has no 4:2:2,
|
|
+ * refuses the codec ("format 0x2 not supported, supported formats: 0x1"), after which the guest
|
|
+ * encodes nothing.
|
|
+ */
|
|
+static uint32_t vrend_decode_chroma_format(uint32_t guest_format)
|
|
+{
|
|
+ switch (guest_format) {
|
|
+ case 1: return PIPE_VIDEO_CHROMA_FORMAT_400;
|
|
+ case 2: return PIPE_VIDEO_CHROMA_FORMAT_420;
|
|
+ case 3: return PIPE_VIDEO_CHROMA_FORMAT_422;
|
|
+ case 4: return PIPE_VIDEO_CHROMA_FORMAT_440;
|
|
+ case 5: return PIPE_VIDEO_CHROMA_FORMAT_444;
|
|
+ default: return PIPE_VIDEO_CHROMA_FORMAT_NONE;
|
|
+ }
|
|
+}
|
|
+
|
|
static int vrend_decode_create_video_codec(struct vrend_context *ctx,
|
|
const uint32_t *buf,
|
|
uint32_t length)
|
|
@@ -1778,7 +1798,8 @@ static int vrend_decode_create_video_codec(struct vrend_context *ctx,
|
|
uint32_t handle = get_buf_entry(buf, VIRGL_CREATE_VIDEO_CODEC_HANDLE);
|
|
uint32_t profile = get_buf_entry(buf, VIRGL_CREATE_VIDEO_CODEC_PROFILE);
|
|
uint32_t entrypoint = get_buf_entry(buf, VIRGL_CREATE_VIDEO_CODEC_ENTRYPOINT);
|
|
- uint32_t chroma_fmt = get_buf_entry(buf, VIRGL_CREATE_VIDEO_CODEC_CHROMA_FMT);
|
|
+ uint32_t chroma_fmt = vrend_decode_chroma_format(
|
|
+ get_buf_entry(buf, VIRGL_CREATE_VIDEO_CODEC_CHROMA_FMT));
|
|
uint32_t level = get_buf_entry(buf, VIRGL_CREATE_VIDEO_CODEC_LEVEL);
|
|
uint32_t width = get_buf_entry(buf, VIRGL_CREATE_VIDEO_CODEC_WIDTH);
|
|
uint32_t height = get_buf_entry(buf, VIRGL_CREATE_VIDEO_CODEC_HEIGHT);
|