When creating an image out of a swapchain on Android, the android
layer call will detect a VkBindImageMemorySwapchainInfoKHR in the
pNext chain of the vkBindImageMemory2() call and add a
VkNativeBufferANDROID in the chain. This is what we should use as
backing memory for that image.
v2: Fix a couple of obvious mistakes (Tapani)
v3: Silence build warning (Lionel)
Fix invalid object argument to vk_error() (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: bc3c71b87a ("anv: don't try to access Android swapchains")
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5180
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12244>
We're just using this as a minor optimization to allocate pages for
buffers up front outside of some kernel locking. It's not essential.
The SET_DOMAIN ioctl may be going away in the future, so let's be a
bit cautious and try it but not fail.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044>
We need to raise an error when importing a user pointer as a BO if the
supplied pointer can't actually be used on the GPU. Previously, we were
(ab)using the SET_DOMAIN ioctl for this, but it's not really intended
for that purpose, and is going away on discrete.
Fortunately, there's a new kernel API for this: the I915_USERPTR_PROBE
flag tries to perform basic sanity checking of the supplied pointer so
that we can at least reject obvious misuse of this API up front.
Use the new API where available. Fall back to SET_DOMAIN if it isn't.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044>
Previously, when importing a resource with modifiers that include
clear color as auxiliary data, we were mapping the clear color BO
on the CPU in order to set res->aux.clear_color to the value stored
there.
We are generally trying to avoid CPU mapping imported buffers, because
in hybrid setups, they could be from a different device, and may not be
mappable. So we'd like to avoid that here.
This CPU-side knowledge of the clear color is only used in a few cases:
1. Avoiding a resolve due to a partial clear with a changing clear color
2. Avoiding disabling CCS when rendering to a texture view of a resource
where the only format difference is sRGB vs. linear and the clear
color is 0/1.
Instead of mapping the clear color BO on the CPU, we instead set a flag
indicating that we don't know the clear color, and reset it to known on
our first clear.
In the first case, the first partial fast clear of a resource would eat
an extra resolve (there is no penalty if we clear the whole resource).
The second case doesn't seem that critical, as it's someone rendering
to an imported BO - when the common case is to texture from it.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11888>
When incrementing unifa address in DCE optimization, ensure that we
setup correctly the current block, so the ldfunif optimization is also
executed correctly.
This fixes
dEQP-VK.graphicsfuzz.cov-struct-float-array-mix-uniform-vectors
heap-buffer overflow with address sanitizer enabled.
v2 (Iago):
- Save and restore current block
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12339>
While this feature is optional in Vulkan 1.1 and we don't currently
expose it, the CTS still requires that the entry points exist.
From the Vulkan 1.1 spec:
"If the VK_KHR_sampler_ycbcr_conversion extension is not supported,
support for the samplerYcbcrConversion feature is optional."
(...)
"samplerYcbcrConversion specifies whether the implementation supports
sampler YCBCR conversion. If samplerYcbcrConversion is VK_FALSE,
sampler YCBCR conversion is not supported, and samplers using sampler
YCBCR conversion must not be used."
Fixes (with Vulkan 1.1 exposed):
dEQP-VK.api.version_check.entry_points
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12338>
This allows this pattern:
$ radeonsi-run-tests.py /tmp/foo
... reports that some piglit tests regressed ...
$ radeonsi-run-tests.py -t /tmp/foo/new_baseline/sienna_cichlid-piglit-quick-fail.csv
... this only runs the test that regressed ...
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12306>
Before a73cb106a6, cso contexts were never reused, but now that they
are we need to be extra careful that the state in the cso context and
in the pipe context matches even after an unbind, since when the cso
context is reused the state might otherwise get out of sync (as there is
no concept of "initial state", basically cso always relied on the default
values being the same both in cso and the drivers).
This fixes some errors we've seen internally with lavapipe.
Fixes: a73cb106a6 ("aux/cso: split cso_destroy_context into unbind and a destroy functions")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12261>
This allows to set VK_PRIMITIVE_TOPOLOGY_PATCH_LIST dynamically when
tessellation used.
If other values are set via vkCmdSetPrimitiveTopologyEXT for the case,
the validation layer can detect the issue.
Fixes dEQP-VK.pipeline.extended_dynamic_state.*.topology_patch*
Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12299>
drm_i915_query_perf_config::data is an unsized array and declaring a
struct containing an unsized array that isn't at the end is a GNU
extension which trips up Android builds. Instead, stuff both into a
char array of the appropriate size. This emulates what you'd normally
do to allocate one of these with malloc only on the stack.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12308>
Again, we don't need all the dependency checking, seqno incrementing
and duplicate tracking for batch->bo. Just use the unchecked version.
This commit is not particularly significant since it really just saves
us a check in the iris_use_pinned_bo() hot path, but since we already
have the helper function, why not?
v2:
- (turns out the answer to "why not?" is because the patch had a bug)
- Call ensure_exec_obj_space() since batch batch chaining can happen
and doesn't guarantee pre-reserved space (Ken).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12194>
Don't use iris_use_pinned_bo(), go directly with add_bo_to_batch(),
skipping every check. This allows us to early return from
iris_use_pinned_bo when the workaround bo is used, saving us the call
to find_validation_entry() which ends up doing nothing except
iterating over every bo in the batch. Also don't bother with
ensure_exec_obj_space() since we just reset the batch and this is the
second BO we're adding to it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12194>
