The write helper is just pulling code we already have out into a helper
and flipping the order of the loop and the switch. The read helper will
be useful in the next commit where we add small constant support. This
keeps the two helpers right next to each other in the file where they're
easy to compare and we can ensure that they stay in sync.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9000>
The nir_op_is_vec() helper I added in 842338e2f0 ("nir: Add a
nir_op_is_vec helper") treats nir_op_mov as a vec even though the
semanitcs of the two are different. In retrospect, this was a mistake
as the previous three fixup commits show. This commit splits the helper
into two: nir_op_is_vec() and nir_op_is_vec_or_mov() and uses the
appropriate helper at each call site. Hopefully, this rename will
encurage any future users of these helpers to think about nir_op_mov as
separate from nir_op_vecN and we can avoid these bugs.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24704>
It's unnecessary because earlier parts of the pass will ensure that a
mov of undef is turned into an undef. It's also wrong because
nir_op_mov has different semantics from nir_op_vecN when it comes to how
sources map to destination components.
Fixes: 5f26c21e62 ("nir: Expand opt_undef to handle undef channels in a store intrinsic")
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24704>
For mov we need to follow the swizzle for the destination component, not
grab swizzle[0] for some random source.
Fixes: a406fff78a ("nir/inline_uniforms: support vector uniform")
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24704>
The cases in the if are the same as the cases we're using for the early
break. Just check the things and break if it's not a handleable case.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24704>
I don't think this does anything at the moment, because all accesses are
scalar aligned.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24350>
Previously, it was restricted to clear colors where R==G==B, but it seems
to work if that isn't the case.
This restriction was probably a leftover from before comp-to-single.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24400>
These work in some circumstances (dEQP-VK.spirv_assembly.instruction.graphics.16bit_storage.input_output_float_16_to_64.scalar9_tessc),
but I'm not sure if they work in all, blending certainly doesn't work and
this probably wasn't intended in the first place.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Fixes: 01bd012edd ("amd: fix 64-bit integer color image clears")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24400>
This is a partial fix for the case where
VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT and the aliased attachment clears
the attachment that was last used in a previous subpass (we have to move
the stores to the last used subpass, as well).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20994>
This will help us share gmem space between attachments that aren't used at
the same time. It's also a correctness fix for
VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT, because they're supposed to
happen at the first subpass using the attachment, not the start of the
renderpass.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20994>
For delaying clears to subpass begin time, I needed to save these until
later. Turns out this cleans up a good bit of threading these values all
through the command buffer setup.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20994>
I wanted to use it for the attachments and clear values of a
vkCmdBeginRenderPass(), but both can be 0 count. In that case, we would
end up with vk_default_alloc(0,0) because nothing had set the alignment,
and assertion fail instead of allocating 0 bytes.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20994>
This reverts commit 6b494745be.
The logic is not entirely correct: the comparison is between two
static-analysis estimates of a dynamic system with variables that aren't
captured by the shader source, so using ">" will always have greater potential
to cause regressions whenever the performance difference between the two builds
is something not captured by the static model, no matter how much the model is
improved.
Reference: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9262
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24615>
Bootstrap 5.3.1 is out, implementing the color fix we introduced to make
dark-mode more readable. So let's update to that, and drop our override.
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24670>
Adding GEM handles to the global list is necessary to allow
maintaining a single reference count for handles that are shared
between multiple buffer objects.
Since exported handles can end up being shared with other buffer
objects, as in the case that drmPrimeHandleToFD() and gbm_bo_import()
are called externally to Mesa, they too must be added to the global
list.
Unfortunately, doing this properly requires a new libdrm API. Use
the best possible option for now.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9552
Signed-off-by: Dor Askayo <dor.askayo@gmail.com>
Acked-by: Karol Herbst <git@karolherbst.de>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24648>
Prepare to be shared with prolog/epilog generation which
does not have si_shader param.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24443>
Need to split shader binary into exec and data part, then combine
exec and data of all shader parts separately. So const data symbols
in code need to be relocated.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24443>
