avoid issues later by checking this now while we're here

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

this is ugly and will be cleaned up later, but the idea is to have identical
handling between samplers and images such that for each type, an array of resources
is processed and it's just setting up variables which fall through to the actual
descriptor struct processing

Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

this is sort of a weird mechanism since shader images have no allocated
struct and just hang out on the context

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

we'll reuse this for shader images

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

since we don't have the device info we have to emit some caps on the
fly here

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

now that atomic handling is standardized, there's only a few actual ops left
to have proper image support

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

this is sort of what we should be moving towards for io as well at some point,
the gist of the change here being that when images are deref'd, we need
to be able to do a lookup on the deref store later on in order to get the
image back

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

this standardizes and simplifies atomic op dispatch since none of them have
any special handling

it also removes unnecessary (but harmless) memory semantics from a previous commit

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

this just does spirv variable setup

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

image_types will be used for images in the next commit

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

I'm not claiming this is 100% correct, but it works

Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

this tells us if a batch has a draw command pending

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

this is a huge perf hog that will be improved on later, but it's necessary for now
in order to correctly determine whether we can use resources as shader images
since gallium gives us no info about usage

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

these are used for images

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

these are functions with 6 operands

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

this is wrongly named and conflicts with things that are actually
image_views (assuming we're using gallium terminology in order to match
the rest of the ecosystem)

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!8504>

fossil-db (GFX10.3):
Totals from 11485 (8.24% of 139391) affected shaders:
SGPRs: 1032456 -> 1033696 (+0.12%); split: -0.69%, +0.81%
VGPRs: 815332 -> 807448 (-0.97%); split: -1.04%, +0.07%
SpillSGPRs: 18014 -> 13497 (-25.07%); split: -28.28%, +3.20%
SpillVGPRs: 1821 -> 1749 (-3.95%)
CodeSize: 101194172 -> 101235028 (+0.04%); split: -0.06%, +0.10%
Scratch: 198656 -> 178176 (-10.31%)
MaxWaves: 86703 -> 87219 (+0.60%); split: +0.67%, -0.07%
Instrs: 19224250 -> 19238562 (+0.07%); split: -0.05%, +0.13%
Cycles: 1486045388 -> 1487481292 (+0.10%); split: -0.03%, +0.13%
VMEM: 2040484 -> 2127647 (+4.27%); split: +6.64%, -2.37%
SMEM: 724060 -> 674966 (-6.78%); split: +1.22%, -8.00%
VClause: 312375 -> 314735 (+0.76%); split: -0.26%, +1.02%
SClause: 702274 -> 711991 (+1.38%); split: -0.77%, +2.15%
Copies: 1413440 -> 1422782 (+0.66%); split: -0.45%, +1.11%
Branches: 658696 -> 658838 (+0.02%); split: -0.12%, +0.14%
PreSGPRs: 884666 -> 879736 (-0.56%); split: -1.30%, +0.74%
PreVGPRs: 777374 -> 769947 (-0.96%)

Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <mesa/mesa!6490>

Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <mesa/mesa!6490>

fossil-db (GFX10.3):
Totals from 3231 (2.32% of 139391) affected shaders:
SGPRs: 168654 -> 167454 (-0.71%); split: -0.72%, +0.00%
VGPRs: 152352 -> 152416 (+0.04%)
CodeSize: 13872836 -> 13806376 (-0.48%); split: -0.50%, +0.02%
MaxWaves: 36640 -> 36634 (-0.02%)
Instrs: 2639959 -> 2626852 (-0.50%); split: -0.52%, +0.03%
Cycles: 77706000 -> 77496792 (-0.27%); split: -0.28%, +0.01%
VMEM: 809496 -> 790847 (-2.30%); split: +2.06%, -4.36%
SMEM: 267843 -> 253187 (-5.47%); split: +0.76%, -6.23%
VClause: 61353 -> 60426 (-1.51%); split: -1.86%, +0.35%
SClause: 95409 -> 92355 (-3.20%); split: -3.24%, +0.04%
Copies: 194951 -> 196702 (+0.90%); split: -0.53%, +1.43%
Branches: 84320 -> 84331 (+0.01%); split: -0.00%, +0.02%
PreSGPRs: 110162 -> 110203 (+0.04%); split: -0.04%, +0.07%
PreVGPRs: 127021 -> 127037 (+0.01%)

Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <mesa/mesa!6490>

If we want syntax-highlighting to actually work here, we should make
sure the code actually parses.

This fixes a warning during docs build.

Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!8243>

Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!8243>

There's a few more cases that needs proper quoting for Sphinx. Asterisks
and ticks at the start of words, as well as underscores at the end of
symbols, even when they have trailing escaped characters.

We should really find a way to robustly escape these things when
generating them.

Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!8243>

Although I assume that this should be caught by the validation layers,
recently while triaging the following tests:
dEQP-VK.ycbcr.query.*r8g8b8a8_unorm*

We found that they were setting a descriptorCount of zero, because it
was not handling correctly the differences between Vulkan 1.0 and
Vulkan 1.1.

So let's just assert, just in case it happens again, as that would
make the bugfixing far easier.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <mesa/mesa!8614>

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <mesa/mesa!8570>

The documentation states that if we disable Early Z for the whole
frame in the RCL Tile Rendering Mode packet, then we should not
emit any draw calls with it enabled (which we can do by enabling
it in the CFG_BITS packet).

Since we emit our RCL after recording our draw calls in the BCL
and we were not considering there if any condition for global disable
would be met, it was possible that we end up with an incorrect
configuration when we decide for a global disable in the RCL, which
can cause rendering artifacts. This can be easily observed by simply
forcing the RCL bit to disable early Z in applications that are known
to enable it in CFG_BITS (such as the UE Shooter demo for example).

With this change we keep track of this scenario when we record
draw calls in the BCL and if decide that we need to disable EZ for
the entire job, we make sure we never enable it for any draw calls
in the frame.

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <mesa/mesa!8589>

This is an optimization that should make Z/S clears faster. To enable
this we can't have any Z/S loads or stores in the job. Also, it seems
that enabling early Z/S clearing is independent of whether early Z/S
testing is enabled.

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <mesa/mesa!8589>

There was a misunderstanding regarding the scope of some hardware bugs
that led us to think that:

1. The Clear Tile Buffer Z/S bit was broken
2. The Clear Tile Buffer RTs bit would also clear Z/S.

1) is not really true, what happened was that some other bugs for which
we need workarounds anyway would have that effect. 2) was only true
for V3D 4.1, so it doesn't affect v3dv.

This change makes proper use of the Z/S bit instead of falling back to
clearing all tile buffers every time we have a Z/S clear. This also
allows us to do color clears on the tile store (which is faster) rather
than falling back to the clear all RTs bit every time we have a Z/S clear.

v2: rewrite the original comment about the hardwarebug description to
    include recent discussions with Broadcom instead of keeping it as
    is and amending it with an update note.

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <mesa/mesa!8589>

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <mesa/mesa!8589>

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <mesa/mesa!8589>

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <mesa/mesa!8589>

Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Gitlab: mesa/mesa#3993
Part-of: <mesa/mesa!8163>

Matches SPIR-V -> NIR implementation of OpArrayLength.

Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <mesa/mesa!8163>