The lack of ACCESS_COHERENT was probably fine, the worst it would do would
add a pointless iteration after loading an out-of-date value.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37417>
I'm having hip surgery (same surgery as last year, other hip) on Oct 22,
which I'm hoping goes well and hoping (and expecting) that I'll have
recovered enough after a week to be able to sit with my laptop for long
enough chunks to do release management.
Worst case, if I can't do it I'll push back the 25.2.6 release by
a week, but I think I'll keep the branchpoint as that one doesn't take
much work as there's nothing to backport, just creating a couple of
branches and tags, and setting up a worktree locally which I can do in
advance (and have just done so).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37435>
To lower 64bit sources we emit a COLLECT -> SPLIT pair to force
allocation into consecutive registers. When the sources for COLLECT
are outputs of the same SPLIT already, we can omit the COLLECT + SPLIT
pair.
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Aksel Hjerpbakk <aksel.hjerpbakk@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37398>
No manual changes here, this is simply running
$ ninja -C build/ clang-format
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Acked-by: Simon Perretta <simon.perretta@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37222>
SMEM instructions mask off the low bits for the base and offset sources
both before and after they're added. However, NIR expects ACO to only
care about the alignment of the final address.
fossil-db (gfx1201):
Totals from 21 (0.03% of 79839) affected shaders:
Instrs: 229780 -> 229876 (+0.04%)
CodeSize: 1267724 -> 1268080 (+0.03%)
Latency: 2800924 -> 2800978 (+0.00%)
InvThroughput: 520250 -> 520256 (+0.00%)
Copies: 27878 -> 27876 (-0.01%); split: -0.01%, +0.00%
SALU: 29591 -> 29643 (+0.18%)
fossil-db (polaris10):
Totals from 3 (0.00% of 62201) affected shaders:
Latency: 2651 -> 2652 (+0.04%)
InvThroughput: 662 -> 663 (+0.15%)
PreSGPRs: 51 -> 54 (+5.88%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37301>
This seems to be equal assert with febe90e109 as we hit this when
launching Quake II RTX.
Fixes: 69b6b4cb28 ("anv: add shader instruction emission")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37429>
Implement retrieving color buffer info via gralloc0. This is a simpler
alternative to imapper4/5 which requires a dependency on libui that
would require a heavy effort to import headers and stub to be able to
build out of tree.
Since VNDK no longer releases headers since API Level 35 and they are
now only auto-generated, copy over the neccessary defines.
Signed-off-by: Juston Li <justonli@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37185>
Remove more generated files
deps are removed
args need to be quoted.
Add example to run mesa_vs docker image
pass args to choose MSVC version properly
Add EXTRA_MESON_ARGS for meson configure
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37210>
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(114): error C2220: the following warning is treated as an error
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(114): warning C5286: implicit conversion from enum type '<unnamed-enum-LVP_CMD_WRITE_BUFFER_CP>' to enum type 'vk_cmd_type'; use an explicit cast to silence this warning
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(114): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(152): warning C5286: implicit conversion from enum type '<unnamed-enum-LVP_CMD_WRITE_BUFFER_CP>' to enum type 'vk_cmd_type'; use an explicit cast to silence this warning
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(152): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(173): warning C5286: implicit conversion from enum type '<unnamed-enum-LVP_CMD_WRITE_BUFFER_CP>' to enum type 'vk_cmd_type'; use an explicit cast to silence this warning
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(173): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(204): warning C5286: implicit conversion from enum type '<unnamed-enum-LVP_CMD_WRITE_BUFFER_CP>' to enum type 'vk_cmd_type'; use an explicit cast to silence this warning
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(204): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(706): warning C5286: implicit conversion from enum type '<unnamed-enum-LVP_CMD_WRITE_BUFFER_CP>' to enum type 'vk_cmd_type'; use an explicit cast to silence this warning
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(706): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(722): warning C5286: implicit conversion from enum type '<unnamed-enum-LVP_CMD_WRITE_BUFFER_CP>' to enum type 'vk_cmd_type'; use an explicit cast to silence this warning
../src/gallium/frontends/lavapipe/lvp_acceleration_structure.c(722): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
warnings are introduced with new cl compiler:
Microsoft (R) C/C++ Optimizing Compiler Version 19.44.35214 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37041>
this reuses some of the machinery from regular gfx shaders, but there
are some key differences:
* separate program/GPL caching
* separate GPL vertex input (technically illegal because spec hasn't caught up)
* in descriptor layouts, task+mesh occupy vs+tcs space (and thus vs+tcs layouts add mesh stages)
* lots of 'is_mesh' checks sprinkled all over
otherwise much of this change is just enlarging arrays
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37427>
... to make it forward compatible / to make it not crash older
Gfxstream host builds.
Test: Capture guest and host trace and inspect in perfetto UI
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37410>
... to allow sharing perfetto global flow ids between guest and host
so that combined traces can have an arrow between the guest and host
render threads to aid debugging.
Test: Capture guest and host trace and inspect in perfetto UI
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37410>
While Intel will use the full feature set of util_lut3 in the future, AGX can
use the cut down 2-source versions right now to get us an in-tree user.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37200>
Wasn't 100% sure about some of these derivations so let's add tests.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37200>
Many instruction sets (Intel, Apple, NVIDIA) implement bitwise operations with a
single general instruction that takes a lookup table in sum-of-products
(minterms) form. Working with these tables manually is a bit gnarly, and
multiple backends need to do this. This adds common code for representing such
lookup tables with 2- or 3-sources, with a rich set of helpers for building,
inspecting, and manipulating the LUTs.
Eventually, we may want to introduce a nir_op_bitop3 instruction to NIR to build
common code for fusing boolean expression trees into lookup tables. That NIR
pass will presumably use the helpers here.
NAK already has this abstraction internally (in Rust). Possibly NAK will be able
to drop (or cut down) that code once we handle this in NIR.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37200>
We will use this to manipulate lookup tables, but it's a common algorithm.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37200>
these are new buffers with empty contents which are immediately
unmapped after a memcpy, so there's no reason to force
the driver (or tc) to sync
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36634>
these are new textures with empty contents which are immediately
unmapped after a strided memcpy, so there's no reason to force
the driver (or tc) to sync
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36634>
