There's no GL_NV_gpu_shader4 extension, and the TEX opcode is defined in
NV_gpu_program4. Correct the mistake.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19594>
Without additional signalling of modifiers, CRCs cannot possibly in a correct
way work across process boundaries. Since we don't do that signalling, we should
not be allocating private CRCs for imported resources, and we should not be
using our own private CRCs for internal resources.
The entire out-of-bands CRC infrastructure is a hack to let us do CRCs even for
imported/exported BOs, but that can't possibly work. Remove it, and remove a
pile of special cases across the driver.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19576>
If the map doesn't set MAP_DISCARD_RANGE, we do have to copy the existing
contents over. MAP_WRITE on its only gives permission to replace the contents,
unfortunately it does not require that the application actually do so.
Closes: #7640
Fixes: 0b26a9f773 ("panfrost: Don't copy resources if replaced")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Roman Elshin
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19576>
Stick to macos-11 to prevent accident broken
always install meson with pip to prevent pull new version of python
Cc: mesa-stable
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19615>
Fixes issue with "is helper invocation" that in recent SPIR-V is mapped to
a volatile Load. The CSE was catching the loads before they were transformed
in the new is_helper_invocation intrinsic (that is not reorderable).
Fixes: 729df14e45 ("nir: Handle volatile semantics for loading HelperInvocation builtin")
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: M Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19432>
Vulkan has VkChromaLocation and all drivers suggest
VK_CHROMA_LOCATION_MIDPOINT on Android. The blob also uses MIDPOINT.
Based on my limited tests, the image quality is higher with MIDPOINT.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19514>
This seems to have no effect on a618, but restores linear filtering on
a635 when the texture is yuv. The blob sets it on a635 as well (but not
on a618).
Fixed android.media.cts.DecodeAccuracyTest#* on a635.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19514>
Function device_select_once_init are removed in-favor of SIMPLE_MTX_INITIALIZER
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18493>
Since we expect a limited # of unique border-color entry states, we can
use a global table of border-color entries, rather than constructing the
state at draw time. This shifts all the border-color overhead from draw
time to sampler state CSO creation time. And it's less code!
A hashtable is used to map unique border-color table value to entry so
multiple usages of what maps to the same table entry all re-use a single
slot in the table. This puts an upper bound on the # of unique border-
color plus format value. In practice this shouldn't be a problem, we'll
just size the table to be large enough to not run into problems with
CTS. Note that the border-color table entry is not completely format
dependent (mostly just integer vs float dependent), so for example a
single color with different float formats can map to a single table
entry.
This also fixes the problem that we completely ignored border-color for
GS/tess stages.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7518
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19561>
All defined in the baremetal-test-arm*
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19548>
With the current scheme, looking at game startup which should be the
worst case (most heavily loaded) time for the compiler threads, and they
seem to be ~10% busy. Furthermore we typically have a mix of "big" and
"LITTLE" cores.. with about half being "big". So sizing the thread pool
to the half the # of CPU cores seems reasonable.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19387>
Android's implementation of the blob-cache get/put funcs do not
implement any compression. And the default cache size is rather small,
at 2MB (!!) per app (although I assume everyone patches android to
increase the size limit).
We don't bother compressing the has_key/put_key path, since that path is
only storing a uint32_t.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19387>
If the surface is already in use by another swapchain, return
VK_ERROR_NATIVE_WINDOW_IN_USE_KHR. The spec states:
> If pCreateInfo->oldSwapchain is VK_NULL_HANDLE, and the native
> window referred to by pCreateInfo->surface is already associated
> with a Vulkan swapchain, VK_ERROR_NATIVE_WINDOW_IN_USE_KHR must
> be returned.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
References: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7467
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19229>
It turns out that this actually is supported. GMEM can hold multiple
layers which are cleared, loaded, and resolved separately. The stride
between layers seems to be implicitly calculated based on the tile size,
and we have to match it when blitting to/from GMEM. One tricky thing is
that now we may realize that we don't have enough space for GMEM only
when computing the tiling config, because we may not know the number of
framebuffer layers until we have the framebuffer and too many
framebuffer layers will exhaust GMEM.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19505>
According to RadeonSI, only GFX10 and GFX10.3 need to emulate.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19319>
Karol Herbst
Erik Faye-Lund
Alyssa Rosenzweig
Alyssa Rosenzweig
Samuel Pitoiset
Yonggang Luo
Martin Roukala (né Peres)
Konstantin Seurer
Caio Oliveira
Chia-I Wu
Rob Clark
David Heidelberg
Simon Ser
Eric Engestrom
Yusuf Khan
Connor Abbott
Lionel Landwerlin
Tapani Pälli