We implement this by blitting the requested region to a linear image
setup to use the buffer memory store at the requested offset.
Because we can't store linear depth/stencil images, we implement
copies of depth/stencil aspects by using a compatible color blit.
To do this, we also need to account for the fact that when we are
copying depth from a d24 format we need to copy them from the MSB
24-bits of each word as provided by the hardware and store them
in the LSB 24-bit of the buffer (as per Vulkan requirements). This
is achieved by expanding our blit interface to also accept a swizzle
to apply to the source texture.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
The page alignment requirement is for UIF images only, and for linear
images it is actually useful to use a 4-byte alignment so we can
use them to write images to linear buffers at arbitrary positions, which
we will need when copying subrects of an image to a buffer.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
An image can be suballocated from a larger memory allocation, in which
case we get a memory offset for the start of the bound region at
vkBindImageMemory. Take that offset into account when doing image
addressing calculations.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
With compressed formats we compute the final height/width dividing by
the block sizes. On some cases the block sizes are bigger that the
original values, or it is not a exact division, so we need to round up
the division.
Fixes tests like:
dEQP-VK.texture.compressed.*
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
As opposed to returning true only if it can handle the case and it
also successfully processes it.
This is because we expect handled cases to be successfully processed
except in abnormal situations such as out-of-memory errors. If an OOM
is the reason a fallback path fails, we don't want to try another path
(which will likely hit an OOM too): we have already recorded the OOM
error in the command buffer and we just want to stop executing the
command, so just flag the case as handled and move on.
Also, if we don't do this, in an OOM scenario we'll likely end up running
out of fallback paths and end up asserting (on debug builds), which makes
some CTS tests unhappy because they expect OOM to be handled more
gracefully, so this allows us to make CTS happy also in debug builds,
which is convenient.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
In "v3dv: implement stencil aspect blits for combined depth/stencil format"
we only implemented the support we needed to implement partial copies.
Copies only allow to copy a single aspect, so we really only supported blitting
either the depth aspect or the stencil aspect, but not both, however,
actual blits (as per vkCmdBlitImage) allow to blit both stencil and depth
aspects at the same time, so this adds support for that.
Finally, this also fixes the fact that we were not really masking color writes
effectively for stencil-only blits, since create_blit_pipeline() would check
the requested aspect to see if it would need to mask writes, but by the time
we called this, we had already switched the aspect to color. The reason this
was not caught before is that for copies this would only mean that when we
copied stencil we would also copy depth, and the image copy CTS tests are
probably copying both aspects anyway.
Fixes:
dEQP-VK.api.copy_and_blit.core.blit_image.all_formats.depth_stencil.*d24_unorm_s8_uint*
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
The idea is that we also want to use the blit mechanism to implement
the copy, like we do for partial image copies. Unfortunately, we can't
sample from a linear image, so we first need to upload the buffer
contents to a tiled image, and then blit from that image to the
destination, which is not great for performance or memory usage.
In the future, we mihgt be able to do better by using a specialized
shader for these copies that takes a UBO as input instead of a texture.
The shader would then be able to access the linea buffer through the
UBO directly without having to copy the buffer contents to a tiled
image first.
This only supports color images for now, we will add support for
depth/stencil images separately.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
Since we don't support rendering to compressed formats, we implement this
by using a compatible format with the same bpp as the compressed format.
However, we need to take into account that the underlying compressed image
bpp is computed for a full block, so when we specify regions on the
compressed image, we need to divide offsets and dimensions by the block
size.
This works well for anything that copies to a compressed format using
the TLB, but it doesn't specifically address copies from compressed
formats to other compatible images. These go through the blit path
and require to copy by blitting (texturing) from the compressed format
to another format. In this case, we choose a comptible format with
the per-texel bpp (not the block bpp) of the compressed format so it
matches the setup for the blit operation.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
To do this we just implement the stencil blit as a masked color bit
with uint8 format. This allows us to support blitting on combined
depth/stencil formats, and therefore, also partial image copies
for these formats.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
For this we use blits with nearest filtering and choose a compatible
format for the render target if the copy format is not renderable.
This works for all supported formats except combined depth/stencil
(for which we don't support blitting for now) and compressed formats.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
So far we were just asserting or aborting if any of the internal
method used during the pipeline creation failed.
We needed to change the return value of several methods, in order to
bubble up the proper memory allocation error.
Note that as the pipeline creation is complex and splitted in several
methods, if an error happens in the middle, it returns back, and rely
on the higher level to call PipelineDestroy. This method needs to take
into account that some of the resources could have not been allocated
when freeing it.
Also note that v3dv_get_shader_variant is used during the pipeline
bind, as with the new resources bound, we need to check if we need to
recompile a new variant. At that moment we are not creating a new
vulkan object so we can really return a OOM error. For now we just
assert on that case.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
This was allocating image views in the stack, which was kind of
hackish, and of course was expecting that allocated Vulkan objects
could be immediately freed after being recorded in the command buffer
which is not always safe to do in the general case (even if it was
here). This makes things more consistent and reliable.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
This uses the framework to register private commmand buffer objects
that get freed automatically when the command buffer is destroyed by
the application.
This change also moves the descriptor set pool that the meta blit path
uses to allocate descriptors for the blit source textures, from the
device to the command buffer, so we can have a descriptor pool per
command buffer. This is necessary to ensure correct behavior when
doing multi-threaded command buffer recording (alternatively, we would
have to lock around the descriptor set allocation code, which would be
undesirable).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
This allows the driver to register private Vulkan objects it creates as part
of command buffer recording (usually for meta operations) in the command
buffer, so they can be destroyed together with it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
The hardware can't do sampling from raster depth/stencil textures and
1D images are always raster, even if the user requested optimal tiling.
Using an image as the source of a blit is a transfer source operation,
so we can't expose that either, as blitting involves sampling.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
In this case the hardware seems to copy the bits that actually fit
in the destination instead of clamping to the maximum value allowed
by the bit size of the destination components like Vulkan expects.
Fix this by adding code to clamp the color results to the bit size
of the destination components.
It should be noted that this is a general issue with the hardware,
and while we can fix it here for blits done by the driver, user
shaders writing outside the range of the destination bit size will
have the same issue and we probably don't want to add code to clamp
every single render target write in every shader with integer format.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
The pipeline stages have a reference to the NIR code produced from
the SPIR-V shader modules, but they never destroy it.
It should also be noted that our coordinate shader stage was sharing
the NIR with the vertex shader stage, which is kind of tricky to handle
and probably very error prone. Just make sure each pipeline stage has
owns it NIR shader and that we always free it when the stage is
destroyed.
Also, for the case of NIR modules created by the driver internally,
we always need to clone them, since the driver will destroy the NIR
as soon as it is done creating pipelines with it. We could also not
clone it and let the pipeline stage take ownership of the NIR code for
NIR modules, but that would be inconsistent with how ownership works for
SPIR-V modules.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
This needs to be updated everytime we bind a new pipeline, but we can
bind a pipeline and not have an actual job yet, so we want to postpone
this until we actually need to emit CFG_BITS, during the pre-draw
setup.
Also, rename the update helper to be about the job rather the command
buffer, since it is updating state that we track per job.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
We were asserting that we had a valid subpass index, but we can have
meta operations that run outside a render pass, such as for blitting.
If we allow this, then we also need to account for the fact that
pipelines can be bound outside a render pass too.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
While very limited in scope, this might be the most efficient way to blit
when applicable. In fact, we might also want to use this for the image copy
commands when possible instead of the TLB.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
This is similar to the scenario where we have a submit without
any command buffers, even if we don't have any actual GPU work to do
we still might need to signal fences/semaphored and possibly wait on
previous jobs to finish, so we need to submit something to the kernel
to get all that done right.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
Most of our state doesn't carry over across jobs, so it needs to be re-emitted.
For example, if we have two render passes running back to back using the
same pipeline, the application could decide to only bind the vertex buffer
or/and the pipeline just once, but as soon as we record the second render
pass and create a new job for it we will need to re-emit the shader state
record for it just because it is a new job.
We could probably only do this for jobs inside a render pass, since those
are the only ones that actually draw something and need to care about
dirty state, however, there is no harm in doing this for all jobs, for the
same reason.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
We were enabling VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT for
any format valid for texturing, but for example, right now we don't
support linear filtering on any depth format.
This is needed to get some hundreds of tests like this:
dEQP-VK.pipeline.sampler.view_type.1d.format.r32g32_sfloat.mag_filter.linear
properly skipped (those were all Crashes with the simulator, and
almost all Fails with the real device).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
When testing if we could merge the new subpass into the previous one
We were taking the subpass index from the state (which isn't updated
to the new subpass until a bit later when the job for the new subpass
has been settled). This means that we were doing the merge checks with
the previous subpass, not the current one.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
There are some texture operations (like mipmap query levels) that
doesn't require a sampler. In fact, you should ignore it. So we need
to take it into account when combining the
indexes. nir_tex_instr_src_index is returning a negative value to
identify that case, but as we are using a uint32_t to pack both values
(for convenience, easy to pack/unpack the hash table key), we just use
a uint value big enough to be a wrong sampler id.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
This requires that we emit a specific draw command and that we emit
the base instance if not zero right before the instanced draw call.
Notice that we were already doing this for instanced indexed draw
calls, so here we are only adding this for non-indexed draw calls.
We also need to flag whether the vertex shader reads the base instance
in the shader record (which it will if it reads uses gl_InstanceIndex,
as that is lowered in Vulkan to base_instance + instance_id).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
Iago Toral Quiroga
Alejandro Piñeiro