if the table is filled with deleted entries, we don't need to rzalloc+free an identical
block of memory for the table, we can just memset the existing one
the same applies to table clears without a function passed in that the table
doesn't need to be iterated and can just be memset
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8450>
if the table is filled with deleted entries, we don't need to rzalloc+free an identical
block of memory for the table, we can just memset the existing one
the same applies to table clears without a function passed in that the table
doesn't need to be iterated and can just be memset
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8450>
If we don't tag compute sgpr as dirty they will point to the
ol buffer location.
This fixes arb_compute_shader-dlist with mcbp enabled.
Fixes: 85a6bcca61 ("radeonsi: pass at most 3 images and/or shader buffers via user SGPRs for compute")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8433>
The former allows specifying how many processes to spawn for tests. The
latter seems to spawn (up to) as many test processes as there are CPU
cores.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8451>
We sometimes use anv_layout_to_aux_state() to compute the aux state of
an image during the resolve operations at the end of a render
(sub)pass.
If we're dealing with a multisampled image that is created without a
transfer usage, our internal code might trigger a resolve using the
transfer layout (see genX_cmd_buffer.c:cmd_buffer_end_subpass), for
which the image doesn't the usage bit. The current code tries to AND
the 2 usages which won't have any bit in common, thus skipping all
checks below.
v2: Add the transfer usages depending on attachment usage (Lionel)
v3: Limit to samples > 1 (Jason) && DEPTH_STENCIL_ATTACHMENT_BIT (Lionel)
v4: Add transfer usage at image creation (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 54b525caf0 ("anv: Rework anv_layout_to_aux_state")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4037
Reviewed-by: Reviewed-by: Tapani Pälli <tapani.palli@intel.com> (v1)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8307>
SpvOpAtomicLoad and SpvOpAtomicStore are translated into
nir_intrinsic_image_deref_store/load instead of some separate
atomic intrinsics, however they don't have src or dest type
specified. Turnip doesn't support shaderImageFloat32Atomics
so type is just integer.
Fixes:
dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.image.guard_local.image.frag
dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.workgroup.payload_local.buffer.guard_local.image.comp
dEQP-VK.memory_model.write_after_read.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_local.image.comp
dEQP-VK.memory_model.write_after_read.core11.u32.coherent.fence_fence.atomicwrite.workgroup.payload_local.image.guard_local.image.comp
dEQP-VK.memory_model.write_after_read.core11.u32.coherent.fence_fence.atomicwrite.workgroup.payload_nonlocal.workgroup.guard_local.image.comp
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8476>
The tgsi.rst was not very clear but didn't indicate that they were
supported, and llvmpipe only supported double abs and not negate.
glsl_to_tgsi never generated them, and neither did the new nir_to_tgsi, so
just garbage collect it.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8369>
tgsi.rst says it's not supported, and llvmpipe, r600, and virgl don't
support it. Make sure nobody else introduces them like I did while
testing only on softpipe.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8369>
While tgsi_exec.c (softpipe) implemented 32b integer src mods, the
tgsi.rst documentation says only 32b negate is supported and not abs.
llvmpipe implemented 32 and 64 negate but not abs, virgl implemented
negate incorrectly, and r600 apparently doesn't do any integer src mods.
glsl_to_tgsi has apparently never generated integer src mods.
Given that r600 can't do any integer src mods, just stop trying to
generate them for TGSI.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8369>
It's unsupported, but gets set unconditionally by the state tracker,
even when fbfetch is to be used.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8461>
* struct shader_info provides a 32bit mask for textures_used
* samplers and samplerviews are a 1:1 mapping for shader descriptors
* also according to spec this is always 32 per stage
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8457>
We currently don't use push constants with the COMPUTE_WALKER command.
Make all uniforms to be pull constants.
The local group id previously was a push constant, but is now
available in R0.2[7:0].
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8342>
Commit bfcdc8f174 ("pan/bi: Add some zero bytes after shaders on
Bifrost") should have fixed the problem.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8470>
Note that we can't actually remove the packed structs themselves yet,
because tu still uses them in some hand-coded blit shaders.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7997>
Also, uncomment the `stc` test vectors (since the new decoder decodes
these properly) and comment out an instruction which looks suspiciously
like -6.0 in hex.
This also switches the parser back to `atomic.b.op` from `atomic.op.b`
which was a short-term workaround to make it easier for the legacy
disassembler.
Also switch the binary encoding for ldib to clear b0, because the new
disassembler warns about unexpected dontcare bits (which cases the
disasm to not match).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7997>
Drops decoding an ~850KB collection of instructions from ~4min to ~1sec.
Granted for normal sized shaders, this probably doesn't matter.. but it
at reduces my cycle time for fixing things to match existing disasm
syntax using this massive collection of unique instructions.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7997>
Once we switch over to the xml based ir3 ISA definition, the opcodes
will be decoupled from instruction encoding. Which will let us better
handle cases where a single "opcode" (from instruction encoding stand-
point) means different things on different generations. And also cases
like the different variations of `b`ranch instructions, which share a
single hw "opcode" plus a separate "brtype" field. When we start using
these in ir3, we'd like to treat them as separate instructions and not
have to care about the details of how they are encoded.
For now, these are only used internally within the new xml generated
instruction encoding, but once the existing "packed struct" encoding/
decoding is replace, we'll update ir3 to start using the new opcode
enums directly (except for the `mov` variants).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7997>
We'll want to re-use this when cutting over to the new XML based
instruction encoding. So untangle it from instruction packing.
Also, move handling of the appended constant data out of the
assembler, since this isn't much related to instruction encoding.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7997>
Mike Blumenkrantz
Pierre-Eric Pelloux-Prayer
Michel Dänzer
Lionel Landwerlin
Danylo Piliaiev
Witold Baryluk
Vinson Lee
Eric Anholt
Ilia Mirkin
Jason Ekstrand
Jordan Justen
Dylan Baker
Boris Brezillon
Rhys Perry
Rob Clark