While we're moving it, reformat a bit to make it match util_sign_extend
better.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17214>
As long as we left-shift the unsigned version, this has no undefined
behavior and is fewer instructions. The only tricky bit is that a right
shift of a negative number is technically implementation-defined (not
undefined) behavior in C. However, if it's ever anything other than an
arithmatic right-shift, there's lots of other places where Mesa will
break today.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17214>
The current implementation depends on both of these things for
correctness. If width > 64, you get UB wrap-around and, if
val >= (1 << width), the subtract trick won't work.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17214>
Also move it to the end of the switch as is more conventional. For some
reason, later patches in the series make ANV fail to build because GCC
stops detecting the assert(!"str") as not returning.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17214>
Now that usage flags can be specified even when using the modifier path for
allocation and frontends like GBM and EGL wayland do this properly, we can
drop the assumption that all resources allocated through the modifier
enabled path need to be SCANOUT capable.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17364>
Use a typeless format when VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT is
set, so we can cast to compatible types at least. Still doesn't
work when formats are of the same size but from incompatible
types (like R32_FLOAT and RGBA8_UNORM), which Vulkan considers
as compatible while D3D12 doesn't, but it gets us closer to what
the Vulkan API wants.
D3D12_FEATURE_DATA_D3D12_OPTIONS12::RelaxedFormatCastingSupported
should address the remaining limitations.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17368>
CopyTextureRegion() works fine if the formats belong to the
same group (matching the same _TYPELESS type), so let's avoid
creating a temporary resource in that case.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17368>
D3D12 supports fomat casting through optional features. Let's
add a helper to query whether 2 formats are compatible or not.
The compatibility depends on the formats+usage pair
(CopyTextureRegion() is less strict than the texture sampling
logic).
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17368>
This only works if the framebuffer config is exactly the same so
testing both subpasses have the same attachments is not enough,
they also need to be exactly in the same order.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17358>
this eliminates (some) out-of-bounds bo access and will ensure that
bo sizing is always accurate by breaking all the cases where it isn't
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17239>
using the attribute slot size isn't sufficient in this case, as the layout
rules may have additional effects upon sizing
instead, just use the explicit size
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17239>
TGSI has no legitimate[1] notion of linked shaders, which means tgsi_to_nir
should conservatively assume everything all shaders are separable. This requires
setting nir->info.separate_shader to warn drivers that shader CSOs might be
mixed and matched. Otherwise, the driver might enable optimizations that
are invalid for separate shaders, causing issues when the shaders are
later treated as separable.
This will fix varying linking with u_blitter's shaders on Panfrost (Bifrost and
older), when util_blitter_clear is used with Panfrost.
[1] There was a TGSI property added recently to forward
nir->info.separate_shader up to virglrenderer, but it's not actually used for
anything in virglrenderer and I am still struggling to understand what the use
case would be. My gut says we should revert b634030542 ("tgsi: Add
SEPARABLE_PROGRAM property"), but I'm not interested in fighting that yak right
now. Notably, the u_blitter and hud shaders are separable but are not marked
with this property.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17282>
New tests, dEQP line rasterization test fix that lets Intel pass.
Clears out bogus xfails from 1.3.2.0 uprev on a630, which I suspect were
"we lost the device twice on a full run once, and those fails got pasted
in without checking if it happened a full run again" (since we haven't
seen them in other full run attempts).
Also clears out the a630 vk asan xfails (essentially all tests run) by
turning off leak detection which was just catching leaks in vkcts.
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17304>
If we're applying the literal 0x3f800000 to a fp16 vop3p instruction, we
shouldn't use the 1.0 inline constant, because the hardware will use the
16-bit 1.0: 0x00003c00.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16296>
This previously didn't correctly consider negative integers when bits=16
(which sign-extend) and would have combined 0xfffe0000.xy as -2.yx. Now it
combines 0xfffeffff.xy as that instead. It was also skipped when bits=32.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16296>
This would have created a 1.0.xx operand from 0x3c00.xx or 0x3c003c00.xy
for vop3p instructions which have 32-bit operands.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16296>
We were using a 16-bit inline constant with a 32-bit instruction and the
test would have created
"v1: %_:v[0] = v_alignbyte_b32 0.5, %_:v[1][16:32], 2" instead.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16296>
I don't think the presence of med3 here breaks anything, but it shouldn't
be here anyway.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16296>
If a shader ends with a workgroup barrier, it must wait for slot #7 at the end
to finish the barrier. After inserting flow control, we get:
BARRIER
NOP.wait
NOP.end
Currently, the flow control pass assumes that .end implies all other control
flow, and will merge this down to
BARRIER.end
However, this is incorrect. Slot #7 is no longer waited on. In theory, this
cannot affect the correctness of the shader. In practice, the hardware checks
that all barriers are reached. Terminating without waiting on slot #7 first
raises an INSTR_BARRIER_FAULT. We need to weaken the flow control merging
slightly to avoid this incorrect merge, instead emitting:
BARRIER.wait
NOP.end
Of course, all of these cases are inefficient: terminal barriers shouldn't be
emitted in the first place. I wrote out an optimization for this. We can merge
it if we find a workload that it actually helps.
Fixes test_half.vstore_half.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17264>
Mesa as a whole requires C++14 nowadays, so this isn't needed any more.
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17307>
Jason Ekstrand
Georg Lehmann
Samuel Pitoiset
Lucas Stach
Boris Brezillon
Iago Toral Quiroga
Lionel Landwerlin
Mike Blumenkrantz
Alyssa Rosenzweig
Emma Anholt
Rhys Perry
M Henning