When Marge rebases, it creates two pipelines, one in the author's account
due to the rebase and another one in the target account due to the merge
request event. Depending on the order they appear, Marge erroneously
check the author's pipeline, and since it doesn't have the rights to
start this pipeline, Marge fails to merge because it timed out (since the
pipeline never got run).
Fix this by disabling the author's pipeline (source of type "push") when
a merge request is open.
We only disable when the pipeline is triggered by marge to not affect
running ci_run_n_monitor.py script
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24730>
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>
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>
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>
