Those are variants of f2f16 that always round up/down. Constant folding
requires nextafter that supports half floats (util_nextafter).
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37883>
This is the least invasive way to switch all of Mesa to BLAKE3. It's done
this way for transitional reasons.
SHA1_DIGEST_LENGTH is already equal to BLAKE3_KEY_LEN. This just switches
the SHA1 implementation to BLAKE3.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39110>
The last 12 bytes are always 0 for now. With this, all SHA1 functions
can be internally implemented as BLAKE3, so that we can switch everything
to BLAKE3 by only changing the implementation of the sha1 utility.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39110>
fmin/fmax are not signed zero correct.
The name is taken from RDNA4's ISA, because the full IEEE name is a bit long.
Cc: mesa-stable
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39137>
When converting between snorm and between unorm values, the following
patch introduced 64-bit division on all platforms.
util: Add and use functions to calculate min and max int for a size
Commit hash: 72259a870f
The following unit math
// local MAX_UINT macro based on UINT32_MAX
(uint64_t * uint32_t + uint32_t) / uint32_t
changed to
// macros.h inlined 'uint64_t u_uintN_max()' functions.
(uint64_t * uint64_t + uint32_t) / uint64_t
This can significantly impact performance on 32-bit platforms.
Address this by type-casting the return values from the inlined
functions to avoid the 64-bit divide on 32-bit platforms.
Signed-off-by: Micah Shennum <micah.shennum@garmin.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39001>
This reverts commit dcd9b90aff.
The game falls back to software rendering if any of the enumerated GPUs
have invalid vendorID. This fix causes a regression for systems with an
AMD GPU where the game works perfectly fine, that also happen to have an
Intel iGPU.
The Intel iGPU will be enumerated with vendorID=-1 and this will cause
the game to not use the AMD GPU either. Clearly an issue with the game
but since this workaround is causing more issues than it is solving,
remove the config.
From what I can tell, this fix _did_ work at the time of committing, but
as this is a live service game it gets regularly updated and this buggy
behavior with choosing the device has been introduced recently.
Fixes: dcd9b90aff ("drirc/anv: force_vk_vendor=-1 for Wuthering Waves")
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Acked-by: Taras Pisetskyi <taras.pisetskyi@globallogic.com>
Signed-off-by: llyyr <llyyr.public@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39089>
Fix compiler error:
../src/util/blob.c:344:8: error: assigning to 'uint8_t *' from
'const void *' discards qualifiers
[-Werror,-Wincompatible-pointer-types-discards-qualifiers]
glibc now provides C23-style type-generic string functions. memchr
returns const void * when passed a const void * argument. Update nul
declaration to const since it's only used to find the null terminator
position and calculate a size.
Fixes: 1c9877327e ("glsl: Add blob.c---a simple interface for serializing data")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39048>
This feature causes piles of vertex shader timeouts in the CTS which makes CTS
testing extremely unreliable on my min-spec M1. Since we only really have it as
a tickbox for Proton, hide it except for Proton - at least for now.
This eliminates our known flakes.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mary Guillemard <mary@mary.zone>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39111>
Add the actual registers used (including uniforms used) by the shader
to stats. This is calculated by the stats gathering code, because the
scheduler and scoreboard passes run after register allocation and can
sometimes change the results.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38961>
When running Yooka-Laylee under FEX, the executable name will be the one of
the FEX binary, which the existing driconf option won't match. FEX is able
to override the executable name in newer versions, but overall it's still
more reliable to match the application name provided through Vulkan.
Fixes: 0574bfd5f4 ("tu: add UBO lowering workaround for Yooka-Laylee")
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39012>
This game sets the reset isolation bit which causes the GL context
creation to fail as Mesa doesn't support the
GLX_ARB_robustness_application_isolation extension. Here we override
and clear the bit.
According to the spec says:
"The GLX_ARB_robustness_application_isolation and
GLX_ARB_robustness_share_group_isolation extensions do not provide
guarantees for graphics resets caused by applications which did
not create their contexts with both the LOSE_CONTEXT_ON_RESET_ARB
reset notification strategy and the
GLX_CONTEXT_RESET_ISOLATION_BIT_ARB bit."
And the game doesn't set LOSE_CONTEXT_ON_RESET_ARB so technically
we could ignore the reset isolation bit even if Mesa did support
the extension.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13336
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38668>
This allows us to override and clear the reset isolation bit.
It will be used in the following patch to override missing support
for GLX_CONTEXT_RESET_ISOLATION_BIT_ARB.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38668>
We currently have BITSET_*_RANGE macros which take a closed interval/range: a
start bit and an end bit. Occassionally that is what you want, but most of the
time callers actually want a start and a length. For example, register
allocators will often do operations at (variable start register, variable start
register + variable size - 1). It's more convenient to just take a start and a
size, while also making the size=0 case well-defined as a no-op set/clear and
false for test.
This patch adds BITSET_*_COUNT macros aliasing to the existing range macros, and
the rest of the series converts many call sites across the tree to use the new
macros.
Of the few call sites not converted, a whole bunch look like off-by-one bugs
which I did not want to "fix" here and risk breaking something else. Probably
worth checking your driver if you have RANGE calls leftover after this series.
Also, aco and dozen both open-coded RANGE helpers that should probably be
switched to the common code but that's neither here nor there.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38955>
Unity's Vulkan backend used by Spilled! requires the vk_dont_care_as_load
workaround to achieve correct rendering. Observed on Turnip, in GMEM mode.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38863>
Several web sites block clients with "Apple" in the WebGL renderer
string if the reported OS is not one of Apple's.
This check seems to implemented via a 3rd party product which is slowly
rolled out over more web sites. Instead of playing whack-a-mole with
web sites in multiple browsers override the OpenGL renderer in mesa for
known browsers.
Backport-to: 25.3
Signed-off-by: Janne Grunau <j@jannau.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38845>
A vertex shader performs OOB UBO reads causing vertex corruption.
Disable UBO to const lowering to force bounds checking which fixes the
corruption.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38781>
When building with linux_glibc_x86_64 in AOSP, this is
observed.
src/util/u_debug_stack.h:66:4: error: unknown type name 'uint64_t'
66 | uint64_t start_ip;
| ^
Adding <stdint.h> fixes it.
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38644>
This enhances the DescriptorType enum to include the
memory handle type (DMABUF vs SHM) alongside the size,
allowing consumers to differentiate between DMA-BUF and
shared memory file descriptors without redundant code.
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38677>
Otherwise, the following error is observed:
src/util/cache_ops_x86_clflushopt.c:40:22:
error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
40 | void *end = start + size;
| ~~~~~ ^
src/util/cache_ops_x86_clflushopt.c:44:9:
error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
44 | p += cpu_caps->cacheline;
| ~ ^
This works with GNU extension enabled, but does lead to warnings
with Clang.
v2: Add to trial_c + trial_cpp checks (Erik)
v3: use c_msvc_compat_args to avoid fixing other instances of this issue (Erik)
Fixes: 555881e574 ("util/cache_ops: Add some cache flush helpers")
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38752>
It's will be used to replace SetEnvironmentVariableA,putenv on windows
and putenv,setenv on non-windows
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Antonio Ospite <antonio.ospite@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38640>
RDR2 VRAM memory management when resizable BAR is enabled seems
incorrect because it keeps allocating VRAM without freeing anything.
This introduces a drirc option to emulate a fake carveout of 256MiB to
workaround this game bug. This also adjust memory budgets by
distributing it between visible and invisible because AMDGPU reports
the same value for both when REBAR is enabled.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12091
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38627>
