Wa_16018063123 don't apply to video engine also video engine don't
support XY_FAST_COLOR_BLT.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Fixes: ec43c20182 ("anv: implement dummy blit for Wa_16018063123")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35700>
(cherry picked from commit 926e6a94ad)
For 3D or GPGPU modes the same render engine should be used, CCS
register should only be used when using compute engine.
Fixes: 46f5359238 ("anv: Invalidate aux map for copy/video engine")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35700>
(cherry picked from commit e68f81eaf6)
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)
ac_estimate_size() triggers an assertion because the block size isn't
aligned to a power of two for ASTC formats.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35879>
(cherry picked from commit cb6f2d9409)
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)
For each dimension, we `threads *= lws`.. which is still zero if threads
is initialized to zero.
Fixes: eca4f0f632 ("rusticl/kernel: check that local size on dispatch doesn't exceed limits")
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35864>
(cherry picked from commit 6bc47e65d7)
Right now the headers are not counted when we calculate the total slice
size of an AFBC(3D) image. Fix that by special-casing size_B
initialization for AFBC.
I couldn't get back to the original commit introducing this mistakes,
so I'm flagging for backport instead of adding a proper Fixes tag.
Backport-to: 25.1
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Tested-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35555>
(cherry picked from commit 1389a23708)
Otherwise the comparison will always be false for protected content.
Also remove extra setting of the protected bit that was happening later.
Fixes: 8d9cc6aa23 ("anv: properly flag image/imageviews for ISL protection")
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35870>
(cherry picked from commit 5b58b838fe)
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)
this is required by the spec. fixes
gles-3.0-transform-feedback-uniform-buffer-object.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Backport-to: 25.1
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35802>
(cherry picked from commit 03a5b7f25c)
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)
