Compressed formats were disabled because of the different layout for
u_interleaved(compressed), where the 16x16 texel tile model for
non-compressed is replaced by a 4x4 block tile. This prevents us from
creating RGBA views of compressed images, which break copies.
The simple option is to keep compressed images linear. The more complex
one would be to patch coordinates/frag-coords on the shader side when
we're dealing with a compressed texture/color-attachment, but given
we're using vk_meta for copies, it's not something we can easily do,
so let's go for the first option and see if we want to revisit it
later.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29451>
We move the modifier selection after the panvk_image initialization
so we have less VkXxx objects to retrieve, and split the 3 cases
(explicit modifier, explicit modifier list ordered by preference and
driver auto-selection based on the image attributes) to make things
clearer.
We also check formats against the pan_best_modifiers array which is
sorted by GPU order of preference and serve as an is_valid_modifier()
too.
Finally, we add the following new constraints on u-tiled/AFBC:
- don't allow u-tiled on images with compressed formats that might have
non-compressed views
- don't allow u-tiled or AFBC on 1D images
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29451>
Specifically:
- `alpine-build-testing`
- `fedora-release`
- `.meson-arm` (inherited by all the arm build jobs)
- `debian-arm64` (because it overrides the inherited list)
- `debian-vulkan`
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30658>
The CI-wide default is 20min, so if we set a 20min job timeout here, we
can't get the results of our jobs when they timeout.
Instead of setting the test timeout to 15min, which would be too short
for some jobs, leave it at 20min (but be explicit about it and protect
against a future change of that default), and bump the job timeout by
5min to allow for results to be uploaded.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30694>
We were currently emitting logical atomic instructions with a packed
destination region for sub-dword LSC atomics, along the lines of:
> untyped_atomic_logical(32) dst<1>:HF, ...
However, these instructions use an LSC data size D16U32, which means
that the 16b data on the return payload is expanded to 32b by the LSC
shared function, so we were lying to the compiler about the location
of the individual channels on the return payload, its execution
masking, etc. This is why the hacks that manually set the
'inst->size_written' of the instruction were required.
In some cases this worked, but any non-trivial manipulation of the
instruction destination by lowering or optimization passes could have
led to corruption, as has been reproduced in deqp-vk during
lower_simd_width() for shaders that use 16-bit atomics in SIMD32
dispatch mode.
Note that LSC sub-dword reads aren't affected by this because they use
raw UD destinations and specify the actual bit size of the operation
datatype as the immediate SURFACE_LOGICAL_SRC_IMM_ARG, which doesn't
work for atomic operations since that immediate specifies the atomic
opcode.
Instead, have the logical operation implement the behavior of 16-bit
destinations correctly instead of silently replacing the 16-bit region
with an inconsistent 32-bit region -- This is done by emitting the MOV
instructions used to pack the data from the UD temporary into the
packed destination from the lower_logical_sends() pass instead of from
the NIR translation pass.
Fixes: 43169dbbe5 ("intel/compiler: Support 16 bit float ops")
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30683>
This improves drivers in the following ways:
* iris_hiz_exec() and crocus_hiz_exec() gets rid of the narrowly-used
update_clear_depth parameters.
* iris avoids fast-clearing if the aux state is CLEAR. crocus avoids
this too, but didn't actually need it in the first place.
* iris updates the value once per fast_clear_depth() call instead of
doing an update for each layer being cleared.
* anv now updates the clear value when transitioning from an undefined
layout instead of doing so on every fast-clear. This should be safer
because we don't perform state cache invalidates when changing the
clear value. So, existing surface states won't have any stale values.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30520>
this pbo shader works by iterating over the framebuffer size
and storing a value to an offset for each source pixel. if the
number of pixels being written out does not correspond to fragcoord
to the extent that certain source pixels are not written at all, however,
then this method should not be used in order to avoid giving broken results
cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30689>
The new workaround tries to strike a balance between simplicity and
functionality (for testing purposes). Instead of checking for the
alignment of a specific LOD when fast-clearing, we take an
all-or-nothing approach for LOD1+.
I haven't found any app to clear LOD1+ except for a Dirt Rally trace
some time ago. If I remember correctly, that trace clears all LODs,
doesn't render to them, then clears again with a different color,
incurring resolves. So, skipping LOD1+ fast clears will avoid those
resolves. Other apps I tested include Synmark2, glmark2, GfxBench5, and
the Vulkan games in internal our benchmarking tool.
Now that we've added updated and simplified checks in the drivers
themselves, we delete blorp_can_hiz_clear_depth.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30250>
None of our tracked games use partial depth clears, so only allow it in
simple cases for testing purposes. This change also fixes an issue on
gfx8, where we had been accidentally disabling full surface clears if
the LOD was not 8x4 aligned.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30250>
I did some more debugging of this feature, but this time with a modified
version of the piglit test, ./bin/depthstencil-render-miplevels.
I modified the test to:
* Control which LOD to stop populating/clearing
* Print out the results of readpixels to stderr
From there, I could see how different surface dimensions affected
fast-clears. Depending on the surface dimensions, fast-clearing an LOD
above the LOD0 could cause other LODs to be cleared and/or cause the
targeted LOD to be only partially cleared (for example, when the LOD0
dimension is 66x66 and the test doesn't clear LOD3+). This never happens
when fast-clearing LOD0 however.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5258
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30250>
Boris Brezillon