Not something we plan to ever support on Bifrost. v7 needs 64-bit
lowered at the NIR level. The support for 64-bit clauses on v6 is iffy
and not worth worrying about at this point.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8215>
Message-passing instructions that read/write staging registers access
either:
* a fixed number of registers
* vecsize registers (/2 for LD/ST_CVT if register_format is 16-bit)
* a computed number for TEXC
This adds the fixed counts into the XML for the first type and space to
specify the latter types.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8213>
Message-passing instructions have an associated message type, which the
clause header needs to signal. Instead of open coding this, let's
annotate the XML. Instructions not otherwise marked do not generate
messages.
Three exceptions apply:
* UBO loads need to use the attribute message type.
* Tile buffer access to Z/S needs ZS message type
* LD_VAR_SPECIAL.fragz needs ZS message type
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8213>
We already use plain neg/abs for this, don't mix it. Will avoid weird
enums for abs/neg with a generated IR.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8213>
Easy reduction in generated code, while we're at it. Pretty obvious
change after working on similar fixes for the other generators.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8213>
Certain transcendental instructions are not even possible to generate
since these bits are lowered away before the Bifrost backend is touched,
as far as I know.
Job management instructions (most interestingly DOORBELL) do not
correspond to OpenGL/OpenCL/Vulkan.
Segment arithmetic seems mostly useless for real code, any actual use
case I can think of is already covered by indirect loads/stores which
does the segment arithmetic implicitly. I've never seen this in blob
code, probably just a future proofing thing.
Dropping these instructions corresponds to a 3% reduction in generated
lines of code for the printer, builder, and packer for the new IR. Not a
terrible yield for functionality we'll likely never need.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8213>
Useful for instructions that need to be modeled in the IR (with support
in the builder and printer) but will always be lowered away before
packing since they don't correspond to anything real.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8213>
Certain instructions are highly unlikely to ever be used in the Bifrost
compiler, due to differences in the Mesa stack versus the Arm compiler,
as well as hardware features added speculatively and that never became
API visible. It doesn't make sense to include these instructions in the
IR, so let's disable them, while retaining complete disassembly.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8213>
These tests were designed before having access to canonical information
about the hardware and thus had two purposes:
* Validating that our understanding of an instruction (as defined by IR
semantics) matches hardware behaviour -- obsoleted by new information.
* Validating that the IR packing code is correct -- obsoleted by
rewriting the IR and rewriting the packing.
I dislike removing tests as much as the next person, but the value of
these will be nil by the end of the series, and will prove burdensome.
Proper unit tests will be useful, however.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8213>
The first callback which uses an image's loaderPrivate data was recently
added. Prior to this, dri2_create_image_khr_texture had been setting the
unused loaderPrivate field on the image it creates. This caused a
pointer type mixup in platform_android when it started using the new
callback. Fix this by no longer unnecessarily setting loaderPrivate in
dri2_create_image_khr_texture.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4010
Fixes: a2fb87eea6 ("egl/android: implement image cleanup callback")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8211>
Fixes dEQP-VK.api.copy_and_blit.*.4_bit. I think the MSAA2x and
MSAA8x just passed by luck.
Fixes: 7b21ce401f ("radv: disable FMASK compression when drawing with GENERAL layout")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7915>
fd_batch_check_size() should be after fd_batch_unlock_submit(),
otherwise batch_flush() called from fd_batch_check_size()
would wait on mutex forever.
Fixes: 02298ed1 "freedreno: Add submit lock"
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8205>
In gfx10_sh_query_end a new query buffer is being allocated if there are pending
shader queries. However since emit_shader_query is called only once per draw
command, this newly allocated buffer is not used subsequently.
So even though this newly allocated buffer is treated as the last query buffer,
it is never actually used by any of the queries. Essentially there is no need
to allocate a new query buffer on the same context i.e. draw command.
The existing query buffer can be used to provide the answers to multiple queries.
Allocating an extra buffer makes subsequent queries wait on a query buffer whose
fence will never be triggered since there are no subsequent draw commands to
trigger the same.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8083>
this is super gross. spirv doesn't provide any facility for doing per-component
writes, which means all components of a value must be written every time
to this end, we need to manually split both the src and dst composites and
do per-component access for each store in order to accurately handle both
non-sequential wrmasks (which could be handled by nir_lower_wrmasks, yes, but
we aren't using it) as well as partial wrmasks
see also mesa/mesa#4006
Reviewed-by: Erik Faye-Lund <kusmabite@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8152>
GL allows the pipeline to "infer" a tcs shader if a tes shader is bound using
API-specified default values for gl_TessLevelOuter and gl_TessLevelInner,
but VK requires that both shaders be explicitly present
to handle this, create a generic tcs which translates all vs outputs to
invocation-based arrays and copy the appropriate value to the expected tes
input array location. also emit the default inner/outer values as push constants
so we don't have to recompile the shaders whenever the api calls occur
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8152>
