This has gotten complicated enough that we need somewhere outside of the
driver itself to give an overall flow of how the feature is implemented.
This includes a few things that are enabled in the subsequent commits,
specifically the LRZ parts.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36475>
We don't go through the loop when there are no queues.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 884df891d7 ("anv: allow device creation with no queue")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36910>
This might actually fixes a couple of things because needed dynamic
states are computed before radv_emit_graphics_pipeline(), so dirtying
them too late doesn't make much sense.
This doesn't fix anything known.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36900>
When building as subproject, this will include libdisplay-info tests
when running `meson test` and they incorrectly detect edid-decode
binary being available causing the tests to fail. There are also
issues with 32bit build.
Updating to latest libdisplay-info doesn't seem like a good solution
as that pulls in additional build dependencies.
Since this is an optional dependency, drop the wrap file.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13657
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36897>
Venus renderer side has strict entry points sanitization based on the
app requested app api version + physical device api version. So on the
driver, we should follow the same for legacy client apps.
Meanwhile, VK_PIPELINE_STAGE_NONE can't be used when we hit the sync2
emulation path, so we swap it with VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT
placeholder for the 2nd sync scope there.
Fixes: 07cee75c39 ("venus: layer vkQueueSubmit2 over vkQueueSubmit w/o sync2")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36830>
With UBSan enabled, we get the following issue:
```
../src/compiler/glsl/ir.h:116:4: runtime error: member access within address 0x555637c62c10 which does not point to an object of type 'ir_instruction'
0x555637c62c10: note: object has invalid vptr
5f 76 61 6c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
invalid vptr
```
This only happens the first time a ir_variable (which derives from
ir_instruction) is created; next calls don't show the issue any more.
The problem is with the following call in the `new()` operator:
```
((ir_instruction*)((uintptr_t)p))->node_linalloc = ctx;
```
In this case, the ir_instruction structure is not fully constructed and
thus UBSan complains about it. In the next calls, as the structure is
now fully constructed it doesn't complain any more.
The right approach would be fully creating the structure, and afterwards
doing the context assignment. But this would require quite a lot of
changes, passing the context through the constructors to assign it.
A simpler solution is just disabling this check for this case, as we
know what is happening.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36884>
This specific macro allow to create a new() operator version with a
sanitizer flag disabled.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36884>
Meson doesn't support for checking no_sanitize attributes, so we do it
manually through testing.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36884>
Instead of being encoded as a contiguous 64-bit mask of individual registers,
the robustness information is now encoded as a vector of up to 4 bytes that
represent the limits of each of the pushed UBO ranges in 16 byte units.
Some buggy Direct3D workloads are known to depend on a robustness alignment
as low as 16 bytes to work properly.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36455>
The branch offset needs to fit in 8 bits, and with the shr(3) modifier,
this means the max legal value is 2040. Let's verify that while packing.
CID: 1503283
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36724>
We already have a more robust helper for this, so let's use it rather
than open-coding the same.
While we're at it, return early on error for readability here. There's
no need to continue the logic in those cases.
CID: 1444074
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36724>
lseek can return a negative value on error here. While it's not likely
to happen, let's add some error-checking here to prevent bad behavior if
we're unlucky.
CID: 1648299
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36724>
If the shader contains zero words, we would try to use -1 as an index
into an array at the end of this function, which would be bad. But
shaders without any words are, uh, no point in disassembling in the
first place, so this seems like a theoretical bug in the first place.
However, since the only thing we *really* care about last_next_tag is if
is TAG_BREAK or not, let's initialize it to TAG_BREAK instead. This
means we'll avoid a bogus print at the end here, even if we ended up
calling this on an empty shader.
CID: 1458835
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36724>
r1.w should be written, so let's add an assert here instead of making
lcra_add_node_interference() overrun a buffer here.
CID: 1510007
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36724>
Allocations can fail, and since this is an optimization pass, let's just
skip the pass and let some other code deal with the OOM situation.
Fixes: 800a861431 ("pan/bi: Fuse FCMP/ICMP on Valhall")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36724>
wsi_common_vk_instance_supports_present_wait returns true for all
supported wsi platforms here, so we can unconditionally advertise them
behind RADV_USE_WSI_PLATFORM like the other wsi extensions (also to not
tangle with Android).
v2: guard presentId2 and presentWait2 features as well
v3: drop direct option query for vk_khr_present_wait
Acked-by: Daniel Stone <daniels@collabora.com> (v1)
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36835>
wsi_common_vk_instance_supports_present_wait returns true for all
supported wsi platforms here, so we can unconditionally advertise them
behind TU_USE_WSI_PLATFORM like the other wsi extensions (also to not
tangle with Android).
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36835>
That was a legacy thing only needed for the original present_id/wait
suport.
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36835>
wsi_common_vk_instance_supports_present_wait returns true for all
supported wsi platforms here, so we can unconditionally advertise them
behind NVK_USE_WSI_PLATFORM like the other wsi extensions (also to not
tangle with Android).
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36835>
wsi_common_vk_instance_supports_present_wait returns true for all
supported wsi platforms here, so we can unconditionally advertise them
behind ANV_USE_WSI_PLATFORM like the other wsi extensions (also to not
tangle with Android).
v2: guard presentId2 and presentWait2 features as well
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v1)
Acked-by: Daniel Stone <daniels@collabora.com> (v1)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36835>
wsi_common_vk_instance_supports_present_wait returns true for all
supported wsi platforms here, so we can unconditionally advertise them
behind ANV_USE_WSI_PLATFORM like the other wsi extensions (also to not
tangle with Android).
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36835>
Now that we have pan_image_test_modifier_with_format(), use it do our
native modifier check. This involves fully describing the YUV lowering
even for formats that don't have a native YUV-as-RGB fallback.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35761>
If the plane formats are __DRI_IMAGE_FORMAT_NONE (AKA PIPE_FORMAT_NONE),
we can't lower the planar-YUV. I guess this code relies on
::is_format_supported(PIPE_FORMAT_NONE, PIPE_BIND_SAMPLER_VIEW)
returning false, but it's not obvious to me that it should, and panfrost
has been returning true on this one for quite a long time. It could be
that panfrost is wrong, and this case should be rejected, but it's just
as simple to reject the lowering if the plane format is
__DRI_IMAGE_FORMAT_NONE instead of deferring this check to the driver,
because ultimately we can't lower NV15/NV20 unless the driver supports
NV15/NV20 or R10_G10B10_{420,422}.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35761>
MTK_TILED is not in the native_mods list, so drop the check we had in
this loop.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35761>
It's not necessarily shorter, because of the pan_image_props
initialization but we're likely to omit details when doing the check.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35761>
pan_image_test_props() checks all the image properties at once, and
pan_image_test_modifier_with_format() just a <modifier,format> pair.
This will allow us to use the check done in pan_mod instead of
duplicating the same set of rules in panvk/panfrost and possibly having
one that's ahead of the other.
There are still checks we can't do at the pan_mod/image level, like
anything involving format lowering, but that's okay.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35761>
