Part of the memory allocated (private) is a temporary working buffer
for the GRL kernels. Once the build operation is done, the buffer
becomes unused.
Rather than allocate a new buffer each time, reuse the current last
allocated one if its size fits the next build operation.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25570>
In the default case, there's a special case with a few conditions.
Prefer the cheapest conditions first, so we can take advantage of
short-circuiting.
Effect is a small but still significant reduce in shader compilation
times, as can be seen by:
- Fossil replay for Rise of the Tomb Raider
```
Difference at 95.0% confidence
-0.433333 +/- 0.028609
-1.42556% +/- 0.0941163%
(Student's t, pooled s = 0.0337886)
```
- Fossil replay for Batman Arkham City
```
Difference at 95.0% confidence
-8.84 +/- 0.146083
-1.65932% +/- 0.0274207%
(Student's t, pooled s = 0.125423)
```
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25549>
unflushed usage is unflushed regardless of the submit count and is
critical for detecting multi-context synchronization
fixes Wolfenstein: The New Order load screen deadlock
Fixes: db12b881c7 ("zink: track/check submit info on resource batch usage")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25572>
The function `mmap64` is part of the large file extension and should not be
called directly. Instead `mmap` should be use and let the system use the
correct interface.
Signed-off-by: Simon Zeni <simon.zeni@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25569>
There are some minor differences
- fix incorrectly use of device->meta_state.resolve_compute.p_layout
- when on_demand is true, the creation of ds and pipeline layouts are
also deferred
- unlike radv_meta_get_view_type, vk_texcompress_etc2_image_view_type
returns 1d/2d array image views
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25071>
This is based on radv's ETC2 emulation. There is no real change to the
generated NIR shader.
v2: rename vk_texcompress_etc2_image_format to vk_texcompress_etc2_emulation_format
update the comments
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25071>
1. Move block used for detecting R8152 problems to the bootloader
phase where it belongs. Also remove requirement to 100 failures and just
retry immediatelly.
2. Consider job failed after 10 errors, not 100. From the logs on
cheza-14, ~ 30 errors is enough to fail.
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25285>
In the age of the internet, we can use hyperlinking to content instead
of just telling users about something! Let's do that here as well!
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24921>
Move emitting the EOP even which writes the availability bit after the
GDS copy to ensure it's available.
This should fix all GS primitives/invocations flakes in CI.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25457>
It was reported that it broke Stoney. Something probably uses a suboptimal
pitch, like minigbm.
Fixes: 7d066330e0 - ac/surface: relax custom pitch requirements to any multiple of 256B on gfx10.3+
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25540>
When the first auxiliary context is locked and wants to compile and upload
a shader asynchronously, we need to use another auxiliary context
in the compiler thread because the first one is locked at that point.
This adds an array of auxiliary contexts into si_screen and changes how aux
contexts are accessed.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25494>
For one thing, they actually assert that the alignment factor is a power
of two. More importantly, though, because they're real functions and
not macros, they up-cast the alignment to a full uint32_t or uint64_t
before doing the alignment calculation. If you do ALIGN_POT() on a
64-bit value with a 32-bit alignment, it truncates to 32 bits because
the NOT is done before the up-cast due to C implicit cast rules.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25555>
