They're both implemented in common code as long as you use
vk_command_buffer.
Acked-by: Emma Anholt <emma@anholt.net>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15560>
The common Vulkan sync framework will do most of the queueing for us.
It will even sort out timeline semaphore dependencies and ensure
everything executes in-order. All we have to do is make sure our
vk_sync type implements VK_SYNC_FEATURE_WAIT_PENDING. This lets us get
rid of a big pile of code.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15651>
To avoid altering any currently existing callers, we continue on with
the calculation regardless of overflow. This also matches the behavior
of GCC's __builtin_add_overflow().
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15651>
dEQP-VK.binding_model.buffer_device_address.set3.depth3.basessbo.convertuvec2.nostore.multi.scalar.vert
runtime -24.4002% +/- 1.94375% (n=7). The win (I think) is in LLVM not
having to chew through handling the extra loops on every constant-offset
SSBO load, not in actual rendering time.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14999>
If we know the offset is constant, we don't have ask LLVM to loop over the
elements pulling the same value out over and over.
This doesn't seem to have produced a win in the testcase I was looking at,
but it was an easier entrypoint to figuring out how to do scalar memory
access than load_memory, and will probably affect some workload.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14999>
In a fragment shader or inside of control flow, invocation 0 might be
inactive, and so our use-first-invocation-and-broadcast optimizations
would be invalid, and the loop logic of an emit_read_invocation would
defeat the point of these optimized paths.
For load_kernel_input, I didn't guard the uniform path with the check
because some CL tests that are currently passing are doing the
load_kernel_input under (presumably) uniform control flow. Instead, I
dropped in a once warning for the next person to be debugging CL.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14999>
These are not data-race safe (like many other once patterns in Mesa), so
they might not log exactly once, but it should be good enough for not
spamming the console.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14999>
We already have a way to pass env vars around, just use that instead of
packing/unpacking it on the kernel command line.
Cleans up HW runner job log output some more.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15332>
This should help highlight the actual test results, as opposed to the setup
and teardown.
Also tuned the "set -x"es a little bit so we get less surrounding noise in
the echo process.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15332>
VK-GL-CTS causes tons of these due to a bug in glslang, to the point where
it's hard to find actual issues in test logs. Disable the warning for
now, with a link to the issue we're waiting on being resolved.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15332>
You're not supposed to include a '\n' in mesa_log*() messages because
android logging will log what you provide on its own line anyway, so each
mesa_log() should be the body of a log line. But also, getting everyone
to consistently not do that is hopeless because we're all so trained by
printf(). So, just detect an existing \n and don't add a new one.
Cleans up deqp-vk debug output a bunch from turnip.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15332>
When parts of the tree needs later c and c++ versions, they should ask
for it in the build-system itself, not expect the user to ask for it on
the command-line instead. So let's not paper over things by specifying
them here.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15706>
We do require C++20 still, because designated initializers is part of
that standard. This is almost a revert, but conditionally selecting
between c++latest or c++20 when available, as that's what we really want.
Fixes: 55ca1c8db3 ("vulkan/microsoft: Remove `override_options: ['cpp_std=c++latest']` option for visual studio")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15706>
Designated initializers require C++20, which is a bit easier said than
done to support well across meson versions. Let's avoid using them
for now instead.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15706>
Designated initializers are a C++20 feature, but we don't use C++20. In
fact, enabling C++20 for ACO triggers new compiler errors due to some
equality semantics details.
So let's instead stop using designated initializers here.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15706>
This doesn't fix anything known but it could happen in theory.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15729>
These are the changes automatically generated from the venus-protocol
repository.
Update the file to add `VK_EXT_index_type_uint8` and
`VK_EXT_conditional_rendering`
Signed-off-by: Igor Torrente <igor.torrente@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15652>
Signed-off-by: Omar Akkila <omar.akkila@collabora.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15668>
These both require swizzling so border colors won't work. However,
they're conveniently in the list of formats for which custom border
colors require you to specify a format in the sampler. That list
constists of:
- VK_FORMAT_B4G4R4A4_UNORM_PACK16
- VK_FORMAT_B5G6R5_UNORM_PACK16
- VK_FORMAT_B5G5R5A1_UNORM_PACK16
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6226
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15624>
Renato Pereyra
Jason Ekstrand
Emma Anholt
Mike Blumenkrantz
Connor Abbott
Erik Faye-Lund
Thong Thai
Konstantin Seurer
Roman Stratiienko
Samuel Pitoiset
Igor Torrente
Yiwei Zhang
Omar Akkila
Benjamin Cheng