winsys/amdgpu: optimize looping inefficiencies in add_bo_fence_dependencies

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13478>

winsys/amdgpu: move BO fence array updates to the CS thread

We always wait for num_active_ioctls == 0 before we use the fence,
so we can just add fences to BOs in the CS thread.

Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13478>

winsys/amdgpu: don't use ip_instance and ring fields of fence and IB structures

They are always 0.

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13478>

winsys/amdgpu: increase the BO hash list size

This decreases overhead inside amdgpu_cs_add_buffer by 40%
for viewperf2020/catia.

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13478>

winsys/amdgpu: don't clear RADEON_USAGE_SYNCHRONIZED for last_added_bo_usage

It was breaking the early return path.

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13478>

winsys/amdgpu: remove an amdgpu_cs dereference from amdgpu_cs_add_buffer

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13478>

winsys/amdgpu: simplify parameter passing and derefs in cs_add_buffer

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13478>

gallium/radeon: merge BO read/write usage flags with priority flags

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13478>

gallium/radeon: remove unused RADEON_DEPENDENCY_START_FENCE

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13478>

gallium/radeon: remove/merge some BO priorities and remove holes

The upper bits will be used by RADEON_USAGE_*

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13478>

gallium/radeon: change the BO priority definitions to bits

This is for the next microoptimization.

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13478>

radeonsi: remove unused parameters in si_emit_draw_packets

This is a leftover from GS fast launch and compute-based culling.

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13539>

radeonsi: enable shader culling for indirect draws

It was mistakenly disabled, decreasing performance a lot.

Only valid for Mesa 21.3.

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Cc: 21.3 <mesa-stable@lists.freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13539>

util: make util_get_process_exec_path work on FreeBSD w/o procfs

sysctl is the correct way of getting the current executable's path.
procfs is not mounted by default.

Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1598>

util: __getProgramName: remove check for ancient FreeBSD versions, simplify ifdefs

FreeBSD 5.0 was released in 2003.
We really do not need to check that we're on >= 4.4.

Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1598>

radeon/vcn: combine session init func

Combine the session init function for h.264 and hevc to reduce redundancy.

Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13511>

radeon/vcn: combine encode params func

Combine the encode params function for h.264 and hevc to reduce redundancy.

Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13511>

radeon/vcn: remove redundancy for vcn2 enc

Remove redundancy functions for vcn2 encode. Re-using the vcn1 quality params
function as a result.

Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13511>

radeon/vcn: update vcn2 enc interface

Add missing parameters according to vcn 2 encode interface.

Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13511>

radeon/vcn: update vcn1 enc interface

Update vcn 1 encode interface, upgrade interface minor version from 2 to 9,
and add necessary parameters accordingly.

Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13511>

ci: Enable testing radeonsi's libva using libva-util unit tests.

We've noticed issues with these tests when uprevving Mesa in Chrome OS.
This CI catches some existing failures, and some debug-build assertion
failures as well.

To do this, uprev deqp-runner for its new gtest-runner command.  This
runner is not as efficient as I would hope, due to some expensive code in
gtest.  I've reported the issue to gtest and it should be easily fixable,
but for now it at least means we get to use the same baseline/skip/flake
handling we have from deqp and piglit runners.

I also fixed build-libdrm for our rootfses to not throw away libdrm's
share directory, which was causing a bunch of test-time spam from radeon's
libdrm when trying to look up its marketing name tables (not that big of a
deal for deqp-runner, but really noisy for piglit and libva-utils which
make gallium screens approximatly per-test).

Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13419>

freedreno/a6xx: Emit GRAS_LRZ_MRT_BUF_INFO_0

Analogous to the previous commit, this fixes the case where turnip sets
this reg to a media (yuv) format and then a gallium job is run next.

Fixes: 9c895e13 ("tu: Emit GRAS_LRZ_MRT_BUF_INFO_0")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13578>

tu: Always write GRAS_LRZ_MRT_BUF_INFO_0

This fixes flakes in dEQP-VK.pipeline.stencil.nocolor.format.* when run
after ycbcr tests. Apparently LRZ needs to know if there's a media
format enabled even if there are no color attachments, so we need to
write something here. Presumably any "normal" format would work but 0
seems like a good neutral choice.

Fixes: 9c895e13 ("tu: Emit GRAS_LRZ_MRT_BUF_INFO_0")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13578>

intel/genxml: Add XY_BLOCK_COPY_BLT on Tigerlake and later.

This is a new blitter command introduced on Tigerlake and expanded
substantially on XeHP.  XY_BLOCK_COPY_BLT is actually fast, unlike
the legacy blitter commands.  iris will use this in the future, and
anv hopefully could use it for a transfer queue someday as well.

Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13520>

intel/genxml: Allow MI_FLUSH_DW on the blitter

Pretty sure this is how you flush the blitter.

Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13520>

intel/genxml: Include blitter commands in gen*_pack.h

We're going to want to use the blitter again on newer hardware,
which means we need to be able to use genxml to emit those commands.

Acked-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13520>

intel/genxml: Assert that all MOCS fields are non-zero on Gfx7+

Let's try and catch performance problems before we have to do large
painful amounts of analysis to detect a missed field.

Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

intel/genxml: Add an field option for nonzero="true"

This asserts that the value supplied is non-zero.  Useful for things
like MOCS fields on modern platforms where we really want to avoid
setting it to 0 (uncached).

mbz types cannot be flagged as nonzero.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

i965: Set MOCS for Bindless Surface/Sampler State base addresses

We don't use bindless surface or sampler states today, and are unlikely
to ever implement that in i965, but we can set a MOCS value regardless
to avoid asserts in upcoming patches that assert MOCS isn't zero.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

i965: Port STATE_BASE_ADDRESS to genxml and fix bugs

This largely copies crocus's code for this (but with Gfx9+ handling).

This version also fixes missing MOCS settings on several platforms,
which we hadn't noticed were missing.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

i965: Fix MOCS for BLORP buffer copies

We were passing a MOCS of 0, which is uncached.  Yikes.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

i965: Set MOCS for 3DSTATE_INDEX_BUFFER on Gfx6/7 as well.

For some reason we were only setting this on Gfx8+.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

i965: Set MOCS for 3DSTATE_SO_BUFFERS on Gfx7.x too

For some reason we were only setting this on Gfx8+.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

i965: Set MOCS on NULL stream output buffers

We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications.  One case where we use
MOCS of 0 is disabled stream output targets,  MOCS shouldn't matter, as
there's no actual buffer to be cached.

That said, it should be harmless to set MOCS for these null stream
output buffers; we can just assume a MOCS for generic internal buffers.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

i965: Set MOCS for push constant buffers on Haswell and Gfx9+

We set MOCS on Ivybridge/Baytrail, but not Haswell, and not Skylake
and later.  We shoud set it everywhere.  While we're at it, we also
set it for null constant buffers, so that we aren't programming a 0
MOCS, to allow us to add some safeguards against that.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

i965: Set default MOCS for NULL depth/stencil/HiZ buffers

isl now uses info->mocs regardless of whether there's any actual
depth/stencil/HiZ buffers involved, so pass it a legitimate one,
rather than zero.  When we have entirely NULL surfaces, we just
default to the MOCS value for an internal buffer.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

i965: Use ISL for MOCS rather than open coding it everywhere

The ISL MOCS infrastructure didn't exist when we wrote the i965 code,
but now that it does, we ought to use it, deleting a complicated mess
that was replicated all throughout the codebase.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

crocus: Fix MOCS for buffer copies.

We were passing a MOCS of 0, which is uncached.  Yikes.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

crocus: Set MOCS for 3DSTATE_SO_BUFFERS on Gfx7.x too

For some reason we were only setting this on Gfx8+.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

crocus: Set MOCS for push constant buffers where possible

We apparently were not setting MOCS for 3DSTATE_CONSTANT_XS at all.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

crocus: Set default MOCS for NULL depth/stencil/HiZ buffers

isl now uses info->mocs regardless of whether there's any actual
depth/stencil/HiZ buffers involved, so pass it a legitimate one,
rather than zero.  When we have entirely NULL surfaces, we just
default to the MOCS value for an internal buffer.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

crocus: Set MOCS on NULL stream output buffers

We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications.  One case where we use
MOCS of 0 is disabled stream output targets,  MOCS shouldn't matter, as
there's no actual buffer to be cached.

That said, it should be harmless to set MOCS for these null stream
output buffers; we can just assume a MOCS for generic internal buffers.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

crocus: Set MOCS for index buffers on Gen6+

For some reason we were only setting them on Gen8+.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

crocus: Tidy the ifdefs for emitting STATE_BASE_ADDRESS

This reorganizes the code so that we set fields in a tidy order:

   1. Set the base addresses

   2. Set either buffer sizes (Gfx8) or upper bound values (Gfx4-7)
      (These are logically the same thing, but expressed differently.)

   3. Set MOCS (Gfx6+)

I find this easier to follow.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

crocus: Set MOCS for most state base addresses on pre-Gen8

We were only setting MOCS for dynamic state, surface state, instruction,
and indirect base addresses on Gen8+.  We should set them on Gen6+.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

anv: Set MOCS on NULL stream output buffers

We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications.  One case where we use
MOCS of 0 is disabled stream output targets,  MOCS shouldn't matter, as
there's no actual buffer to be cached.

That said, it should be harmless to set MOCS for these null stream
output buffers; we can just assume a MOCS for generic internal buffers.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

anv: Set MOCS on NULL vertex buffers

We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications.  One case where we use
MOCS of 0 is 3DSTATE_VERTEX_BUFFERS where we set NullVertexBuffer.
It shouldn't matter here, as there's no actual buffer to be cached.

That said, it should be harmless to set MOCS for null vertex buffers.
We can assume an internal buffer and request isl's vertex buffer MOCS.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

anv: Set MOCS in 3DSTATE_CONSTANT_XS even if there isn't a buffer.

This avoids MOCS != 0 assertions in later patches.  iris also does this,
and we do it for the 3DSTATE_CONSTANT_ALL packet path as well.  It's a
bit pointless, but it should hopefully be harmless also.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

anv: Set MOCS for 3DSTATE_CONSTANT_XS on Gfx7.x as well

We were only setting this on Gfx9+.  It's MBZ on Gfx8, but it exists
on Gfx7.x and doesn't have those restrictions there; we should set it.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

anv: Set default MOCS for NULL depth/stencil/HiZ buffers

isl now uses info->mocs regardless of whether there's any actual
depth/stencil/HiZ buffers involved, so pass it a legitimate one,
rather than zero.  When we have entirely NULL surfaces, we just
default to isl's MOCS value for an internal depth buffer.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

iris: Fix MOCS for buffer copies

We were passing a MOCS of 0, which is uncached.  Yikes.

Fixes: c5b22441f1c ("iris: Fix buffer -> buffer copy_region")

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

iris: Set MOCS on NULL stream output buffers

We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications.  One case where we use
MOCS of 0 is disabled stream output targets,  MOCS shouldn't matter, as
there's no actual buffer to be cached.

That said, it should be harmless to set MOCS for these null stream
output buffers; we can just assume a MOCS for generic internal buffers.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

iris: Set MOCS on NULL vertex buffers

We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications.  One case where we use
MOCS of 0 is 3DSTATE_VERTEX_BUFFERS where we set NullVertexBuffer.
It shouldn't matter here, as there's no actual buffer to be cached.

That said, it should be harmless to set MOCS for null vertex buffers.
We can assume an internal buffer and request isl's vertex buffer MOCS.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

iris: Set MOCS on 3DSTATE_CONSTANT_ALL packets that disable all buffers

We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications.  One case where we missed
setting a non-zero MOCS was in 3DSTATE_CONSTANT_ALL packets which fully
disable all constant buffers.  (If any constant buffer was present, we
would set an actual MOCS value.)

MOCS really shouldn't matter here, as there are no actual constant
buffers to be cached.  That said, it should be harmless to do so, and
we can just assume a generic MOCS for internal buffers.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

iris: Set MOCS on 3DSTATE_CONSTANT_XS on Gfx9+

We were leaving this blank due to a Broadwell restriction, causing our
constant buffers to be uncached.  We later fixed this for Gfx12+, but
left Gfx9-11 without a fix.  We should specify one.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

iris: Set default MOCS for NULL depth/stencil/HiZ buffers

isl now uses info->mocs regardless of whether there's any actual
depth/stencil/HiZ buffers involved, so pass it a legitimate one,
rather than zero.  When we have entirely NULL surfaces, we just
default to isl's MOCS value for an internal depth buffer.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

iris: Set Bindless Sampler State MOCS

We don't use bindless sampler states today, but when we do, we'll want
them to have proper MOCS values.  This also avoids asserts in upcoming
patches which enforce that MOCS isn't zero.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

iris: Drop unnecessary parenthesis

Trivial.

Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

blorp: Use a non-zero MOCS for disabled constant buffers

We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications.  One case where we use
MOCS of 0 is disabled constant buffers, where MOCS shouldn't matter, as
there's no actual buffer to be cached.

That said, it should be harmless to set MOCS for these null constant
buffers; we can just assume a generic MOCS for internal buffers.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

blorp: Fill in MOCS for null depth/stencil/HiZ buffers.

isl now uses info->mocs regardless of whether there's any actual
depth/stencil/HiZ buffers involved, so pass it a legitimate one,
rather than zero.  We just assume a generic internal MOCS when we
have entirely NULL surfaces.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

blorp: Fill in MOCS even for SURFTYPE_NULL surfaces.

We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications.  One case where we use
MOCS of 0 is SURFTYPE_NULL surfaces, where MOCS really shouldn't matter,
as there's no actual surface to be cached.

That said, it should be harmless to set MOCS for these null surfaces;
we can just assume a generic MOCS for internal buffers.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

isl: Fill in MOCS for NULL depth, stencil, and HiZ buffers.

We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications.  One case where we use
MOCS of 0 is SURFTYPE_NULL depth, stencil, and HiZ buffers, where MOCS
really shouldn't matter, as there's no actual surface to be cached.

That said, it should be harmless to set MOCS for these null surfaces.
We now set the one provided in info->mocs regardless of whether any
buffers actually exist or not.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

isl: Fill in MOCS even for SURFTYPE_NULL surfaces.

We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications.  One case where we use
MOCS of 0 is SURFTYPE_NULL surfaces, where MOCS really shouldn't matter,
as there's no actual surface to be cached.

That said, it should be harmless to set MOCS for these null surfaces;
we can just assume a generic MOCS for internal buffers.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

intel/genxml: Change 3DSTATE_CONSTANT_XS::MOCS to be MBZ on Gfx8.

The Broadwell PRM says: "Constant Buffer Object Control State must
always be programmed to zero."

This patch changes the MOCS field in gen8.xml to be "mbz" type, so that
it's impossible to set it to a non-zero value.

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

intel/genxml: Drop "Hierarchical Depth Buffer MOCS" field

This is redundant with the existing "MOCS" field.  We don't need both.

Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

intel/genxml: Add an "mbz" data type

There are some fields which Must Be Zero, and we don't want to allow
setting them from the template struct, but we do want them in the XML
to allow them to be decoded properly, and for documentation purposes.

This adds a new "mbz" type, much like "mbo", except it doesn't set
anything in the struct.  We also update the decoder to handle it.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

intel/genxml: Fix Indirect Object Access Upper Bound on Gfx4

We had this field mislabeled as "Instruction Access Upper Bound", but
instruction state base address doesn't exist until Gfx5.  This is
supposed to be the upper bound for indirect object base address,
matching the G45 copy.

Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>

drirc: enable do_dce_before_clip_cull_analysis for ANSA

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

glsl/drirc: add an option for gl_ClipVertex / gl_CullDistance checks

The GLSL spec says it's an error if a shader statically writes to these
2 variables.

Until this commit, Mesa refused to link a shader if it had an unused
function writing to one of these variables while another (used) function
wrote to the other.

This commit adds an option to perform dead function elimination after
the intra-stage linking step but before performing these checks.

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

docs: update calendar and link releases notes for 21.2.5

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

docs: add sha256 sums for 21.2.5

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

docs: add release notes for 21.2.5

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

r300: improve precission of linear interpolation

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

ir3/ra: Check register file upper bound when updating preferred_reg

Otherwise we could get invalid reg in get_reg()

Would fix many dEQP-VK.ssbo.phys.layout.*

Fixes: 0ffcb19b9d9fbe902224542047c389a661fbf816 "ir3: Rewrite register allocation"

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

radeon/vce: Limiting max supported refernce frames to 1  for h264 encoding

VCE currently restricted  max_supported reference frames to 1

Signed-off-by: shanshengwang <shansheng.wang@amd.com>
Suggested-by: Suresh Guttula <suresh.guttula@amd.com>
Acked-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13543>

ac/nir: remove bogus assertion about the position for culling

It's undefined to not export a position but some applications rely
on that. The position is always initialized to 0,0,0,1 everywhere else
if not exported.

Fixes KHR-GL46.shader_image_load_store.multiple-uniforms with Zink.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13470>

intel/pps: reuse timestamp_frequency from intel_device_info

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13571>

intel/pps: provide accurate min sampling period

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13571>

intel/dev: printout timestamp period

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13571>

docs: put a list of commands to setup perfetto

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13571>

pps: add an intel config file

It was useful to set a colleague up on perfetto.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13571>

pps: remove counter_ids fields

Those appear not to be recognized anymore by perfetto.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13571>

intel/dev/test: Assert (verx10 / 10) == ver

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13568>

aco: use std::vector and IDSet in RA validator

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/13541>

broadcom/compiler: padding fixes to QPU assembly dumps

When there are dst/src modifiers it is pretty common that instructions
take too much space and lead to alignment issues that make code a lot
harder to read, so align the MUL and SIG columns a bit wider to avoid
this:

Before:

0x380021828003faa8 fmax  rf2, rf42.abs, rf40.abs; nop
0x3800f186c503f0f0 fcmp.pushc  -, rf3, rf48; nop
0x380c038b85b83282 fmax  rf11, rf10, rf2; mov.ifa  rf14, rf46
0x3800219ab503f359 and  rf26, rf13, rf25; nop
0x3820f186c503f2f0 fcmp.pushc  -, rf11, rf48; nop           ; thrsw
0x382c013fb5b8368e and  rf63, rf26, rf14; mov.ifa  rf4, rf46; thrsw
0x38002185b503ffc4 and  rf5, rf63, rf4  ; nop
0x38002186b503f141 and  rf6, rf5, rf1   ; nop
0x382031873503f186 vfpack  tlb, rf6, rf6; nop               ; thrsw
0x380031873503f18f vfpack  tlb, rf6, rf15; nop
0x38003186bb03f000 nop                  ; nop

After:

0x380021828003faa8 fmax rf2, rf42.abs, rf40.abs  ; nop
0x3800f186c503f0f0 fcmp.pushc -, rf3, rf48       ; nop
0x380c038b85b83282 fmax rf11, rf10, rf2          ; mov.ifa rf14, rf46
0x3800219ab503f359 and rf26, rf13, rf25          ; nop
0x3820f186c503f2f0 fcmp.pushc -, rf11, rf48      ; nop                         ; thrsw
0x382c013fb5b8368e and rf63, rf26, rf14          ; mov.ifa rf4, rf46           ; thrsw
0x38002185b503ffc4 and rf5, rf63, rf4            ; nop
0x38002186b503f141 and rf6, rf5, rf1             ; nop
0x382031873503f186 vfpack tlb, rf6, rf6          ; nop                         ; thrsw
0x380031873503f18f vfpack tlb, rf6, rf15         ; nop
0x38003186bb03f000 nop                           ; nop

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

zink: always use explicit lod for texture() when legal in non-fragment stages

implicit lod is something else entirely

fixes #5566

cc: mesa-stable

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

zink: set aspectMask for renderpass2 VkAttachmentReference2 structs

this is otherwise just garbage

fixes #5569

cc: mesa-stable

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

zink: use align64 for allocation sizes

avoid 32bit sint overflows

fixes #5568

cc: mesa-stable

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

zink: cache bo SpvId array types

this cuts down on a truckload of useless new validation spam

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

venus: implement vn_buffer_cache_entries_create

1. advertise high hit rate cache combinations, and we should limit the
   caches to those only require device memory pool alloc
2. use size = 1 to ask for buffer memory requirements so that we do a
   sanity check on our assumption of returned size and alignment. For
   implementations don't meet our assumption, continue without cache.

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13428>

venus: implement vn_buffer_cache_get_memory_requirements

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13428>

venus: implement vn_buffer_get_max_buffer_size

This change estimates the max_buffer_size with quick sort. Try to
avoid some traffic upon device creation time, but not worth adding a
buffer simple create api to avoid the extra requirement query traffic
since this is temporary.

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13428>

venus: add buffer cache init and usage flows

1. struct vn_buffer_cache_entry for buffer memory requirements
2. struct vn_buffer_cache for all buffer related cached info
3. implement vn_buffer_cache_init
4. implement vn_buffer_cache_fini
5. empty vn_buffer_get_max_buffer_size
6. empty vn_buffer_cache_entries_create
7. implement vn_buffer_cache_entries_destroy
8. empty vn_buffer_cache_get_memory_requirements

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13428>

venus: add struct vn_image_memory_requirements

This aligns with vn_buffer_memory_requirements and can potentially
simplify future image memory requirements cache init.

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13428>

venus: add struct vn_buffer_memory_requirements

This will simplify later buffer cache api.

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13428>

venus: refactor the ahb buffer mem_type_bits query api

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13428>

venus: refactor to add vn_buffer_init

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13428>

venus: refactor to add vn_device_init

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13428>

venus: release queues on device creation failure

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13428>

zink: add better handling for CUBE_COMPATIBLE bit

this check was illegal because the usage bits weren't yet populated,
so add another check after usage bits are determined to figure out if
CUBE_COMPATIBLE can be applied

additionally, checking sample counts was never needed since the spec
prohibits CUBE_COMPATIBLE use with multisampling

zink DEBUG: ERR: 'Validation Error: [ VUID-vkGetPhysicalDeviceImageFormatProperties-usage-requiredbitmask ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x991b3105 | vkGetPhysicalDeviceImageFormatProperties: value of usage must not be 0. The Vulkan spec states: usage must not be 0 (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkGetPhysicalDeviceImageFormatProperties-usage-requiredbitmask)'

Fixes: 71494c4874c ("zink: only mark resources as cube-compatible if supported")

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