This enables more accurate estimation of the maximum achievable CPU-bound
performance.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8849>
It's never true with slab and sparse buffers.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8849>
It's never true with slab and sparse buffers.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8849>
It's never true with slab and sparse buffers.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8849>
It's never used with slab and sparse buffers.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8849>
The initialization of abs_timeout fixes a warning that started appearing
with this commit.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8849>
This decreases the CPU time percentage of amdgpu_cs_add_buffer by 50%
on Ryzen 3900X.
We don't need to call amdgpu_bo_is_referenced_by_any_cs
in amdgpu_bo_can_reclaim. The reclaim function is only called for buffers
that have 0 references.
The only downside is that amdgpu_bo_is_referenced_by_cs might be slower
in some very rare cases. Overall the driver overhead is better.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8849>
This allows testing virgl over vtest by setting GALLIUM_DRIVER=virpipe
when the X server uses a proprietary driver.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: John Bates <jbates@chromium.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8888>
Fix defect reported by Coverity Scan.
Invalid type in argument to printf format specifier (PRINTF_ARGS)
invalid_type: Argument *__errno_location() to format specifier %s was expected to have type char * but has type int.
Fixes: d37124b065 ("virgl: add support for VIRGL_CAP_V2_UNTYPED_RESOURCE")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8874>
this must be reset to avoid issues when using VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT_EXT
when some descriptors in the set may not have been bound
fixes#4219
Fixes: 126d5adb11 ("radv: Use host memory pool for non-freeable descriptors.")
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8840>
failing to unset any existing pointers here leads to stale bo entries in
the list and then the kernel rejecting the cmdbuf with ENOENT
Fixes: 126d5adb11 ("radv: Use host memory pool for non-freeable descriptors.")
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8840>
Branch instructions can point to the last shader block, which might be
empty. In this case, the branch points to a clause that doesn't exists,
leading to INVALID_ENC faults when the GPU tries to jump to this clause.
Check if the block is a terminal block before updating the branch
offset: jumping/branching to NULL is equivalent to a shader termination,
so the default value of 0 works just fine for terminal branches.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8848>
Needed to decide what to do with JUMPs/BRANCHes to such blocks.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8848>
This is really nasty, and shouldn't really be needed, but we have a
problem where both Zink and Lavapipe checks $GALLIUM_DRIVER, meaning that
Zink tries to use Lavapipe, and Lavapipe tries to use Zink.
This patch side-steps that by temporarily setting $GALLIUM_DRIVER to
"llvmpipe", giving Lavapipe a chance to succeed.
This is not great at all. The most obvious problem is that this is super
thread-unsafe, effectively modifying global state without any care. In
reality, we'd only want the pipe-loader in the *same thread* to ignore
Zink, but it's not so obvious how to do that without introducing lots of
ugly zink-specific cruft.
People shouldn't be using Zink if they don't have a GPU, it's going to
be much better to use LLVMpipe in that case. So let's not worry too much
about this case, and instead guard this dangerous logic with an
ZINK_USE_LAVAPIPE environment variable. This means this behavior only
happens if people opt in to it.
With this in place, we can start using Zink + Lavapipe on CI.
In the longer run, it might be better to use Adam Jackson's copper
loader instead, and drop exposing Zink as a software rasterizer
entirely. But that's something for the great future where we have flying
cars and all.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7881>
The generated code is often terrible, but the situations where this is
needed are rare.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Tony Wasserka <tony.wasserka@gmx.de>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8713>
The new message buffer will save the dpb buffers from previous
allocation based on the max resolution.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Boyuan Zhang <boyuan.zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8851>
This is trivial because this path relies on our blit_shader interface
which supports this already, so it just needs to pass it along.
I don't think this is ever triggered practice, since we should be
able to handle any case that could require this with the texel buffer
path, but at least it allows us to simplify a bit the code.
Tested by manually disabling the priority paths to ensure we exercise
component swizzles with this path.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8875>
This path is very memory hungry and batching allows us to reduce
this by allocating memory just once and reuse it for all regions
in the batch instead of allocating once per region.
v2: document return value for this function (apinheiro).
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8875>
We do this by converting them to a compatible color copy and using a
destination color mask as well as a source component swizzle to handle
D24 format semantics according to the V3D hardware requirements,
similar to what we do with our blit shader interface.
This path is faster than the terrible copy_buffer_to_image_blit,
which requires to copy the source buffer to a tiled image first
and should be avoided as much as possible, since it is slow and
can also quickly increase device memory usage.
This fixes occasional OOM errors when loading traces in renderdoc.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8875>
Only batches involving the tiler block need to add the tiler heap to the
list of accessed BOs. While at it, clarify who's accessing this heap.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Icecream95 <ixn@disroot.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8822>
The polygon list is written by tiler jobs and read by fragment ones,
and nothing should re-use the heap until the fragment job is done.
4fec6c9448 ("panfrost: Add the tiler heap to fragment jobs") fixed
this for the !multi-context case by adding the heap BO to fragment job.
But the tiler heap is shared accross contexts, and vertex/tiler+fragment
job submission is done through 2 separate ioctls, meaning that
vertex/tiler and fragment jobs from 2 different context might be
interleaved.
Add a lock at the device level to ensure tiler/vertex+fragment jobs are
submitted sequentially, with no other jobs using the same tiler heap
in-between.
Cc: mesa-stable
Fixes: d8deb1eb6a ("panfrost: Share tiler_heap across batches/contexts")
Reported-by: Icecream95 <ixn@disroot.org>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Icecream95 <ixn@disroot.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8822>
Newer versions of SPIR-V require that all the global variables used by
the entry point are declared (in contrast to only I/O in previous
versions), so there's no need to remove dead variables or keep track
of the indirectly used variables.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8456>
OpEntryPoint declares the list of variables in Input and Output
storage classes that are used. Use that information to skip creating
other variables from such storage classes that are unused by the entry
point.
After that change, is not necessary to use remove dead variables for
those types of variables; and because of that is also not necessary to
lower initalizers for output variables.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8456>
Fix defect reported by Coverity.
Uninitialized pointer field (UNINIT_CTOR)
uninit_member: Non-static class member sub is not initialized in
this constructor nor in any functions that it calls.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7229>
It's exposed with ARB_tf2, which we claimed support for. All the KHR-GL33
TF tests pass for me locally except for no_errors, which I have some
outstanding fixes for with khronos. Our CI build seems to be having some
issue with exceptions inside of deqp.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8843>
Instead of depending on anv_extensions.py, fetch the patch version from
the XML ourselves. This way it can be moved to common code and used by
other ICDs going forward.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8792>
For years, I've maintained that I like to bump this number manually
because it gives me a point at which to say, "I've looked at most of the
issues and I think we're up to date." The reality, however, is that I
just bump it every few months and don't really do any thorough checking.
We may as well just bump it on header updates.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8792>
Instead of building it into the auto-generated condition we use for the
per-driver ${driver}_physical_device_get_supported_extensions()
function, generate a table and handle it inside the various common
extension enumeration and verification routines. This reduces our
reliance on code-gen for extension enables.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8792>
