This seems to be the best compromise I can come up with so far.
I can't figure out to get the tier2 programming to match between
264 and 265, maybe they are just programmed different here, good
old firmware.
Fixes: 1693c03a39 ("radv/video: add initial h264 decoder for VCN")
Reviewed-by: Lynne <dev@lynne.ee>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23227>
(cherry picked from commit b5963fc1f0)
Indeed, the fence reference was not freed.
For instance, this issue is triggered with
"piglit/bin/ext_external_objects-vk-semaphores-2 -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: 7b6cd912a5 ("mesa/st: get rid of ST_CALLOC_STRUCT use CALLOC_STRUCT")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23296>
(cherry picked from commit 84f465ec81)
radv_destroy_shader_upload_queue waits for a semaphore, which will in turn
call query_reset_status on hw_ctx that will fail due to being already
destroyed.
Fix radv/amdgpu: amdgpu_cs_query_reset_state2 failed. (-9) spam in the logs
with RADV_PERFTEST=dmashaders.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23276>
(cherry picked from commit 978d80fbe2)
The existing guardband region calculation was mixing up x/y_min with
x/y_max in cmd_buffer_emit_viewport(), causing the calculated viewport
area to always be an empty region. Luckily intel_calculate_guardband_size()
returns a non-empty but bogus guardband region in that case, so this
doesn't seem to have led to conformance regressions, but the
off-center guardbands could potentially impact performance in
geometry-heavy rendering.
Fixes: 893fa30afe ("anv: Include scissors in viewport calculations")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23174>
(cherry picked from commit 9c26a6b3bb)
We don't need to add an offset in the buffer, because we submit
the offset where the data was written to to the host. The
correction of this offset is also not needed and results in draw
errors.
Fixes: 0cf5d1f226
gallium: remove PIPE_CAP_INFO_START_WITH_USER_INDICES and fix all drivers
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23196>
(cherry picked from commit d4fc359748)
CTS is testing 2D to 3D image copies but the checks are incomplete and
we used to only copy the first slice.
This should fix
dEQP-GLES31.functional.copy_image.non_compressed.*.texture2d_array_to_texture3d
with ANGLE.
Cc: mesa-stable
Suggested-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23231>
(cherry picked from commit d2d07a7262)
We're currently aligning the offset to the size of the data structure
itself when the upload manager actually expects a POT. Ideally this
would be the next POT that's greater than the size of the structure.
Fixes: c24a574e6c ("iris: Don't allocate a BO per query object")
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20153>
(cherry picked from commit 14dec0c147)
Fix issue by handling the OpString instructions when walking through
the preamble for validation.
The gl_spirv_validation() creates a vtn_builder() and walks the
instructions looking for a subset of the information. However
our current way to walk the instructions will also perform tracking
of OpLine/OpNoLine, that may make references to OpString instructions
that were being previously ignored by gl_spirv_validation().
This would cause the parsing to fail.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9004
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22973>
(cherry picked from commit 1b31d528b9)
Need to explicitly clamp the indirect count against maxSequencesCount,
or we risk writing bogus commands into spill region.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23252>
(cherry picked from commit 5266bb0211)
If two threads deserialize the raw object at the same time, the
refcount could be more than 1 temporarily.
This can be reproduced with Granite during the multi-threaded pipeline
cache pre-warm on startup, and also with Dota2.
Fixes: cbab396f54 ("vulkan/pipeline_cache: replace raw data objects on cache insertion of real objects")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22853>
(cherry picked from commit 8126e0287d)
This should be set to the enum, ffmpeg has it wrong so far, but the sample decoder has it right.
convert radv to the proper answer.
Fixes: 1693c03a39 ("radv/video: add initial h264 decoder for VCN")
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23225>
(cherry picked from commit ea2eade57b)
Fixes: 68a926a15b ("glthread: set GL_OUT_OF_MEMORY if we fail to upload vertices")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23166>
(cherry picked from commit 39a9ebde37)
Indeed, the locally allocated "stimg" reference was not freed
on a specific code path.
For instance, this issue is triggered on radeonsi or r600 with:
"piglit/bin/egl-ext_egl_image_storage -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: 6a3f5c6512 ("mesa: simplify st_egl_image binding process for texture storage")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23165>
(cherry picked from commit 83cd7d23a2)
When the fragment shader reads the VRS builtin, VRS flat shading
shouldn't be enabled, otherwise the value might not be what the FS
expects.
Fixes dEQP-VK.fragment_shading_rate.renderpass2.monolithic.multipass.*
on RDNA2 (VRS flat shading isn't yet enabled on RDNA3).
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23187>
(cherry picked from commit b439bd5a58)
reason:
decoder uses the target buffer address in record
to indentify the reference frames. When target
buffer has changed outside of decoding process,
it has to be updated back to decoder, otherwise
the outdated reference will cause image corruption.
Cc: mesa-stable
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23061>
(cherry picked from commit 5b2544f868)
The query result resource will be written to by the host, so we have to
declare it as dirty if we want to see the change.
Fixes: 9279a28f0 (virgl: ARB_query_buffer_object support)
v2: Update expectations in CI
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23121>
(cherry picked from commit 330a1db016)
With Anv/Zink, the piglit test :
arb_shader_storage_buffer_object-max-ssbo-size -auto -fbo fsexceed
is failing validation after copy propagation :
load_payload(8) vgrf15:F, vgrf1+0.12<0>:F, vgrf1+0.0<0>:F, vgrf1+0.4<0>:F, vgrf1+0.8<0>:F, vgrf1+0.12<0>:F
../src/intel/compiler/brw_fs_validate.cpp:191: A <= B failed
A = inst->src[i].offset / REG_SIZE + regs_read(inst, i) = 2
B = alloc.sizes[inst->src[i].nr] = 1
In most cases it works because src[0] would be at offset 0 and so
reading a full reg passes validation, but Anv/Zink started emitting
slightly different code adding an offset maybe the size read 2 GRFs.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23126>
(cherry picked from commit 21c7b55f6f)
has_work controls whether a flush can be deferred, i.e., when unset
a flush may be deferred
since a promoted cmd must still be flushed to take effect, ensure this
is always set when promoted cmds are pending
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23035>
(cherry picked from commit 0f510040dc)
when needs_present_readback is set, reordering is disabled without hitting
the path that would normally disable promotion for the resource, so this
needs to be changed manually to avoid layout desync on the swapchain
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23035>
(cherry picked from commit 3c010319bb)
in a scenario where an ordered read op occurs for an image,
successive read-only barriers SHOULD be able to be promoted
...but they can't, because there isn't yet a mechanism for handling layout
transitions between the unordered cmdbuf and the ordered cmdbuf,
meaning that promoting e.g., a SHADER_READ_ONLY barrier after a TRANSFER_SRC
barrier will leave the image with the wrong layout for the transfer op:
TRANSFER_SRC(unordered) -> COPY(ordered) -> SHADER_READ_ONLY(unordered)
becomes
TRANSFER_SRC(unordered) -> SHADER_READ_ONLY(unordered) -> COPY(ordered)
ideally I'll get around to figuring this out at some point
affects:
dEQP-GLES31.functional.copy_image.non_compressed.viewclass_32_bits.r32i_r32i.texture2d_array_to_renderbuffer
Fixes: bf0af0f8ed ("zink: move all barrier-related functions to c++")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23035>
(cherry picked from commit 9c8b6754b0)
in the case where a draw is triggered after a flush, zink_update_descriptor_refs
will be called to set batch tracking for descriptors. this function also
handles refs for fb attachments, and everything is usually fine there
the problem with this approach is that tracking is no longer set on view
objects at renderpass begin, which makes them susceptible to early deletion
if a rp isn't started from a draw call
instead, apply batch tracking to fb attachment resources on renderpass
begin if the BATCH_CHANGED flag is set (need to rename this at some point)
in order to guarantee that the resource (object) lifetime will match the
cmdbuf runtime [since imageviews are now only freed upon batch completion]
fixes#9059
Fixes: f6bbd7875a ("zink: remove batch tracking/usage from view types"
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23132>
(cherry picked from commit 62961b172f)
