fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2025-12-23 13:20:14 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

frontends/va: Stop using PIPE_VIDEO_CAP_ENC_SUPPORTS_ASYNC_OPERATION

Browse source 
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 <sivileri@microsoft.com>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31933>
This commit is contained in:
David Rosca 2024-11-01 08:44:08 +01:00 • committed by Marge Bot
parent fa65224c86
commit baa96bce45
1 changed files with 0 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
src/gallium/frontends/va/buffer.c
View file

@ -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);