The existing wsi code paths work in the most correct manner now w.r.t
implicit fencing, memory allocation, prime buffer blit, etc.
With this and the prior change, ANV with headless doubled the perf and
beats the windowed vkmark run.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36687>
Previously the present marks the image free, and the next acquire would
immediately acquire the just presented image back, which likely still
has pending gpu work going on. To avoid introducing a present queue in
headless, we simply tweak to acquire swapchain images in a loop to give
the app the most likely idle image.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36687>
Previously, if neither packaging.version or distutils.version is present
in the environment the has_mako check would return non-zero exit code
and meson would print that mako is required which is misleading since
mako can be in the environment but not packaging or distutils. This can
happen for Python>=3.12 where distutils is no longer in the Python
stdlib but provided externally by setuptools.
Signed-off-by: bbhtt <bbhtt.zn0i8@slmail.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36697>
Without this, mesa fails to build with:
src/vulkan/util/vk_enum_to_str.c:684:14: error:
‘VK_COMPRESSED_TRIANGLE_FORMAT_AMDX_MAX_ENUM’ undeclared (first use in
this function); did you mean
‘VK_COMPRESSED_TRIANGLE_FORMAT_MAX_ENUM_AMDX’?
Fixes: c74ad9f142 ("vulkan: Update headers/xml for 1.4.325")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36693>
The goal here was to avoid propagating source modifiers, unusual
regions, and other things that couldn't be used as a send source.
A few patches ago ("brw: Properly resolve non-sendable sources in a few
logical opcodes") we fixed the logical send lowering to handle these
by resolving them when constructing the send payload. So now prior
to lowering, we don't need to treat these opcodes specially.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
This introduces enums for SHADER_OPCODE_SEND[_GATHER] sources, similar
similar to what we've done for most of the newer logical opcodes. This
allows us to use actual names for sources rather than remembering their
order, or leaving ourselves comments like /* ex_desc */ all over. It
will also make it easier to add or reorder sources in the future.
While we're at it, we also standardize on the number of sources.
Previously, we allowed SHADER_OPCODE_SEND to have either 3 (monosend) or
4 (split send) sources, but this is mostly for haphazard historical
reasons. We now specify all sources every time, eliminating the need
for careful inst->source checks before accessing the last source.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
Sources decorated with source modifiers, immediates, or particular
stride combinations may not be directly usable as SEND operands. We
have to resolve them to an ordinary VGRF first.
Most opcodes do this as part of broader payload construction, but these
send directly because the messages are very simple.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
We used to have inst->mlen set on various virtual opcodes, but these
days the only instructions that should have inst->mlen set are
SHADER_OPCODE_SEND and SHADER_OPCODE_SEND_GATHER, which are already
covered in inst->is_send_from_grf(). So we don't need to check for mlen
specifically.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
Explicitly list FS_OPCODE_INTERPOLATE_AT_* as allowed, as they were
already allowed by the default case. Interlock, memory fence, and
barrier were disallowed and remain so. Uniform pull constant load
was allowed and remains so. SHADER_OPCODE_SEND and SEND_GATHER get
explicit handling.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
Every case but SHADER_OPCODE_SEND and SHADER_OPCODE_BARRIER will be
lowered to SEND before register allocation happens. And the barrier
send has a null destination, so the restriction doesn't apply.
Note that this hack is for Gfx9 only, so we don't need to worry about
Xe3's SHADER_OPCODE_SEND_GATHER feature.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
A number of places emit monolithic sends, where the second payload is
empty. Some places were using a BAD_FILE register, while others were
specifying the hardware ARF null register. Switch to BAD_FILE for
consistency - this is usually what we do for "source isn't present".
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34040>
This has to happen before lowering doubles, we can't do this in the backend.
Otherwise the backend's own vote_feq lower will result in an unlowered 64-bit
feq operation which it can't consume and can't lower. On GL drivers without
native fp64, this fixes tests like:
KHR-Single-GL46.subgroups.vote.graphics.subgroupallequal_double
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36649>
As we use _WIN32 in many place, and WIN32 usage are depends on windows.h that defined in minwindef.h.
So do not use it at all, after this change, DETECT_OS_WINDOWS and _WIN32 will have the same effect.
This is for avoid confusion when DETECT_OS_WINDOWS and _WIN32 are mixed used.
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36654>
Erico Nunes