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>
All expressions have been replaced by their closest equivalent. No major
simplification efforts have been made to minimize risk of regressions.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7799>
This makes for a more self-describing iteration behavior, and it gets rid
of the need for the duplicated "final check" at the bottom.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7799>
