It's going to be called by si_get_nir_shader.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19429>
Clamp vertex color in nir. Now only GS copy shader use
si_vertex_color_clamping, so move it there. It will be
completely removed after we switch to nir GS copy shader.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19429>
Clang enables it by default, but GCC does not. Enable it explicitly to
have some consistency between the supported compilers.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Eric Engestrom <eric@igalia.com>
Acked-by: Dylan Baker <dylan.c.baker@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19439>
We know cmdstream buffers are immediately mmap'd, which is both
expensive on the host, and breaks the pipelining as guest is forced
to stall waiting for the host. So pre-allocate some cmdestream
buffers, so that we have something that is (hopefully) already
allocated and mapped to guest's physical memory before we need it.
The older buffer from the head of the prealloc list replaces the
newly allocated buffer which is pushed to the tail of the prealloc
list.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19656>
Using the same size that we suballoc from for suballoc'd streaming and
long-lived stateobjs should help improve bo cache usage, by making more
of the backing BOs the same size and interchangable.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19656>
It doesn't produce different code when compiled for the host machine,
and this avoids needing two copies and possibly a host machine emulator
in cross compilation settings
Reviewed-by: Luis Felipe Strano Moraes <luis.strano@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19449>
- consistently use list.extend instead of list +=, which has gotchas
- condense list extension calls when possible
Reviewed-by: Luis Felipe Strano Moraes <luis.strano@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19449>
Since we're not doing anything fancy, we can just use `subprocess.run`.
I've also removed the custom error class, we're not going to catch it,
so just printing and exiting is fine.
v2:
- Print stdout as well as stderr in case of a glslang failure
Reviewed-by: Luis Felipe Strano Moraes <luis.strano@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19449>
We expect that convert_to_static_variable and override_version will find
and replace something, so let's fail loudly if they don't.
Reviewed-by: Luis Felipe Strano Moraes <luis.strano@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19449>
I'm not 100% sure whether it's right to make --vn required, or to avoid
the static conversion, but this seems correct. Mypy (type checking
coming soon) points out that if --vn is None then the
convert_to_static_variable function will fail. Our one use of this sets
--vn, so there is no change there. Making --vn required
ensures that it will never be None, avoiding the problem.
Reviewed-by: Luis Felipe Strano Moraes <luis.strano@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19449>
The variable is called `extra`, but what's written is `extra - flags`,
and `flags` is undefined, so if the variable was ever passed there would
be an uncaught exception.
fixes: 9786d9ef2a
Reviewed-by: Luis Felipe Strano Moraes <luis.strano@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19449>
In Python 3 (the only python we support) `io.open` is an alias of the
builtin `open` function, so it's not getting us anything, and we're not
using it consistently.
Reviewed-by: Luis Felipe Strano Moraes <luis.strano@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19449>
args.Olib is set to `store_true`, which means it will always be `True`
or `False`, this means that the we always, unconditionally, add
`--keep-uncalled` to the command line.
fixes: 9786d9ef2a
Reviewed-by: Luis Felipe Strano Moraes <luis.strano@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19449>
aztec_ruins under ANGLE was getting LRZ writes disabled because 0xf out of
the 0x3 mask was enabled. The goal was to see if there are partial writes
being done, though. This caused a 2-3% performance regression.
Fixes: 85d0205db1 ("tu: Implement extendedDynamicState3ColorWriteMask")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19635>
The nir_opt_algebraic() call to clean up nir_lower_imul's split up mul
operations (stuff like "the top 16 bits were 0, no need to mul and add
that part") would trigger the options->fuse_ffma_* early ffma splitting,
so you need to call nir_opt_algebraic_late() again after that (which, in
turn, requires a DCE).
Gets us a lot more ffmas in Aztec Ruins high under zink/angle, but doesn't
seem to change perf.
shader-db highlights:
total instructions in shared programs: 11574843 -> 10999629 (-4.97%)
instructions in affected programs: 3308870 -> 2733656 (-17.38%)
total dwords in shared programs: 24344722 -> 23230122 (-4.58%)
dwords in affected programs: 6569568 -> 5454968 (-16.97%)
total full in shared programs: 762616 -> 762224 (-0.05%)
full in affected programs: 15505 -> 15113 (-2.53%)
total stp in shared programs: 4046 -> 4050 (0.10%)
stp in affected programs: 3372 -> 3376 (0.12%)
total ldp in shared programs: 2166 -> 2170 (0.18%)
ldp in affected programs: 1716 -> 1720 (0.23%)
total (ss) in shared programs: 219541 -> 216261 (-1.49%)
(ss) in affected programs: 23227 -> 19947 (-14.12%)
total (sy) in shared programs: 101633 -> 101927 (0.29%)
(sy) in affected programs: 8611 -> 8905 (3.41%)
total waves in shared programs: 1501942 -> 1501772 (-0.01%)
waves in affected programs: 1880 -> 1710 (-9.04%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18946>
If we're in handle_collect()'s dst allocation and are part of a merge set
near the end of the file, our check for reg_elem_size(reg) would let us
use the preferred reg when that would immediately lead to
allocate_dst_fixed() creating an interval extending thruogh reg_size(reg)
that overflows the file.
Avoids a regression on gfxbench5/gl_5_high_off/17.shader_test in the next
commit. No change on shader-db.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18946>
This should make it easier to keep links in our docs up-to-date.
But, because links can die behind our backs, we can't really enable this
all over the place, or we'll risk blocking merge-requests due to
unrelated changes.
So let's just make this a periodic job on the main branch instead.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
There's a *lot* of relnotes, and we don't really actively maintain them.
Let's drop linkchecking them to speed things up a bit.
This does a whole lot of nothing unless you have Sphinx 4.4 or newer.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
The use of a hash symbol in a URI is an anchor, not to indicate an IRC
channel name. This confuses the Sphinx linkchecker.
Dropping the hash here still makes the link work fine, so let's just do
that.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
Here's a few redirects that we should apply, in case the redirects
gets removed in the future.
These are mostly of the 301 (moved permanently) kind, but also a
few where the site probably *should* have used the permanent
error-code.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
These links redirect to something seemingly random. Here's my best
effort to update them to the relevant pages in the current docs.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
These links redirect to a catch-all page, and not really where we want
people to end up. Let's correct these links and point to the benchmark
specific pages.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
While it would be possible to dig this one up through web.archive.org,
there's a much better article written by Fabian Giesen on the subject,
so let's just link that one instead.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
There's no point in linking to a copy of this article on a defunct site.
So let's just remove it, the original source works just fine.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
The page that was linked here is defunct, and doesn't have a direct
replacement. But a good alternative is to link to the OpenGL wiki, which
has a lot of useful information on the subject.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19574>
