New tests, dEQP line rasterization test fix that lets Intel pass.
Clears out bogus xfails from 1.3.2.0 uprev on a630, which I suspect were
"we lost the device twice on a full run once, and those fails got pasted
in without checking if it happened a full run again" (since we haven't
seen them in other full run attempts).
Also clears out the a630 vk asan xfails (essentially all tests run) by
turning off leak detection which was just catching leaks in vkcts.
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17304>
Before, we needed CP post-sched to copy-propagate references to NIR
registers produced by out-of-ssa. Now that we're in SSA, this pass ends
up not doing anything useful, and actually gets in the way by occasionally
creating a cycle in the DAG.
The entire shader-db impact is:
instructions HURT: shaders/closed/steam/tropico-5/78.shader_test FRAG: 238 -> 242 (1.68%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17320>
Not only runs less testing when only one driver is impacted, but also
makes sure zink+turnip is turned off when the farm is.
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17287>
On a650+ we use the new Z24UINT_S8UINT format to sample the stencil
aspect of D24S8, which returns stencil in the second component and also
uses the second integer component for the border color. However Vulkan
mandates that the first component is used for the stencil border color.
There's no workaround we know of, so we have to fall back to the old
behavior where there is a workaround. If we know the format, we can
fixup the border color ourselves though.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17177>
From the API's point of view, border color replacement looks like this:
--------------------
| API Border Color |
--------------------
|
----------- | ---------------- ----------
| API fmt |-------->| User Swizzle |----->| Shader |
----------- ---------------- ----------
From the HW point of view, it looks like this:
-------------------
| HW Border Color |
-------------------
|
---------- ----------- | --------------- ----------
| HW fmt |-----| HW swap |------>| Tex Swizzle |----->| Shader |
---------- ----------- --------------- ----------
When the HW fmt + HW swap isn't enough to represent an API format, we
need to prepend our own swizzle to the the user's swizzle, so the tex
swizzle is a "format swizzle" composed with the user swizzle. However,
we don't want this format swizzle to be applied to border colors, so
there's a workaround in freedreno which is meant to undo the format
swizzle so that the HW border color with the format swizzle applied
equals the API border color, and everything is ok. However, on a6xx at
least it was incorrectly undoing the entire tex swizzle. This broke
border color with a user swizzle, because it was now effectively not
getting applied for the border color. It also made it seem like the user
swizzle is required for the workaround, which would have implications
for VK_EXT_border_color_swizzle with turnip, but it's not.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17177>
On-GPU LRZ direction tracking allows LRZ to support secondary cmdbufs,
reusing LRZ between renderpasses, and in future to support LRZ when
VK_KHR_dynamic_rendering is used.
With on-gpu tracking we have to be careful keeping LRZ state in sync
with underlying depth image, which means we should invalidate LRZ
when underlying image is changed or the view of image is different
from previous renderpass.
All of this resulted in LRZ logic being thinly spread through the code,
making it hard to understand. So most of it was moved to tu_lrz.c.
For more details on past and new LRZ features see comment at the
top of tu_lrz.c.
Note about blob:
- Blob is much more happy to do LRZ_FLUSH, it flushes at the start
of the renderpass, after binning, and at the end of the renderpass.
- Blob seem not to care about changes in depth image done via
vkCmdCopyImage.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6347
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16251>
We have a lot of spilling coverage in a618 pre-merge, don't do it all (~2
minutes) here. Also, force-gmem touch testing should probably test less than
the default run does!
This should help make up for having added the tu-zink run.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17125>
The libvulkan-dev was needed for building zink, which ended up turning on
the vulkan tests in piglit. Split them out here.
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17125>
Fix defect reported by Coverity Scan.
Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking rop_reads_dst suggests that it may be
null, but it has already been dereferenced on all paths leading to the
check.
Fixes: 94be0dd0b8 ("tu: Implement extendedDynamicState2LogicOp")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17099>
SSBO access works very differently from UBO access. Straddling
loads/stores isn't an issue, loads/stores instead must be aligned to the
element size and can have up to 4 components.
We support 16-bit access with SSBOs on a650+, and sometimes the
vectorizer tries to create a misaligned 32-bit access when combining
32-bit and 16-bit accesses. The UBO-focused logic didn't reject this,
which is now fixed. This fixes a number of VK-CTS regressions on a650+.
Fixes: bf49d4a084 ("freedreno/ir3: Enable load/store vectorization for SSBO access, too.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17040>
We had it set up for arm64 asan already, do it for everyone else too. In
cleaning up the duplication, this fixes a pasteo in rpi3 which had the
"artifacts: false" on the wrong job, causing it to do a slow download of
the mesa build from gitlab.
Doing this required also moving the ".use-debian/arm_test" in as well, so
that its "needs:" didn't overwrite ours if it appeared after us in the
consumer's "extends:"
Should save about 20 seconds on rpi3 jobs.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17146>
This needs to be accurate so that when we split and then schedule a new
a0.x/a1.x/p0.x write we will eventually make progress. It wasn't taking
the kill_path into account which could create an infinite loop as we
keep scheduling writes whose uses are blocked because they are memory
instructions not on the kill_path.
Closes: #6413
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16635>
Even if there is libdrm we shouldn't use it if KGSL is selected.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17173>
This should help with "marge got stuck for an hour and all I got was this
failed job with no results/" when a system intermittently wedges.
This replaces the BM_POE_TIMEOUT ("did we get something on serial in the
last 3 minutes?") that rpi had, in favor of checking that the whole test
job gets through in 20 minutes.
Acked-by: Juan A. Suarez <jasuarez@igalia.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17096>
Per Vulkan spec only "Draw" commands should be counted towards
occlusion query.
Apparently RB_SAMPLE_COUNT_CONTROL::UNK0 bool controls whether
sample counting is enabled, so we could use it to disable
sample counting for 3d blits which are sometimes used for
clear/copy/blit/gmem-store/resolve operations.
Fixes GL CTS tests running through Zink:
dEQP-GLES3.functional.occlusion_query.depth_clear
dEQP-GLES3.functional.occlusion_query.depth_clear_stencil_clear
dEQP-GLES3.functional.occlusion_query.scissor_depth_clear_stencil_clear
dEQP-GLES3.functional.occlusion_query.scissor_stencil_clear
dEQP-GLES3.functional.occlusion_query.stencil_clear
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6559
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17138>
We used to use WZYX and apply swizzles. Because swizzles apply for
border colors as well, the gallium driver un-swizzled the border colors
to cancel out swizzles. That did not work for turnip because turnip
advertises customBorderColorWithoutFormat and does not know when to
un-swizzle.
This change replaces WZYX by XYZW and removes the swizzles.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6516
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16647>
A single compiled_shaders instance could be reused by several
pipelines, but strings from disasm info could be stolen only once.
So now we have to copy them.
Fixes crashes when using RenderDoc.
Fixes: 05329d7f9a
("tu: Implement pipeline caching with shared Vulkan cache")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17053>