Add a wrapper to allow calling the right simulator function based on
the hardware under simulation.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
Some of the counters need to be defined correctly.
v2: Remove references to extended performance counters. The hw does
not support them.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
In v3d 4.x we handle formats that are reversed or R/B swapped by
applying a format swizzle. This doesn't work on border colors though,
and for that there is a specific bit to reverse the border color in
the texture shader state.
In v3d 7.x we have new reverse and swap R/B bits and we no longer have
a bit to reverse the border color because the new reverse bit applies
to border texels too. Because of this, we absolutely need to use these
new bits in order to get correct border colors in all cases with these
formats.
When we enable the reverse and/or swap R/B bits, we are effectively
applying the format swizzle through them, so in these cases we need to
make sure the swizzle we program in the texture shader state is the
view swizzle provided by the API and not the composition of the format
swizzle with the view swizzle like we do in 4.x for all formats. The
same applies to custom border colors: we must not apply the format
swizzle to them for formats that are reversed or R/B swapped, because
again, this format swizzle is already applied through these new bits.
While we are doing this, we also fully adopt the texture shader state
spec from v3d 7.1.5 for v3d 7.x instead of using a description from
7.1.2 which is incompatible and required the driver to manually pack
some of the bits.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
We can use the actual bpp of each color attachment to compute real
tile memory requirements, which may allow us to choose a larger tile
size configuration than in V3D 4.2 in certain scenarios.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
TFU has changed on v71, specially on which registers to use, so that
means that support code change across versions. So as part of this
commit TFU copying is moved to a v3dx file.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
There are some new fields for YCbCr with pointers for the various
planes in multi-planar formats. These need to match the base address
pointer in the texture state, or the hardware will assume this is a
multi-planar texture.
Notice we don't use an address type for these fields in the XML
description. This is because the addresses are 64-bit aligned (even
though the PRM doesn't say it) which means the 6 LSB bits are
implicitly 0, but the fields are encoded before the 6th bit of their
starting byte, so we can't use the usual trick we do with address
types where the first 6 bits in the byte are implicitly overwritten by
other fields and we have to encode this manually as a uint field. This
would mean that if we had an actual BO we would also need to add it
manually to the job's list, but since we don't have one, we don't have
to do anything about it.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
As the packet CLIPPER_XY scaling, this needs to be computed on 1/64ths
of pixel, instead of 1/256ths of pixels.
As this is the usual values that we get from macros, we add manually a
v42 and v71 macro, and define a new helper to get those.
Those granularity values are the same for Vulkan and OpenGL, so
perhaps we should move them to a common place.
As with v3dv, V3D_X macro name is somewhat confusing. It is
specifically created to ask for define values that depends on the
version. But I also felt that V3D_DEFINE_X was too long.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
On V3D 7.1 there is not a flag on the Shader State Record to specify
if we are using shared or separate segments. This is done by setting
the vpm input size to 0 (so we need to ensure that the output would be
the max needed for input/output).
We were already doing the latter on the prog_data_vs, so we just need
to use those values, instead of assigning default values.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
Starting point for v71 version inclusion:
* Adds as one of the versions to be compiled on meson
* Updated the v3d_X and v3dX macros to include version 71
* Update the code enough to get it building when using v71.
Any real v71 support will be implemented on following commits.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
When the Z scale is too small guardband clipping may not clip
correctly, so disable it, which is a new option in V3D 7.x.
This fixes this test in V3D 7.x without needing any workarounds:
dEQP-VK.draw.renderpass.inverted_depth_ranges.nodepthclamp_deltazero
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
On V3D 7.1 there is not a flag on the Shader State Record to specify
if we are using shared or separate segments. This is done by setting
the vpm input size to 0 (so we need to ensure that the output would be
the max needed for input/output).
We were already doing the latter on the prog_data_vs, so we just need
to use those values, instead of assigning default values.
As we are here, we also add some comments on the compiler part.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
There are some new fields for YCbCr with pointers for the various
planes in multi-planar formats. These need to match the base address
pointer in the texture state, or the hardware will assume this is a
multi-planar texture.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
It is likely that we would need more changes, as this packet changed,
but this is enough to get basic tests running. Any additional support
will be handled with new commits.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
Content, structure and size would depend on the generation. Even if it
is needed at all.
So let's move it to the v3dvx files.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
