Report the -rXpY info in the deviceID.
Reviewed-by: John Anthony <john.anthony@arm.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39267>
Texel buffers are currently described by a TextureDescriptor, which
leads to restrictive limits on size and alignment. These limits can be
avoided by using AttributeDescriptors + AttributeBufferDescriptors
instead.
This requires us to access texel buffers using attributes rather than
textures, which involves setting up AttributeDescriptors and
AttributeBufferDescriptors in their respective allocations, rather than
the previous TextureDescriptors in the texture allocation.
This is already done for images, so we simply place the texel buffer
attributes after the images and ensure the indexing if offset correctly.
Accessing a texel buffer thus becomes:
1. Get the buffer address and ConversionDescriptor with LEA_ATTR[_IMM]
2. Use LD_CVT to get the value
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38490>
Once we move texel buffers to use Attribute Buffers, we'll encode them
as MALI_ATTRIBUTE_TYPE_1D. This means we can store the actual Attribute
Descriptor in what is usually the space for an
ATTRIBUTE_BUFFER_CONTINUATION_3D.
This is good, as we'll need to use the offset functionality of the
Attribute Descriptor to allow lowering
uniformTexelBufferOffsetAlignmentBytes.
This commit therefore creates a path for setting up the Attribute
Descriptor and Attribute Buffer Descriptor for texel buffers in
meta_desc_copy.
Note that this path will not be taken yet, as no images use
MALI_ATTRIBUTE_TYPE_1D.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38490>
As we'll need to pack texel buffer attributes after image attributes in
panfrost and after vertex attributes in panvk, this adds a lowering pass
to achieve that.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38490>
Rather than loading a single 64bit channel with
load_texel_buf_index_address_pan, load three channels of 32bit each. The
last channel is required by the next commit.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38490>
panfrost_emit_image_attribs is only called when the context's image
state is dirtied and uses the context's image_mask to write attributes
and attribute buffers.
However, it uses the shader's attribute_count (which in this context is
the last bit of the shader's images_used) to calculate the size of the
buffers.
In case more images are bound than the currently bound shader uses, this
would lead to out-of-bounds writes.
This change updates the allocation to use the last bit in the context's
image_mask for size calculations.
It also removes an unused parameter from emit_image_bufs and updates a
parameter name in emit_image_attribs to be more descriptive and match
the documentation.
Fixes: dc85f65e05 ("panfrost: emit shader image attribute descriptors")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38490>
nir_u2u32 is presumably a leftover from when the texture size was loaded
from a 16 bit field, but should no longer be necessary now that we're
loading 32 bits
Also renames the "bytes" variable to "size" to align with the descriptor
we're reading.
Fixes: 4573110e4e ("pan/v9+: Make texel buffers use BufferDescriptor")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38490>
VGPRs can be linear too, and RT function calls will add VMEM
instructions acting on linear VGPRs. Using the linear VGPR in a block
with only linear preds will cause the pass to incorrectly skip inserting
s_waitcnt.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39157>
`_mesa_delete_program` and `_mesa_reference_program_` both use fields
in `sh` without determining whether `sh` or `arb` is valid. Herein
lies the problem. I cannot see any reliable way to determine which is
valid without knowing what call path you are in.
There are two possible methods, but neither seems particularly
reliable. We could check whether `shader_program` is `NULL`, or we
could check whether `Parameters` (only used for ARB assembly shaders)
is `NULL`.
Instead of doing that, I chose to add a new field that captures the
`is_arb_asm` parameter already passed to `_mesa_init_gl_program`. This
seemed the most reliable. It is possible that more
`assert(!prog->is_arb_asm)` and `assert(prog->is_arb_asm)` should be
sprinkled throughout the code base.
I don't know how this has not already been a problem. Starting with
492a176cbb ("util: increase SHA1_DIGEST_LENGTH to 32
(BLAKE3_KEY_LEN)"), I observed segfaults in
`_mesa_uniform_detach_all_driver_storage` while freeing ARB assembly
shaders. Those shaders should never hit this path.
Not all assembly shaders hit this path. In fact, **nothing** in the
open shader-db encounters this problem. This is presumably why
pre-merge CI didn't catch this problem. In my closed shader-db,
shaders from the following applications hit this:
- rocketbirds-hardboiled-chicken
- shadowrun-returns
- windward
- ziggurat
I believe it was just blind luck that most of the time the fields of
`sh::data` that were access through this path, `sh::BindlessSamplers`,
and `sh::BindlessImages` happened to line up with fields of `arb` that
contained `NULL`. Changing the size of the hash key changed that luck.
Fixes: ca16c271fa ("mesa: make struct in gl_program a union and remove FIXME")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39243>
This just makes the code slightly easier to follow, because we don't
need to bother with the verbose PVR_PER_ARCH macros here.
Functions that are left out are those that doens't have an alias. This
is either because they are only used by the dispatch-code, or because
they are entrypoints. Neither of those benefits from an alias.
Reviewed-by: Ashish Chauhan <ashish.chauhan@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39035>
When using the aliases for the PVR_PER_ARCH functions, it's hard to see
what's per-arch and what's not. Let's bake that into the name instead,
so it's a bit more clear.
Reviewed-by: Ashish Chauhan <ashish.chauhan@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39035>
This is not the norm... yet. A later patch will go in the oposite
direction, but it seems better to make things consistent first, in case
we decide to not stick with the later patch.
Reviewed-by: Ashish Chauhan <ashish.chauhan@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39035>
These were just missed case when switching to the aliases earlier. This
is just a consistency issue, it doesn't affect correctness.
Reviewed-by: Ashish Chauhan <ashish.chauhan@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39035>
Not sure how this didn't blow up in testing, but this misses the
entire per-arch dance for this function. Let's fix it up!
Fixes: e762592bff ("pvr: build pvr_arch_*.c as a multi-arch sources")
Reviewed-by: Ashish Chauhan <ashish.chauhan@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39035>
We don't need pvr_physical_device.h included here, but we *do* need it
in pvr_arch_framebuffer.c, so let's move the include there. This will
help with avoiding circular includes.
Fixes: e762592bff ("pvr: build pvr_arch_*.c as a multi-arch sources")
Reviewed-by: Ashish Chauhan <ashish.chauhan@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39035>
Not sure how we missed this, but we need the declaration here. This
probably only worked because of transitative includes, which we shound't
rely on.
Fixes: 82fad3f258 ("pvr: Enable PBE_FILTERABLE_F16")
Reviewed-by: Ashish Chauhan <ashish.chauhan@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39035>
Not sure how we missed this, but we need to include pvr_formats.h here,
otherwise we don't see all the definitions we need. We probably got away
without this due to other transitive includes, but let's not rely on
that.
Fixes: 949e41a664 ("pvr: split pvr_formats.c")
Reviewed-by: Ashish Chauhan <ashish.chauhan@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39035>
should_split_render_pass()? No! You should not split the render pass.
You should never split the render pass! There's a better way and it's
the DCD0.primitive_barrier bit. This bit tells the fragment unit to
treat the current primitive as a barrier which forces it to wait until
all previous primitives for the covered fragments have executed before
executing this one. This give us a nice, pipelined, way to do fragment
barriers that doesn't involve splitting the render pass.
This new approach also has the advantage that it works properly in
secondary command buffers as it needs to know nothing about the actual
rendering state since it's just a draw call. Even the dimensions of the
primitive itself are determined by the hardware.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14328
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39051>
Blend shaders are alreaday lowered. However, since the lowering pass is
idempotent, it's harmless to lower again.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39244>
It's a lot more explicit to just have an intrinsic for this than to
treat blend shaders as their own weird stage. Also, the new intrinsic
uses the same io_semantics as a fragment store so the back-end code is a
little easier to read because it now checks sem.dual_source_blend_index
instead of the generic load_input offset.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39244>
The one non-trivial change here is that we're now using BLEND with a
constant descriptor instead of ST_TILE for MSAA blend shaders. However,
this shouldn't make any practical difference.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39244>
This helper is shorter and it also caches the result in the collect
cache so it can be used as a vector (or, in this case, a 64-bit value).
Cc: mesa-stable
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39244>
