The logical send lowering already resolves sources when constructing
the send payload, so prior to that lowering, we don't need to apply
any special restrictions here.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
The logical send lowering already resolves sources when constructing
the send payload, so prior to that lowering, we don't need to apply
any special restrictions here.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
The goal here was to avoid propagating source modifiers, unusual
regions, and other things that couldn't be used as a send source.
A few patches ago ("brw: Properly resolve non-sendable sources in a few
logical opcodes") we fixed the logical send lowering to handle these
by resolving them when constructing the send payload. So now prior
to lowering, we don't need to treat these opcodes specially.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
This introduces enums for SHADER_OPCODE_SEND[_GATHER] sources, similar
similar to what we've done for most of the newer logical opcodes. This
allows us to use actual names for sources rather than remembering their
order, or leaving ourselves comments like /* ex_desc */ all over. It
will also make it easier to add or reorder sources in the future.
While we're at it, we also standardize on the number of sources.
Previously, we allowed SHADER_OPCODE_SEND to have either 3 (monosend) or
4 (split send) sources, but this is mostly for haphazard historical
reasons. We now specify all sources every time, eliminating the need
for careful inst->source checks before accessing the last source.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
Sources decorated with source modifiers, immediates, or particular
stride combinations may not be directly usable as SEND operands. We
have to resolve them to an ordinary VGRF first.
Most opcodes do this as part of broader payload construction, but these
send directly because the messages are very simple.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
The is_send() helper is just a wrapper around inst->is_send_from_grf()
now, so we can combine the two. Trim the name from is_send_from_grf()
to is_send(), as it's shorter, and also matches is_math().
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
We used to have inst->mlen set on various virtual opcodes, but these
days the only instructions that should have inst->mlen set are
SHADER_OPCODE_SEND and SHADER_OPCODE_SEND_GATHER, which are already
covered in inst->is_send_from_grf(). So we don't need to check for mlen
specifically.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
Explicitly list FS_OPCODE_INTERPOLATE_AT_* as allowed, as they were
already allowed by the default case. Interlock, memory fence, and
barrier were disallowed and remain so. Uniform pull constant load
was allowed and remains so. SHADER_OPCODE_SEND and SEND_GATHER get
explicit handling.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
Every case but SHADER_OPCODE_SEND and SHADER_OPCODE_BARRIER will be
lowered to SEND before register allocation happens. And the barrier
send has a null destination, so the restriction doesn't apply.
Note that this hack is for Gfx9 only, so we don't need to worry about
Xe3's SHADER_OPCODE_SEND_GATHER feature.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
We used to have other opcodes as well, but we've since transitioned
entirely to logical send lowering prior to register allocation.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
A number of places emit monolithic sends, where the second payload is
empty. Some places were using a BAD_FILE register, while others were
specifying the hardware ARF null register. Switch to BAD_FILE for
consistency - this is usually what we do for "source isn't present".
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
This has to happen before lowering doubles, we can't do this in the backend.
Otherwise the backend's own vote_feq lower will result in an unlowered 64-bit
feq operation which it can't consume and can't lower. On GL drivers without
native fp64, this fixes tests like:
KHR-Single-GL46.subgroups.vote.graphics.subgroupallequal_double
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36649>
glsl needs to plumb this from the backend. we should clean up
nir_lower_subgroups to use this later but I don't have time to churn everything
right now.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36649>
As we use _WIN32 in many place, and WIN32 usage are depends on windows.h that defined in minwindef.h.
So do not use it at all, after this change, DETECT_OS_WINDOWS and _WIN32 will have the same effect.
This is for avoid confusion when DETECT_OS_WINDOWS and _WIN32 are mixed used.
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36654>
As float16_t may comes from arm_neon.h:
arm_neon.h:74:16: error: conflicting declaration 'typedef __fp16 float16_t'
74 | typedef __fp16 float16_t;
Also it is std::float16_t from <stdfloat> as part of C++23
So place it under namespace mesa to avoid conflict when upgrading xxhash.h to v0.8.3
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36654>
We did not count invocations when a shader discarded fragments.
Can just move this to before running the shader so the exec mask
still includes them.
Reviewed-by: Brian Paul <brian.paul@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36678>
When perfetto isn't enabled, atrace can still be used freely on Android.
All trace micros have accounted for that, but the init is missed.
Cc: mesa-stable
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36655>
This could cause importing buffers, in particular multiplanar YUV, since
when the offset of the plane is added, the aligned size could be beyond
the end of the buffer.
Fixes: 27b0f64b3e ("freedreno/a6xx: Use handle for explicit layout")
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36656>
A bunch of fields are fixed and other depends on what stages are
bound.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36665>
This instruction has a bunch of fixed fields and the rest depends on
the shader stages enabled. With the pipeline object going away, we
can't keep this on the pipeline.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36665>
Using 3DSTATE_SBE_SWIZ for providing the implicit PrimitiveID value
(when not written by the previous stage) seems to be the legacy way of
doing things on Gfx7 and prior.
On Gfx8+ we got this new
3DSTATE_SBE::PrimitiveIDOverrideAttributeSelect to get the HW to write
the value wherever we want.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36665>
The pipeline object going away, we won't have a place to keep this. We
can make the diff/emission efficient enough that it won't matter much.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36665>
The vulkan runtime doesn´t store this parameter in the dynamic state
(since it's not a dynamic state). Just capture it at compile time and
leave on the wm_prog_data.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36665>
Convert pipe format to virgl format since virglrenderer will convert it
back from virgl format to pip format when create pipe_resource.
According to the call stack, only if vflags include flag:
PIPE_RESOURCE_FLAG_MAP_PERSISTENT or PIPE_RESOURCE_FLAG_MAP_COHERENT
will make it call into virgl_drm_winsys_resource_create_blob() so here
remove redundant if condition in virgl_drm_winsys_resource_create_blob().
Signed-off-by: Julia Zhang <julia.zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36672>
