I didn't test "nvk: Fix maxVariableDescriptorCount with iub" as
thoroughly as I should have and it regressed
dEQP-VK.api.maintenance3_check.descriptor_set because we were then
violating the requirement that maxPerSetDescriptors describes a limit
that's guaranteed to be supported (and reported as supported in
GetDescriptorSetLayoutSupport).
That commit was also based on a misreading of nvk_nir_lower_descriptors.c
where I thought that the end offset of an inline uniform block needed to
be less than the size of a UBO. That is not the case - on closer
inspection that code gracefully falls back to placing IUBs in globablmem
if necessary. So, we can afford to be less strict about our IUB sizing
and only require that IUBs follow the existing limit imposed by
maxInlineUniformBlockSize.
Fixes: ff7f785f09 ("nvk: Fix maxVariableDescriptorCount with iub")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37922>
It assumes you don't have dead writes to variables in the last block, and
will copy-propagate consts from the first write it finds.
Without this, the upcoming nir_opt_copy_prop_vars() change to have more
restricted write masks caused less nir_opt_dead_write_vars() (since it
doesn't trim write masks for dead writes, only removes fully-dead writes),
and then zero-initialization of variables at the top of a shader got
propagated, rather than the final store of the used channels of the
variable.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37313>
Usage of implicit input file in valhall_parse_isa makes it very
complicated for tools like ninja-to-soong to generate the Android
equivalent build file.
Instead use an explicit argument.
It also deduplicate the location of the input file name to have it
only in 'meson.build'.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37742>
The extension is emulated on top of traditional transient attachments,
with the driver creating extra internal attachments for each subpass
where the MSRTSS sample count doesn't match the color or depth/stencil
attachment's sample count and insert unresolves/resolves around them,
except for the cases where the original attachment is unused
before/after the subpass respectively. An important case is if the
original attachment would be cleared at the beginning of the subpass, in
which case we rewrite the clear to apply to the driver-internal
multisample attachment. This requires redirecting the clear colors in
CmdBeginRenderPass2.
We create images, image views, and backing memory for these attachments
that are part of the framebuffer with classic renderpasses or allocated
per-render-pass with dynamic rendering.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37919>
These ops replicate the single-sampled source attachment to the
multi-sampled destination attachment before the start of a subpass. This
is the new hardware feature for
VK_EXT_multisample_render_to_single_sampled, and the actual
implementation of the extension emulates everything on top of these.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37919>
This is an old leftover from the skeleton stage of the driver, and we
have never needed anything other than the image view. Having this in
the way made it impossible to write generic code that reads the
attachments in the !image_framebuffer and dynamic rendering cases.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37919>
This will be necessary so that the 3d path can handle "unresolves",
where we select the single-sampled shader for the single-sampled source
but enable multisampling *without* per-sample shading to replicate it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37919>
We need to always use the FMT6_Z24S8_AS_R8G8B8A8 format for GMEM even if
UBWC is disabled, as already done for the 2d store path. Because we
use the pre-baked RB_MRT_BUF_INFO register value, this means we have to
override it.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37919>
This was already present in the 2d paths but not in the 3d path,
probably because the flag was moved there only on a7xx and it was
missed. Prevents page faults from bad flag buffer accesses.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37919>
This can happen if we resolve to a resolve attachment and then use that
resolve attachment as an input attachment in a later subpass. We don't
need to put it in GMEM, but it's still considered "written" because
input attachment reads need a dependency after the resolve.
MSRTSS input attachment tests effectively created such a scenario after
lowering to transient multisample attachments and inserting resolves.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37919>
If the first use of an attachment is as an input attachment, but it has
LOAD_OP_CLEAR, then we have to clear the attachment in GMEM and patch
the input attachment to refer to GMEM. Noticed by inspection.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37919>
Trivial but still better than cs_add32 workaround on platforms
supporting MOVE_REG32.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37951>
This change:
1. Use a different loop var for outer multidraw repeat
2. Make sure fau total_count matches the filled faus per loop
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37951>
Fix a regression from an unfortunate typo.
Fixes: 48e8d6d207 ("panfrost, panvk: The size of resource tables needs to be a multiple of 4.")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37951>
Should only set once outside the multidraw loop so that per draw can
patch its own own desc attribs when needed.
Fixes: a5a0dd3ccc ("panvk: Implement multiDrawIndirect for v10+")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37951>
bi_load_tl's dst arg was named src, this was confusing.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37955>
IADD_IMM and uniform loads should not be spilled. Make them
rematerializable. Restrict to loads that write at most one register
for simplicity for now.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37955>
Mesh shader workgroups always have the same amount of subgroups.
When the API workgroup size is the same as the real workgroup
size, this is a small optimization (using a constant instead of
a shader arg).
When the API workgroup size is smaller than the real workgroup
size (eg. when the number of output vertices or primitves is
greater than the API workgroup size on RDNA 2), this fixes a
potential bug because num_subgroups would return the "real"
workgroup size instead of the API one.
Cc: mesa-stable
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37947>
The object buf is referenced at the beginning of the
r600_draw_rectangle() function and should be freed
at the end. This issue was introduced with cbb6e0277f.
Fixes: cbb6e0277f ("r600: stop using util_set_vertex_buffers")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37617>
We don't request feedback for create and destroy commands, so it's
not needed to allocate feedback buffer.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37884>
We don't request feedback for create and destroy commands, so it's
not needed to allocate feedback buffer.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37884>
