This takes a different approach. It turns out we can patch
vkCmd{Begin,End}RenderPass, vkCmdWaitEvents, and vkCmdPipelineBarrier to
do queue family ownership transfers without tracking image ownerships.
v2: check the value of VN_PRESENT_SRC_INTERNAL_LAYOUT and keep this
Android-only
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> (v1)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10709>
dEQP-VK.api.external.memory.opaque_fd.* re-imports and fails because
external_handles was VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT on
allocation and is VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT on
re-import.
Fixes: ccefcb0baf ("venus: fix misaligned bo_flags between import and query")
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/11154>
Iris only runs on BDW+ and ANV already handles this by not even trying
on anything older than HSW. The only driver benefiting from this common
check is i965. Moving it out makes the pass more generic and if some
driver comes along which can push UBOs on IVB, it should work for that.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11145>
Always chain wsi_image_create_info to VkImageCreateInfo, which indicates
that the image is a wsi image and can be transitioned to/from
VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.
Add prime_blit_buffer to the struct as well. When set, it indicates the
prime blit destination and implies that the image is a prime blit
source.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10789>
It appears that CP can over-fetch push constants slightly. While it
otherwise has no problem fetching from an alignment of 32 bytes, if that
32 bytes is at the end of a mapped bo, this can trigger fetching up to
32 bytes beyond the patch, triggering an iova fault. While otherwise
"harmless", it is probably better to not have random intermittent
faults.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11142>
It notably didn't fit the pattern of RGB5_A1_UNORM, and violated the
general pattern for bitmask format BE channels (channels are ordered
right-to-left in the BE columns in the CSV due to the parser walking them
in that order for historical reasons).
Acked-by: Adam Jackson <ajax@redhat.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10505>
These tests passed for LE, and the BE channel ordering specified obviously
didn't fit the pattern of the other BE formats (channels are listed
right-to-left in the BE columns for historical reasons).
Note that we can't write pure-integer format tests in u_format_tests.c
currently.
Acked-by: Adam Jackson <ajax@redhat.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10505>
nir_assign_io_var_locations() does not use outputs_written when
assigning driver locations. Use driver_location to avoid incorrectly
guessing what locations it assigned.
Copied from lavapipe 8731a1beb7
Will fix provoking vertex tf tests when VK_EXT_provoking_vertex
would be enabled:
dEQP-VK.rasterization.provoking_vertex.transform_feedback.*
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11111>
Previously, iris_bufmgr had the ability to maintain multiple
simultaneous memory mappings for a BO, one in WB mode (with CPU caches),
and another in WC (streaming) mode. Depending on the flags passed to
iris_bo_map(), we would select one mode or the other.
The rules for deciding which to use were:
- Systems with LLC always use WB mode because it's basically free
- Non-LLC systems used...
- WB maps for all BOs where snooping is enabled (which translates to
when BO_ALLOC_COHERENT is set at allocation time)
- WB maps for reads unless persistent, coherent, async, or raw.
- WC maps for everything else.
This patch simplifies the system by selecting a single mmap mode at
BO allocation time, and always using that. Each BO now has at most one
map at a time, rather than up to two (or three before we deleted GTT
map support in recent patches).
In practical terms, this eliminates the capability to use WB maps for
reads of non-snooped BOs on non-LLC systems. Such reads would now be
slow, uncached reads. However, iris_transfer_map recently began using
staging blits for such reads - so the GPU copies the data to a snooped
buffer which will be mapped WB. So, rather than incurring slow UC
reads, we really just take the hit of a blit, and retain fast reads.
The rest of the rules remain the same.
There are a few reasons for this:
1. TTM doesn't support mapping an object as both WB and WC. The
cacheability is treated as a property of the object, not the map.
The kernel is moving to use TTM as part of adding discrete local
memory support. So it makes sense to centralize on that model.
2. Mapping the same BO as both WB and WC is impossible to support on
some CPUs. It works on x86/x86_64, which was fine for integrated
GPUs, but it may become an issue for discrete graphics paired with
other CPUs (should that ever be a thing we need to support).
3. It's overall much simpler. We only have one bo->map field, and
manage to drop a significant amount of boilerplate.
One issue that arises is the interaction with the BO cache: BOs with
WB maps and WC maps will be lumped together into the same cache. This
means that a cached BO may have the wrong mmap mode. We check that,
and if it doesn't match, we unmap it, waiting until iris_bo_map is
called to restore one with the desired mode. This may underutilize
cache mappings slightly on non-LLC systems, but I don't expect it to
have a large impact.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4747
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10941>
Chia-I Wu