lavapipe: ci updates

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15320>

lavapipe: skip format checks for EXTENDED_USAGE

we can effectively skip any kind of checks here and just assume that one
of two scenarios is in effect:
* the user is about to attempt some incredibly illegal behavior that VVL will catch
* the user is about to attempt a pro gamer move and we'll be fine

in either case, it's EXTENDED_USAGE, so hopefully we're about to make a texture
view from a compatible and supported format

cc: mesa-stable

fixes:
dEQP-VK.image.extended_usage_bit_compatibility.image_format_properties*

Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15320>

lavapipe: use the correct value for dynamic render resolve attachment indexing

subpass->color_count is (obviously) not set yet, so this would just clobber
the color attachments any time resolves were used

Fixes: 8a6160a3542 ("lavapipe: VK_KHR_dynamic_rendering")

fixes:
dEQP-VK.draw.dynamic_rendering.multiple_interpolation.structured.with_sample_decoration.4_samples

Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15330>

lavapipe: remove broken workaround for zink depth texturing.

Cc: mesa-stable
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15297>

zink: workaround depth texture mode alpha.

Since spir-v only has single channel depth sampling, it breaks
with the old school GL_ALPHA depth mode swizzle, so just detect
that case and smash all the channels.

Cc: mesa-stable
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15297>

tu: Expose subgroup arithmetic

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

ir3: Add support for subgroup arithmetic

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

ir3: Track physical edges when inserting (ss) for shared regs

Normally this wouldn't matter, but it will matter for the upcoming scan
macro because the running tally is communicated through a shared
register across a physical edge. It may also matter if a live-range
split occurs.

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

util/bitset: Fix off-by-one in __bitset_set_range

Fixes: b3b03e33c9f ("util/bitset: add BITSET_SET_RANGE(..)")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

ir3/spill: Mark reload destination as early-clobber

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

ir3/ra: Add IR3_REG_EARLY_CLOBBER

We'll need this to model the subgroup reduction macros.

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

ir3/ra: Add proper support for multiple destinations

We weren't considering the other destinations when allocating a
destination, so we could allocate overlapping destinations. This wasn't
done before because we never had a need for it, but the subgroup
reduction macros will need it.

The trickiest part of this is that we have to rewrite the
compress_regs_left fallback, because we may have to move around the
other already-allocated destinations. We now have a list of destinations
to (re)allocate in addition to the popped live intervals. For the rest
of the destination handling, we can just bail out if the proposed spot
for something overlaps another destination, but for the fallback we have
to handle all the cases gracefully. I also added support for odd
combinations of multiple destinations where some of them are tied, which
we'll use in the next commit to handle early-clobber destinations and
which will actually be used because one of the destinations of the
subgroup reduction macro will be early-clobber. The result is that the
order of intervals to allocate is now a lot more complicated.

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

ir3/ra: Sanitize parallel copy flags better

For pcopies we only care about the register's type, i.e. whether its a
half-register and whether it's an array (plus its size). Copying over
other flags like IR3_REG_RELATIV just leads to sadness and validator
assertions.

Fixes: 0ffcb19b9d9 ("ir3: Rewrite register allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

ir3/ra: Fix ra_foreach_dst_n

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

ir3/ra: Fix tied destination handling with multiple destinations

Before, we were careful to

1. Get the source physreg.
2. Allocate the destination.
3. Insert a copy with the source being the physreg from step 1.

and this guaranteed that if the tied source were moved in step 2 we'd
still insert a copy from the correct place. However this won't work with
multiple destinations because an earlier destination could've already
moved the tied source around. Instead flip steps 2 and 3 (we'll insert
the copy before we allocate the interval, but that's ok) and run the
first two steps in a separate loop before any destinations are
allocated.

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

ir3/sched: Support multiple destinations

Note: this is a behavior change for arrays, because it will count the
entire array instead of just the components written in the register
pressure calculation. However this is more accurate since this matches
how RA works.

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

ir3/dce: Support multiple destinations

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

ir3/cp_postsched: Support multiple destinations

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14107>

vulkan,lavapipe: Move some enqueue helpers to common code

Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>

lavapipe: Re-use auto-generated vk_cmd_enqueue entrypoints

Re-use auto-generated vk_cmd_enqueue entrypoints instead of generating
our own version doing the same thing.  In order to effectively do this,
we also add an allow-list of which entrypoints lavapipe actually handles
to avoid issues where the autogenerated one stomps a vkCmdFoo2 wrapper.

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>

lavapipe: Reset the free_cmd_buffers list in TrimCommandPool

We delete all the command buffers but they're still in the list so
future allocations may try to re-use them post-free and another trim
will re-delete them.

Fixes: b38879f8c5f5 ("vallium: initial import of the vulkan frontend")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>

vulkan/cmd_queue: Generate enqueue entrypoints

Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>

vulkan/cmd_queue: Properly deconstify array of pointers

When manipulating an array of pointers, what we want to desconstify is
the array, not the entry type.

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>

vulkan/cmd_queue: Stop generating enqueue helpers for INTEL perf queries

They don't return void and they're not used by anyone except the Intel
drivers so there's no point in supporting them.

Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>

vulkan/cmd_queue: Re-flow MANUAL_COMMANDS

This just makes it all a bit easier to read.

Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>

vulkan/cmd_queue: Remove duplicate entries in MANUAL_COMMANDS

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>

vulkan/runtime: Add a vk_cmd_queue object to vk_command_buffer

This is paving the road for generic secondary command buffer support,
where commands are simply recorded in a software queue and replayed
on the primary command buffer when vkCmdExecuteCommands() is called.

Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>

vulkan/cmd_queue: Add an initializer for the vk_cmd_queue object

Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>

vulkan/cmd_queue: Constify vk_cmd_queue.alloc

The implementation shouldn't modify the allocator.

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15311>

lavapipe: add the full list of cts fails

easier to keep track this way

Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15294>

virgl: Check texture multisample compatibility

v2: Support VIRGL_FORMAT_NONE (Gert Wollny)

Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Suggested-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15115>

virgl/ci: Uprev virglrenderer

Suggested-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15115>

tu: Implement VK_EXT_depth_clip_control

Since negativeOneToOne is a static property of the pipeline and
viewport state could be dynamic, we have to defer viewport state
emission until negativeOneToOne value is known.

See: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6070

Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14363>

broadcom/compiler: remove unused functions

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15302>

docs: add release notes for 22.0.0

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15312>

docs: Add calendar entries for 22.0 release.

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15312>

docs: update calendar and link releases notes for 22.0.0

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15312>

ac: Query the amdgpu MEC firmware version.

MEC (Micro Engine Compute) is the firmware which is responsible for
the compute-only queues on AMD GPUs. It is present on GFX7 and newer.
This patch will query the version of this firmware and print it
among the others.

Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15283>

mesa: Fix discard_framebuffer for fbo vs winsys

GL is annoying when it comes to having different enums for winsys vs
fbo.

Note that the issue this closes was only accidentially exposed by a
change the resulted in sysmem vs GMEM path taken.

Fixes: db2ae511210 ("mesa: Skip partial InvalidateFramebuffer of packed depth/stencil.")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6103
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15308>

docs/ci: Add docs for using a POE switch to control boards, like nouveau.

Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15201>

docs/ci: Update some bare-metal CI docs.

We haven't been using initramfs in a long time, don't point people that
direction.  Do point people at existing instances of these CI variants,
though.

Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15201>

ci/nouveau: Add a manual run for the Jetson Nano (GM20B).

The test suite is full of flakes around transform feedback, atomics, and
tess.  But, I hope it can be useful for regression testing core Mesa
reworks.

This required updating the kernel to 5.16.12 to get a more stable boot
process.  That kernel rebuild caused an update of the container with
piglit which that was missed in a previous MR, so we got new xfails in x86
swrast.

Acked-by: Ilia Mirkin <imirkin@alum.mit.edu> (nouveau)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15201>

ci/nouveau: Add nouveau support to the rootfs.

This required updating the kernel to 5.16.12 to get a more stable boot
process.  That kernel rebuild caused an update of the container with
piglit which that was missed in a previous MR, so we got new xfails in x86
swrast.  Also, including modules on arm64 exposed a bug in v3d's
poe-powered.sh rsyncing of modules.

Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15201>

ci: Stop xz-compressing firmware for ramdisks.

This ends up breaking nouveau because the renames break symlinks in the
firmware directory structure.  We don't need it any more since we stopped
doing ramdisks.

Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15201>

ci/bare-metal: Increase maximum retry count for POE boots.

The manual jetson CI job I'm introducing has serious boot reliability
trouble, but also we've seen frequent intermittent failures on bcm where
at least 2 boots don't seem to be enough (#6041).

Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15201>

ci/bare-metal: Drop the BM_POE_USERNAME/PASSWORD env var checks.

They're unused since the transition to SNMP in the rpi test farm.

Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15201>

zink: lower dmod on AMD hardware

this hardware won't return the correct value from dmod instructions,
so lower it to ensure that cts passes

nobody else will ever hit this, so perf isn't an issue and regular fmod
can be left alone

fixes (amd):
KHR-GL46.gpu_shader_fp64.builtin.mod_d*

Fixes: 5fae35fb17d6d89c4fe1d9d5a19d827caf25b9fc ('zink: fix 64bit float shader ops ')

Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15306>

zink: add another radv fail

it looks like this one was erroneously excluded

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15307>

zink: update radv fails

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15307>

venus: add VK_EXT_vertex_attribute_divisor

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15265>

venus: add VK_EXT_shader_stencil_export

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15265>

venus: add VK_EXT_robustness2

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15265>

venus: add VK_EXT_depth_clip_enable

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15265>

venus: add VK_EXT_conservative_rasterization

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15265>

venus: add VK_EXT_shader_demote_to_helper_invocation

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15265>

venus: update venus-protocol headers

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15265>

anv: include Primitive Header in mesh shader per-primitive output

Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15303>

anv: set number of viewports in clip state (mesh)

Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15303>

intel/compiler: mark some variables as per-primitive in FS if they come from MS

Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15303>

intel/compiler: handle ViewportIndex, PrimitiveID and Layer in MUE setup

Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15303>

intel/compiler: inject MUE initialization

Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15303>

intel/compiler: shift mesh urb read/write window when offset is too large

Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15303>

aco: always emit vk_cvt_pkrtz_f16_f32 for nir_op_pack_half_2x16_split

From the VK_KHR_shader_float_controls extension:

    "5) Do any of the “Pack” GLSL.std.450 instructions count as
     conversion instructions and have the rounding mode applied?"

    "RESOLVED: No, only instructions listed in “section 3.32.11.
     Conversion Instructions” of the SPIR-V specification count as
     conversion instructions."

This is also the same logic as the LLVM backend.

No fossils-db changes on Sienna Cichlid.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15301>

docs: improve language in zink article

Turns out, this was not proper use of language!

Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15300>

docs: fixup zink gl 4.3 requirements

The multiViewport feature isn't required for GL 4.3, it's required for
GL 4.1. Technically speaking, we could have just dropped it because we
already list the maxViewports requirement. But it seems better to be
very clear here to me.

Fixes: 29f8f21bff6 ("docs: document zink GL 4.3 requirements")
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15300>

broadcom/compiler: don't always assign r5 if available

Instead, only favor assigning r5 if we have first decided to
assign an accumulator. This helps with assining r5 to short
lived uniforms, favoring accumulator rotation to facilitate
QPU merges.

total instructions in shared programs: 12656164 -> 12628339 (-0.22%)
instructions in affected programs: 5368373 -> 5340548 (-0.52%)
helped: 17420
HURT: 9996

total uniforms in shared programs: 3704776 -> 3704863 (<.01%)
uniforms in affected programs: 12247 -> 12334 (0.71%)
helped: 23
HURT: 78

total max-temps in shared programs: 2153505 -> 2152684 (-0.04%)
max-temps in affected programs: 26468 -> 25647 (-3.10%)
helped: 569
HURT: 328

total fills in shared programs: 4656 -> 4657 (0.02%)
fills in affected programs: 43 -> 44 (2.33%)
helped: 0
HURT: 1

total sfu-stalls in shared programs: 34728 -> 34403 (-0.94%)
sfu-stalls in affected programs: 3411 -> 3086 (-9.53%)
helped: 842
HURT: 534

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15276>

broadcom/compiler: add comment on why we don't use r5 with ldunifa

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15276>

broadcom/compiler: adjust register threshold for 2-thread compiles

We have twice the registers in this case so it makes sense to double
this as well. While this causes slight regressions in shader-db
stats (due to additional register pressure), it helps us hide latency
of memory reads better on 2-thread compiles, where the thread switch
mechanism will be less effective. This shows a ~3% performance
improvement on the UE4 SunTemple demo.

total instructions in shared programs: 12642413 -> 12656164 (0.11%)
instructions in affected programs: 2272652 -> 2286403 (0.61%)
helped: 2924
HURT: 3389

total uniforms in shared programs: 3703861 -> 3704776 (0.02%)
uniforms in affected programs: 213729 -> 214644 (0.43%)
helped: 823
HURT: 1272

total max-temps in shared programs: 2150686 -> 2153505 (0.13%)
max-temps in affected programs: 191332 -> 194151 (1.47%)
helped: 1900
HURT: 1891

total spills in shared programs: 3255 -> 3274 (0.58%)
spills in affected programs: 166 -> 185 (11.45%)
helped: 3
HURT: 6

total fills in shared programs: 4630 -> 4656 (0.56%)
fills in affected programs: 367 -> 393 (7.08%)
helped: 7
HURT: 15

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15276>

broadcom/compiler: add a strategy to disable scheduling of general TMU reads

This can add quite a bit of register pressure so it makes sense to disable it
to prevent us from dropping to 2 threads or increase spills:

total instructions in shared programs: 12672813 -> 12642413 (-0.24%)
instructions in affected programs: 256721 -> 226321 (-11.84%)
helped: 719
HURT: 77

total threads in shared programs: 415534 -> 416322 (0.19%)
threads in affected programs: 788 -> 1576 (100.00%)
helped: 394
HURT: 0

total uniforms in shared programs: 3711370 -> 3703861 (-0.20%)
uniforms in affected programs: 28859 -> 21350 (-26.02%)
helped: 204
HURT: 455

total max-temps in shared programs: 2159439 -> 2150686 (-0.41%)
max-temps in affected programs: 32945 -> 24192 (-26.57%)
helped: 585
HURT: 47

total spills in shared programs: 5966 -> 3255 (-45.44%)
spills in affected programs: 2933 -> 222 (-92.43%)
helped: 192
HURT: 4

total fills in shared programs: 9328 -> 4630 (-50.36%)
fills in affected programs: 5184 -> 486 (-90.62%)
helped: 196
HURT: 0

Compared to the stats before adding scheduling of non-filtered
memory reads we see we that we have now gotten back all that was
lost and then some:

total instructions in shared programs: 12663186 -> 12642413 (-0.16%)
instructions in affected programs: 2051803 -> 2031030 (-1.01%)
helped: 4885
HURT: 3338

total threads in shared programs: 415870 -> 416322 (0.11%)
threads in affected programs: 896 -> 1348 (50.45%)
helped: 300
HURT: 74

total uniforms in shared programs: 3711629 -> 3703861 (-0.21%)
uniforms in affected programs: 158766 -> 150998 (-4.89%)
helped: 1973
HURT: 499

total max-temps in shared programs: 2138857 -> 2150686 (0.55%)
max-temps in affected programs: 177920 -> 189749 (6.65%)
helped: 2666
HURT: 2035

total spills in shared programs: 3860 -> 3255 (-15.67%)
spills in affected programs: 2653 -> 2048 (-22.80%)
helped: 77
HURT: 21

total fills in shared programs: 5573 -> 4630 (-16.92%)
fills in affected programs: 3839 -> 2896 (-24.56%)
helped: 81
HURT: 15

total sfu-stalls in shared programs: 39583 -> 38154 (-3.61%)
sfu-stalls in affected programs: 8993 -> 7564 (-15.89%)
helped: 1808
HURT: 1038

total nops in shared programs: 324894 -> 323685 (-0.37%)
nops in affected programs: 30362 -> 29153 (-3.98%)
helped: 2513
HURT: 2077

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15276>

broadcom/compiler: define v3d-specific delays for NIR instructions

We do a few changes over NIR's defaults:

1. Lower delay for texture reads. Empirically, we don't observe any
   benefits with delays over 50 and since this delay value is still
   used by the scheduler in the "favor register pressure" case it is
   benefitial to avoid overestimating it too much.

2. Adjust delay for non-filtered TMU reads to the delay selected for
   texture reads.

3. In our case, UBO reads from dynamically uniform addresses don't
   use the TMU and have a latency of 1 instruction in the best case
   scenario or 4 at worse, so we go with 1 so we don't try to move
   this early.

This helps us get back some of what we lost when updating the
default scheduler configuration to add a delay for non-filtered
memory reads:

total instructions in shared programs: 13126587 -> 12671765 (-3.46%)
instructions in affected programs: 3764097 -> 3309275 (-12.08%)
helped: 14664
HURT: 4244

total threads in shared programs: 407208 -> 415522 (2.04%)
threads in affected programs: 8716 -> 17030 (95.39%)
helped: 4224
HURT: 67

total uniforms in shared programs: 3812698 -> 3711224 (-2.66%)
uniforms in affected programs: 335170 -> 233696 (-30.28%)
helped: 2816
HURT: 3551

total max-temps in shared programs: 2318430 -> 2159345 (-6.86%)
max-temps in affected programs: 539991 -> 380906 (-29.46%)
helped: 13173
HURT: 1440

total spills in shared programs: 49086 -> 5966 (-87.85%)
spills in affected programs: 48306 -> 5186 (-89.26%)
helped: 1655
HURT: 28

total fills in shared programs: 55810 -> 9328 (-83.29%)
fills in affected programs: 54821 -> 8339 (-84.79%)
helped: 1659
HURT: 22

LOST:   0
GAINED: 3

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15276>

nir/schedule: allow drivers to decide about instruction latency

On V3D reading UBOs from uniform addresses uses a more efficient
mechanism with lower latency. On other platforms there may be
simular scenarios.

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15276>

nir/schedule: use larger delay for non-filtered memory reads

This has been pending for a long time. It is not very consistent to
add a significant delay for textures and not do it for UBOs, etc
The reason we have not been doing this so far is the accumulated effect
on register pressure for V3D as shown by shader-db results below, but
from the point of view of a generic scheduler it makes sense to do this.

Later patches will address V3D specific issues with register pressure
derived from this by letting the driver control its instruction delay
settings.

total instructions in shared programs: 12662138 -> 13126587 (3.67%)
instructions in affected programs: 1813091 -> 2277540 (25.62%)
helped: 2410
HURT: 10499

total threads in shared programs: 415858 -> 407208 (-2.08%)
threads in affected programs: 17348 -> 8698 (-49.86%)
helped: 8
HURT: 4333

total uniforms in shared programs: 3711483 -> 3812698 (2.73%)
uniforms in affected programs: 128012 -> 229227 (79.07%)
helped: 3474
HURT: 2143

total max-temps in shared programs: 2138763 -> 2318430 (8.40%)
max-temps in affected programs: 318780 -> 498447 (56.36%)
helped: 588
HURT: 11997

total spills in shared programs: 3860 -> 49086 (1171.66%)
spills in affected programs: 709 -> 45935 (6378.84%)
helped: 23
HURT: 1595

total fills in shared programs: 5573 -> 55810 (901.44%)
fills in affected programs: 1067 -> 51304 (4708.25%)
helped: 23
HURT: 1595

LOST:   3
GAINED: 0

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15276>

nir/schedule: handle nir_intrinsic_group_memory_barrier

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15276>

nir/schedule: fix handling of generic memory barrier

We can get a generic nir_intrinsic_memory_barrier to represent a
barrier involving multiple semantics (instead of getting individual
specific barriers for each semantic). This means that we need to
consider these as potentially affecting shared memory access as well.

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15276>

broadcom/compiler: stop moving UBO loads before NIR scheduling

This doesn't have any significant impact shader-db stats and would
reduce our capacity to hide latency from the loads, so it is probably
undesirable:

total instructions in shared programs: 12663189 -> 12663186 (<.01%)
instructions in affected programs: 4222 -> 4219 (-0.07%)
helped: 9
HURT: 4

total uniforms in shared programs: 3711624 -> 3711629 (<.01%)
uniforms in affected programs: 186 -> 191 (2.69%)
helped: 0
HURT: 2

total max-temps in shared programs: 2138822 -> 2138857 (<.01%)
max-temps in affected programs: 569 -> 604 (6.15%)
helped: 1
HURT: 9

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15276>

lavapipe: set non-zero device/driver uuid

Closes #5875

Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15230>

turnip: Make autotuner work with reusable command buffers

To achieve it each command buffer now has its own GPU memory.

However the BOs usage by autotuner is not optimal, the ideal
pattern would be to use some memory pool to suballocate small
GPU memory chunks, since most command buffers have only a few
renderpasses.

Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5990

Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14996>

virgl: Add a few more formats to the format table

These formats are used by the piglit

   arb_texture_buffer_object-formats fs arb

Adding them here keeps the piglit from crashing, but most of the related
tests don't pass.

Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13645>

intel: Use 3DSTATE_BINDING_TABLE_POOL_ALLOC exclusively on Gfx11+

On Icelake and later, we can use a new 3DSTATE_BINDING_TABLE_POOL_ALLOC
command to update the location of the binder (buffer containing binding
table entries), rather than having to move Surface State Base Address
via a STATE_BASE_ADDRESS command.  This has less stalling and also means
our surface addresses can remain relative to a fixed 4GB address range,
meaning we don't have to re-stream them any time the binder changes.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14507>

intel: Limit Wa_1607854226 to Gfx12.0 only

This workaround is needed on all Gfx12.0 parts, but doesn't appear to be
necessary on XeHP.  The other drivers do not appear to be applying this
workaround on those parts.  As further evidence, we accidentally added
the 3DSTATE_BINDING_TABLE_POOL_ALLOC commands after switching back to
GPGPU mode, which would be an incorrect way to implement the workaround,
and things seem to be working.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14507>

iris: Rename surface_base_address to binder_address in a few places

On Gfx11+, we're going to stop changing Surface State Base Address
and instead start changing the Binding Table Pool address instead.

So, rename a few things to track the last binder address, which is
what we're actually changing, regardless of how we program it.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14507>

iris: Use more efficient binding table pointer formats on Icelake+.

Skylake and older use a 15:5 binding table pointer format, which means
our binder can be at most 64kB in size.  Each binding table within the
binder must be aligned to 32B.

XeHP uses a new 20:5 binding table format, which allows us to increase
the binder size to 1MB while retaining the nice 32B alignment.  Larger
binders mean fewer stalls as we update the base address for the binder.

Icelake and Tigerlake can either use the 15:5 format or an 18:8 format.
18:8 mode requires the base of each binding table to be aligned to 256B
instead of 32B, but it gives us a maximum binder size of 512kB.

We can store 64 binding table entries in a 256B chunk (256B / 4B = 64),
but only 8 entries in a 32B chunk (32B / 4B = 8).  Assuming that most
binding tables have fewer than 64 entries, this means that with the 18:8
format, we're likely to be able to fit 2048 (512KB / 256B) tables into a
a buffer before needing to allocate a new one and stall.

Technically, the old format could also store 2048 binding tables per
buffer as well (64KB / 32B = 2048).  However, tables that needed more
than 8 entries would need multiple 32B chunks.  A single table would
take multiple aligned chunks, while with the larger 256B format, it
could fit in a single one.

This cuts binder resets by 6.3% on a Shadow of Mordor benchmark trace.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14507>

blorp: Add a binding_table_offset_to_pointer helper

On Gen11+, we have a feature that requires us to shift binding table
offsets by 3.  This adds a helper which gives the driver a hook to do
this if it so chooses.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14507>

gallium/tc: zero alloc transfers

Otherwise this causes trouble with unitialized memory, eg with:
   struct si_transfer {
      struct threaded_transfer b;
      struct si_resource *staging;
   };
'staging' will not be initialized and this causes #6109.

Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6109

Cc: mesa-stable
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15298>

util/slab: add slab_zalloc

A a variant that clears the allocated object to 0.

Cc: mesa-stable
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15298>

tu: Refactor VS DECODE/DEST to be emitted in two pkt4

Refactor to emit VFD_DECODE and VFD_DEST_CNTL in two packets
regardless of attribute count.

Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14584>

mesa/st: make export_point_size shader key clobber existing psiz

this is necessary to upload the API value using the uniform constant

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15228>

mesa/st: check max output components for adding pointsize during precompile

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15228>

mesa/st: count FF shaders as needing psiz export for precompile

this is consistent with logic for regular compiles

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15228>

mesa/st: precompile with API pointsize only if the shader doesn't have pointsize

this is a more accurate hint, and maintains the existing behavior given
subsequent changes to this area

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15228>

mesa/st: simplify pointsize precompile conditional

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15228>

mesa/st: simplify pointsize shader update conditional

ES contexts have no API toggle for this, so it will never be flagged

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15228>

mesa: always set PointSizeEnabled for API_OPENGLES2

this is implicit, so make it explicit

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15228>

mesa/st: only add pointsize output if it doesn't exceed max component limit

fixes (zink-nvidia):
dEQP-GLES31.functional.geometry_shading.basic*

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15228>

nir/gather_info: check copy_deref instrs for writing outputs

this is a valid way to write an output even though it usually gets rewritten
to some other instruction later on

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15228>

mesa/st: conditionally add pointsize outputs to ES tess/geom shaders

if the driver requires this value to be set, add it if the shader doesn't
use the ext to allow exporting it

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15228>

mesa/st: add a gl_program struct flag to skip psiz exports for xfb

if this output did not exist in the original shader,
then it must not be exported in xfb

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15228>

glsl: store OES/EXT point_size extension enablement to shader struct

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15228>

panvk: Implement vkCmdDispatch()

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15248>

panvk: Add support for storage image

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15248>