This feature actually worked, but accidentally triggered some
CTS failures due do an unrelated sample_mask bug. That bug
is fixed in the previous commits in this series, so re-enable
fragmentStoresAndAtomics.
There are two spurious CI failures created by this change; one is in
a ycbcr test (which we're still working on) and the other is a CTS
bug (it's using a feature we don't advertise).
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32879>
this was missed in the original v3d pass, and then the common code port
inherited the bug. (so strictly this fix "should" be backported even farther
back but it won't apply before the Fixes here, and I don't think we do LTS that
far back anyway).
in theory this should fix a corner case with robustness on the gl (but not
vulkan, at least for apple) drivers on broadcom & apple.
Fixes: f0fb8d05e3 ("nir: Add nir_lower_robust_access pass")
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32907>
rather than try to enumerate everything a driver might want with an unmanageable
collection of booleans, just do a filter callback + data. this ends up simpler
overall, and will allow Intel to use this pass for just 64-bit images without
needing to add even more booleans.
while we're churning the pass signature, also do a quick port to
nir_shader_intrinsics_pass
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> [NIR and V3D]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32907>
The loop checking if exec is overwritten didn't check for NULL
instructions, and didn't fix up reg write indices after inserting
instructions.
Fixes: fcd94a8c ("aco: move try_optimize_branching_sequence() to postRA optimizations")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32746>
We need to add a variant of the texld instruction, which is used with a shadow
samper and passed the shadow reference value via src2.
Blob generates such texld's for deqp's GLES3.functional.texture.shadow.2d.* (GC3000).
Fixes spec@arb_depth_texture@texdepth.
Fixes: abe5bd35 ("etnaviv: Switch to isa_assemble_instruction(..)")
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32926>
Marek recently changed hole_size to be signed, rather than unsigned.
A negative hole_size means that the two loads overlap - and thus are
prime candidates to be combined.
My original hole_size handling was:
if hole_size > 4 * (8 - low->num_components) then don't vectorize
For non-overlapping loads, this worked: NIR's largest vector is vec16,
and if low was already a vec16, combining it with anything would exceed
that, so it'd never be considered. That meant low would always be a
vec8 or less, so (8 - low->num_components) was a positive number.
Now that we see overlapping loads, we can see a vec16 low, vec4 high,
and also a negative hole size, giving us fun comparisons like:
-16 > 4 * (8 - 16) => -16 > -32 => true, don't vectorize
Which is absolutely the wrong thing to do, because the high load's data
is entirely included within the former load's data.
The idea here was to make sure the second load would be able to pack at
least one component into the first's V8 result. But even this isn't the
best, because...even if it's simply adjacent, doing one V16 load is more
efficient than requesting two back to back V8 loads.
So, we just simplify down to a static check: if there's an entire V8 of
hole, don't vectorize. This already won't happen because the core pass
has max_hole set to 28 bytes (7 32-bit components), but that could
change based on the needs of other drivers, so let's be defensive.
fossil-db results on Alchemist:
Instrs: 161533978 -> 161295137 (-0.15%); split: -0.20%, +0.05%
Subgroup size: 8092544 -> 8092568 (+0.00%)
Send messages: 7915233 -> 7844503 (-0.89%); split: -0.94%, +0.05%
Cycle count: 16577700697 -> 16702609256 (+0.75%); split: -0.59%, +1.35%
Spill count: 72338 -> 67226 (-7.07%); split: -7.36%, +0.29%
Fill count: 134058 -> 125980 (-6.03%); split: -6.83%, +0.80%
Scratch Memory Size: 4092928 -> 3786752 (-7.48%); split: -7.53%, +0.05%
Max live registers: 33031460 -> 32945994 (-0.26%); split: -0.27%, +0.01%
Max dispatch width: 5778384 -> 5778536 (+0.00%); split: +0.26%, -0.26%
Non SSA regs after NIR: 179809505 -> 152735471 (-15.06%); split: -15.08%, +0.03%
Fixes: c21bc65ba7 ("nir/opt_load_store_vectorize: make hole_size signed to indicate overlapping loads")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32932>
When a SEND instruction is a EOT, the scoreboard lowering will not
allocate a new SBID for it, since nothing needs to wait for it. In
Gfx12 this allowed the SEND to get out-of-order $.dst or $.src
dependencies.
Starting on Xe2+ this is not supported anymore, in favor of supporting
more combined modes.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32712>
Currently we scale the polygon offset units with a fixed factor,
matching the MRD (minimal resolvable distance) for a 16bpp depth
buffer. This wastes a lot of precision when a 24bpp depth buffer
is used.
Apply the correct MRD scale, depending on the format of the
currently bound depth buffer.
Fixes piglit spec@!opengl 1.4@gl-1.4-polygon-offset.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32756>
This is similar to what link_intrastage_shaders is doing and it
fixes the following test:
KHR-Single-GL46.subgroups.builtin_var.compute.subgroupsize_compute
Which was failing with SPIRV but passing with GLSL, the diff being:
- SPIRV: "subgroup_size: 1"
- GLSL: "subgroup_size: 2"
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32698>
The blitter VS expects coords to fit in a signed int16. When this
is not the case, use util_blitter_draw_rectangle instead.
Since util_blitter_draw_rectangle sets vertex elements, we need
to make sure they're properly restored.
The alternative to this fallback would be to pass coordinates
unpacked (so 4 SGPRs instead of 2), but this doesn't fix the
fbo-blit-check-limits test because of uv interpolation precision
issue.
Using 2 triangles instead of a rectangle + disabling
window_space_position helps but then this breaks some GLES3 tests,
like dEQP-GLES3.functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_x
(which doesn't pass either if u_blitter is used for all cases).
Using a single triangle covering the whole rectangles fixes all
cases but it then requires to setup scissors to not write too
much pixels...
So, instead of adding so much complexity, let's use u_blitter
for the "large coordinates" fallback, and keep the rectangle blit
for the other cases.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32698>
