Fix defect reported by Coverity Scan.
Resource leak (RESOURCE_LEAK)
leaked_storage: Variable fp going out of scope leaks the storage it points to.
Fixes: 4fd7495c69 ("intel/clc: add ability to output NIR")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27778>
Not only do we want to know where an Op originated from, but also how it got
transformed along the way if possible. Preferably all the way to the final
machine code emitted.
This commit inserts OpAnnotates in some of the optimization passes when
map_instr() or Instr::new_boxed is used.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27158>
For submissions with an empty last batch containing no cmd buffers but
with semaphores as zink does, adding feedback to that batch would make
it no longer empty and increase submission overhead on some drivers.
Since feedback order is enforced by barriers, the feedback cmds can
instead be appended to the previous batch (if it exists) so that the
last batch remains empty.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27830>
This pulls everything into nvk_cmd_draw.c where it's a bit easier to
manage. When the time comes for switching to EXT_shader_object, this
will let us handle VK_EXT_dynamic_rendering_unused_attachments via the
common vk_pipeline code.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
These implementations are built on top of vk_shader. For the most part,
the driver shouldn't notice a difference between draws consuming
pipelines vs. draws consuming shaders. The only real difference is
that, when vk_driver_shader_ops::compile() is called for pipelines, a
struct vk_graphics_pipeline_state is provided. For shader objects, the
state object will be NULL indicating that all state is unknown. Besides
that, all the rest of the differences between Vulkan 1.0 pipelines,
VK_EXT_graphics_pipeline_library, and VK_EXT_shader_object are handled
by the Vulkan runtime code.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
We need to be able to thunk through a destroy callback if we want to
have different kinds of pipelines implemented in different parts of the
stack.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
This adds a new base vk_shader object along with vtables for creating,
binding, and working with shader objects.
Unlike other parts of the runtime, the new shader object code is a bit
more sanitized and opinionated than just handing you the Vulkan
entrypoints. For one thing, the create_shaders() calback takes a NIR
shader, not SPIR-V. Conversion of SPIR-V into NIR, handling of magic
meta NIR shaders, etc. is all done in common code. [De]serialization is
done via `struct blob` and the common code does a checksum of the binary
and handles rejecting invalid binaries based on shaderBinaryUUID and
shaderBinaryVersion. This should make life a bit easier for driver
authors as well as provides a bit nicer interface for building the
common pipeline implementation on top of shader objects.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
Because these functions were introduced by VK_EXT_shader_objects, we
technically have to expose them even though they have to do with NV
extensions that no one else supports.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
We're supposed to just ignore samples above what we support, and there's
no VU matching this assert. Fixes a crash in
dEQP-VK.pipeline.shader_object_unlinked_spirv.extended_dynamic_state.misc.sample_shading_dynamic_sample_count.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
nir->info.outputs_written isn't used for fragment shaders except as an
early out a few lines above this, so we don't rely on this property.
My best guess is that this was intended to check if the information
from nir_gather_info is stale, but dead variables fail the assert
even if the info is up to date.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27595>
Reference frame list is formed by each of the provided
recon_frame, while the assumption here is to use the API
provided by VAAPI interface, when a frame is marked as
"long term reference" by
av1->picture_flags.bits.long_term_reference
Its recon_frame will be kept in DPB marked by its
recon_frame as signature. When a future input requests
refering to it, it can go this way:
1. set av1->ref_frame_ctrl_l0.field.search_idx2 to indicate
which ref_frame_idx slot will be used.
x = av1->ref_frame_ctrl_l0.field.search_idx2;
2. n = av1->ref_frame_idx[x-1];
av1->reference_frames[n] as the signature to compare with.
if av1->reference_frames[n] is pointing to the
same video buffer (signature) as the one marked as
"long term reference". Then the new input is refering to
it only.
3. in SVC case, long terms are used for temproal_id 0 only,
because using long term means potentially scene change
could happen.
4. the "long term reference" recon_frame should be kept,
instead of being reused until it is no longer needed to
avoid signature duplication.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27771>
