Per Ken Graunke, corruption issues with push
constants for render batches on Gen12 graphics
have been observed and worked around by re-emitting
push constants at the start of the batch buffer.
We're seeing similar issues with compute batches,
so we'll apply the same work-around.
Fixes corruption reported in Blender on ADL/RPL
CC: mesa-stable
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35873>
(cherry picked from commit 8fd008a45f)
The Midgard compiler only deals with sized NIR types for image loads and
stores. Since we already have nir_get_nir_type_for_glsl_base_type()
which can provide us with the corresponding sized type, let's just use
that, and drop the extra table.
This fixes the following piglits on Mali-T760:
- spec/ext_texture_compression_s3tc/getteximage-targets 2d s3tc
- spec/ext_texture_compression_s3tc/getteximage-targets cube s3tc
Fixes: 9123ee0f18 ("st/mesa/pbo: Set src type on image_store")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35882>
(cherry picked from commit 96d124092f)
The chances of this happening are near zero with the way we do surface
ops today but I have seen it in the wild and this is apparently a rule.
The hardware throws an illegal instruction encoding if it sees 255.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35895>
(cherry picked from commit 19bee26056)
This looks like a hw bug on GFX10.3-GFX11.5 because RB+ seems to only
work as expected when all channels (RGBA) are written. With that format,
RGB channels must be all set or unset but setting the A channel is
legal so far.
This will reduce rendering performance with that format but it's the
less intrusive solution for now. This might be revisited in the near
future, also with more VKCTS coverage.
This has been tested and verified on GFX10.3 (NAVI21) and GFX11
(NAVI31) and GFX12 (NAVI48), unfortunately I don't have GFX11.5 but
let's assume it's broken there too.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13371
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35631>
(cherry picked from commit 10ef9c6a80)
Maximum texture dimension is 2^16, but we're limited by the 32-bit
fields that are used to pass strides/sizes in various descriptors.
Assuming RGBA32_FLOAT is the biggest format we support, that gives us a
16k-1 image size for 2D and cube map, and 512 for 3D.
Change our GetPhysicalDeviceImageFormatProperties2() implementation so
that smaller formats can still advertise bigger image sizes.
Fixes: d5ed77800e ("panvk: Fix GetPhysicalDeviceProperties2() to report accurate info")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35555>
(cherry picked from commit e25a91d919)
Piglit arb_texture_buffer_object-render-no-bo was generating
gpu resets because the uniform stream was missing the last
Fragment Shader uniform. So it was reading instead of the last
fragment shader uniform the first uniform of the vertex shader.
And using that unrelated VS uniform as the sampler address where
the texture should be read.
So now if a buffer object is not bound for a texture buffer object
we write the texture state base address to 0 (NULL) so the default
texture state is used.
So only is needed to set the 4 lower bits of the tmu_p0 with
the bit-mask of word enables.
Fixes: bb8285c258 ("v3d: add support for no buffer object bound")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35847>
(cherry picked from commit 0f8c681c5c)
As per the old comment:
"These formats correspond to the similarly named MESA_FORMAT_*
tokens, except in the native endian of the CPU. For example, on
little endian __DRI_IMAGE_FORMAT_XRGB8888 corresponds to
MESA_FORMAT_XRGB8888, but MESA_FORMAT_XRGB8888_REV on big endian."
Fixes: 7e10601786 ("dri: Redeclare __DRI_IMAGE_FORMAT_* as PIPE_FORMAT_*")
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35814>
(cherry picked from commit 2ca46c7a7a)
nvidia hardware can't render to linear surfaces except under some
very limited circumstances, one of those is if Z is enabled.
However there appears to be some combination of gnome-shell, and
prime (with 2 nouveau cards) where we end up getting through the
GL API to the situation where we try this. This in a production
build causes the kernel to crash with a GR error.
However there existed a period of time where the hw/kernel due to
some other random hw misconfiguration didn't crash when this happened
and doing this was prefect fine. (linear + tiled Z).
This restores the userspace code to do this and just ignores the
Z buffers if we are asked for linear rendering, and seems sufficient
to fix the problem.
I do understand this is a workaround, but I think it's reasonable to
add to the nouveau GL driver at this time since we don't want to
maintain if for ever and it probably should fix a bunch of wierd
user problems with multi gpu and nouveau.
Cc: mesa-stable
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35221>
(cherry picked from commit 06e8db646a)
