Those are for push constants, no point in doing that because :
- there is no HW constant offsets in push constants (payload
delivery), it's just register offset calculation
- if we have an dynamic value it's already using MOV_INDIRECT
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: e103afe7be ("brw: run the nir_opt_offsets pass and set the maximum offset size")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36958>
The bottom right corner of the copy exceeded the maximum allowed
value in GRAS_A2D_DEST_BR.x
In order to fix this, we have to do a second copy per line of
the last texels.
Fixes asserts in:
dEQP-GLES31.functional.copy_image.*
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36939>
"scale" was a bad name as it meant nothing others could comprehend.
However that value corresponded to the tile size of the Matrix layouts.
For int8 we have a tile size of 4, for 16 and 32 bit values we have a size
of 2.
For the future the same value need to be 32 for booleans, 8 for int4, 1
for fp64 and tf32 and 4 for all em types.
The "scale = 1 << scale;" assignment can simply be removed because it was
4 for 2 and 2 for 1 simply being the expected value after this change.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36391>
FdMemoryDataSource was being registered as a Perfetto data source
unconditionally which led to anything calling fd_device_new(...)
attempting to do this even when they might not have Perfetto
initialized which is done as a part of util_perfetto_init, without
which trying to register the event causes a SEGFAULT.
Fixes: c7045e3e63 ("perfetto: unify init")
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36993>
We are still in the process of moving our kernels to gfx-ci/linux, but
we got the request to uprev the kernel a month ago when I started my
holiday, so let's not delay it more. Anyway, it is better to change
only one variable at a time so no harm done.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32533>
UCHE and CCU use virtual-tagged addresses, so whenever an alias may have
changed we have to always flush and invalidate everything. We detect
this through the sparse memory aliasing flag on the buffer/image, or for
plain memory barriers whether the feature is enabled.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32533>
Plumb through support for a sparse queue and enable sparse binding using
the kernel interfaces we added earlier. We also support sparse residency
for buffers, which is straightforward, but sparse residency for images
is much more complicated so it will be enabled later.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32533>
Add a "sparse VMA" abstraction, and functions creating them, destroying
them, and submitting commands to map and unmap BOs into them. This
mirrors the Vulkan API, but with image offsets resolved to page offsets.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32533>
Use a new driver-internal VM_BIND submit queue for mapping and unmapping
"normal" BOs. This will be required for sparse, because we can't mix
the old and new interface, but it should also allow us to stop using
"zombie" VMAs and the bo list.
Also use MSM_BO_NO_SHARE, which we assume is available when VM_BIND is.
This should significantly reduce kernel submit overhead, in parallel to
the userspace submit overhead cut by using VM_BIND.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32533>
According to the spec and as implemented by other drivers, this should
use the size of the buffer instead of the size of the VkDeviceMemory
it's bound to when VK_WHOLE_SIZE is specified or pSizes is NULL. The
current behavior doesn't make sense at all for sparse buffers which are
not bound to a single VkDeviceMemory. Just use the common helper that
already does the right thing, copied from anv.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32533>
The kernel was rounding the size up for us, but it doesn't like a
non-aligned map size, so just sanitize the size here.
tu_cs was relying on the size not being rounded to keep the maximum size
2^20-1 or less, so fix that by using the initial unrounded size.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32533>
For VM_BIND, BO deletion will have to be implemented differently in
native drm and virtio. We already have a somewhat awkward situation with
native-specific code in the common BO deletion helper, which we only get
away with because it's for kernels without SET_IOVA in which case virtio
isn't supported. Add a few common helpers for some of the guts, and move
the guts into backend-specific functions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32533>
We're supposed to completely ignore VkTimelineSemaphoreSubmitInfo if
there aren't any timeline semaphores, including the array lengths, which
is made clear by the various VUs already cited by the code. The
vkQueueSubmit() path correctly handled this when asserting but still
dereferenced pWaitSemaphoreValues unconditionally, which could lead to
dereferencing an invalid pointer if waitSemaphoreValueCount is less than
waitSemaphoreCount. The vkQueueSparseBind() path didn't even assert
correctly. Bring vkQueueSparseBind() in line with vkQueueSubmit()
and make both only dereference the wait/signal array once we've
determined it must be present. While we're here, also fix the assert in
vkQueueSubmit() to disallow a waitSemaphoreValueCount of 0 if there are
timeline semaphores present, which conversely is not allowed.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36989>
The blit code is destructive on the framebuffer state, which means
that it can set new render targets. If you have 2 BGRA surfaces bound
for logic ops, then after setting up the surface for the first one,
the blit for the second will end up destroying + re-creating the
surface for the first one.
Let's be robust to this by putting the blit in a first pass, and
then actually initializing all of the descriptors in a second pass.
This is still woefully inefficient but at least it's correct.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36945>
Lionel Landwerlin