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>
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>
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>
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>
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 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>
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>
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>
