Make sure to preserve the depth or stencil components of D24S8 using the
fixed codepath just added. While we're here, fix the detection of
whether an attachment is bound.
Fixes: cb0f414b ("tu: Add support for suspending and resuming renderpasses")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26154>
We need to make sure that we don't trash a passthrough depth/stencil
aspect if we need to store the whole attachment by loading it
beforehand.
Fixes: cb0f414b ("tu: Add support for suspending and resuming renderpasses")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26154>
These are pure VK-CTS jobs, they don't run any GL tests.
It doesn't matter right now because these two jobs are disabled, but
when they get re-enabled, we'll want this to have been fixed.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30677>
Add an argument to ci_run_n_monitor specifying certain stages to be
excluded from consideration, defaulting to the one with post-merge and
performance jobs. This allows, e.g., to run all Panfrost pre-merge jobs:
./ci_run_n_monitor.py --target 'panfrost.*'
or to run all Freedreno pre-merge jobs:
./ci_run_n_monitor.py --target '.*' --include-stage freedreno
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30784>
We used the logical cfg in helper_sched under the assumption that (eq)
only kills active helpers. This could lead to something like this:
br p0.x, else
sam
(eq)nop
jump end
else:
sam
end:
It turns out this is not correct: (eq) kills *all* helpers so the
snippet above could produce wrong results.
To fix this, simply switch from using the logical cfg in helper_sched to
using the physical cfg.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29409>
opt_jump destroys the physical cfg but it turns out we need it
afterwards in helper_sched. Keeping it correctly up-to-date during
opt_jump turned out to be tricky and complex. Simply recalculate it
afterwards to keep things simple.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29409>
When calling ir3_calc_reconvergence after opt_jump, it may happen that
there are multiple divergent branches to the same block. This was
handled incorrectly since first_divergent_pred was unconditionally
overwritten for successors of divergent branches. This patch fixes this
by only making sure only the earliest divergent predecessor is used.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29409>
After opt_jump, we might end up with weird control flow likes this:
block0: br block2
[more blocks]
block1: br block3
block2: ...
block3: ...
Since block2 is a logical successor of block1 (due to the fall through),
a physical edge will be added. However, another one will be added
because the branch to block3 crosses block2 (which is a reconvergence
point due to the branch from block0). This currently results in an
assert. This commit fixes this by ignoring successors of the start block
of edges that cross reconvergence points.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29409>
Instead of handling backedges after a physical edge is added that extends
the divergence range, handle it at the beginning of the loop. This
handles the TODO by making sure that we also check for backedges after a
block is added to the worklist at the beginning due to a divergent
branch. For example, this fixes cases where opt_jump optimizes
"if (foo) { break; }" to remove the break block and we have a divergent
branch across the loop backedge.
While we're here, also fix an off-by-one that meant we wouldn't handle
backedges that jumped to the immediate previous block (which is again
possible after opt_jump) or the same block.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29409>
Planned downtime in the farm:
* Start: 2024-08-22 06:00 UTC
* End: 2024-08-22 12:00 UTC
Risk notice due to electrical maintenance in the building where the farm
is hosted:
* Start: 2024-08-19 07:00 UTC
* End: 2024-08-22 16:00 UTC
So, there is a time window when the farm will be disabled. But there is
a bigger window when there is a change for this commit to be merged.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30534>
We were specifying align_offset = 64 and align_mul = 64, which is
invalid. nir_combined_align() asserts that align_offset < align_mul.
Our intention here is to perform cacheline-aligned (64B-aligned) block
loads, so we should set align_mul = 64 and can leave align_offset = 0.
Fixes: fbafa9cabd ("intel/nir: remove load_global_const_block_intel intrinsic")
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30755>
