Use pan_ instead of panfrost_ as a prefix, and move the function to
pan_format.h, since this modifier has nothing to do with AFBC. We keep
it in pan_format.h since the amount of code doesn't justify having a
separate file for MTK tiling.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ryan Mckeever <ryan.mckeever@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34767>
Let's turn the pan_best_modifiers[] array into a PAN_SUPPORTED_MODIFIERS()
macro, such that:
- we don't have to update PAN_MODIFIER_COUNT when adding new modifiers
- we can let the compiler see through the values inside this array and
possibly optimize the modifier selection loop
While at it, we move this new PAN_SUPPORTED_MODIFIERS() macro to
pan_format.h, since modifiers and formats are kinda related, and
pan_layout.c/pan_texture.h were not a great fit.
Also move the drm_is_xxx() macros to pan_format.h, to be consistent.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ryan Mckeever <ryan.mckeever@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34767>
It's not used, and we shouldn't have to check the format to identify
a modifier anyway.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34767>
This way, a pan_format instance fits into a single u32. This forces us
to have an explicit translation in pipe_to_pan_bind_flags(), which is
probably a good thing anyway.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ryan Mckeever <ryan.mckeever@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34767>
c_args is not used for C++, so these were just being ignored. As far as
I know this was inconsequential. I doubt anybody is compiling panfrost
on msvc, and I didn't see any initializer override warnings.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35035>
We had a duplicate function there, let's use common code instead and
allow v4.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34997>
We move pan_raw_format_mask_midgard to pan_format.c instead making
pan_shader.c not depending on any GENX.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34895>
Also move bifrost_blend_type_from_nir to pan_blend.c, rename it and
makes it not GENX.
This part is related to blend so it makes more sense to have it there
and this will allow us to make pan_shader.c not GENX.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34895>
Storage access to images using LEA_TEX[_IMM] has limitations on some
fields in the texture descriptors, making them incompatible with the
descriptors required for texture access, specifically in the case
non-zero levels.
This change sets up two sets of texture descriptors for image views of
storage images, then picks the correct one when writing the image view
descriptors.
Backport-to: 25.0
Backport-to: 25.1
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34839>
We're currently not setting the v10+ width/height in the plane
descriptors. This change ensures we do.
Backport-to: 25.0
Backport-to: 25.1
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34839>
Rather than setting the plane size to the full allocation minus the
current offset, set it to the actual size of the plane.
Fixes: db20152c8a ("panfrost: Handle Valhall texturing")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34839>
Currently, we will always be setting the slice stride in the plane
descriptor to the surface stride, as the check for multisampling is true
even for single sampled surfaces.
This change fixes this check.
Fixes: db20152c8a ("panfrost: Handle Valhall texturing")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34839>
This will simplify things a bit later
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32650>
We were not using the nir_lower_printf_buffer pass, this fix issues with
printf usages with OpenCL C internal shaders.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34814>
This is similar to the approach in panvk, where we pass blend constants
to the blend shader in fixed FAU slots instead of specializing the
shader on blend constants. TODO: explain midgard stuff
This eliminates the blend shader variant cache, which performed very
badly when the working set of blend constants in an application was >32
(the maximum number of variants stored). Just increasing the cache size
like we did in f1f39fa645 ("panfrost: Increase the limit for blend
shader variants") would help for applications with a larger static set,
but we would still have cache thrashing on applications which change the
blend constants dynamically.
For gfxbench gl_driver, which uses 386 blend constant values, this
improves FPS on a G610 from 6.06 to 40.48. Most applications are
unaffected, because they don't use enough constant values to cause
thrashing.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Ryan Mckeever <ryan.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34666>
The blend shader cache from pan_blend.h is not used in panvk, which has
it's own blend shader cache and compilation entrypoint. Moving this
allows us to use gallium-specific things in the cache.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Ryan Mckeever <ryan.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34666>
v10 have 96 and v12+ have 128, not the opposite.
Fixes: 811525b543 ("pan/genxml: Build libpanfrost_decode for v12")
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34815>
This is supported since v12 and we fixed the last remaining issues
related to it.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34674>
This logic to enable LD_VAR_BUF[_IMM] is on the conservative side.
For fixed varyings, we would need to know what the VS outputs to correctly
compute the indices the FS has to load from. For general varyings, the
locations are aligned either by the linker or by the application in case
of separable shaders.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34074>
This change removes the limit of 16 varyings caused by the 8-bit offset
value used in LD_VAR_BUF[_IMM]. LD_VAR[_IMM] is used instead and the
necessary ADs are emitted at draw time.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34074>
A8_UNORM on v9+ is using RGBA8_UNORM as a pixel format with the
A8_UNORM clump format to dealing with the diffences between
RGBA8 and the actual A8 in-memory layout.
The problem is, LEA_TEX only loads the InternalConversionDescriptor
which contains only the pixel format, and that's what ST_CVT uses
to do the conversion, so we'll actually store 4 components instead
of one.
This shows up with
dEQP-VK.image.load_store.without_any_format.buffer.a8_unorm* after
enabling maintenance5.
For now I've turned off the image storage capability for A8_UNORM
on all gens, but I'd be fine disabling it only on v9+ if you think
that's preferable.
Fixes: d95423686f ("pan/format: Add PAN_BIND_STORAGE_IMAGE flag")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34648>
On v12+, the hardware report support for 8 levels but
effectively only support up to 4 levels.
In case more than 4 levels are used, it will default to 0xAA when
tile_size is 32x32 or lower, otherwise 0xAC when the tile_size is greater than 32x32.
This patch makes it that we now ensure that the bins can fit inside out
tiler budget and otherwise drop levels until it fit.
This also allows the hardware to decide the hierarchy on v12+
if we know it will fit.
This fixes "dEQP-GLES31.functional.fbo.no_attachments.maximums.all" and
dEQP-GLES31.functional.fbo.no_attachments.maximums.size" on v12+ but
also likely more if we were exhausting the memory budget.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Backport-to: 25.1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34559>
The HW does not support STORAGE_IMAGE for all formats that can be sampled
or used as render targets. The HW does not support STORAGE_TEXEL_BUFFER
for all formats that can be used as render targets.
Signed-off-by: Ryan Mckeever <ryan.mckeever@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33787>
We need GPU_FEATURES to determine if this is another variant but this
will do for now.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34032>
We need GPU_FEATURES to determine if this is another variant but this
will do for now.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34032>
This rule changed with v11 and is needed for
"dEQP-VK.fragment_operations.early_fragment.discard_early_fragment_tests_stencil"
to pass.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34032>
The meta tile size changed on v12+ to 64x64 and the same apply to the
checksum region size.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34032>
On "5th Gen", the meta tile size changed to 64x64.
This adds a new helper to get the meta tile size depending on the
generation.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34032>
This is the official name, let's match with newer generation too.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34032>
Read-only ZS optimization can only happen if the ZS tile buffer is not
written, which can only be known when the fixed-function settings is
set.
Change pan_earlyzs_get() to take an enum instead of a boolean and
differentiate ZS-read and ZS-read-with-readonly-optimization-allowed.
Fixes: 25a993731087 ("pan/earlyzs: Support the shader ZS read-only case and its optimization on v10+")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34480>
The setting of the clean_pixel_write_enable flag in pan_prepare_rt
was not consistent with the crc valid calculations in pan_emit_fbd.
This caused the crc_valid flag to not be accurate, causing transaction
elimination to fail.
Fixes: eac8f1d460 ("Revert "panfrost: Disable CRC by default"")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34408>
In order to enable higher MSAA modes, we're going to have to perform
some calculations on how to budget the (sometimes) limited tile-buffer
space.
Due to limited tilebuffer space, we need to prioritize a bit here.
First, we reserve space for 4x MSAA for all formats. Then we try to fit
8 color attachments into the tile-buffer. And then finally, we calculate
how many extra multi-sample buffers we can fit into the rest.
The reason we reserve 4x MSAA first, is that this is required by all
Vulkan versions. It also prevents us from regressing existing features.
Then we try to pick 8 color attachments next, because that's required by
Vulkan 1.4 as well as Vulkan Roadmap 2024 and D3D12. Vulkan Roadmap 2022
requires 7 as well.
This adds helpers that implements this, which can be used by both the
Gallium and the Vulkan driver. It's really benefitial if both of these
drivers prioritize the same way here.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
On v5, as well as v7 onwards, we can disable pipelining in order to fit
more data into the tile-memory. This is important in order to support
multiple, large color buffers with high MSAA sample counts.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
We also have a budget for the tile size for depth-buffers. It's
currently hard to trigger issues with this than for color-buffers,
but this becomes important when we support larger MSAA counts.
We also need to take a bit of care for stencil-only attachments, because
they also count against a limit here. We really only care about the
sample counts here, because the stencil buffer budget is always a
quarter of the depth-buffer budget, and always uses a single byte per
sample.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
There's two limitations we have to cater to:
1. The HW needs at least one render-target. We can disable write-back for
it, but it needs to allocate tile-buffer space for it.
2. The HW can't have "holes" in the render-targets.
In both of those cases, we already set up dummy RGBA8 UNORM as the format,
and disable write-back. But we forgot to take this into account when
calculating the tile buffer allocation.
This makes what we program the HW to do consistent, meaning we don't end
up smashing the tile-buffer space. We might be able to do something
better by adjusting how we program these buffers, but let's leave that
for later.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
These GPUs had their tilebuffer sizes listed at twice their actual
values. While that still works, it ends up disabling pipelining in some
cases. This gives a significant performance hit, compared to using the
correct values.
But, it turns out to be hard or impossible to trigger at the moment, due
to the limited number of MSAA samples we support. Once that changes,
this is a lot easier to trigger, so let's fix it up.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
This is an n-queen pattern, where no two values should be on the same
row or column. But this and the second to last element has the same y
component, and neither has the negative one.
Let's fix this up by setting the first value to the negative value. This
matches the D3D 16x sample pattern.
Fixes: a61fb62966 ("panfrost: Upload sample positions on device init")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33925>
Valhall supports all combinations of ftz/preserve denorm behavior
between FP16 and FP32 except FP16=ftz, FP32=preserve. Because of this,
we can't advertise independent denorm behavior.
Even with INDEPENDENCE_NONE, it is still possible for shaders to set
denorm behavior for one size and leave the other size unspecified.
Previously we were defaulting to preserve for any unspecified size, but
with FP16=ftz, we need to default unspecified FP32 to preserve.
When advertising INDEPENDENCE_NONE, the CTS checks that the
shaderDenormFlushToZeroFloat* and shaderDenormPreserveFloat* features
are equal for all sizes, so we need to advertise the same supported
denorm behavior for FP64 even though we don't support FP64 at all.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33660>
