zink: NV_compute_shader_derivatives

nothing complicated here

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

zink: correct sparse bo mem_type_idx placement

VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT = 0x01 has been incidently the
correct memory type index, but isn't guaranteed to be, which is why it
hasn't caused issues yet

Fixes: f9515d93 ("zink: allocate/place memory using memoryTypeIndex directly")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20264>

zink: trival renames heap_idx -> memoryTypeIndex

Trival renames to correctly identify vulkan memory type indices aren't
the same as zink heaps

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

zink: zink_heap isn't 1-to-1 with memoryTypeIndex

Clarify the relationship between zink heaps and vulkan memory type
indices, and resolve the issues from mixing the two up.

Closes: #7588, #7813
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20264>

meson: Use feature option methods for xmlconfig

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for shared-llvm

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for egl

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for zstd

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for xlib-lease

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for power8

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for lmsensors

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for libunwind

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for valgrind

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for llvm

Still not as awesome as it should be, but an improvement over what we had
before.

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for gbm

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for gles2

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for gles1

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for shared-glapi

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for shader_cache

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for gallium-xa

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for gallium-va

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for gallium-vdpau

Which we can use with the require method, and use the feature itself
as the require argument to dependency call. All of this results in less
code

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: use a feature option for dri3

This removes the deprecated 'true' and 'false' options, and uses a meson
feature, requiring significantly less code.

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: drop meson < 0.54 workaround

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: replace uses of ExternalProgram.path with .full_path

The former is deprecated

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: replace has_exe_wrapper with can_run_host_binaries

The former is a deprecated alias for the latter, which more accurately
describes what the function does.

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

meson: bump minimum required version to meson 0.59

This gives us some utility methods for feature options, allowing even
simpler code. We can replace something like:
```meson
_opt = get_option('opt')
if _opt.auto()
  opt = host_machine.system() != 'windows'
else
  opt = opt.enabled()
endif
```
with
```meson
opt = get_option('opt') \
    .disable_auto_if(host_machine.system() != 'windows') \
    .allowed()
```

Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20409>

zink: handle modifier nplanes queries correctly for planar formats

this just returns the number of planes in the base format as a default, which
matches the behavior of other drivers

cc: mesa-stable

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

zink: store drm format as internal_format for imported resources

internal_format is the "real" format of a resource, and the "real" format
of imported resources is the external-facing format, not the pipe format

this ensures the correct format is available for internal ops, such as nplanes queries

Fixes: 2e2775c11b0 ("zink: fix PIPE_RESOURCE_PARAM_NPLANES with format modifier")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20753>

radv: rename ac_surf_nbc_view::max_mip to num_levels

For readability.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20761>

radv: fix creating BC image views when the base layer is > 0

When the base array layer of the image view is > 0, addrlib computes
the offset (in HwlComputeSubResourceOffsetForSwizzlePattern) which is
then added to the base VA in RADV. But if the driver doesn't reset
the base array layer, the hw will compute incorrect addressing
(ie. base array will be added twice). This also matches AMDVLK.

This fixes a VM fault followed by a GPU hang on RDNA2 when trying
to join a multiplayer game with medium settings in Halo Infinite.

Fixes: 98ba1e0d817 ("radv: Fix mipmap views on GFX10+")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20761>

radv: fix buffer to image copies with BC views on the graphics queue

The color surface descriptor needs to be adjusted, otherwise addressing
is wrong.

Fixes tests performed on the graphics queue from
dEQP-VK.api.copy_and_blit.*.image_to_buffer.2d_images.mip_copies_*.

Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7900
Fixes: 98ba1e0d817 ("radv: Fix mipmap views on GFX10+")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20761>

radv: fix setting MAX_MIP for BC views

MAX_MIP should always be the number of levels minus one from the hw
perspective.

This doesn't fix anything known.

Fixes: 98ba1e0d817 ("radv: Fix mipmap views on GFX10+")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20761>

mesa/st: drop unused param

Signed-off-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20772>

glthread: fix glArrayElement handling

This must be marshalled synchronously or the attrib pointers' content
might change by the time we use them.

Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8068
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20748>

vbo: lower VBO_SAVE_BUFFER_SIZE to avoid large VRAM usage

The ideal case for performance is to have a single buffer for
all display list. The caveat is that large buffers are less
likely to be freed because they're refcounted: it only takes
1 user (diplay list) to keep it in VRAM.

This lowers VRAM usage when replaying the trace attached
of the trace attached to !6140 from 5.5 GB to about 1.8 GB.

Viewperf snx performance isn't affected.

Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6140
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20748>

vbo: remove bogus assert

grow_vertex_storage may call wrap_filled_vertex, which will
trigger the assert incorrectly because the new size will be
smaller than 'new_size' but it's correct because
'vertex_store->used' has been reset to 0.

Fixes: a08baaff976 ("vbo/dlist: fix indentation in vbo_save_api.c")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20748>

nir/lower_io: fix bounds checking for 64bit_bounded_global

If the offset is negative like it's the case in

dEQP-VK.robustness.robustness2.bind.notemplate.r32i.unroll.volatile.storage_buffer_dynamic.readwrite.no_fmt_qual.len_256.samples_1.1d.comp

we end up passing the bounds checking condition because it's using
signed integers.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Suggested-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Cc: mesa-stable
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20762>

intel/compiler: Use more symbolic source names in components_read()

Rather than hardcoding source 1, source 2, etc.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20604>

intel/compiler: Drop dest checking in atomic code

NIR atomic operation intrinsics all have destinations.  This is just
copy and pasted from other generic intrinsic handling where that may
or may not be the case.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20604>

intel/compiler: Delete all the A64 atomic variants for type sizes

These are handled identically in almost all cases.  There is one place
in the legacy surface lowering that was obtaining the bitsize from the
opcode, but the LSC-based lowering uses (type_sz(inst->dst.type) * 8)
for that and works just fine.  If we just do that in the legacy lowering
too, then we don't need this plethora of opcodes.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20604>

intel/compiler: Combine nir_emit_{ssbo,shared}_atomic into one helper

These are basically identical save for:
- shared has surface hardcoded to SLM rather than an SSBO index
- shared has to handle adding the 'base' const_index (SSBO have none)
- the NIR source index for data is shifted by one

It's not worth copy and pasting the entire function for this.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20604>

intel/compiler: Delete fs_visitor::nir_emit_{ssbo,shared}_atomic_float()

These are now basically identical to their non-float counterparts.  The
only thing that differed was the opcode checking to determine which
operands existed.  Now that we have a unified opcode enum and a helper
for the number of data operands, we can just use that.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20604>

intel/compiler: Drop redundant 32-bit expansion for shared float atomics

We already expanded data to 32-bit a few lines earlier, so this is just
redundantly doing it a second time.

Fixes: 43169dbbe5f ("intel/compiler: Support 16 bit float ops")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20604>

intel/compiler: Eliminate SHADER_OPCODE_UNTYPED_ATOMIC_FLOAT

The only reason for the separate opcode was because of the overlapping
BRW_AOP_* enums, making it impossible to tell whether a particular AOP
was the integer or float operation.  Now that we use the lsc_opcode
enums, we can just have the legacy lowering inspect the opcode and
select the right descriptor.  No need for a separate opcode.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20604>

intel/compiler: Add an lsc_op_num_data_values() helper

There are a number of places that need to know how many operands an LSC
atomic takes (0 for inc/dec, 1 for most things, 2 for cmpxchg).  We can
add a helper for that and eliminate some code (with more to come).

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20604>

intel/compiler: Use LSC opcode enum rather than legacy BRW_AOPs

This gets our logical atomic messages using the lsc_opcode enum rather
than the legacy BRW_AOP_* defines.  We have to translate one way or
another, and using the modern set makes sense going forward.

One advantage is that the lsc_opcode encoding has opcodes for both
integer and floating point atomics in the same enum, whereas the legacy
encoding used overlapping values (BRW_AOP_AND == 1 == BRW_AOP_FMAX),
which made it impossible to handle both sensibly in common code.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20604>

intel/compiler: Move atomic op translation into emit_*_atomic()

There's no need to pass both the intrinsic and an opcode computed from
that same intrinsic.  Just do it in the functions themselves.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20604>

anv: fix generated indirect draw shader stats checks

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: c950fe97a0 ("anv: implement generated (indexed) indirect draws")
Tested-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20776>

intel/hasvk: remove some stale comments, wa was removed

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20783>

intel/fs/gfx12+: Drop redundant handling of SHADER_OPCODE_BROADCAST in exec pipe inference.

Commit c80c0ed9433035c2f4dc6 introduced handling of
SHADER_OPCODE_BROADCAST into inferred_exec_pipe(), but it was already
being handled, drop the redundant handling.  Shouldn't lead to any
functional changes.

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

intel/eu/gfx12+: Implement decoding of 64-bit immediates.

C.f. a12533f2ce2e5a4aeae0f1fc8d759de73bdb6e2d.  The corresponding
change for the decoding path was never implemented so the disassembler
was printing incorrect immediate values.

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

intel/disasm/gfx12+: Fix print out of non-existing condmod field with 64-bit immediate.

The conditional mode field doesn't exist for instructions with a
64-bit immediate, so this would currently print garbage.

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

intel/disasm/gfx12+: Use helper instead of hardcoded bit access for 64-bit immediates.

So we don't have to duplicate code to handle differences in the
encoding of 64-bit immediates across platforms.

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

intel/fs/gfx12: Ensure that prior reads have executed before barrier with acquire semantics.

This avoids a violation of the Vulkan memory model that was leading to
intermittent failures of at least 8k test-cases of the Vulkan CTS
(within the group dEQP-VK.memory_model.*) on TGL and DG2 platforms.
In theory the issue may be reproducible on earlier platforms like IVB
and ICL, but the SYNC.ALLWR instruction is not available on those
platforms so a different (likely costlier) fix will be needed.

The issue occurs within the sequence we emit for a NIR memory barrier
with acquire semantics requiring the synchronization of multiple
caches, e.g. in pseudocode for a barrier involving the TGM and UGM
caches on DG2:

 x <- load.ugm // Atomic read sequenced-before the barrier
 y <- fence.ugm
 z <- fence.tgm
 wait(y, z)
 w <- load.tgm // Read sequenced-after the barrier

In the example we must provide the guarantee that the memory load for
x is completed before the one for w, however this ordering can be
reversed with the intervention of a concurrent thread, since the UGM
fence will block on the prior UGM load and potentially take a long
time, while the TGM fence may complete and invalidate the TGM cache
immediately, so a concurrent thread could pollute the TGM cache with
stale contents for the w location *before* the UGM load has completed,
leading to an inversion of the expected memory ordering.

v2: Apply the workaround regardless of whether the NIR barrier
    intrinsic specifies multiple storage classes or a single one,
    since an acquire barrier is required to order subsequent requests
    relative to previous atomic requests of unknown storage class not
    necessarily specified by the memory scope information of the
    intrinsic.

Cc: mesa-stable
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20690>

nir/lower_blend: No-op nir_color_mask if no mask

In this usual case, do a quick check to avoid generating 5 useless instructions
(mov/vec4 instructions). They'll get copypropped but that creates more work for
the optimizer and nir/lower_blend runs in a hot variant path on both Asahi and
Panfrost.

Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20016>

nir/lower_blend: Handle undefs in stores

nir/lower_blend asserts:

   assert(nir_intrinsic_write_mask(store) ==
          nir_component_mask(store->num_components));

For the special blend shaders used in Panfrost, this holds. But for arbitrary
shaders coming out of GLSL-to-NIR (as used with Asahi), this does not hold. In
particular, after nir_opt_undef runs, undefined components can be trimmed.
Concretely, if we have the shader:

    gl_FragColor.xyz = foo;

Then this becomes in NIR

   gl_FragColor = vec4(foo.xyz, undef);

and then opt_undef will give the store_deref a wrmask of xyz but 4 components.
Then lower_blend asserts out.

Found in a gfxbench shader on asahi.

Closes: #6982
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20016>

nir/lower_blend: Don't do logic ops on pure float

Per the spec.

Fixes arb_color_buffer_float-render on both Panfrost and Asahi (before/after
reproduced on Mali-T860 and AGX G13 respectively). Without that patch, that test
fails the assertion:

arb_color_buffer_float-render: ../src/compiler/nir/nir_lower_blend.c:259: nir_blend_logicop: Assertion `util_format_is_pure_integer(format)' failed.

Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20016>

nir/lower_blend: Avoid useless iand with logic ops

The upper bits start correctly, there's no need to clear them as long as we keep
them zero'ed by using ixor with a valid bit mask instead of inot.

Makes the code generated for logic op slightly less ridiculous. I'm joking. It's
still ridiculous but I'm not in the mood to fix up the Midgard compiler and it's
just a little ALU for a feature almost nothing uses.

Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20016>

nir/lower_blend: Fix SNORM logic ops

We need to sign extend. Incidentally this means the iand above is useless for
SNORM.

Fixes arb_color_buffer_float-render with GL_RGBA8_SNORM.

Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20016>

nir/lower_blend: Clamp blend factors

Particularly constant colours, but also (more obscurely) SNORM.

Fixes arb_color_buffer_float-render with SNORM framebuffers. Issue affects both
Asahi and Panfrost (the latter after we start advertising EXT_render_snorm).

v2: Check the blend factor to avoid unnecessary clamps. This avoids regressing
blend shader code quality on Panfrost.

Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com> [v1]
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20016>

nir/lower_blend: Fix alpha=1 for RGBX format

In this case we have 4 components but the value of the fourth component
is undefined. Apply the fixup we already have.

Fixes
dEQP-GLES3.functional.draw_buffers_indexed.random.max_implementation_draw_buffers.0
on Asahi. That test blend with DST_ALPHA with its RGB565 attachment,
which is fine if RGB565 is preserved, but Asahi is demoting that
format to RGBX8 which means -- after lowering the tilebuffer access --
we blend with an ssa_undef.

Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20016>

d3d12: Add support for Xbox GDK.

The big items in this patch:
- New screen file, to support the Xbox "windowing" system
- Lots of small macros/changes to support the Xbox D3D12 API without messing with the Win32 path too much
- A few changes to avoid requiring COM interfaces (the big one was QueryInterface which is unsupported)

Co-authored-by: Ethan Lee <flibitijibibo@gmail.com>
Co-authored-by: David Jacewicz <david.jacewicz@protonmail.com>
Co-authored-by: tieuchanlong <tieuchanlong@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19022>

wgl: Add support for Xbox GDK.

This patch is comprised of three main changes:
- Add a "shim" for GDI, since Xbox doesn't expose this library
- New framebuffer file, to support the Xbox "windowing" system
- Implement a custom WndProc hook for Xbox, since SetWindowsHookEx isn't supported either

Other than that, it's similar to the previous Xbox commits which mostly disable Win32-specific logic.

Co-authored-by: Ethan Lee <flibitijibibo@gmail.com>
Co-authored-by: David Jacewicz <david.jacewicz@protonmail.com>
Co-authored-by: tieuchanlong <tieuchanlong@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19022>

dxil_validator: Add support for Xbox GDK.

In addition to the DLL names being different, we don't have to do the versioning work since we don't have to fuss with known bad versions (for example).

Co-authored-by: Ethan Lee <flibitijibibo@gmail.com>
Co-authored-by: David Jacewicz <david.jacewicz@protonmail.com>
Co-authored-by: tieuchanlong <tieuchanlong@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19022>

util: Add #ifdefs for Xbox GDK support.

For the most part this just disables debug/console code, with the minor exception of u_memstream_open.

Co-authored-by: Ethan Lee <flibitijibibo@gmail.com>
Co-authored-by: David Jacewicz <david.jacewicz@protonmail.com>
Co-authored-by: tieuchanlong <tieuchanlong@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19022>

futex: Change INT_MAX to INT32_MAX.

Some platforms (i.e. Xbox) don't have INT_MAX, so use the stdint constant instead.

Co-authored-by: Ethan Lee <flibitijibibo@gmail.com>
Co-authored-by: David Jacewicz <david.jacewicz@protonmail.com>
Co-authored-by: tieuchanlong <tieuchanlong@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19022>

anv: use vk_realloc for the anv_execbuf arrays

Three reasons for that:

0. The operation we're doing here is actually a reallocation.

1. The newer code is, IMHO, easier to read.

2. Realloc has this property where sometimes, when possible, it will
   expand your array without moving it somewhere else, so it doesn't
   need to copy the memory contents, returning the original pointer
   back to you. I did some analysis and while that case is not common,
   it does happen sometimes in real world applications (I could see it
   happening in Shootergame and Aztec Ruins, but not Dota 2), so we're
   able to save a few CPU cycles.

v2: Rebase.

Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20703>

anv: rename anv_execbuf->array_length to bo_array_length

Because this is counting the array length of the things related to the
BOs, just like syncobj_array_length is counting the array length of
the things related to syncobjs.

v2: Rebase.

Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20703>

anv: run buf_finish() if add_bo() fails during execute_simple_batch()

This is the only code path where we don't run anv_execbuf_finish() in
case anv_execbuf_add_bo() fails. While there is not a bug in the
current tree, I recently made an (uncommitted) modification that
started leaking memory and made me realize the lack of cleanup here.
If we had anv_execbuf_finish() being called upon error like we're
going to have after this patch my modification wouldn't have caused
the memory leak.

I think it's much safer and future-proof if we're able to operate
under the assumption that whatever is allocated and set to anv_execbuf
will be dealt with upon failure of anything else related to it, so
functions that fail should only be required to free pointers not yet
assigned to anv_execbuf.

The dEQP-VK 'alloc_callback_fail' tests should exercise this code
path. The one I was specifically using here is:
  dEQP-VK.api.object_management.alloc_callback_fail.device_group

v2: Rebase.

Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20703>

anv: check the return value of anv_execbuf_add_bo_bitset()

Because anv_execbuf_add_bo_bitset() calls anv_execbuf_add_bo(), which
can fail if its memory allocations fail.

I have seen dEQP tests exercising memory allocation failures during
anv_execbuf_add_bo(), but I don't think the path coming from
add_bo_biset() was specifically exercised. Anyway, add the error check
just in case.

v2: Rebase.

Cc: mesa-stable
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20703>

anv: don't leave undefined values in exec->syncobj_values

In anv_execbuf_add_syncobj(), we try to not create or use
exec->syncobj_values if we don't need to. But when we figure we're
going to need it (i.e., when timeline_value is not zero), then we
create exec->syncobj_values with vk_zalloc, which means every previous
value is set to zero, as it should be. This is all correct.

The problem starts when we add a 16th element. In this case we double
exec->syncobj_array_length and realloc the buffer by using vk_alloc
and copying the old array to the new one. After that, we write the
timeline_value to the array only if it's not zero, and that's the
problem: since we just used vkalloc and memcpy, we don't have any
guarantees that the new array will be zero after the 16th element, and
if timeline_value is zero we write nothing to that position.

Once we start using exec->syncobj_values we have to commit to using
it, so the "if (timeline_value)" check near the end of the function
has to be changed to "if (exec->syncobj_values)", so we actually set
elements after the 16th to zero when they need to be zero.  Another
approach to fix this would be to memset the new elements once we
double syncobj_array_length.

In practice, I couldn't find any application or deqp test that used
more than 3 elements in exec->syncobj_array_length, and we need more
than 16 elements in order to be able to reproduce the bug, so I'm not
aware of any real-world bug that goes away with this patch. This issue
was found while reading code.

If we craft a little Vulkan program that submits a ton of timeline and
binary semaphores on vkQueueSubmit, then waits for them, we get the
following error without this patch:

MESA: error: ../../src/intel/vulkan/anv_batch_chain.c:1910: execbuf2 failed: Invalid argument (VK_ERROR_DEVICE_LOST)

v2: Rebase.

Cc: mesa-stable
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20703>

docs/panvk: VK_KHR_descriptor_update_template

Implemented in !14780

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

v3dv: remove unused clamp_to_transparent_black_border property

Commit e07c5467 ("v3dv/format: use XYZ1 swizzle for three-component formats")
removes the only code that handled the clamp_to_transparent_black_border
variable. Therefore, the variable can be deleted, as it is not currently
being used.

Fixes: e07c5467 ("v3dv/format: use XYZ1 swizzle for three-component formats")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20746>

Revert "nouveau/ci: temporary disable gk20a-gles"

This reverts commit 8a1a3a31dacf9369f81cb5336acdbdd35dd8b520.  The farm
should be back up, and I swear nginx startup is fixed for real this time.

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

ci/intel: fully utilize asus-cx9400-volteer

We have 15 machines:
 * 12 for anv-tgl-vk
 * 1 for intel-tgl-skqp
 * 2 for zink-anv-tgl and zink-anv-tgl-traces

Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20754>

ci/anv: add multiple fails uncovered by change of sharding

Another fail discovered by changing number of parallel jobs.

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

Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20754>

gallum/asahi: fix memory leak in agx_resource_from_handle

Missing FREE(rsc)

Apply 1 suggestion(s) to 1 file(s)

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

nir/divergence: add missing RT intrinsinc handling

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20763>

mesa: Set info.separate_shader for ARB programs

ARB programs are logically separate, and Mesa will happily mix and match them.
We need to alert backends of this fact, by setting nir->info.separate_shader.
Otherwise, backends may link shaders invalidly.

Fixes fp-abs-01 on Bifrost. (We don't use separate_shader for anything on
Valhall, so the issue doesn't appear there.)

Compare 151aa19c215 ("ttn: Set nir->info.separate_shader"), which fixed a
similar issue with TGSI.

Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20688>

ci: Add some new folks to the restricted-traces access list.

They should now get pre-merge gated on the restricted traces passing.

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

r300: remove backend negative addressing emulation

This is now handled in ntt.

Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20672>

r300: set ubo_vec4_max ntt option properly

Besides making sure we don't overflow our reg index, this also prevents
constant folding resulting in negative relative offset in nir_opt_offsets.

Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20672>

ntt: pass ubo_vec4_max nir_opt_offsets flag through ntt options

This will be used by the r300 driver in the next commit.

Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20672>

tool/pps: Fix 32-bit build issue with format string

Fixes a 32-bit build issue with Perfetto enabled.
Move the printf format specifier to use PRIx64 which
will be consistent regardless of the build type.

Signed-Off By: Isaac Bosompem <mrisaacb@google.com>

Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20732>

d3d12: Lower minimum supported Shader Model to 6.0

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

lima: fix memory leak related to u_transfer_helper_create()

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x7fb6224340 in calloc (/usr/lib64/libasan.so.6.0.0+0xa4340)
    #1 0x7facfdd5a0 in u_transfer_helper_create ../src/gallium/auxiliary/util/u_transfer_helper.c:580
    #2 0x7facf2e09c in lima_resource_screen_init ../src/gallium/drivers/lima/lima_resource.c:935
    #3 0x7facf23af4 in lima_screen_create ../src/gallium/drivers/lima/lima_screen.c:746
    #4 0x7fac83ed30 in kmsro_drm_screen_create ../src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c:124

Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20764>

pvr: add support for tile buffer output clear

Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20742>

pvr: fix uses_tile_buffers in clear color attachment

Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20742>

radeonsi/sqtt: implement offset workaround for gfx11

Based on PAL and Samuel's code from !20338.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20529>

radeonsi/sqtt: update registers for gfx11

Based on registers delta and PAL.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20529>

radeonsi/sqtt: disable SE1+ on GFX11

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20529>

radeonsi/sqtt: don't read results for disabled SEs

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20529>

ac: add TC_OP_ATOMIC_SUB_32

This will be used by SQTT to implement a workaround on GFX11

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20529>

v3dv: enable shaderStorageImageReadWithoutFormat

Note that as we are enabling the feature, we need to set the
VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR for any format
that supports STORAGE_IMAGE_BIT, from spec:

   "An implementation that supports
   VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT for any format from the given
   list of formats and supports shaderStorageImageReadWithoutFormat
   must support VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT
   for that same format if Vulkan 1.3 or the
   VK_KHR_format_feature_flags2 extension is supported."

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20744>

broadcom/compiler: treat PIPE_FORMAT_NONE as 32-bit formats for output type

Needed to support Vulkan feature shaderStorageImageReadWithoutFormat.

With that enabled we could receive a NONE format on a load image. For
those we treat them as 32-bit formats, that would mean that the
lowering would not need to do any format-specific unpacking.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20744>

broadcom/compiler: v3d_nir_lower_txf_ms doesn't need v3d_compile

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20744>

intel/blorp: Lower base_workgroup_id to zero

We don't use a base workgroup ID for BLOCS.  It needs to be lowered, or
else we'll assert fail when compiling the compute shader.

(Note for stable: this patch doesn't fix a bug in 4abdecce226
specifically, but rather is a missing patch that needed to go along with
the rest of MR 20068, on whichever branches it exists on.)

Fixes: 4abdecce226 ("iris: Lower load_base_workgroup_id to zero")
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20750>

freedreno: add support for markers.

Signed-off-by: amber@igalia.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20727>

util/u_trace: pass utrace context to marker functions.

This is needed later by freedreno in order to get
more device information in trace functions.

Signed-off-by: amber@igalia.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20727>