The execution time of vkcts has drastically changed with the latest
update, especially for APUs. This commit bumps the timeout to give
them a chance to finish.
Fixes: 836ce97f5e (ci: bump VK-GL-CTS to 1.3.2.0)
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16810>
We don't need to go as far as the fake front thing when MSAA is being used, because the
swapchain (single-sampled) is already decoupled from the app render buffers. But we do
need to direct the frontbuffer flush to the single-sampled back buffer, and then present
the back buffer. We also need to swap the buffers when we do this, so the next blit
targets the former front buffer.
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16227>
ce1a381e57 ("turnip: enable VK_KHR_16bit_storage on A650") determined
that the type of the instr decided the type of the value being stored in
the ".b" case. But it would be surprising if image stores had the type
determine the coordinates' precision instead of the value's, and once we
turned on image instruction precision lowering we ran into asserts.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16616>
A 1D texture operation may need to do a mov to turn a reference to a
channel of an SSA value into a scalar value to be passed as the texture
coordinate (since texture srcs can't do swizzles). Seen in
amnesia-the-dark-descent/low/46.shader_test() for example, where a 1D
texture is used to remap each of r,g,b from a previous texture result.
Besides, the nir_op_is_vec() case will (perhaps surprisingly) look through
a mov, anyway.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16616>
Triggered a BIR validation error, which made debugging a breeze. That validation
pass (dimensionality checks) gets a lot of use, it seems :-)
Fixes:
dEQP-VK.ssbo.layout.2_level_array.std430.row_major_mat4x2_comp_access_store_cols
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16724>
This handles VK_REMAINING_* for us, instead of underflowing and clearing no
levels/layers.
Fixes dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.single_layer.*
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16724>
2D AFBC should be working now, flip the switch. 3D AFBC needs more research to
get right, honestly it's not clear how 3D AFBC on Bifrost is working...
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16800>
We need to pack special AFBC-specific plane descriptors instead of the generic
plane descriptor. Nothing too fancy here, though.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16800>
Add the required handling when packing render target and depth buffer
descriptors on Valhall. This is mostly equivalent to Bifrost.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16800>
Map a canonical format (a hardware-independent pipe_format) to a compression
mode (Valhall-specific hardware enum defined in GenXML). To be used for packing
plane descriptors and render target descriptors when AFBC is in use on Valhall.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16800>
For callers that have a device object, it's easy to pass dev->arch instead of
dev. But this requires callers to have a reference to the device, which is
tricky for callers that only have the arch via PAN_ARCH. Pass dev->arch instead
of dev to accommodate them.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16800>
..and assert the other sources are null. The one place this might fail in the
future is for real FMA, but we don't support that for GL.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16798>
These do not convey any additional information, and fail to account for
shrinking. In particular, a 64-bit writemask with .keephi would fail to
disassemble and instead trip the assertion, since that would be the ZW
components. Just delete the broken code.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16798>
Otherwise, we can get vec3 with u2u32 with 64-bit sources which we need lowered.
Since our current approach is "scalarize all 64-bit ops", we need to check for
conversions too.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16798>
Logically at the same part of the compile pipeline as clause scheduling on
Bifrost. Lots of similarities, too. Now that we generate flow control only as a
late pass, various hacks in the compiler are no longer necessary and are
dropped.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16804>
Test that we correctly track the scoreboard, helper invocations, reconvergence,
and ends and insert NOPs to effect this expected flow control.
As the pass inserts NOPs but does not otherwise modify the shader, this is easy
to test with well-defined behaviour of the pass.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16804>