this was kinda useless since it meant that the set was invalidated any
time the shader image was unbound
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11188>
this is the only time it might need to be used, so it can be updated naturally here
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11188>
this is all pretty much standardized now, so it can be combined into something
simpler
Acked-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11188>
if the offsets are assigned in the right order, they don't need to be
ordered later
Acked-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11188>
now cached descriptors also use a push set for ubo0, also reusing the
ZINK_DESCRIPTOR_TYPES for this set for enum purposes
Acked-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11188>
this is now closer to the cached descriptor set layout, but with
the push set as the zero-indexed set (passed as ZINK_DESCRIPTOR_TYPES
for enum purposes)
Acked-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11188>
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>
