NIR has two implementations of lower_idiv, keyed on the
imprecise_32bit_lowering flag. This flag is misleading: the results when
setting this flag "imprecise", they're completely wrong for some values.
If a backend has a native implementation of umul_high, the correct path
isn't that much more expensive. If it doesn't, it's substantially slower
for highp integer divison... but in practice, non-constant highp integer
division is pretty rare.
After a painful migration of the tree, this code path has no more users.
Remove it so nobody else gets the bright idea of using it again.
Closes: #6555
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19303>
imprecise_32bit_lowering produces wrong outputs for some inputs. Do not
use it, it is wrong. The correct lowering generates umul_high
instructions, which need to be lowered via lower_alu. That lowering in
turn produces uadd_carry instructions which also need lowering.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19303>
As a memory object, the MemConstant check should be the same as
MemGlobal.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19352>
This breaks MSAA, even when compression is not activated. The issue is
mostly theoretical, as we always enable color compression with MSAA, but
I ran into some GPU hangs when I disabled compression to run some tests.
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/19066>
Fixes MSAA corruptions on GC3000. 0x4 seems to be enough to fix the
misrendering, but blob seems to always emit 0x5.
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/19066>
On GPUs with the SMALL_MSAA feature, color tiles of the MSAA resource
are 256B, even if the GPU doesn't have the CACHE128B256BPERLINE feature.
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/19066>
For MSAA downsampling to work correctly, the RS engine needs to know
the exact format of the blit source/target. The compatible formats are
fine as long as the RS is only used as a tiler without doing any
conversion.
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/19066>
The RS window alignment restrictions apply to the downsampled side of the
blit, so we must increase the blit size alignment by the MSAA scale to
avoid RS hangs. If a multi-pipe resolve is used (when the GPU doesn't have
the singlebuffer feature) then the Y alignment needs to be increased by
the number of pixel pipes.
The resource allocation has already been fixed to take this additional
alignment requirement into account.
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/19066>
The RS window aligment restrictions apply to the downsampled size of a
MSAA resource, so in order to be able to do the downsample blit for all
possible sizes, we must make sure to increase the alignment of the
multisampled resource by the MSAA scale.
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/19066>
Instead of special casing compressed formats in the caller, handle
them properly when working out the resource alignment. For good measure
add an assert that the layout is linear, as expected.
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/19066>
Instead of adjusting the Y alignment in the callers, just do the
right (and consistent) thing in etna_layout_multiple.
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/19066>
This function assigns proper values to the padding and halign parameters
for all valid layouts. Using unreachable() in the default path of the
switch statement asserts that we got a valid layout, so we can get rid of
some superfluous variable initializations and asserts in the call sites.
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/19066>
The call sites of this function make a number of adjustments to the
padding/alignment returned by this function, which are inconsistent
and still don't cover all necessary cases. To be able to extend this
function move it out of the header and make the parameters passed
more useful by providing all necessary information at once.
No functional change, just a preparation for the following changes.
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/19066>
Having only-recently hooked monitoring up for zink-on-radv, I am
starting to capture some flakes. So, I am unsure about the reproduction
rate of this failure, but I can say it is not extremely common.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19335>
In 7f6ecb8667 we added reference counting for descriptor set layouts,
however, we didn't realize that pools created without the flag
VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT don't free individual
descriptors and can only be reset or destroyed. Since we only drop
references when individual descriptor sets were destroyed, we would
leak set layouts referenced from descriptor sets allocated from these
pools.
Fix that by keeping a list of all allocated descriptor sets (no matter
whether VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT is present or
not) and then traversing the list dropping the references on pool resets
and destroys.
Fixes: 7f6ecb8667 ('v3dv: add reference counting for descriptor set layouts')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19337>
This will affect MTL which will have fp64 support without int64
support.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Iván Briano <ivan.briano@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19284>
