v3dv: vkCmdCopyBufferToImage for depth/stencil formats

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

v3dv: implement vkCmdCopyBufferToImage for color formats

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

v3dv/cmd_buffer: support for push constants

By default they are trivially lowered to load_uniform.

We still need to allocate an UBO for push constants, used for those
that are accessed using a non-const index. This is automatically
handled by the compiler, as it cames back as asking a
QUNIFORM_UBO_ADDR. This is what already does for gallium.

Note that if needing the UBO, we are uploading the full push constant
data. An improvement would be to try to upload only the data that
needs to rely on the UBO (so non-const accesses to uniforms).

Also, the code is not handling getting out of space from the UBO
bo. This would be tackled at a different commit.

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

v3d/compiler: handle GL/Vulkan differences in uniform handling

This also adds a v3d_execution_environment, so compiler could know if
it is generating code for OpenGL or Vulkan needs.

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

v3dv: implement vkCmdClearDepthStencilImage

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

v3dv: fix buffer automatic stride for image to buffer copies

When the client requests a tightly packet copy, we should take
the stride from the size of the region to copy, not from the size
of the image (which can be larger).

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

v3dv: implement vkCmdClearColorImage

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

v3dv: implement vkCmdCopyImage

As with vkCmdCopyImageToBuffer, this implements a fast path using the
TLB for the case where we are copying images from offset (0, 0). We
don't have the fallback path for other cases yet.

For this we need to rethink a bit our loads and stores so we can handle
depth/stencil copies correctly. Specifically, we are expected to do
different things depending on whether we are copying to a linear buffer
or to an image.

When copying depth/stencil to a buffer, we can only copy one aspect
at a time and the result should be tightly packed in the destination
buffer.

When copying depth/stencil to an image, we can copy one or both aspects,
and we need to write them in the corresponding aspect of the destination
image.

Because we can't do stores from the Z/S tile buffers in raster format,
we need to do image to buffer copies of these aspects using the a color
tile buffer and a compatible color format. However, when we are copying
to another image, since we need to write the channels in the corresponding
aspect of the destination image, we need to do this using by loading and
storing from an appropriate Z/S tile buffer.

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

v3dv: fix copy size for image to buffer copies

For some reason we were ignoring the extent to copy that was
passed in the region to copy and instead we were computing a
a region based on the image size and the selected miplevel.

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

v3dv: refactor common code in meta copy operations

Creates internal helpers to avoid replicating code in various places
and uses the fake framebuffer to pre-compute supertile coverage.

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

v3dv: add a concept of a fake framebuffer for meta-copy operations

This is mostly to simplify some of the code and avoid the need to pass
the internal type of our single render target to every function in the
chain.

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

v3dv: move the framebuffer setup code for buffer copy/fill to a helper

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

v3dv: implement vkCmdFillBuffer

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

v3dv: implement vkCmdUpdateBuffer

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

v3dv: implement vkCmdCopyBuffer

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

v3dv: don't advertise texel buffer support yet.

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

v3dv: Add more supported formats to our format table

Some of these may need additional work to work for real, but we should
be able to support them.

We also include some formats that are not supported for images, but
that we want to support for buffers, such as R32G32B32 for a vertex
buffer.  In the future we might want to expand the format table to
specify which formats are supported for buffers.

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

v3dv: no need to manually add assembly bo to the job

The _cl utility methods are already doing that implicitly, as a way to
ensure that any address emitted gets its bo included on the job.

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

v3dv: take the number of layers from the framebuffer

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

v3dv: ignore image view aspects for depth/stencil attachments

 From the Vulkan spec:

   "When an image view of a depth/stencil image is used as a
    depth/stencil framebuffer attachment, the aspectMask is ignored
    and both depth and stencil image subresources are used."

So in that scenario, we ignore the aspect mask on the view and go
check the actual format of the underlying image to decide if we
have depth or depth+stencil aspects.

This gets VkRunner's depth-buffer.shader_test to pass.

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

v3dv: fix clockwise primitive setting

It looks like the hardware does this backwards. The GL driver
also reverses it.

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

v3dv: implement indexed draws

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

v3dv: implement vkCmdClearAttachments

For now this only implements a fast path using the tile buffer, so it
can only be used when clearing full images, but this is good enough
for VkRunner.

The implementation is a bit tricky because this command executes
inside a render pass, and yet, since we are using the tile buffer to
clear, this needs to go in its own job. This means that with this, we
need to be able to split a subpass into multiple jobs which creates
some issues.

For example, certain operations, such as the subpass load operation
(particularly if it is a clear) should only happen on the first job of
the subpass and subsequent jobs in the same subpass should always
load.

Similarly, we should not discard the last store on an attachment
unless we know it is the last job for the last subpass that uses the
attachment.

To handle these cases we add two new flags to the job, one to know if
the job is not the first in a subpass (is_subpass_continue) and
another one to know if a job is the last in a subpass
(is_subpass_finish).

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

v3dv: add a helper to get the Z/S buffer from an aspect mask

We will be using this when we need to implement other clearing commands.

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

v3dv: add a helper to compute the hardware clear color

We will be using this when we implement other clearing commands
(currently this is only used for the atatchment load clear operation).

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

v3dv/pipeline: null check for pCreateInfo->pDepthStencilState

This prevents a crash when the validation layers are enabled for some
of our ubo tests. Again, it seems that if some attachments are
missing, the validation layers remove some of the structs from the
pCreateInfo.

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

v3dv/descriptor_set: support for array of ubo/ssbo

For that we include the array_index when asking for a ubo/ssbo index
from the descriptor_map.

Until now, array_index was not included, but the descriptor_map took
into account the array_size. This had the advantage that you only need
a entry on the descriptor map, and the index was properly return.

But this make it complex to get back the set, binding and array_index
back from the ubo/ssbo binding. So it was more easy to just add
array_index. Somehow now the "key" on the descriptor map is the
combination of (set, binding, array_index).

Note that this also make sense as the vulkan api identifies each array
index as a descriptor, so for example, from spec,
VkDescriptorSetLayoutBinding:descriptorCount

 "descriptorCount is the number of descriptors contained in the
  binding, accessed in a shader as an array"

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

v3dv: initial descriptor set support

Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.

This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.

Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.

We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).

Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.

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

v3dv: debug nir shader also after spirv_to_nir

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

v3dv: fix the mess with dynamic state handling

The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.

This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.

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

v3dv: implement dynamic stencil states

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

v3dv: clamp stencil masks and reference value to supported limits

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

v3dv: implement early Z optimization

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

v3dv: fix viewport state from pipeline

We were not computing viewport transform for static viewports provided with
the pipeline state. Also, we were not copying the transform into the command
buffer state when we bound the pipeline.

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

v3dv: support copying depth/stencil aspects to buffer

Just as with color copies, we only support tile buffer copies for now,
so we can only copy regions that start at offset (0,0).

Because the hardware doesn't support storing depth/stencil buffers to
raster format, we need to load and store our data to/from the tile
buffer as a compatible color format instead.

The Vulkan spec also has specific expectations regarding placement
of X8/S8 bits in 24-bit depth formats which don't match the hardware's
so these formats require specific work so we can swizzle channels
to match the Vulkan spec.

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

v3dv: fix indentation

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

v3dv/bo: add a bo name

This is only used when doing a clif/cle dump, but makes it far easier
to understand.

Most names are the same that the ones used at v3d (CL, tile_alloc,
TDSA), except those that on v3d were labelled as "resource", as right
now we don't have a resource uploader that englobes different
things. In fact, the good thing of not having that uploader is that
individual bos has a more accurate description of their purpose.

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

v3dv: implement stencil testing

This works on combined depth/stencil formats only, separate stencil
is not supported yet.

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

v3dv: support depth testing on combined depth/stencil formats

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

v3dv: select correct internal type for depth/stencil formats

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

v3dv: select the depth/stencil buffer from the attachment aspect mask

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

v3dv: compute subpass ranges for attachments at render pass creation time

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

v3dv: don't always skip tile buffer stores

Otherwise we would lose updates relevant to subsequent subpasses in
the same renderpass that read or partially write the attachment.

The only scenario where we can safely do this is on the last subpass
that uses the attachment, so long as we don't need to emit the store
for the clear.

This also fixes a bug in the computation of the first subpass that
uses an attachment.

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

v3dv: implement support for depth testing

This ignores stencil for now and focuses on depth testing without
support for early depth testing.

To implement this we need to start considering how many of our
framebuffer attachments are color attachments, since some of the
computations we use to determine tile sizes and binning configuration
depend on this.

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

v3dv: don't swap RB channels when copying images to buffers

We don't need to do this, since we are just copying. Also, we are not
swapping on the store, so doing it on the load would be incorrect.
This gets the prime blit present path in WSI common to render R/B
channels correctly after blitting from the BGRA image to the linear
buffer for display output.

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

v3dv: rename drm device fields so they are more explict

Also, remove references to the master_fd. This is only useful for
VK_KHR_display which we are not currently implementing.

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

v3dv: allocate winsys BOs properly

When running on real hardware we need to allocate winsys buffers on
the display device and import them into the v3d device for rendering.

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

v3dv: implement device detection on actual hardware

When running on the real hardware we have two devices: the v3d render
node and the vc4 display node. We need the latter to allocate
winsys BOs for v3d to render into. Since exporting these BOs is
a privileged operation, we need to obtain the fd for this device
through the display server. For now we only support doing this through
the XCB DRI3 platform.

Also, do not duplicate or re-open the DRM devices when creating logical
devices. The simulator checks that the file descriptor is exactly
the same we used to initialize it when we created the physical device
and aborts if it sees a different fd number, even if it points to the
same device.

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

v3dv/pipeline: adding some nir-based linking

Among other things, gets a constants output from a vs, used as input
to a fs, to get lowered and moved as a load const on the fs.

Heavily based on st_glsl_to_nir, already used by the v3d
driver. Slightly adapted to our needs, but there are still room for
customization.

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

v3d/cmd_buffer: emit flat_shade/noperspective/centroid flags

We just emit the default ZERO_ALL values, to cover at least the cases
where that is enough. Need to emit non-default values if needed.

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

v3dv: stubs for Create/DestroyPipelineCache

Good enough to avoid vkrunner crashing.

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

v3dv: hook up WSI support

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

v3dv: implement DRM modifier setup for WSI

This is only really relevant when running on real hardware, since
when we run on the simulator we don't care about the format of the
swapchain images.

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

v3dv: implement vkGetImageSubresourceLayout

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

v3dv: fix copy image to buffer

If either of bufferRowLength or bufferImageHeight are zero, then that
aspect alone of the image is tighly packed. We were assuming that if
either was zero both aspects were tightly packed, which is wrong.

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

v3dv: implement VK_KHR_external_memory{_fd,_dma_buf}

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

v3dv: implement VK_KHR_external_memory_capabilities

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

v3dv/format: add R32G32B32A32_SFLOAT format

This is clearly supported, and we already confirmed that work with
some of our tests.

Needed to avoid an assertion of such tests when validation layers are
enabled.

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

v3dv: implement VK_KHR_get_physical_device_properties2

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

v3dv: include Vulkan version 1.1 as unsupported.

This is so we can generate entry points for extensions that have been
promoted to core in 1.1.

Entry points for promoted extensions are aliased without the KHR suffix
in the Vulkan API XML, and the entry point generation scripts are designed
to point the dispatch tables to entry points generated from the non-aliased
function names, however, these are not included in the header file without
this change.

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

v3dv: implement vkGetPhysicalDeviceSparseImageFormatProperties

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

v3dv: provide default values for input attributes

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

v3dv: vertex input support

This includes:

   * Implementation for CmdBindVertexBuffers

   * Gather vertex input info during CreateGraphicsPipelines
     (pipeline_init) and SHADER_STATE_ATTRIBUTE_RECORD prepacking

   * Final emission of such packet during CmdDraw
     (cmd_buffer_emit_graphics_pipeline)

Default attributes values will be handled on a following patch.

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

v3dv/pipeline: lower fs/vs inputs/outputs

For now mostly call to nir_assign_io_var_locations

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

v3dv: support queue submissions with multiple command buffers

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

v3dv: implement fences

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

v3dv: implement semaphore waits and signals on queue submissions

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

v3dv: implement vk{Create,Destroy}Semaphore

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

v3dv: implement vkDeviceWaitIdle

This is really a hack, but it is better than not having anything. In the
future we should have a syncobject that we could wait on.

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

v3dv: prepack VCM_CACHE_SIZE

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

v3dv: partial prepack of the gl_shader_state_record

We can't prepack all the record, as addresses need the job, and
uniforms depend on dynamic value.

Also due cl_emit_with_prepacked and v3dv_pack asserting correct
values, we need to define two values twice, that lead to move
vpm_config to the pipeline. In any case, the latter will be useful
when we start to prepack more stuff.

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

v3dv/cmd_buffer: emit CFG_BITS

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

v3dv: handle VK_ATTACHMENT_UNUSED properly in more places

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

v3dv/cmd_buffer: rename render pass RCL emission helpers to be more explicit

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

v3dv: create a helper to start a new frame

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

v3dv: rewrite the attachment needs clearing condition

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

v3dv: fix tile buffer loading

So we do what we actually state in the comment. Particularly, the load
operation only affects the first subpass that uses the attachment,
after that we always want to load, but we were only doing that for
attachments marked as CLEAR.

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

v3dv: merge subpasses into the same job when possible

Generally, we can do this when they render to the same collection of
attachments and we only need to emit a single RCL for them.

To implement this, we need to track the first subpass that is included
in the job and rewrite our loads and stores in the RCL to refer to that
subpass instead of the current subpass (which would be the last included
in the RCL).

When we merge jobs we also reuse the tile state/alloc BOs and we only
emit the binning setup once.

The environment variable V3DV_NO_MERGE_JOBS can be set to disable
job merging and have each subpass be in a separate job. This can be
useful for debugging issues spawning from incorrect subpass merges.

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

v3dv: only clear attachments on the first subpass that uses them

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

v3dv: rewrite attachment state tracking

Keep track of attachment state for each attachment in the renderpass
instead of tracking it only for the attachments in the current subpass.

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

v3dv: add a note on interactions between clearing and scissor

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

v3dv: fix clipping against render area

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

v3dv: do not automatically emit a binner flush when finishing jobs

Binner flushes should be emitted naturally at the end of each draw,
if we are finishing a job and it doesn't have the binner flush, it
probably means that we have bogus emission code somewhere.

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

v3dv: implement vkCmdPipelineBarrier

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

v3dv: use the correct miplevel slice for the tile load operation

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

v3dv: implement vkCmdNextSubpass

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

v3d/compiler: update uses_vid/uses_iid check

In order to take into account the vulkan specific system values
SYSTEM_VALUE_INSTANCE_INDEX and SYSTEM_VALUE_VERTEX_ID_ZERO_BASE.

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

v3dv/cmd_buffer: start jobs with CmdBeginRenderPass

We want to create jobs when we start a new render pass so that
commands in the first subpass have a job.

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

v3dv: add the concept of a job

As we make progress towards more complex submissions we will need to split
our command buffers into smaller executable units (jobs) that we can
submit indepdently to the kernel. This will be required to implement
pipeline barriers, split subpasses that have depedencies on previous
subpasses, split render passes that use more than 4 render targets, etc.

For now we keep things simple and we only keep one job as current
recording target in the command buffer, and we generate a new one
with every subpass or with any commands we see outside of a render pass
(only vkCopyImageToBuffer for now). In the future we probably want to
optimize this by merging subpasses into the same job when possible,
etc.

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

v3dv: implement vkCmdCopyImageToBuffer

For now we only support the TLB path, which limits us to copying
regions that start at offset (0,0). In the future, we will need to add
a fallback path that uses blitting to copy regions with an offset.

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

v3dv: rename and make compute_tile_size_for_framebuffer() public

We will use this when we implement copying images to buffers using the
TLB, where we'll need to setup a framebuffer and tiling configuration
for the TLB store to the destination buffer.

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

v3dv: split framebuffer internal bpp calculations from tiling calculations

We want to reuse the latter aspect in a context were we already have
the internal bpp available.

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

v3dv: add v3dv_write_uniforms

Initial port of the equivalent v3d_write_uniforms, to be used by the
cmd_buffer when emitting the drawing packets.

Initially doesn't include all the quniform types, only those needed by
the initial basic vulkan tests.

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

v3dv/cmd_buffer: cache viewport translate/scale

Before that commit we were calling get_viewport_xform to get those
values twice (to emit scissor and viewport), and we found that we
would need that info even more times. So let's just compute that info
when setting the viewport, and reuse the values.

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

v3dv: clif format dumping support

Add support for V3D_DEBUG=clif. Useful to compare clif_dumps from
vulkan small-programs and the equivalent opengl ones.

As we are here we expand clif_dump_packet wrapper to use
v3d42_clif_dump_packet if needed, as the vulkan driver would use that
packet version.

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

v3dv/cmd_buffer: add shader source bos to cmd_buffer

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

v3dv/cmd_buffer: start to emit draw packets

Starting using only the packet VERTEX_ARRAY_PRIMS

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

v3dv/cmd_buffer: emit shader_state packets

Values still doesn't take into account having vertex elements data,
but keeps some of that half-done code in comments. It would be better
to do that when we get an example using it.

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

v3dv: flush at the end of each subpass

We can't start a new BCL if we haven't flushed the current one, so
make sure we do that at the end of each subpass for now.

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

v3dv: emit tile loads

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