In order to keep track of reference frame buffer address changing,
using past_ref to compare with render_pic_list, once the one in
past_ref is valid and if render_pic_list has that entry, it will
need to update it to the latest one in ref[i].
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5868
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14646>
The reference buffer address is used as the indication in h264 DPB
Tier2, when reference buffer was reallocated, h264 DPB would lose
track of that reference picture. Adding a pointer obsolete_buf in
vlVaSurface data structure for tracking this released buffer, also
in h264_picture_desc adding a private field, which contains
past_ref[16] for tracking previously released buffer vs current
buffer for reference frames.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5868
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14646>
this avoids dereferencing pg->dd which is allocated a few lines later
Fixes: 417477f60e ("zink: always use lazy (non-push) updating for fbfetch descriptors")
fixes (radv):
dEQP-GLES31.functional.blend_equation_advanced.basic.multiply
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14718>
drawing unpopulated xfb data is legal(?) and tested in cts, and the correct
operation is to just drop the draw, so do that here
fixes (nvidia):
GTF-GL46.gtf40.GL3Tests.transform_feedback2.transform_feedback2_api
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14694>
Includes a fake framebuffer allocation that's necessary for the code we
still use from the regular render passes.
v3: (Lionel)
- Reuse the attachment count from the faux render pass, remove now
unused function
- Add a cmd_buffer_end_rendering function to match begin_rendering,
making use of the split stuff from end_subpass
v4: (Lionel)
- Don't bother with mark_images_writen or resolves on suspend case
- Remove flush at the end of end_rendering, it's not needed
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13980>
v3: (Lionel)
- Handle VkPipelineRenderingCreateInfoKHR not being present
- Rename dynamic_pass and set it for regular render passes too
v4: C99 is good (Lionel)
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13980>
There's two of them because they can be created from three points in the
code that provide different details and this is the least ugly way I
could think of for now.
v2: Avoid allocations (Lionel)
v3: Move definition closer to its usage (Lionel)
v4: (Lionel)
- Simplify anv_dynamic_pass_init_full
- Zero out pass/subpass to avoid stall pointers
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13980>
This was made way more complicated than it needs to be for a Midgard-only pass.
The only caller doesn't care about the class, only if it's native or not.
Simplify it appropriately.
It really isn't that hard.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14724>
These "quirks" are common for Midgard, yet are only consumed by
pan_lower_framebuffer -- a Midgard-only pass. So the quirks should be removed
and inlined into their users. Thid removes MIDGARD_QUIRKS altogether.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14724>
When multiple variables are packed into the same location, we need
to re-construct variables that read/write the same components of that
register so that the DXIL signature is correct. We could try to
merge these variables, but getting the types right sounds harder than
just preserving the multiple individual variables.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
GLSL puts a bunch of tessellation info in the eval shaders, because
passthrough control shaders can exist. D3D12 puts it in the control
(hull) shader instead. So, when specializing, copy info from domain
to hull. For initial compiles (no domain shader), just make something
up.
D3D12 also requires the domain and hull shaders to have identical
patch constant signatures. Use the existing infrastructure and extend
it to also propagate patch constants. Notably, patch constant locations
are outside of the 64-bit range value so they require a separate pass
to avoid shifts larger than 64.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
This is required to be able to use the necessary number of varyings,
otherwise we hit asserts because mesa/st starts assigning varyings
locations above 64 due to the +9 reserving these texcoords.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
In order to get the semantics right, we need to know how many of the clip/
cull fields are designated for which purpose. In the case of a shader that
can receive these fields as both input and output, the shader_info property
is reserved to store the output info. We could add a dedicated input field
to shader_info, but since it'd probably only be useful for us, just send
it through a side channel during shader linking.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
Docs say that its presence in signatures as a "shadow" element (meaning it's not
accessed via load/store, but with a dedicated opcode) is legacy. It seems it
wasn't carried forward when HS/DS were added in D3D11.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
In HS, store_per_vertex_output maps to storeOutput in DXIL. The data
that isn't per-vertex is patch constants.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
DXIL validation will complain if the tess factor signature entries have the
wrong number of components for the shader's domain. Make sure that both
hull and domain shaders have the right number, and drop loads and stores
from the removed components.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
This way, patch varyings come before the patch sysvals (tess levels).
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
