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. Non-constant highp integer division is
rare enough this shouldn't noticeably harm performance of real applications.
Address r600 portion of #6555.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18154>
The default lib prefix is `lib`, so adding `lib` to the lib name just
results in `liblibbroadcom_v3d.a` for instance.
Those are internal, build-temporary static libraries that end up being
linked into the real user-visible libraries, so it doesn't really
matter, but we might as well just clean up their names anyway.
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18171>
This way, blend info that's left zeroed out defaults to disabled. Fixes an
assertion failure in KHR-GLES31.core.draw_buffers_indexed.color_masks due to
the blend CSO max_rt being set unreliably. This is also probably clearer.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17841>
On Midgard, we need a "blend" shader even if blending is disabled, if the format
isn't blendable. This is inefficient. Bifrost solves this by decoupling the
format conversion from the blending, allowing opaque (unblended) output to any
format without a blend shader or fragment key.
Unfortunately, our blend code is from the Midgard era -- I wrote an early
version of nir_lower_blend when I was still in high school! -- so we've been
using blend shaders for opaque output even on Bifrost. Whoops!
In SuperTuxKart, reduces blend shader calls by 30%, translating to a 15%
reduction in i-cache misses.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17841>
The type of the output variable will propagate through the store_output
intrinsic's src_type field to the BLEND instruction's register format field. On
Valhall, the register format for a BLEND comes from the instruction -- the
register format specified in the conversion descriptor (used on Bifrost) is
ignored. That means it has to match.
Previously, we always used a blend shader for integer rendering. Since blend
shaders ignore the register format of the BLEND instruction, that masked this
issue. That also means we don't need to backport this.
Will prevent a regression from the following commit.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17841>
For untyped_color_outputs, we need to ignore the type of the colour output in
the shader and instead use the type from the format. We have all the information
to do this at blend descriptor pack time, but not at shader compile time. This
means we need a (somewhat expensive) fixup in this edge case to ingest
NIR-to-TGSI. This will prevent a regression from the rest of the series.
Although the register_format field is also present on Valhall blend descriptors,
it is ignored so we don't need the fixup there.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17841>
Colour outputs in TGSI are untyped so we have to ignore the register format on
the store_output. Luckily, Valhall gives us the auto32 escape hatch to deal with
it, and Bifrost doesn't care anyway. This will avoid regressions from native int
output without corrupting the compiler for GLSL and SPIR-V shaders that are
well-typed.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17841>
Clause scheduler edition of db2bdc1dc3 ("pan/bi: Require ATEST coverage mask
input in R60"). ATEST wants to read r60, which can't work if its input isn't
even in a register.
When per-sample shading isn't in use, prevents regressions in:
KHR-GLES31.core.sample_variables.mask.*
These tests previously passed because per-sample shading was forced. It's
not clear whether the bug addressed in this patch is possible to hit "in the
wild", i.e. without the optimizations in this series that allow us to use
per-pixel shading in more cases.
No shader-db changes.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17841>
Fixes flaking in
dEQP-GLES31.functional.image_load_store.cube.qualifiers.volatile_r32i due to
image reads being moved past a BARRIER.
To make this more robust/optimal, we probably need scheduling information
(coherent/volatile/etc) added to instructions like ACO does. That's left for a
future extension, for now I just want the test to stop flaking.
Fixes: 569e5dc745 ("pan/bi: Schedule for pressure pre-RA")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17841>
Unnecessary rename that breaks forward compatibility... but Apple says
this is just NULL. Do the simpler thing. Note that the argument is a
mach_port_t, which is a natural_t == uint32_t in userspace... even
though it's a pointer in the kernel. Although Apple's docs claim that
kIOMasterPortDefault is NULL, it's really just 0.
../src/asahi/lib/agx_device.c:290:35: warning: 'kIOMasterPortDefault' is deprecated: first deprecated in macOS 12.0 [-Wdeprecated-declarations]
IOServiceGetMatchingService(kIOMasterPortDefault, matching);
^~~~~~~~~~~~~~~~~~~~
kIOMainPortDefault
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18121>
Shader-db stats with RV530:
total instructions in shared programs: 166499 -> 164362 (-1.28%)
instructions in affected programs: 80056 -> 77919 (-2.67%)
total temps in shared programs: 21658 -> 21565 (-0.43%)
temps in affected programs: 1780 -> 1687 (-5.22%)
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17560>
Shader-db stats with RV530:
total instructions in shared programs: 169509 -> 166013 (-2.06%)
instructions in affected programs: 99126 -> 95630 (-3.53%)
total presub in shared programs: 10975 -> 10758 (-1.98%)
presub in affected programs: 744 -> 527 (-29.17%)
total temps in shared programs: 21722 -> 21649 (-0.34%)
temps in affected programs: 1350 -> 1277 (-5.41%)
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17560>
Skip the merge if one of the instructions writes just w channel
and we are compiling a fragment shader. We can pair-schedule it together
later anyway and it will also give the scheduler a bit more flexibility.
Shader-db stats with RV530:
total instructions in shared programs: 169522 -> 169509 (<.01%)
instructions in affected programs: 14170 -> 14157 (-0.09%)
total temps in shared programs: 21712 -> 21722 (0.05%)
temps in affected programs: 324 -> 334 (3.09%)
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17560>
