By default, Mesa's X11 Vulkan WSI will wait for buffers to be ready
before submitting them to Xwayland when the swapchain is created
with the IMMEDIATE mode.
This is undesirable when the Wayland compositor already monitors
fences. A Wayland compositor may want to know the delay between
the buffer submition and the end of the GPU work, this is impossible
to measure if the WSI waits for the buffer to be ready before
submission.
Since most compositors don't monitor fences, let's introduce a driconf
option for this for now. We can reconsider once more compositors
have better support for fences.
Signed-off-by: Simon Ser <contact@emersion.fr>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11290>
Re-usable command buffer could be resubmitted any number of times,
but tracepoints are written once. u_trace_clone_append allows
copying tracepoints and copying timestamps if GPU doesn't support
writing timestamps into indirect address.
The case of tiling GPUs is similar, command stream for draws is
resubmitted for each tile.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10969>
With little modifications u_trace could be usable for Vulkan drivers.
Beside removing dependencies on gallium, the other notable change is
the passing of opaque flush_data pointer via u_trace_flush. There
is data which becomes available only at this point which other drivers
may want to pass.
For example Vulkan drivers would want to pass at least submission id
(for perfetto) and a sync object to wait on in u_trace_read_ts.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10969>
This partially reverts commit 4d9acfa533.
The original patch said:
"Python 3 handles unicode strings by default, so we can drop all that."
But this breaks building on RHEL 7 (or similiar) since python3 support
on is much more limited than newer distros. Backporting all the needed
python 3 libraries to EL7 is a pretty big task, and isn't very easy to
maintain.
For workstation purposes, we need the AMD MM/GL driver building on RHEL
7, so only src/util/driconf_static.py needs to be reverted.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12549>
Doesn't fix, but improves the situation in issue #5163. The
VK.spirv_assembly.instruction.graphics.spirv_ids_abuse.lots_ids_* tests
emit about 160k instructions. ir3_sched blows out the stack after
dag_traverse_bottom_up_node reaches a depth of about 130k frames.
This patch replaces the recursively-implemented post-order traversal
with an iterative implementation using a stack, allowing us to process
DAGs as large as memory can hold.
Definitely makes you appreciate the elegance of recursion...
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12232>
The flock is per-fd, not per thread, and we do it outside of the main mutex. This was
done to avoid having to wait in the mutex, but we can get a case where one ends up running
the body with the flock unlocked.
Fix this by adding a mutex that doesn't need to be locked for reads.
Fixes: 4f0f8133a3 "util/fossilize_db: Do not lock the fossilize db permanently."
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12266>
Don't anticipate seeing any partial written headers but just in case we
should probably wait on the lock to make sure whatever header was being
written is finished being written.
Fixes: 4f0f8133a3 "util/fossilize_db: Do not lock the fossilize db permanently."
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12204>
Many places need to know the maximum or minimum possible value for a
given size integer... so everyone just open-codes their favorite
version. There is some potential to hit either undefined or
implementation-defined behavior, so having one version that Just Works
seems beneficial.
v2: Fix copy-and-pasted bug (INT64_MAX instead of INT64_MIN) in
u_intmin. Noticed by CI. Lol. Rename functions
`s/u_(uint|int)(min|max)/u_\1N_\2/g`. Suggested by Jason. Add some
unit tests that would have caught the copy-and-paste bug before wasting
CI time. Change the implementation of u_intN_min to use the same
pattern as stdint.h. This avoids the integer division. Noticed by
Jason.
v3: Add changes to convert_clear_color
(src/gallium/drivers/iris/iris_clear.c). Suggested by Nanley.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Suggested-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12177>
A number of android games are so far, sadly, unaware of open source
drivers. And when they see an unknown driver they lump it in the lowest
performance tier, artificially limiting framerate and/or gfx settings.
So until the games catch up, use driconf to override vendor/renderer
settings for moar fps and nicer gfx.
Furthermore, some games seem to be limiting *too* conservatively when
we otherwise have plenty of headroom even if we claim to be a bigger
adreno. Possibly a concession to battery life or tighter thermal
constraints in a phone, as compared to something like a chromebook.
Or maybe the flagship gaming phone thing is a scam ;-)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12135>
Unfortunately I contacted the dev about this issue years ago and he
made a fix, but it has never been released after all these years.
This stops the screen from being completely black in game.
CC: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11941>
ls3a4000 and ls2k1000 cpu is mips64r5 compatible with MSA SIMD
instruction set implemented, while ls3a3000 is mips64r2 compatible only.
Due to lacking llvm support for loongson CPU, llvm::sys::getHostCPUName().
return "generic" on all loongson mips CPU.
So we override the MCPU to mips64r5 if MSA is implemented, feedback to
mips64r2 for all other ordinaries.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11955>
On APUs, we fake heaps to simulate a dGPU setup because it seems to
have the maximum compatibility. Though, some applications like RDR2
still only looks at GTT if the driver reports an iGPU which means it
will only use 1/3rd of total memory available.
This is currently behind a drirc option because it might have
implications for other apps but we might want to extend this later
if everything is fine.
Cc: 21.2 mesa-stable
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/11891>
