this is for the MoltenVK extensions, especially "VK_MVK_moltenvk", which
right now is reserved in the registry. Making it non-standard skips all
the validations.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9021>
the MVK check is a workaround, since VK_MVK_moltenvk is not an official
VK extension per se - the next patch will introduce nonstandardness to
Extension.
Two new validations are added by this patch:
1. extension type (non-instance extensions are rejected)
2. existence of specified instance functions
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9021>
We used that to catch assembly errors in the past,
but now, there are too many hardware features we
use in ACO that are not supported by the LLVM disassembler,
that it is not really suited anymore as a debugging tool.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8921>
This patch delays the calculation of GPR limits in order to
precisely incorporate extra registers (VCC etc.) and shared VGPRs.
Additionally, the allocation granularity is used to set the config.
This has some effect on the reported SGPR stats.
Totals (Navi10):
SGPRs: 6971787 -> 17753642 (+154.65%)
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8921>
This also switches the alloc_granule of Tonga and Iceland
to 96, so that the calculation is consistent.
Also changes the granularity for RDNA to 16 to keep
better stats with the upcoming patch.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8921>
I suspect this marker to be useful for correlating pipeline shaders.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8995>
Fixes INSTR_INVALID_ENC fault on dEQP-GLES31.functional.compute.basic.empty
Fixes: bfcdc8f174 ("pan/bi: Add some zero bytes after shaders on Bifrost")
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9011>
New scheduler broke this. We need to shuffle some code around so we do
the lower pre-schedule instead of post-schedule (no clauses to work
with).
Fixes: 77933d16d8 ("pan/bi: Switch to new scheduler")
Reported-by: Icecream95 <ixn@disroot.org>
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9011>
It's failed for almost a month, so right now it's mostly noise and a
waste of CI resources.
It can easily be re-enabled by an MR which makes it pass again.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8976>
this is really just not what we want to be doing. vulkan has no method for
doing on-gpu checks for xfb overflow, instead providing the info as two values
for the user to do with as they will, forcing us to gpu stall any time we
need to interact with these queries
for the ANY variant of the query, we need to create even more xfb query pools,
since we now need to be monitoring all available vertex streams for overflows
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8992>
There are blit shader specific optimizations available.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9002>
We don't need to create display-targets for shared or scanout, becuase
we never even see those in the sw-winsys case.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8858>
The only type that should really require to be host-visible is the
display-target, and that's just because of our silly flush_frontbuffer
implementation.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8858>
We only need these display-targets to be linear in the case of a
software winsys. In the DRM case, they can be tiled without issues.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8858>
The reason we check for staging-resources here is really because they
are the only images guaranteed to be host-visible.
But on UMA architectures, it's quite likely to have memory that is
*both* host-visible *and* device-local, so let's see what we found
instead.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8858>
spec@arb_timer_query@timestamp-get seems to fail on D3D12 / Windows
every now and then. Until that's been figured out, let's disable the
test in CI.
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8978>
The Vulkan spec says the following for vkCmdBeginTransformFeedbackEXT:
"For each element of pCounterBuffers that is VK_NULL_HANDLE, transform
feedback will start capturing vertex data to byte zero in the
corresponding bound transform feedback buffer."
While not quite as explicit, similar wording exists for
vkCmdEndTransformFeedbackEXT in "Valid Usage" section.
So, this means that we should handle NULL in this case, and simply
ignore the corresponding reads and writes.
This fixes a whole lot of crashes when using transform-feedback with
Zink.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8982>
By the Vulkan specification, and similarly to many other Vulkan calls,
it is allowed to destroy a null descriptor update template.
Signed-off-by: Giovanni Mascellani <gmascellani@codeweavers.com>
Fixes: af5f13e58c ("anv: add VK_KHR_descriptor_update_template support")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9005>
This basically processes UBO loads as uniform loads by writing
the load address to the unifa register and reading sequential
values with ldunifa.
This process is faster than going through the TMU, but we can only
use it when the address we are reading from is uniform across all
channels, since we are basically reading from the UBO address
as if it was a uniform stream.
This leads to better performance in the UE4 Shooter demo.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8980>
ldunifa reads a uniform from the unifa address and updates the unifa
address implicitly, so if we dead-code-eliminate one a follow-up
ldunifa will not read from the appropriate address.
We could avoid this if the compiler ensures that every ldunifa is
paired with an explicit unifa, so for example if we are reading a
vec4, we could emit:
unifa (addrr)
ldunifa
unifa (addr+4)
ldunifa
unifa (addr+8)
ldunifa
unifa (addr+12)
ldunifa
instead of:
unifa (addr)
ldunifa
ldunifa
ldunifa
ldunifa
But since each unifa has a 3 delay slot before we can do ldunifa,
that would end up being quite expensive.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8980>
The simulator asserts on this, which can happen if we merge a ldunif
(or any other instruction that reads a uniform implicitly) and
ldunifa in the same instruction.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8980>