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>
Add vn_cmd_{wait_events,pipeline_barrier}_fix_image_memory_barries to
replace vn_get_intercepted_barriers. The two new functions are
identical currently, but that will change soon.
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/10709>
We need them for wsi queue ownership transfer.
v2: make VN_PRESENT_SRC_INTERNAL_LAYOUT public
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>
If the state was set to VN_COMMAND_BUFFER_STATE_INVALID, return
VK_ERROR_OUT_OF_HOST_MEMORY in vn_EndCommandBuffer.
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/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>
Instead of just reporting the failed statements, print where they
originated. This is useful for tests which have a number of similar
checks.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10898>
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>
Closes#4868
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
Tested-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11115>
No more error-prone encoding of swizzles in the .csv for non-planar
formats!
No change to generated u_format_table.c
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>
Once you read enough of them, there's an obvious pattern that we can just
write a little code for instead of making every dev write it out each time.
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>
Just check against the CSV (which has its codegen now tested with
u_format_test in CI) for now, so we know that our computed channels are
correct.
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>
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>
Z32_FLOAT_S8X24_UINT and X32_S8X24_UINT are in fact the only non-bitmask
formats that have BE swizzles specified, but sorting out those two is
harder.
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>
I wanted to do the next set BE changes here where I have Format's helper
functions available.
No changes in generated u_format_table.c.
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>
My editor likes to enforce pep8, here's some low hanging fruit so I don't
have to do too much add -p.
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>
