We just read this from the NIR and store it in iris_compiled_shader,
there's no reason for the backend compiler to be involved.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39926>
These days, our system value concept is just about iris_program
communicating to iris_state which values to upload into a UBO.
Nowhere in that process is the backend compiler involved, so it
doesn't make sense for there to be brw/elk mechanisms.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39926>
iris needs this, but anv does not, and it's just a small wrapper around
common NIR lowering anyway. This also removes some brw/elk splitting.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39926>
nir_create_passthrough_tcs already validates the result, we don't need
to validate a second time.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39926>
When these are correctly mapped to draw usage, we can't rely on them
being globally initialized in tu_init_hw(). They need to be re-
initialized after rp stomping.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39819>
Use information about register usage to decide what to dump for register
summaries. If --allregs, we continue to dump all regs that we have seen
a register write for. Otherwise we dump registers that are written
since last summary (as before) along with regs with the appropriate
usage.
A new column at the start of the line will show a '?' for registers that
don't match the existing usage (ie. they have been written but usage
doesn't match current "draw"). This could simply mean it is the first
"draw" in the render-pass (collecting per-renderpass values). Or it
could mean a mis-attributed or missing register usage. This new column
is only included for a6xx and newer, since older gens don't have usage
specified in xml.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14829
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39819>
We have other better tests for this now. And the next patch will
balloon the reference trace to 90MB due to large # of draw calls. So
just drop this test.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39819>
The existing implementation did not account for register names that
contain the suffix multiple times (ie. FOO_HIT_COUNT_HI).
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39819>
The NIR_PASS macro only overwrites this when the pass actually makes
progress. If the pass doesn't make progress, the variable stays
uninitialized.
Clang correctly spots this and warns about it.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39968>
The hardware only provides 13 bits for encoding the stack base (in
dwords). That translates to the stack base being required to be below
8192 dwords, or 32kB. It's possible to exceed this - LDS is 64kB after
all. Add an explicit check to make sure we don't end up with offsets
that overflow the hw's address fields. This fixes Metro Exodus Enhanced
Edition, which was using ray queries in a 1024-thread sized workgroup,
resulting in exactly 64kB of LDS being required for the stack.
This check isn't required for RT pipelines as we always use 32 or 64
wide workgroups with no other LDS used, so it's impossible to reach this
stack base limit.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39691>
Just seeing that a passthrough GS was already bound is not sufficient to
know that it is a *matching* passthrough GS. If the application binds a
new VS that requires a different passthrough GS key than the previous
VS, then we need to bind a different passthrough GS.
Fixes: 5bc8284816 ("hk: add Vulkan driver for Apple GPUs")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary@mary.zone>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39624>
Use either libagx_fill_uint4 or libagx_fill based of size and object
alignment for clear_sizes which are a power of two up to 16.
Reported fill rate for 256MB buffers on a M1 Ultra (G13D) in
gpu-ratemeter is 355 GB/s for 16 byte aligned buffers and 155 GB/s for
4 byte aligned buffers.
Signed-off-by: Janne Grunau <janne-fdr@jannau.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39780>
Use a compute shader to copy PIPE_BUFFERs. Based on hk's hk_cmd_copy().
For large copy sizes (>= 128MB) it achieves 3/4 of the available memory
bandwidth on a M1 Ultra (G13D). `gpu-ratemeter gl.bufbw` reports
~625 GB/s for 256MB buffer size. Apple specifies the memory bandwidth of
the M1 Ultra with 819.2 GB/s.
Signed-off-by: Janne Grunau <j@jannau.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39780>
This was used because the exact bit meant something different for
comparisons than it did for the replacement expression, but that isn't the
case anymore.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39809>
These asserts were there to validate this bit of the Vulkan spec:
VUID-vkGetImageSubresourceLayout-mipLevel-01716
The mipLevel member of pSubresource must be less than the mipLevels specified in image
VUID-vkGetImageSubresourceLayout-arrayLayer-01717
The arrayLayer member of pSubresource must be less than the arrayLayers specified in
image
However, this function isn't just called via vkGetImageSubresourceLayout(), but
from elsewhere in the driver. At least in the case of arrayLayer, the assert
doesn't always hold true, for example, in the case of deferred RTA clears on a
2D array image view of a 3D image.
The array layer assert was being hit by the following test cases:
dEQP-VK.renderpass.remaining_array_layers.multi_layer_fb.*
dEQP-VK.renderpass2.remaining_array_layers.multi_layer_fb.*
As the asserts don't really add any value, rather than moving them into
pvr_GetImageSubresourceLayout(), just drop them entirely.
Fixes: ae29e1cf76 ("pvr: drop pvr_assert macro")
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39916>
The change being reverted relaxes the check for what formats
can be used for sampling and rendering beyond driver capabilities.
Revert it in order to mitigated regressions in nightly CI.
A follow up change will be needed for handling
dEQP-VK.api.info.image_format_properties.2d.optimal.*.
This reverts commit 58c7437d3a.
Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39916>
The code was missing a number of special cases for the TQ.
For blits, there is a whole set of conditions that need accounting
for setting the input and output transfer queue surface formats.
When resolving DS, special flags need to be set according to src
and dst format, but this is only one case. Rework this whole logic.
Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Acked-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39916>
vk_format_has_stencil() returns false for VK_FORMAT_X8_D24_UNORM_PACK32.
Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39916>
