Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
The only functional change is that the new code doesn't reserve space
for dummy allocations. However, the old code never actually took dummy
allocations into account when placing RTs so they end up overlapping
anyway and it's not causing problems. Also, we set rt_count when there
are no attachments and that doesn't reserve dummy space so clearly
running with zero attachments is fine.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
For now, both exist simultaneously and we'll try to keep them in sync.
Eventually, everything will be converted to the new structs and we'll
drop the old.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Without this, GDB will say PIPE_FORMAT_ZS_START instead of
PIPE_FORMAT_S8_UINT. This makes pipe_format more debuggable.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
The helper isn't really helping us that much here and we already do our
own thing in the CSF code so we might as well here.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
We don't support CRC in Vulkan right now and this stuff isn't that
useful anyway since we can't do CRC state tracking on the CPU in Vulkan.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
This may have been the easy choice at the time but it leaves us with a
nasty bit of ABI between the framebuffer code and the Vulkan driver.
Instead, do the array calculation in the Vulkan driver.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Having this be stateful is hard to follow. Especially since, in the
previous incarnation, if it's called twice without resetting the dcd
pointer, it'll happily write new DCDs to the old pointer. In the new
version, it's explicit when we build new frame shader DCDs.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
In cases where we have to do the same offset calculation on both the CPU
and GPU halves of a pointer, this lets us do it once and avoid things
getting out-of-sync.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
This adds a helper for filling out framebuffer descriptors as well as
one for mapping to pan_fb_info.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
One of the advantages to this new FB load shader, apart from it being
common, is that it's able to properly handle partial tile loads.
Instead of doing the force_preload/clear dance that PanVK is currently
doing, these shaders are clever enough to detect whether or not they're
inside the Vulkan render area and clear the inside while loading the
border pixels.
In order for this to work, there are two new intrinsics which provide
the framebuffer bounding box and the clear values. We need this in
order to handle partial loads correctly.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Fixes: 6fc1030e4f ("nir: Add some new panfrost fragment shader intrinsics")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
The util code doesn't actually fill things with zeros so the high bits
are undefined. If we really want things replicated, we need to mask off
just the bits we care about.
Cc: mesa-stable
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39759>
I am not aware of any legal reason why this should be there and I haven't done
it on any new code in ages. Drop it rather than updating the emails. I am quite
sure people know how to reach me in any case.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenz.ca>
Acked-by: Mary Guillemard <mary@mary.zone>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40031>
If you were to try to reg allocate to more full regs than the file has,
you'll end up bit clearing off of available[]/available_to_evict[] and
corrupting the RB tree. Let's make sure we don't land there again.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39997>
As the comment says, we want to limit our pressure based on underlying HW
reg file size, not max it out to HW reg file size. This caused us to not
spill when we should when the HW reg size was bigger than the ISA reg file
size, leading to OOB writes in RA when it tried to allocate to the limit
pressure we spilled to.
Fixes segfaults in llama.cpp's test-backend-ops.
Fixes: e6e34883a9 ("ir3: Add wavesize control")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14846
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39997>
To demonstrate that this helper is legitimately useful cross-tree and should
be made common code :-)
Sample AGX IR with this patch:
10 = mov_imm #0x3f5680f1 /* 0.837905 */
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Mary Guillemard <mary@mary.zone>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40021>
This helper is generally useful when trying to prettyprint a 32-bit value, so
make it available to the rest of the tree.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Mary Guillemard <mary@mary.zone>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40021>
Otherwise, the following error is observed:
lvp_pipeline.c:422:28:
error: variable 'progress' is used uninitialized whenever
'if' condition is false [-Werror, -Wsometimes-uninitialized]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40046>
The way I understand the HW docs is that the polygon offset is applied
always in 24bit depth domain (there are no polygon offset depth format
control registers like r600 has), so we need to manually rescale for
16bit buffers.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39196>
The main change here is adding an architecture argument to
pan_blend_can_fixed_function, so that we can take into
account fixed function hardware limitations in particular
generations.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39705>
Blend shaders operate on 4 components, and this makes
a difference for some operations (particularly blends
with constant values). Usually the hardware handles the
conversion smoothly, but there are a few special cases where
there is an alpha channel in the "wrong" place; we need
to handle those specially.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39705>
We can still render to it, but hardware blending needs a slightly
different path (the supplied GL_R8 internal format did not work
correctly).
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39705>
If the output format has no alpha channel then DST_ALPHA is the same
as CONST_ONE, and hence the blend operation becomes trivial (opaque).
This also fixes some piglit test failures, possibly because the
fixed function blending hardware isn't really set up to handle RGB1.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39705>
We were hitting an assert on a piglit test on midgard. Note that,
oddly, PIPE_FORMAT_R10G10B10X2_UINT is not defined, so we cannot
add that case.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39705>
The Vulkan spec states:
"If logicOpEnable is VK_TRUE, then a logical operation selected by
logicOp is applied between each color attachment and the
fragment’s corresponding output value, and blending of all
attachments is treated as if it were disabled. Any attachments
using color formats for which logical operations are not supported
simply pass through the color values unmodified."
pack_blend() was only checking blendEnable from the attachment state,
causing hardware blending to be applied even when logic ops were enabled.
This is the v3dv equivalent of the RADV fix in commit c172f6ef01
("radv: fix disabling logic op for srgb/float formats when blending
is enabled").
Fixes: dEQP-VK.pipeline.monolithic.logic_op_na_formats.*_blend
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40025>
Since the stride is always 32 dwords, we need to treat the workgroup
size as multiples of that value. Using MAX2() only works for cases where
the workgroup size is less than 32, which was hit by some CTS with 1x1
workgroups.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39981>
The Mali GPUs have native support for user-defined depth clamp bounds
via the LOW_DEPTH_CLAMP/HIGH_DEPTH_CLAMP registers and the
depth_clamp_mode field. Wire up the existing runtime plumbing to these
registers so applications can specify a custom depth clamp range instead
of always clamping to the viewport's minDepth/maxDepth.
While at it, drop the redundant CLAMP on depth values in the CSF path.
Since VK_EXT_depth_range_unrestricted is not supported, panvk_depth_range()
is already guaranteed to produce values in the 0..1 range.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39925>
