In general, sinking ALU instructions can negatively impact register pressure,
since it extends the live ranges of the sources, although it does shrink the live range
of the destination.
However, constants do not usually contribute to register pressure. This is not a
totally true assumption, but it's pretty good in practice, since...
* constants can be rematerialized (backend-dependent)
* constants can often be inlined (ISA-dependent)
* constants can sometimes be promoted to free uniform registers (ISA-dependent)
* constants can live in scalar registers although the ALU destination might need
a vector register (and vector registers are assumed to be much more expensive
than scalar registers, again ISA-dependent)
So, assume that constants have zero effect on register pressure. Now consider an
ALU instruction where all but one source is a constant. Then there are two
cases:
1. The ALU instruction is moved past when its source was otherwise killed. Then
there is no effect on register pressure, since the source live range is
extended exactly as much as the destination live range shrinks.
2. The ALU instruction is moved down but its source is still alive where it's
moved to. Then register pressure is improved, since the source live range is
unchanged while the destination live range shrinks.
So, as a heuristic, we always move ALU instructions where n-1 sources are
constant. As an inevitable special case, this also (necessarily) moves unary ALU
ops, which should be beneficial by the same justification. This is not 100%
perfect but it is well-motivated. Results on AGX are decent:
total instructions in shared programs: 1796101 -> 1795652 (-0.02%)
instructions in affected programs: 326822 -> 326373 (-0.14%)
helped: 800
HURT: 371
Inconclusive result (%-change mean confidence interval includes 0).
total bytes in shared programs: 11805004 -> 11801424 (-0.03%)
bytes in affected programs: 2610630 -> 2607050 (-0.14%)
helped: 912
HURT: 462
Inconclusive result (%-change mean confidence interval includes 0).
total halfregs in shared programs: 525818 -> 515399 (-1.98%)
halfregs in affected programs: 118197 -> 107778 (-8.81%)
helped: 2095
HURT: 804
Halfregs are helped.
total threads in shared programs: 18916608 -> 18917056 (<.01%)
threads in affected programs: 4800 -> 5248 (9.33%)
helped: 7
HURT: 0
Threads are helped.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24833>
At the moment, this does nothing. It will prevent problems from the next patch,
however.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24833>
This is the AGX version of load_output, which shaders can use for framebuffer
fetch. It is beneficial to sink framebuffer fetch as late as possible, both to
reduce register pressure but also to reduce serialization of overlapping
fragments.
Results on a collection of ubershaders:
total bytes in shared programs: 1468928 -> 1468550 (-0.03%)
bytes in affected programs: 495300 -> 494922 (-0.08%)
helped: 24
HURT: 0
Bytes are helped.
total halfregs in shared programs: 14162 -> 13946 (-1.53%)
halfregs in affected programs: 5148 -> 4932 (-4.20%)
helped: 27
HURT: 0
Halfregs are helped.
total threads in shared programs: 216896 -> 217664 (0.35%)
threads in affected programs: 6912 -> 7680 (11.11%)
helped: 12
HURT: 0
Threads are helped.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24833>
By the time this runs, we will have already lowered load_ubo and load_vbo to
load_constant_agx so we need to handle the backend version.
This is very important for reducing register pressure in monolithic VS+GS
shaders on AGX. Since no other backend has _agx intrinsics, there's no need for
an option to gate this.
The additional instruction count is from more frequent wait instructions due to
fewer instructions grouped together. This should be mitigated in the future with
an ACO-style latency-reducing scheduler in the backend, after register pressure
is reduced by opt_sink.
total instructions in shared programs: 1793385 -> 1796101 (0.15%)
instructions in affected programs: 199816 -> 202532 (1.36%)
helped: 3
HURT: 941
Instructions are HURT.
total bytes in shared programs: 11799628 -> 11805004 (0.05%)
bytes in affected programs: 1345656 -> 1351032 (0.40%)
helped: 34
HURT: 919
Bytes are HURT.
total halfregs in shared programs: 533151 -> 525818 (-1.38%)
halfregs in affected programs: 40335 -> 33002 (-18.18%)
helped: 613
HURT: 42
Halfregs are helped.
total threads in shared programs: 18910464 -> 18916608 (0.03%)
threads in affected programs: 6144 -> 12288 (100.00%)
helped: 12
HURT: 0
Threads are helped.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24833>
Redefine in terms of the algebraic property. This correctly handles the
Mali-specific derivatives.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24833>
I don't see why a p_logical_end is expected or required. It might not be
present in some situations, which causes an assertion failure:
s2: %19646:s[0-1] = p_reload %19701:v[8], 11
s2: %0:exec, s1: %8817:scc = s_andn2_b64 %19646:s[0-1], %0:exec
s2: %8818:s[20-21] = p_cbranch_z %0:exec BB1116, BB1114
No fossil-db changes (gfx1100).
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25244>
This is when the copies actually happen, not at the branch.
fossil-db (gfx1100):
Totals from 1 (0.00% of 79332) affected shaders:
Instrs: 424 -> 423 (-0.24%)
CodeSize: 2172 -> 2168 (-0.18%)
Latency: 2899 -> 2896 (-0.10%)
Copies: 24 -> 23 (-4.17%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25244>
The wrapdb build script used by v3.7.1-2 would lead to compilation
errors when using glibc which gated id_t's definition behind the
_GNU_SOURCE define which wasn't specified while scanning for types,
this was fixed upstream in wrapdb in v3.7.2-2.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25269>
Fixes crash for
dEQP-VK.mesh_shader.ext.in_out.with_f16.permutation_0.mesh_only and
similar tests on GFX11.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Fixes: 3d29779a25 ("aco/optimizer_postRA: Distinguish overwritten untrackable and subdword.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25223>
../src/freedreno/decode/replay.c: In function ‘safe_ioctl’:
../src/freedreno/decode/replay.c:608:13: error: implicit declaration of function ‘ioctl’ [-Werror=implicit-function-declaration]
608 | ret = ioctl(fd, request, arg);
| ^~~~~
Fixes: e3bbd1688b ("freedreno/replay: Add limited support for KGSL")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25264>
MESA_VK_DEVICE_SELECT_FORCE_DEFAULT_DEVICE=1 is useful but it's tedious
to type. This commit extends slightly DRI_PRIME/MESA_VK_DEVICE_SELECT
syntax support: if "!" is appended at the end then only the selected GPU
will be made visible to the application.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24750>
DRI_PRIME=1 isn't useful on machines with more than 2 GPUs.
This commit adds support to DRI_PRIME=N syntax meaning: select
the Nth GPU (not counting the default GPU).
So on a 3 GPUs system where drmGetDevices2 returns the following:
/dev/dri/renderD130 [default]
/dev/dri/renderD129
/dev/dri/renderD128
DRI_PRIME=1 would select D129 (as is already the case without this
commit), DRI_PRIME=2 would select D128.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24750>
This is what RGP expects and this will give us more fine grained
results given that all shader engines/shader arrays etc would be
sampled.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25240>
Will be useful later to generate string tables for the builtin types.
Note we make some extra effort to ensure C++ client code doesn't need to change,
by keeping glsl_type::*_type pointers around.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com> (Python and Meson changes)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25191>
Fix the use of resource and sampler and keep separate index registers
for both so that indirect resource and sampler access can be done
independently.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25159>
There're two issues with the current implementation:
1. Wait semaphores are implicitly required to be SYNC_FD exportable
2. As a queue command that can further record cmds against the wsi
image, it currently doesn't account for pending cmds in the queue
beyond the wait semaphores.
This change fixes both by doing a queue submission in the call with a
SYNC_FD external signal semaphore. However, due to Android wsi not
exposing swapchain to icd, we have to cache the signal semaphore in the
queue, otherwise would have to create/destroy in each present.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25185>
When building for Android, avoid the LLVM dependency if possible.
Cc: mesa-stable
Acked-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Change-Id: Idda03f954b4b5326e23a848e541411b60fcef063
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24007>
The AMD Vulkan driver uses LLVM by default, but it is possible to build
the driver without the LLVM dependency. In this case, we must explicitly
disable LLVM support, or else meson will die after failing to find LLVM.
The Android build system already knows when to link libLLVM, so forward
that information to meson.
Cc: mesa-stable
Acked-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Change-Id: I7489d3811625b390aaaf2e84e666b4a8d98328b0
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24007>
