v3dv: Call nir_lower_io for push constants

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

v3dv/pipeline: use derefs for ubo/ssbo

There are some potential advantages for that. Even if we are not
taking advantage of them, it would be interesting to be using this
path now, specially as non-deref path could be removed at some point.

Note that instead of returning for both resource_index and
vulkan_descriptor a vec2, we return a scalar for the first one, as it
is what the v3d backend expect (like for get_ssbo_size). For this to
work, we reconfigure the vec2 at vulkan_descriptor using the index and
an unused 0 value.

As far as I see turnip avoids that by lowering too load_ssbo/ubo, so
it just gets the index lowered (that in their case it is a vec3 with a
fixed 0 on the third component), but for now it is easier doing this.

v2: return a single-component for the index, to avoid the backend
    needing to handle it (Eric, Jason).

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

v3dv/device: fix compute_heap_size for the simulator

Asking the simulator the total memory it is using, instead of sysinfo
(that returned the host system memory).

Fixes the following CTS tests when using the simulator:
  dEQP-VK.memory.allocation.basic.percent_1.forward.count_12
  dEQP-VK.memory.allocation.basic.percent_1.reverse.count_12

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

v3d/simulator: add v3d_simulator_get_mem_size

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

broadcom/compiler: allow GLSL_SAMPLER_DIM_BUF on txs emission

Although we don't support texture buffers on the OpenGL driver, we are
already doing that for the Vulkan driver. This would be needed for the
OpenGL driver in any case.

Fixes following tests on v3dv:
 dEQP-VK.memory.pipeline_barrier.host_write_uniform_texel_buffer.*
 dEQP-VK.memory.pipeline_barrier.transfer_dst_uniform_texel_buffer.*

Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>

v3dv/meta: fix hash table insertion

So far we were using directly the local variable key to do the
insertion, when the hash table expects a permanent address. We add a
key field on all the meta structures (that are already basically a
wrapper over v3dv_pipeline).

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

v3dv/pipeline: fix combined_index_map insertions

We were inserting as key directly the local key variable used to
search for entries, but hash_table expect a real pointer. Fixed by
using the array of keys that we already had at v3dv_pipeline.

Fixed failures on the rpi4 like:
dEQP-VK.api.copy_and_blit.core.blit_image.all_formats.color.a1r5g5b5_unorm_pack16.a1r5g5b5_unorm_pack16.general_general_linear

but fwiw, this tests on the simulator, and several other tests on both
the simulator and rpi4, were working just by luck.

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

v3dv/debug: add v3dv_print_v3d_key

Useful to print which v3d keys were used for each variant.

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

v3dv/device: warn when the pipeline cache is disabled

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

v3dv/device: add assert for texture-related limits

There are several limits that when added shouldn't be greater than
V3D_MAX_TEXTURE_SAMPLERS (defined at common/v3d_limits.h), so let's
assert it.

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

v3dv: handle multisample rasterization with empty framebuffers

If the framebuffer has no attachments then multisample rasterization
is enabled based on the rasterizationSamples multisample state of
the pipelines. It should be noted that since we don't support
the variableMultisampleRate feature, all pipelines in the same
subpass must have matching number of samples.

V3D requires that we specifically setup our frames to enable
multisampling or not, and we do this when we create jobs inside
a subpass. Since we create the first job for a subpass as soon as
the subpas starts, this is problematic: if we don't have any
attachments, we don't won't enable MSAA at this point, but later
on we might bind an MSAA pipeline, since pipelines can be bound
at any point in the lifespan of a command buffer.

Here, we fix this by testing if the first draw call in a job uses
an MSAA pipeline but the job the was setup to not use MSAA, and in
that case we re-start the job with MSAA enabled.

We also take care of a corner case that seems to be tested by CTS
where a framebuffer with no attachments doesn't bind any pipelines
with MSAA enabled (so according to the Vulkan spec, multisample
rasterization must be disabled) but the fragment shader in use
reads gl_SampleID (which enables per-sample shading). This would
lead to enabling per-sample shading with single-sample rasterization,
which doesn't make sense and makes the simulator complain, so we just
disable per-sample shading in that case.

Fixes:
dEQP-VK.pipeline.multisample.mixed_count.*

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

v3dv: implement nir_texop_texture_samples

Fixes:
dEQP-VK.glsl.texture_functions.query.texturesamples.*

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>

v3dv: enable sample rate shading if fragment shader reads gl_SampleID

According to the spec, if a fragment shader reads gl_SampleID then the
shader must be evaluated per-sample.

Fixes:
dEQP-VK.pipeline.multisample_shader_builtin.write_sample_mask.4_samples

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

broadcom/compiler: track if the fragment shader forces per-sample MSAA

For example, regarding gl_SampleID, the GLSL spec states:

   "Any static use of this variable in a fragment shader causes the
    entire shader to be evaluated per-sample."

So we need to track if the fragment shader does anything that implicitly
enables per-sample shading in the compiler for the driver to
auto-enable sample rate shading if needed.

v2:
 - Instead of tracking reads of gl_SampleID, check SYSTEM_BIT_SAMPLE_ID
   and SYSTEM_BIT_SAMPLE_POS as well as the sample layout qualifier like
   other drivers are doing to activate this behavior (Eric).

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> (v1)
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>

v3dv/descriptor: remove v3dv_descriptor_map_get_image_view

Now that we added support for texel_buffers, on all the cases that we
were checking for a image_view we end checking for a image_view or
buffer_view, so we stopped to use it. Remove it as it become
superfluous.

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

v3dv/uniforms: handle texture size for texel buffers

This gets tests like the following one working:
dEQP-VK.image.image_size.buffer.readonly_writeonly_1

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

broadcom/compiler: implement nir_intrinsic_load_sample_pos

This is intended to return the sample location within the pixel.

Fixes:
dEQP-VK.pipeline.multisample_shader_builtin.sample_position.*

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>

v3dv/formats: fix exposing FEATURE_UNIFORM/STORAGE_TEXEL_BUFFER_BIT

If the formats are not suitable as texture type, then they can't be
used as texel buffers.

Gets tests like the following one:
   dEQP-VK.image.load_store.without_format.buffer.r32g32b32_sfloat_minalign_uniform

to be properly skipped (instead of Crash on the simulator)

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

v3dv: handle multisample image clears

Fixes:
dEQP-VK.pipeline.framebuffer_attachment.*_ms

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

v3dv: handle multisample resolves for formats that don't support TLB resolves

The TLB multisample resolve feature is only limited to specific format types.
For everything else, including sfloat and integer formats, we need to
fallback to a blit resolve. This needs to be handled both for in-pass
resolves as well as for vkCmdResolveImage.

Because these blits would happen after the tile store operations, we need
to make sure we store the multisampled buffers so we can then read them for
the blit resolve.

Fixes the remaining test failures in:
dEQP-VK.renderpass.suballocation.multisample_resolve.*

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

v3dv: handle multisample resolve of integer formats

The multisample resolve of an integer framebuffer should just take one
of the samples instead of averaging.

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

v3dv: fix blitting of signed integer formats

For these we want to select a signed integer output format
and a signed sampler type.

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

nir/glsl: add a glsl_ivec4_type() helper

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>

v3dv: amend tile size tables with smallest tile sizes available

We'll need this for some cases involving maximum number of multisampled
color targets.

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

v3dv/device: fix minTexelBufferOffsetAlingment

As we understand that texture accesses should be aligned to the UIF
block size.

Fixes several of the CTS tests under this pattern:
  dEQP-VK.binding_model.shader_access.primary_cmd_buf.uniform_texel_buffer.*.offset_nonzero
  dEQP-VK.binding_model.shader_access.primary_cmd_buf.storage_texel_buffer.*.offset_nonzero

Note: for those tests, using a lower value (64) was enough to get them
working, but again, we understand that the real alignment is the UIF
block size.

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

v3dv: add v3dv_limits file

There are several definitions for hw limits on v3dv_image that we want
to share, but v3dv_private was already growing bigger and messier.

So let's move them to a specific header. Note that there is already a
broadcom/common/v3d_limits.h. We are not putting them there because
right now they are only used by the Vulkan driver, but are candidates
to be moved.

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

v3dv/descriptor: support for UNIFORM/STORAGE_TEXEL_BUFFER

This gets passing most uniform/storage_texel buffer tests.

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

broadcom/compiler: handle gl_SampleMask writes in fragment shaders

We didn't need this until now, since this was included with GLES 3.2,
but we need it for Vulkan.

Eric had already done the plumbing for it though, we just need to
actually emit the mask.

Fixes some tests in:
dEQP-VK.renderpass.suballocation.multisample_resolve.*

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>

v3dv: handle multisampled image copies with the blit path

This should be able to handle partial copies of multisampled images.

This change extends our blit shader interface to also handle multisampled
destinations so that if the blit destination is a multisampled image,
the blit will rely on sample rate shading to copy all samples from
the source image (which must have a matching number of samples).

I have not found any tests in CTS that do partial copies of
multisampled images, so I tested this with a full multisampled image
copy, using this test:
dEQP-VK.api.copy_and_blit.core.resolve_image.whole_copy_before_resolving.4_bit

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

v3dv: add a blit fallback path for vkCmdResolveImage

This fallback is required when we have to do partial resolves. It
works the same way as other blit fallbacks for copy operations: it
will bind the source image as a source texture and blit the selected
region to the destination image.

The difference in this case is that the source image is multisampled
and the blit shader needs to fetch and average individual samples for
each texel.

This gets us to pass all the remaining test cases in
dEQP-VK.api.copy_and_blit.core.resolve_image.*

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

v3dv: setup texture shader state correctly for multisampled images

Fixes multisampled cases in:
dEQP-VK.pipeline.multisample.sampled_image.*

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

v3dv: handle multisampled image copies in the TLB path

vkCmdCopyImage can be used to copy multisampled images. We can
easily support that on the TLB path, which copies full images.

For partial copies we will need to amend our blit shader path
to support multisampling resolve.

Fixes:
dEQP-VK.api.copy_and_blit.core.resolve_image.whole_copy_before_resolving.4_bit

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

v3dv: implement vkCmdResolveImage for whole images

For partial resolves we will need a shader blit & resolve fallback.

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

v3dv: implement subpass multisample rendering and resolve

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

v3dv: process VkPipelineMultisampleStateCreateInfo properly

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

v3dv: consider MSAA when computing frame tiling

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

v3dv/pipeline: handle properly OUT_OF_HOST_MEMORY error when allocating p_stage

So far we were just assuming that it would work (so we could try to
access a NULL pointer), and not freeing it properly.

Fixing that was somewhat messy due pipeline_compile_graphics using a
temporary array and then update the internal pipeline stages. As we
are here we just removed the array and simplified
pipeline_compile_graphics code.

Fixes following tests:
  dEQP-VK.api.object_management.alloc_callback_fail.graphics_pipeline
  dEQP-VK.api.object_management.alloc_callback_fail_multiple.graphics_pipeline

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

v3dv/pipeline: pre-generate more that one shader variant

In order to reduce the number of shader builds after pipeline creation
(that ideally shouldn't happen) we pre-generate two shader variants at
pipeline creation time. In addition to the default one, that set the
return size for all texture to 16 bit, we build another variant
setting the return size for all textures to 32-bit. cmd buffer selects
the latter if any of the textures requires 32bit.

So we are using an all 16-bit return size or an all 32-bit return size
variants. This could be slightly improved by pre-generating return
size combinations if the texture number is below a threshold. But that
would require more space, and bigger pipeline creation time, so would
need to be evaluated.

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

v3dv/pipeline: when looking for a variant, check first current variant

So far, when checking for a variant fulfilling a specific v3d key, we
were checking the caches, and if that failed, we compiled a new
variant, and update the current variant.

But we could check first if the current variant fullfils that. This
was not really problematic so far, as checking on the caches was fast,
but now that we could be without any kind of shader cache using
V3DV_ENABLE_PIPELINE_CACHE, it is far better to check first current
variant.

Without this vkQuake3 at 720p drops to 1fps when disabling the cache.

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

v3dv/pipeline: remove custom variant cache

Now that we have a default pipeline cache, we can rely on it. This
allows to remove some code, and avoid the need to have a cache per
each pipeline stage.

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

v3dv/pipeline_cache: add default pipeline cache

That it would be used as fallback. Three advantages:

  * Having a cache for user operations even if the user doesn't
    provide it.

  * Having a cache for internal operations. v3dv_meta_copy creates
    pipelines for some copy path, so it is interesting to have them
    cached.

  * Testing: so now the pipeline cache is tested by more CTS tests.

As any other pipeline cache, it can be disabled with the
V3DV_ENABLE_PIPELINE_CACHE. It was suggested that would make sense to
have a specific envvar for the default pipeline cache, but for now
just one envvar is enough.

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

v3dv/pipeline: provide a shader_sha1 to private ShaderModules

So far for private pipelines we were creating dummy shader modules
where we directly provided the nir shader. But for the pipeline cache
we were using the SPIR-V to generate part of the cache key sha1.

The main use case for private pipelines are meta_copy/clear. Those nir
shaders depend on parameters like the format etc, so we use directly
the serialized form of the NIR shader to generate the sha1.

The other case are the no-op fragment shader that we need to provide
if no fragment shader is defined by the user. For that case we can
just use the default shader name, as the no-op shader is always the
same.

This is required as we plan to add a default pipeline cache, that
would include our private shaders too.

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

v3dv/pipeline_cache: MergePipelineCaches implementation

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

v3dv/pipeline_cache: support to serialize/deserialize cached NIRs

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

v3dv/pipeline_cache: cache v3dv_shader_variants

This also includes being able to serialize them as part of
GetPipelineCacheData and to deserialize it as part of
CreatePipelineCache.

So now we can also upload the assembly of the variant as part of the
PipelineCache creation.

Note that from all this the tricky part was the prog_data
serialization. v3d_compile allocates and fill a new prog_data, with
rzalloc. Among other things because it also allocates internally the
uniform list. So we needed to replicate that when deserializating the
prog_data. Ideally we would like to avoid that, and allocate as much
resources as possible using vk_alloc, but that would mean a somewhat
deep change on the v3d_compiler, that we want to avoid as much
possible for now.

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

v3dv/pipeline: add basic ref counting support for variants

As soon as we start to cache variants on pipeline caches, the same
variant could be used by different pipelines and pipeline caches.

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

v3dv/pipeline_cache: cache nir shaders

Heavily based on anv nir caching. One of the bigger difference is that
we don't create the nir shader using a ralloc_context local to the
main compile graphics method. On anv, after compiling the shader, they
discard the nir shader. We need it as we could need it to build shader
variants later.

As anv, we introduce a environment variable to disable the cache:
  V3DV_ENABLE_PIPELINE_CACHE

By default is enabled. The main purpose for this envvar is debugging,
in order to provide a easy way to discard a bug on the cache.

It is pending to serialize/deserialize the NIR shaders as part of
GetPipelineCacheData and PipelineCacheCreate. We also plan is to cache
too shader variants. We would do that on following patches.

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

v3dv/pipeline_cache: bare basic support for pipeline cache

And this means providing a proper cache object, and being able to
load/retrieve a cache data with a proper header. Not really caching
anything yet. That would be tackle on following patches.

Note that this no-op cache got all the specific pipeline_cache and
pipeline.cache tests passing on the rpi4.

The following tests are still crashing when using the simulator:
 dEQP-VK.synchronization.internally_synchronized_objects.pipeline_cache_compute
 dEQP-VK.synchronization.internally_synchronized_objects.pipeline_cache_graphics

But those are an issue of synchronization tests on the simulator, and
not related with the pipeline cache itself. In general synchronization
tests should be tested on the rpi4.

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

v3dv/device: proper pipeline cache uuid

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

v3dv/device: get proper device ID under simulator

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

v3dv/device: add vendorID/deviceID get helpers

As we would need them for the pipeline cache header.

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

v3dv: fix dynamic state after meta operation

We should always save state on a push before starting a meta operation,
even if we don't have a pipeline, since dynamic state can be set at any
time directly on the command buffer. Similarly, we should always restore
it if the pop after the meta operation signals that it has written any
state, not only if we have a graphics pipeline to restore.

Fixes a rendering artifact in VkQuake.

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

v3dv: enable fillModeNonSolid

This, together with the shaderClipDistance changes, gets vkQuake3
to run without hacks.

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

v3dv: enable shaderClipDistance

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

v3dv: add a fast path for vkCmdClearAttachments

Since vkCmdClearAttachments executes inside a render pass, we would
benefit from converting it to a draw within the current subpass job to
improve batching and avoid expensive tile load/store operations.

This can dramatically improve performance for applications using this
command, however, we can only use this if we are clearing the base
layers of framebuffer attachments, since otherwise we would need to
use layered rendering, which we don't support yet.

This improves vkQuake3 performance dramatically (almost 100%
performance improvement at 1080p), which calls this twice per frame.

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

v3dv: only clear depth/stencil attachments if any aspect needs clearing

When we can't perform the clears using the TLB and fallback to
vkCmdClearAttachments make sure we only emit the clear if any of
the depth/stencil aspects actually needs it.

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

v3dv: emit new shader state if viewport is dirty

If we have a dirty viewport then we need to re-emit our uniforms
to update QUNIFORM_VIEWPORT_*.

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

v3dv: only care about barriers between GPU jobs

We don't need to do anything special for host/gpu synchronization.

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

v3dv: avoid prime blit path when presenting WSI images

This allows us to present WSI images directly rather than going through
a blit path, improving performance.

This improves vkQuake performance at 1080p by 10-20%.

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

v3dv: only use per-buffer clear bit for cases were we are already storing

This bit is helpful if we already need to store the buffer, but otherwise
we should not emit the store only to get the clear, we can use the global
clear packet for that and save us an expensive tile buffer store operation.

Also, we have not been using the per-buffer clear bit for depth/stencil
stores since "v3dv: fix depth/stencil clears on hardware", so we should
never been considering clearing needs to flag stores.

This improves vkQuake performance somewhere between 5%-15% by allowing
us to skip the store of the depth attachment.

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

v3dv: ignore stencil load operation if attachment format doesn't have stencil

This gets vkQuake to render correctly, which creates render passes with
stencil load operations even when the depth/stencil attachment format
doesn't have a stencil aspect. While this is a bit weird, it seems to
be allowed by the spec:

   "If the format has depth and/or stencil components, loadOp and storeOp
    apply only to the depth data, while stencilLoadOp and stencilStoreOp
    define how the stencil data is handled."

In our case we were not ignoring it and this was causing that we emitted a
Z buffer load that seemed to clobber the Z clear, preventing all draw calls
from passing the depth test.

While we are at it, also change the depth/stencil store operation (which
was already handling this scenario correctly) to use the format of the
render pass attachment description rather than the underlying image
format.

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

v3dv: use a binning sync for CL jobs waiting on a semaphore

If we have a semaphore wait the job cannot be started before the semaphore
has been signaled, so we need to wait before starting the binning stage.

Fixes CTS failures in:
dEQP-VK.synchronization.op.single_queue.binary_semaphore.*

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

v3dv: improve pipeline barrier handling

So far we have been getting away with finishing the current job in the
presence of a pipeline barrier and relying on the RCL serialization,
but of course this is not always enough.

This patch  addresses synchronization across different GPU units
(i.e. draw indirect after compute), as well as cases where we need to
sync before binning.

Fixes CTS failures in:
dEQP-VK.synchronization.op.single_queue.barrier.*

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

v3dv: don't support sRGB buffer formats

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

v3dv: handle VK_FORMAT_B8G8R8A8_UNORM vertex attributes

This is the only mandatory vertex attribute format that requires a
swizzle.

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

v3d/compiler: support swapping R/B channels in vertex attributes.

We will need this in Vulkan to support vertex format
VK_FORMAT_B8G8R8A8_UNORM.  The hardware doesn't allow to swizzle
vertex attribute components, so we need to do it in the shader.

v2:
 - Use nir_intrinsic_io_semantics() to retrieve the location instead
   of looping through the shader input variables (Eric).
 - Assert that we only have one component (Eric).

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> (v1)
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>

v3dv: make sure we emit vertex attributes in location order

The order in which we emit the attributes is relevant, since
GL_SHADER_STATE_ATTRIBUTE_RECORD packets don't include an explicit
attribute index. This means that we need to emit them in driver
location order, since the compiler uses that location to compute
attribute offsets in the VPM.

Fixes ~1300 CTS tests in:
dEQP-VK.pipeline.vertex_input.multiple_attributes.out_of_order.*

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

v3dv/device: handle primary nodes for newer kernels

For kernels rpi-5.X.y it changed from brcm,bcm2835-vc4 to
brcm,bcm2711-vc5, so let's just check for both strings.

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

v3dv: fix color border clamping with specific formats

For some reason, CTS expects E5B9G9R9 and B10G11R11 with
transparent black border clamping produce alpha 1 instead of 0.

Since border color takes precedence over the texture state swizzle,
the only way to fix this is to lower the texture swizzle in the shader
to set alpha to 1.

Fixes:
dEQP-VK.pipeline.sampler.view_type.*b10g11r11*clamp_to_border_transparent_black
dEQP-VK.pipeline.sampler.view_type.*e5b9g9r9*.clamp_to_border_transparent_black

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

v3dv: fix regressions for cubemap array load/store

It seems that we only want to set the texture state's depth to the
number of 2D layers divided by 6 when sampling, not wen doing
load/store.

This means that we need to generate two different states and choose
the one to use depending on the descriptor.

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

v3dv: use swizzle X001 with D/S formats

This matches Vulkan CTS expectations.

Fixes (for D/S formats):
dEQP-VK.pipeline.sampler.view_type.*

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

v3dv/image: fix TEXTURE_SHADER_STATE depth for cube arrays

For these we want to divide the number of layers by 6.

Fixes:
dEQP-VK.pipeline.image_view.view_type.cube_array.*
dEQP-VK.pipeline.image.suballocation.sampling_type.combined.view_type.cube_array.*

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

v3dv: handle unnormalized coordinates in samplers

In OpenGL, unnormalized coordinates are implicit based on the sampler
type (rectangle textures), so the compiler can set the flag when needed.
In Vulkan, however, this is configured explicitly in the sampler object,
so the compiler won't set it and we need to do it manually when we are
writing the P1 uniform.

Fixes:
dEQP-VK.pipeline.sampler.exact_sampling.*.unnormalized_coords

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

v3dv: fix blit_shader() to honor the region's aspect mask

When translating combined depth/stencil blits to compatible color blits we
should look at the requested region aspects to decide the color
mask to apply.

Fixes:
dEQP-VK.api.copy_and_blit.*.buffer_to_depthstencil.buffer_offset_d24_unorm_s8_uint_D
dEQP-VK.api.copy_and_blit.*.buffer_to_depthstencil.buffer_offset_d24_unorm_s8_uint_SD
dEQP-VK.api.copy_and_blit.*.buffer_to_depthstencil.buffer_offset_d24_unorm_s8_uint_S_D

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

v3dv: fix srcSubresource description for image to buffer blits

We are emitting a loop copying layer by layer here.

Fixes:
dEQP-VK.pipeline.render_to_image.core.*.huge.*

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

v3dv: fix textureSize() for cube arrays

For these we want to divide the number of layers by 6.

Fixes:
dEQP-VK.glsl.texture_functions.query.texturesize.*samplercubearray*

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

v3dv: fix vkCmdCopyBuffer unaligned TLB access

We need to make sure that our tile load/store operations are aligned
to the selected item size for the copy.

Fixes simulator assert in VkQuake.

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

v3dv: handle draw after barrier

Currently, we end the current job whenever the user emits a
pipeline barrier, but we then expect to have a valid job when
we emit a draw call.

If by the time we have to emit a draw call we don't have a valid
job, we need to create one by resuming execution of the current
subpass.

Fixes some tests in:
dEQP-VK.renderpass.suballocation.attachment_allocation.input_output.*

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

v3dv: improve handling of too large image sizes

Instead of asserting that users don't try to create images that
would require 4GB+ of memory, error out with the corresponding
OOM error when the user tries to actually allocate the memory
for the image.

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

v3dv: add workaround for GFXH-1602

The first attribute must be active if using builtins.

This fixes a lot of simulator crashes for vertex input CTS tests.
It should be noted that some of these tests still fail after this
fix though, so there may be some other bug.

Fixes crashes in:
dEQP-VK.pipeline.vertex_input.multiple_attributes.*

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

v3dv: fix GFXH-930 workaround

We want to check if the coordinate shader is reading attributes, not
the vertex shader.

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

v3dv/device: expose support for image cube array

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

nir: include texture query lod as one of the ops that requires a sampler

In practice we found that we need this for v3d (specifically for cube
map arrays, as they don't support the default value for wrap_i, so a
sampler object is needed to override that value).

It is worth to note that the main reason behind this auxiliar method
was to identify those cases that we didn't have a sampler object
available for Vulkan. So far, we found that we have a sampler object
coming from nir always for that operation.

Fixes cube map array tests like the following:
dEQP-VK.glsl.texture_functions.query.texturequerylod.usamplercubearray_fragment

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>

v3dv/uniforms: support for some QUNIFORM_IMAGE_XXX

As we are using the descriptor sets to access to the specific
v3dv_image_view, we can just reuse the existing methods for the
textures.

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

v3dv/pipeline: lower_image_deref

This is really similar to the existing lower_tex_src_to_offset, but
for now we prefer to keep them independent, just in case we start to
found specific image use-cases as we advance fixing CTS tests.

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

v3dv/descriptors: support for DESCRIPTOR_TYPE_STORAGE_IMAGE

From the descriptor pov is mostly another image without sampler, so
for example, on the descriptor pool bo we only store the texture
shader state.

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

v3dv: implement support for shader spilling

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

v3dv: lower frexp

Fixes:
dEQP-VK.glsl.builtin.precision.frexp.*

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

v3dv: lower unpack_{u,s}norm_2x16

The hardware doesn't have unorm/snorm packing variants and we were
already lowering the packing versions of these.

Fixes:
dEQP-VK.glsl.builtin.function.pack_unpack.unpacksnorm2x16_compute
dEQP-VK.glsl.builtin.function.pack_unpack.unpackunorm2x16_compute

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

v3dv: don't reset descriptor state after a meta operation

If the meta operation did not change descriptor state then we should keep it,
not reset it.

Fixes:
dEQP-VK.fragment_operations.early_fragment.early_fragment_tests_stencil
dEQP-VK.fragment_operations.early_fragment.no_early_fragment_tests_stencil

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

v3dv: handle empty set layouts

Fixes:
dEQP-VK.api.object_management.max_concurrent.descriptor_set_layout_empty
dEQP-VK.api.object_management.single_alloc_callbacks.descriptor_set_layout_empty

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

v3dv: initial support for input attachments

We are treating them as a special case of texture, so the commit is
mostly about integrating them with the existing
SAMPLER/SAMPLER_IMAGE/COMBINED_IMAGE_SAMPLER infrastructure.

This commit doesn't use in any special way the render pass
information, including the dependencies, so it is possible that we
would need to do something else. But this commit gets several CTS
tests, and two Sascha Willem Vulkan demos, so let's start with this
commit and handle any other use case for following commits.

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

v3dv/pipeline: set load_layer_id to zero

We don't support layered rendering so let's lower the intrinsic to
zero for now. Based on turnip commit 99a4f7c ("turnip: set
load_layer_id to zero")

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

v3dv/pipeline: iterate used textures using the combined index map

So far we were using nir->data.num_textures to fill the default values
for the textures used on the shader, and set the value for the number
of textures used.

But nir->data.num_textures doesn't take into account input
attachments, even after nir_lower_input_attachments. Although that
could make sense from a general pov, in our case we are treating input
attachments mostly as textures.

This commit count the number of textures interating through the
pipeline combined index map, as it includes both. This also makes the
populate of the shader key for default values more similar to the one
done at cmd_buffer with real values.

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

v3d/tex: avoid to ask back for a sampler state if not needed

So far we were not asking the driver for the sampler state if we could
just use the default P1 values. But even if we need to fill P1 (for
example to fill up the output type of the format), if the texture
operation doesn't need a sampler, we can let that field as NULL (so
default values) and avoid calling back the driver for a sampler.

This is not mandatory for OpenGL (as we always have a sampler object),
although still a good to have. For Vulkan this is needed, as we don't
have a sampler object in that case.

v2: reword comment (Eric)

Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>

v3dv: pipeline initialization fixes for disabled rasterization

When rasterization is disabled there are a number of CreateInfo
structs that should be ignored. We were managing this correctly
for some cases, but not all of them. Specifically, viewport state
must be ignored and we weren't doing that.

Fixes:
dEQP-VK.api.descriptor_set.descriptor_set_layout_lifetime.graphics

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

v3dv: don't free BOs from imported memory objects

Only free the underlying BO when the exported memory object is freed
to avoid multiple frees of the same memory.

The only exception is winsys BOs where we import a BO created in the
display device into the render device. In this case, we only have one
memory object referencing the BO and we want to destroy it with that
memory object.

Fixes:
dEQP-VK.api.external.memory.dma_buf.*
dEQP-VK.api.external.memory.opaque_fd.*

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

v3dv: assert that our framebuffers are single sampled

This makes it easier to track CTS test fails related to multisampling,
which we don't support yet.

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

v3dv: return a proper error for too large buffer allocations

Fixes: dEQP-VK.api.buffer.basic.size_max_uint64
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>

v3dv: implement indirect compute dispatch

The hardware can't do this, so we need to record a CPU job that will
map the indirect buffer at queue submission time, read the dispatch
parameters and then submit a regular dispatch.

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