The invalidate would take it out of the bc tracking, so you could go
allocate a new batch->idx matching this one, while this one is still in
the bc using that idx.
You can't generate any new rendering with the ctx's old batches at this
point, anyway, so just flush for simplicity.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11439>
It wasn't checking that the transfer map would definitely overwrite all of
the data being initialized by the back blit, and if we knew that it
would then the caller would have provided PIPE_MAP_DISCARD_WHOLE_RESOURCE.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11439>
We take references under the lock, but then accessed the lock-requiring
batch_cache structure without holding the lock. The batches wouldn't get
freed and removed from their slots until the last ref goes away so it was
safe (other than the assert at the end), but writing the simple code is
shorter and requires fewer assumptions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11439>
When the system doesn't have enough memory, GNOME Shell may be crashed
by iris:
gnome-shell[1161]: iris: Failed to submit batchbuffer: Cannot allocate memory
gnome-shell[1161]: GNOME Shell crashed with signal 6
So don't abort() when kernel can't allocate memory to avoid crashing the
entire desktop.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11178>
This is entirely implemented in the SPIR-V frontend.
Relevant CTS tests:
dEQP-VK.spirv_assembly.instruction.compute.non_semantic_info.*
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11440>
Instead of spawning 4 threads when the cache is created,
spawn 1 and let u_queue grow the number of threads if
needed.
I wrote this patch because when running piglit's quick_shader
profile I had lots of samples in disk cache threads - mostly
in native_queued_spin_lock_slowpath kernel function.
Since these tests shouldn't really stress the cache, I assumed
it was caused only by thread creations.
After writing the patch and redoing the measurement, I got an
improvement but I still more hits in the same function for
shader_runner:$disk0 thread so something was wrong.
After digging more, I found out that my shader cache index was
corrupted: the on-disk size was 29MB but the index reported it
was way more than 1GB. So each disk cache thread was spending
a lot of time trying to evict files. Given that my cache had
a really low count of files, the LRU method based on randomly
generating subfolder names failed, so evicting was very slow.
Now that my cache index is fixed, the disk cache threads are
mostly idle but I still think it makes sense to grow the
number of threads instead of spawning 4 at the program start.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11296>
This flag allow to create a single thread initially, but set
max_thread to the request thread count.
If the queue is full and num_threads is lower than max_threads,
we spawn a new thread to help process the queue faster.
This avoid creating N threads at queue creation time.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11296>
Instead of doing vbo_exec_vtx_map during initialization,
defer it until the first actual user.
v2: move init to vbo_exec_wrap_upgrade_vertex (Emma Anholt)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11296>
Fix defect reported by Coverity Scan.
Uninitialized scalar field (UNINIT_CTOR)
uninit_member: Non-static class member progType is not initialized
in this constructor nor in any functions that it calls.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11350>
This fixes the flushing with external textures.
We don't know if we need to flush synchronously with multiple contexts,
so I removed that.
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11341>
Commit 24342e499b changed how primitive
topology is handled on Gfx8+ but missed updating the Gfx7.x code.
As a result, tests which previously used topologies like PATCHLIST_3
instead started using bogus ones like LINESTRIP_ADJ. This caused a
GPU hangs in a bunch of Vulkan conformance tests involving tessellation.
This fixes those hangs.
Fixes: 24342e499b ("anv: fix dynamic primitive topology for tess")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11434>
GL requires explicit glMemoryBarrier calls for shader synchronization
and only calls that map/copy buffers get implicit sync, so we don't actually
need barriers for any of these cases, only the state needs to be updated
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11393>
the visible vram heap is potentially going to be limited in size, so avoid
caching these allocations since that locks them to a given allocation size
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11397>
* buffers can use normal mem prop checking to determine host_visible setting
* sparse buffers are never coherent, so this case can be dropped from the conditional
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11397>
builtin_builder::~builtin_builder() and builtin_builder::release()
are running into race condition. This leads lightsmark to crash at
the end because both calls ralloc_free which mutates the arguments state
This patch fixes lightsmark2008 crash
Fixes: e4da8b9c33 ("mesa/compiler: rework tear down of builtin/types")
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Neha Bhende <bhenden@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11385>
With array registers, there are two num's we care about:
1. The base num that the whole array starts at (->array.base)
2. The num that the instruction uses, plus possibly an indirect offset
(->num or ->array.offset)
For parallel copies we always copy the whole array, so (2) is irrelevant
here. For phis and parallel copies inserted for phis, we used
assign_reg() which assigned ->array.base, but we forgot about this when
constructing our own parallel copies for live range splitting, just
setting ->num instead. The parallel copy lowering was also inconsistent
here, using ra_reg_get_num() (which looks at ->array.base for arrays)
for sources but looking at ->num directly for destinations. This makes
everything use ->array.base consistently.
While we're here, make sure to remove IR3_REG_SSA from liveout copies to
make sure printing works correctly.
Fixes: 0ffcb19 ("ir3: Rewrite register allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11422>
Normally something with IR3_REG_ARRAY doesn't have a register assigned,
but we keep IR3_REG_ARRAY for parallel copies after RA because we need
to know the appropriate size. We want to see the register assigned for
these when printing the RA result before parallel copies are lowered.
The register is in ->array.base in this case, so initialize it to
INVALID_REG and print ->array.base if it's been assigned to something,
similar to ->num in the normal case.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11422>
