rustfmt would change not only lib.rs, which is output by this script,
but also all of the other files in the library. The problem is, those
other files are inputs to lib_rs_gen so the script was changing its own
inputs which meant ninja needed to be run twice before we reached a
fixed point. Remove rustfmt for now to prevent this issue.
Fixes: 591b5da4 ("nouveau/headers: Run rustfmt on generated files")
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36121>
The unordered mode stored in dependencies might be a bitmask and not
only a single mode. In practice, only the "stronger" mode will stick.
Make sure that the code testing for the mode uses "&" instead of "==",
to avoid prevent some valid combinations to happen, e.g.
```
// ...
add(16) g104<1>F g94<1,1,0>F g34<1,1,0>F { align1 1H @7 $7.dst compacted };
```
which without the fix ends up as
```
// ...
sync nop(1) null<0,1,0>UB { align1 WE_all 1N F@7 };
add(16) g104<1>F g94<1,1,0>F g34<1,1,0>F { align1 1H $7.dst compacted };
```
Enables two tests for the scoreboard pass that illustrate this case.
For measuring the effect, re-enabled the sync.nop accounting on total of
instructions and got the following results.
```
Totals:
Instrs: 322041261 -> 321748285 (-0.09%)
Cycle count: 22864587567 -> 22863073741 (-0.01%)
Max dispatch width: 7989040 -> 7989024 (-0.00%); split: +0.00%, -0.00%
Totals from 88212 (9.78% of 902056) affected shaders:
Instrs: 102282050 -> 101989074 (-0.29%)
Cycle count: 12787629859 -> 12786116033 (-0.01%)
Max dispatch width: 525336 -> 525320 (-0.00%); split: +0.01%, -0.01%
```
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36096>
If the loader tells us to use zink, we use zink. This breaks the
Nouveau heuristic where we use Zink instead of the Nouveau GL driver on
Turing and later. The only reason why it works at all is because we
fail to load what the loader requests and then EGL goes "Oops. No
driver! Let's see if Zink works" and we pick it up on the fallback. We
shouldn't depend on those fallbacks if the loader explicitly says to use
Zink for some bit of hardware.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36014>
Instead of duplicating half of the DRM path, just use the DRM path. The
only real functional change that I can see here is that we now advertise
WL_create_wayland_buffer_from_image on Zink, which should be fine. It
also fixes potential bugs where ForceSoftware && Zink could result in
getting visuals from DRM that don't actually work with wl_shm and then
trying to use them through wl_shm via the kopper path.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36014>
Otherwise we're sending lavapipe down the kopper path even though it's
not kopper which creates a mess in the code. Also, in spite of the fact
that there are comments claiming lavapipe hits these paths we also have
asserts that it doesn't. Make everything consistent.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36014>
This moves the multibuffers check earlier to make it clear that this is
an early-exit. We also delete kopper_without_multibuffers in favor of a
local variable that doesn't leak all over everywhere. The new variable
is named force_zink because that's really what we're doing: force-enable
Zink even if the X11 checks fail.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36014>
This is because Android prefers it -- the project likes to make
changes to bionic that have a global effect, and using raw-syscalls
potentially complicates that. This is a backport of:
https://github.com/bytecodealliance/rustix/pull/1478
In addition, nothing in Mesa3D needs the added functionality provided
by raw syscalls.
Test:
meson setup gfxstream-build -Dvulkan-drivers="gfxstream" -Dgallium-drivers="" -Dvirtgpu_kumquat=true -Dopengl=false -Drust_std=2021
still compiles.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36116>
Either Rb or Rc can be the non-register, so the copy if both
not reg should be sufficient.
Totals:
CodeSize: 14025216 -> 14022144 (-0.02%)
Static cycle count: 5313517 -> 5312651 (-0.02%)
Totals from 4 (0.30% of 1332) affected shaders:
CodeSize: 119168 -> 116096 (-2.58%)
Static cycle count: 33920 -> 33054 (-2.55%)
Only affects:
q2rtx/q2rtx-rt-pipeline 42 -0.48% -0.45%
This also helps with the coop matrix shaders.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36104>
The border color of the rv770 gpu behaves the same way as
the evergreen border color. This change updates the software
accordingly.
This change is enabled for all the pre-evergreen gpus.
This change fixes 120 piglit tests. The rv770 ci is updated
as well.
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34502>
This is the backport of 0c0b978938 "radeonsi: set NEVER as
the depth compare func if depth compare is disabled".
The function r600_tex_compare arguments are updated with the "const"
keyword.
This change fixes the test below which was broken after 0c6e56c391:
khr-gl4[5-6]/incomplete_texture_access/sampler: fail pass
Fixes: 0c6e56c391 ("mesa: (more) correctly handle incomplete depth textures")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Acked-by: Vitaliy Triang3l Kuzmin <triang3l@yandex.ru>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35968>
Samuel Pitoiset