From baa96bce45d03aedebba8ef93a10e819e3b5dcee Mon Sep 17 00:00:00 2001 From: David Rosca Date: Fri, 1 Nov 2024 08:44:08 +0100 Subject: [PATCH] frontends/va: Stop using PIPE_VIDEO_CAP_ENC_SUPPORTS_ASYNC_OPERATION The gallium interface always expected the driver to support multiple in-flight feedbacks, so this shouldn't have been needed in the first place. Even if the driver wouldn't support it, we still can't force applications to sync after each frame. In fact, the old VCE dual instance feature relied on the vaSyncSurface not being called every frame. Reviewed-By: Sil Vilerino Reviewed-by: Boyuan Zhang Part-of: --- src/gallium/frontends/va/buffer.c | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/src/gallium/frontends/va/buffer.c b/src/gallium/frontends/va/buffer.c index a3d2003495d..2e15295c8a0 100644 --- a/src/gallium/frontends/va/buffer.c +++ b/src/gallium/frontends/va/buffer.c @@ -543,23 +543,6 @@ vlVaSyncBuffer(VADriverContextP ctx, VABufferID buf_id, uint64_t timeout_ns) if (!drv) return VA_STATUS_ERROR_INVALID_CONTEXT; - /* Some apps like ffmpeg check for vaSyncBuffer to be present - to do async enqueuing of multiple vaEndPicture encode calls - before calling vaSyncBuffer with a pre-defined latency - If vaSyncBuffer is not implemented, they fallback to the - usual synchronous pairs of { vaEndPicture + vaSyncSurface } - - As this might require the driver to support multiple - operations and/or store multiple feedback values before sync - fallback to backward compatible behaviour unless driver - explicitly supports PIPE_VIDEO_CAP_ENC_SUPPORTS_ASYNC_OPERATION - */ - if (!drv->pipe->screen->get_video_param(drv->pipe->screen, - PIPE_VIDEO_PROFILE_UNKNOWN, - PIPE_VIDEO_ENTRYPOINT_ENCODE, - PIPE_VIDEO_CAP_ENC_SUPPORTS_ASYNC_OPERATION)) - return VA_STATUS_ERROR_UNIMPLEMENTED; - mtx_lock(&drv->mutex); buf = handle_table_get(drv->htab, buf_id);