Previously, the optimization to use v_mul_lo_u16 for
32bit multiplications was done in instruction_selection.
This was moved to the optimizer to ease some case distinctions.
The mixed results are due to increased use of SDWA.
Totals from 2616 (1.74% of 150170) affected shaders: (GFX10.3)
VGPRs: 143888 -> 143872 (-0.01%); split: -0.02%, +0.01%
CodeSize: 5604032 -> 5604080 (+0.00%); split: -0.01%, +0.01%
Instrs: 1086798 -> 1083915 (-0.27%); split: -0.27%, +0.01%
Latency: 8215793 -> 8213023 (-0.03%); split: -0.10%, +0.07%
InvThroughput: 20765157 -> 20773766 (+0.04%); split: -0.02%, +0.06%
VClause: 35256 -> 35260 (+0.01%); split: -0.02%, +0.03%
SClause: 29021 -> 29024 (+0.01%); split: -0.00%, +0.01%
Copies: 74163 -> 74306 (+0.19%); split: -0.05%, +0.24%
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11678>
This partially reverts commit 4d9acfa533.
The original patch said:
"Python 3 handles unicode strings by default, so we can drop all that."
But this breaks building on RHEL 7 (or similiar) since python3 support
on is much more limited than newer distros. Backporting all the needed
python 3 libraries to EL7 is a pretty big task, and isn't very easy to
maintain.
For workstation purposes, we need the AMD MM/GL driver building on RHEL
7, so only src/util/driconf_static.py needs to be reverted.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12549>
With this code, we end up generating code such as:
if (!strcmp(extensions[i].extensionName, "VK_KHR_maintenance1")) {
if (VK_MAKE_VERSION(1,2,0) >= screen->vk_version) {
info->have_KHR_maintenance1 = true;
} else {
info->have_KHR_maintenance1 = true;
}
}
That's clearly nonsense, as it does the same thing in the true and false
case. So let's instead try to walk the Vulkan versions up to the one
we're using in a separate pass, and add all extensions that were made core
in that version.
CID: 1473289
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12593>
nir_src_as_const_value can return null pointers, and in other places we
at least assert for this. So let's do that here as well, which makes
Coverity a bit less paranoid.
While we're at it, avoid duplicating the nir_src_as_const_value call to
the same source.
CID: 1444291
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12594>
The documentation for ASSERTED in macros.h says:
> Use ASSERTED to indicate that an identifier is unused outside of an `assert()`,
> so that assert-free builds don't get "unused variable" warnings.
We're using this variable outside of assert, so this shouldn't apply
here.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12594>
It's so much easier to follow this code if there's not any big blocks of
emitting in the middle of the code that figures out exactly what to do.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12594>
nir_src_as_const_value also checks if the src is const, and not
checking that it returned null makes Coverity go paranoid thinking we
could dereference a null-pointer. But because it's slightly better to
check once than to check twice, let's rewrite this to avoid the
double-check, making it obvious what's going on here.
CID: 1485624
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12594>
memcmping NULL pointers is not allowed, and would lead to a crash here.
So let's check that the first isn't NULL; we've already checked that
they're not *both* NULL, so checking one is enough.
CID: 1484801, 1484810
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12559>
This NULL-check makes Coverity paranoid because we just dereferenced the
pointer a few lines above.
But we never call this function with a NULL-pointer here, so the NULL
check isn't needed. Let's just remove it, to calm Coverity down a bit.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12559>
We do this in the other pipe_buffer_map_range failure case, so it makes
sense that we need to do it here as well. If we don't, we'll end up
taking a crash in the check_query_results function, which will
dereference that pointer.
We also need to unmap the buffer if we fail, otherwise we'll leak.
CID: 1475925
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12559>
We're checking if pctx is null here, but that can't be true. If it
could, then the code that follows would have immediately crashed.
A quick peek at other drivers seems to indicate that this is a safe
assumption.
CID: 1474410, 1474554
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12559>
We can't do any of this logic if key is NULL, because that means we'll
dereference memory close to a NULL-pointer.
While we're at it, add some asserts to the zink_fs_key and zink_vs_key
functions who would otherwise be responsible for giving us invalid
non-null pointers out of null-pointers.
CID: 1475973, 1475983
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12559>
If we multiply before we (implicitly) cast the result to the target
type, we needlessly risk overflowing the result.
CID: 1490790, 1475922
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12559>
We currently cause the following scary warning to be printed on
start-up for *every* application regardless if that feature is being
used or not when run on top of ANV:
> WARNING: Some incorrect rendering might occur because the selected
> Vulkan device (Intel(R) UHD Graphics 620 (KBL GT2)) doesn't support
> base Zink requirements: line_rast_feats.stippledRectangularLines
> line_rast_feats.stippledSmoothLines
There's no need to scare the users about this, as most applications
don't care about these combinational features. So let's instead emit a
warning when these features are attempted (but failed) to be used
instead.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12587>
This reverts commit 336dea90f0.
This change was incorrect for two reasons:
1. We already initialize this field on line 334
2. Unconditionally setting this to
VK_BORDER_COLOR_FLOAT_TRANSPARENT_BLACK breaks rendering with e.g
opaque white borders, because we've already matched those to a
non-custom enum value first.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12591>
This is required by Android. Some Android games like nier reincarnation
show a black screen without this.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12393>
Before PS waves are launched, PS inputs are moved from PC to LDS
and the corresponding part of the PC is deallocated.
Each PS input occupies 3 * vec4 (3 * 16 = 48 bytes) of LDS space.
See Figure 10.3 in the GCN3 ISA manual.
These limit occupancy the same way as other stages' LDS usage does.
Note that PS can request additional LDS space via EXTRA_LDS_SIZE,
so that also must be taken into account here.
No Fossil DB changes.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12517>
instead of just reading the template bufferinfo data, ensure that only
buffers which will be read are added to the set to avoid stale cache entries
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12582>
We should not skip the copy when the batch is attached a framebuffer
descriptor, quite the opposite. Let's drop the check instead of reversing
it since we are guaranteed to have an FB attached when
panvk_copy_fb_desc() is called.
Fixes: 792a0ab0b1 ("panvk: Prepare per-gen split")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12590>
The panvk_entrypoints.h header is included by all panvk_vX_xxx.c
source files, without this dependency the build can fail.
Fixes: 792a0ab0b1 ("panvk: Prepare per-gen split")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Fabio Pedretti <pedretti.fabio@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12590>
there's no need to track the number of batches that a query is referenced on,
as all the tracking is already done by the batch_usage mechanism, so this
can be simplified to manage destruction based on whether batch_usage exists
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12578>
these should be staging resources since they're being read from often,
and this allows dropping the UNSYNCHRONIZED flag from map since it should
be inferred
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12578>
Fixes assert when ReadPixels() called to read from FBO to
GL_PIXEL_PACK_BUFFER, on mip-level > 0, since num_layers
wasn't properly calculated with mip-level.
v2: patched 'iris_create_sampler_view' function instead of
'resolve_sampler_views'. Just like it was suggested in this
function's comment.
The logic of fix is similar to one in 'update_image_surface' function
of i965 driver, which is introduced in commit
f9fd0cf479.
With a slight change: setting array_len=1, like it was done in
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5808 ,
since minifying depth fails KHR-GLES2.texture_3d.filtering tests.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4145
Fixes: 3c979b0e ('iris: add some draw resolve hooks')
Signed-off-by: Yevhenii Kharchenko <yevhenii.kharchenko@globallogic.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9253>
Something really bad happen (likely driver bug) if this is triggered.
Replace with some assertions to catch an eventual issue in debug build.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12556>
Although this can likely hang, this is invalid and should be caught
by the validation layers. There is many ways to hang the GPU with VK,
this check alone is useless.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12556>
Daniel Schürmann
Mike Blumenkrantz
Jeremy Newton
Erik Faye-Lund
Lepton Wu
Timur Kristóf
Tomeu Vizoso
Boris Brezillon
Yevhenii Kharchenko
Samuel Pitoiset