Application should send the full DPB state in each pic to keep
the references alive. Ideally the surfaces would be evicted immediately,
but unfortunately this breaks some applications. Add evict flag and
only evict surfaces if not present in reference frames array for two
consecutive frames.
DPB buffers are not destroyed upon eviction, but instead they are kept
around and reused next time a new surface is added to DPB.
Fixes: cc14724d73 ("frontends/va: Implement DPB management for H264/5 encode")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31741>
H264 have 16 as maximum DPB size by spec (A.3.1. f) MaxDpbFrames).
For encode we need one more slot for current recon, so use max size + 1.
Fixes: cc14724d73 ("frontends/va: Implement DPB management for H264/5 encode")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31741>
These are regressions, but impossible to bisect since everything was
completely broken for ages and no test could run at all.
A commit in the range 834b919f...02269223 fixed it, and we now have
results, so let's update the results so that we can see future
unexpected results!
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31806>
Emit dummy VF_STATISTICS state before each VF state.
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31759>
Iris also makes use of compute engine in paralel with render engine,
so here also programing the async compute registers like it is done
in ANV.
This should improve performance when render and compute engine
are running in parallel.
It was also necessary to copy 2 workarounds that are needed before
programing STATE_COMPUTE_MODE.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30796>
While this should not cause any real issues, there is no reason
to unlock the mutex just to lock it again couple lines below.
Fixes coverity issue 1559431 Value not atomically updated
Acked-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31622>
Bit shift would go over 32 bits. Also add assert for maximum
value as allowed by spec.
Fixes coverity issue 1469252 Bad bit shift operation
Fixes: 5edbecb856 ("frontends/va: adding va av1 encoding functions")
Acked-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31622>
* 1547216 Operands don't affect result
- PRESET_MODE_HIGH_QUALITY is maximum value
* 1255678 Dereference after null check
- no need to check against NULL because the data can
only be NULL when the array is empty (size == 0)
* 1619397 Unsigned compared against 0
- check >= 0 is always true in vlVaAddRawHeader
* 1468885 Dereference null return value
- add NULL check for buffers in vlVaRenderPicture
Acked-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31622>
When tracing the command stream with PAN_MESA_DEBUG=trace, all
descriptors are read and decoded. Trying to read an invalid or old
descriptor might cause confusion or (more importantly) a crash.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31768>
si_set_global_binding is a context function, but it touches the bound
compute program. As radeonsi also advertizes PIPE_CAP_SHAREABLE_SHADERS
this function is supposed to be safe when the same compute state object is
bound to multiple contexts at once.
In order to fix this data race global_buffers is moved to si_context so it
becomes context private data instead.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31672>
This also means the infrastructure added by @gallo in 1dc64d0613
("ci: Use merge-skips files during merge pipelines") can be used and all
the manual adding of these files can be dropped, reducing the likeliness
of bugs.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31739>
ffs(VRAM, GTT) returns the GTT bit as it's the smaller.
Simplify the code by explicitely selecting VRAM when both
domains are active, otherwise assert that only 1 bit is set.
Fixes: 593f72aa21 ("winsys/amdgpu-radeon: rework how we describe heaps")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31683>
There are more driver params than what is contained in the indirect
buffer. So switch things around to always allocate a buffer into which
we copy the indirect params.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31534>
Before the gallium driver can support load_shader_consts_via_preamble it
needs a way to differentiate between # of API level UBOs and the number
of UBOs after the driver inserts ones for driver-params, etc. This is
because the driver UBOs are emit in a different place from user UBOs.
If we didn't have this distinction, and the app had more UBOs bound than
the shader used, we would otherwise emit some conflicting UBO
descriptors (ie. ones for unused const slots conflicting with the driver
UBO slots).
This also moves the consts_ubo emit into the PROG state.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31534>
Move this to where the rest of the hs/ds params are emit, because for
a7xx with load_shader_consts_via_preamble we'll need this all to be a
single UBO. So we won't be able to piecemeal upload consts.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31534>
