This should have been a multiply not an add.
Fix an assertion when running in tracing mode on panvk.
Fixes: 79a1d98e1e ("pan/csf: make cs_builder.h usable from c++")
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/35176>
On Kepler, we don't have real surface opcodes. Instead, we have a bunch
of helper ops which make image calculations in the shader reasonably
efficient and we have to lower to that and an address-based load/store.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34975>
Kepler needs different descriptors for Image storage, these descriptors
are not directly used by the hardware but by lowering instructions
(added in later commits)
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34975>
Normal fmin doesn't make any promises about NaN, common additionally
doesn't make any promises about infinities. Would be nice to hook that
up to codegen but lowering them to normal works for now.
Cc: mesa-stable
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34941>
The SPIR-V spec says texelFetch and friends don't take a sampler.
However, on Kepler and earlier hardware, the sampler is read even for
tld. In particular, the hardware reads the sRGB conversion bit in the
sampler and this can be in an inconsistent state if we haven't
initialized samplers properly. On Kepler, we should just reserve a
sampler at device creation time and always use that for tld.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35190>
The sparse image VA needs to be returned to the application for replay.
Reported by Baldur.
VKCTS has coverage but it doesn't verify this yet.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35162>
Turns out, some Midgard GPUs don't support more than 4x MSAA. Add a
quirk for those GPUs, so don't expose it when it doesn't work.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35184>
We can't easily pass multiple initializers here, because a comma in the
initializer list would be treated as a preprocessor argument separator
and not a separator in the initializer lst.
We could also have fixed this with some nested macro ugliness, but let's
instead do what nir_builder does for intrinsic indices and use __VA_ARGS__
to keep this neat.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35184>
When using 16x MSAA, we have two sample-positions on the negative
boundary of the unit-square covering the pixel. This causes problems
when using the default tie-breaking rule, where we miss some
sample-positions when rasterizing primitives covering the entire
viewport.
This works fine on Bifrost and later, but this setting is ignored on
those GPUs, and they assume the default (e.g MINUS_180_OUT_0_IN).
Because we'd prefer for rasterization to match between Midgard and
Bifrost when we can, we only apply this when we have 16x MSAA.
As an added bonus, this behavior matches what the DDK does.
Fixes these tests when 16x MSAA is enabled:
- dEQP-GLES31.functional.texture.multisample.samples_16.use_texture_*
- dEQP-GLES3.functional.multisample.fbo_max_samples.proportionality_alpha_to_coverage
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35184>
This should be helful when we want to enable higher sample counts.
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/35184>
The formatting here has grown some warts over time, let's clean it up a
bit.
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/35184>
The V4 GPUs doesn't have the dynamic allocation logic that V5 and later
has. There's nothing to calculate here; the GPU either supports 8x MSAA,
or 4x MSAA.
Since 8x MSAA is the architectural max, let's have this function report
that. We deal with the 4x limit separately as a quirk, because this
applies to some V5 GPUs as well.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35184>
This value isn't valid on V4, so let's make sure we don't try to use it.
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/35184>
This function was removed about a decade ago, let's get rid of the
prototype as well!
Fixes: a347a0f53f ("mesa: Completely remove QuerySamplesForFormat from driver func table")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35184>
