This has two steps. First, for each range we look at the memory object
and see if it actually needs flushing before we start throwing CLFLUSH
instructions. Second, we look at the whole list of types on device
initialization and decide whether or not we need CLFLUSH at all. The
first part should speed up atom chips a bit since we're currently
CLFLUSHing everything even when we don't need to. The second isn't
needed on most of today's parts because we base it on !has_llc but it is
needed for discrete parts. It's also over-all cleaner.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Felix DeGrood <felix.j.degrood@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11364>
As we move the batch cache from screen to context, it cleans up the diff a
ton to separate this mechanical change out, and makes the API generally
more consistent (since you usually have to pass the ctx anyway).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11368>
A similar path can be used on at least FreeBSD using cpuset_getaffinity.
This is how Ninja determines the number of available CPUs on that
platform. See the GetProcessorCount function in util.cc:
https://github.com/ninja-build/ninja/blob/master/src/util.cc
v2: Fix counting the number of available CPUs. The CPU_COUNT API does
not work the way I thought it did. :face_palm: Noticed by Marek.
Reviewed-by: Adam Jackson <ajax@redhat.com> [v1]
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> [v1]
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11228>
This prevents problems when some CPUs are offline. In a four CPU
system, if CPUs 1 and 2 are offline, the cache topology code would
only examine CPUs 0 and 1... giving incorrect information.
The types are changed to int16_t so that the offset of num_L3_caches
does not change. This triggered a STATIC_ASSERT failure:
STATIC_ASSERT(offsetof(struct util_cpu_caps_t, num_L3_caches) == 5 * sizeof(uint32_t));
I'm assuming there's some assembly code or something that depends on
this offset, and I don't feel like messing with it.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11228>
In the current code, this prevents a very unlikely corner case. More
importantly, it should prevent the next commit from breaking the
universe.
Imagine a system with 64 CPUs configured, but first 32 CPUs are offline.
_SC_NPROCESSORS_CONF will return 32. All of the surrounding code will
interpret this as meaning CPUs 0 through 31, but all of those CPUs are
offline. Nothing good can happen then.
The problem cases require systems with more than 32 CPUs because
util_cpu_caps.num_cpu_mask_bits is always rounded up to a multiple of
32.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11228>
memset operates in bytes, and there are 8-bits in a byte. This is a
very easy to miss typo. :(
Fixes: 9758b1d416 ("util: add util_set_thread_affinity helpers including Windows support")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11228>
The next patch will change the way the number of CPUs is detected, and
this change prevents some code duplication.
v2: Add missing #include. Noticed by Pierre-Eric... not sure how I
missed it. :(
Reviewed-by: Adam Jackson <ajax@redhat.com> [v1]
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11228>
When globalFencing is supported, we can export a native sync fd for
presentation to move rendering off CPU timeline.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11342>
This patch refactors to use vn_Import*FdKHR for Android WSI native sync
fence import when globalFencing is supported. Currently there's no perf
win from this, but will move the composer release fence waiting to the
GPU device side automatically when the entire Venus fencing support is
improved.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11342>
Include provoking vertex checking in u_index_prim_type_convert() to make sure
the right primitive type is returned from the generator function.
Fixes google earth running on VMware svga device on hw version 11.
Fixes: cad2026b72 ("aux/indices: break out primitive type conversion to separate function")
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11367>
Normally when we shadow a resource (whether it is changing the modifier
or not) we do not need to flush existing batches, since they reference
the original version of the resource. There is a special case for
resources that are referenced by a batches framebuffer state, because
this state is emitted when the batch is flushed. Because of this, we
need those batches to be flushed before we shadow the resource.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11371>
Since we can be blitting using a format that is different from the
resource's native format, we also need to validate and demote if
necessary, similar to sampler-views, image-views, and fb state.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11371>
Because R8G8 has a different layout from R16, we not only need to demote
to uncompressed to (for example) sample R8G8 as R16 (or visa versa) but
we also need to demote further to linear.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11371>
Normally when demotion to uncompressed is required, it is handled when
various state is attached (sampler-view, framebuffer, etc). But in this
one path into u_blitter we need to handle it up front, to avoid
recursing back into u_blitter for a decompress blit.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11371>
If a format is not supported as a render target, there is no point in
trying a staging blit, as it will end up in a CPU copy fallback.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11371>
Unlike on Android, KHR_swapchain may be advertised even when the host
driver does not support EXT_image_drm_format_modifier and
EXT_queue_family_foreign. Do not request those extensions when they are
not supported.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11369>
Use a single set and ensure dominance by checking after a equivalent
instruction is found.
Besides removing the need to copy a set, this also lets us resize the set
at the start of the pass in the next commit.
ministat (CSE only):
Difference at 95.0% confidence
-984.956 +/- 28.8559
-6.90075% +/- 0.190231%
(Student's t, pooled s = 26.9052)
ministat (entire run):
Difference at 95.0% confidence
-1246.1 +/- 257.253
-0.998972% +/- 0.205094%
(Student's t, pooled s = 239.863)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Co-authored-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6390>
The first problem was noticed by Coverity (CID 1485970).
Fixes: ab49063f44 ("iris: Only use SET/GET_TILING when exporting/importing BOs")
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11357>
Since we're going to iterate over each bit of this variable using
u_bit_scan, we should make sure we use an unsigned int for the variable.
While this works on GCC, it's not guaranteed to work, and produces a
warning on MSVC.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11358>
HDC Pipeline Flush is the correct method for flushing HDC
pipeline on Gfx12+ HW. Continue using DC Flush for earlier HW.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9834>
Tile Cache flush flushes all Color/Depth values from L3 cache
to memory in Unified Cache mode. This is only required when
CPU access is required.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9834>
Mike Blumenkrantz
Ian Romanick
Yiwei Zhang
Jason Ekstrand
Emma Anholt
Alyssa Rosenzweig
Neha Bhende
Rob Clark
Chia-I Wu
Rhys Perry
Jonathan Marek
Marcin Ślusarz
Erik Faye-Lund
Felix DeGrood