We compute and store pipeline flags in the pipeline object but
we may need to access flags even in the case where the pipeline
init fails.
Fixes: 3f3c83a6b7 ('v3dv: handle VkPipelineCreateFlags2CreateInfoKHR')
Fixes: dEQP-VK.pipeline.monolithic.creation_cache_control.graphics_pipelines.batch_pipelines_early_return_maintenance5
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29669>
VK_KHR_maintenance5 adds additional guarantees for functions that
can return VK_ERROR_DEVICE_LOSS to return this error if the device
was previously lost.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29668>
VK_KHR_maintenance5 adds two new optional formats:
- VK_FORMAT_A1B5G5R5_UNORM_PACK16_KHR
- VK_FORMAT_A8_UNORM_KHR
The former we support natively, the latter we don't. We could
try to implement A8 with some effort by mapping it to R8 with
a 000X swizzle but that alone won't be enough, some issues we
would have to solve include:
- Border colors won't work because the texture shader state
swizzle also applies to these, so our 000X swizzle would mess
things up for them and since we don't know the format used with
the sampler in the general case, we would have always have to
create two samplers internally, one adequate for A8 and one for
the rest of formats and choose one or the other at run time.
- We would have to convert the A8 format to a compatible
R8 format but most of the transfer operations. This should be
fairly trivial since we already have infrastructure for this.
- At rendering time we would need to ensure we make our writes
from the alpha channel. This would probably require that we
use the color_fmt from the fs_key to swizzle color writes in
shaders.
- We would probably also need to special case the format for
color clears, etc
So for now, we don't support it.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29643>
Right now we have a statically allocated vk_graphics_pipeline_state,
that we declare at pipeline_init, and fill at
pipeline_init_dynamic_state. This one can be static as right now it is
only needed during pipeline_init lifetime.
But to fill it, we need a vk_graphics_pipeline_all_state structure,
that right now we declare at pipeline_init_dynamic_state. But that one
become part of that vk_graphics_pipeline_state, so still needed at
pipeline_init.
This was detected when trying to refactor the code to use the
pipeline_state later on, but it raises an "invalid read" error using
valgrind with the current code. It is surprising that didn't cause any
problem.
Fixes: f2236065b7 ("v3dv: port dynamic state tracking to use Mesa Vulkan")
Cc: mesa-stable
Reviewed-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29603>
In the case of buffer to image stores, we work around the limitation
for linear images by loading D/S data into a the color tile buffer
using a compatible format, however, this only works for formats with
a single aspect, for combined depth/stencil formats, since the copies
are specified to only copy a single aspect, we need to be able to
preserve the contents of the other aspect in the destination image,
and for that we still use the depth/stencil buffer, so we are affected
by the restriction.
Fixes some VK_KHR_maintenance5 CTS tests that hit this scenario,
such as some tests in:
dEQP-VK.api.copy_and_blit.core.image_to_image.all_formats.depth_stencil.2d_to_1d.*
In the case of image to image copies, we don't have any workarounds for
linear depth/stencil so we always want to skip the TLB path. I have not
seen any tests hit this scenario.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29597>
We can't render to linear depth/stencil formats but the blit shader
automatically converts D/S blits to compatible color blits where we
don't have this restriction.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29597>
In addition to always being good to have some documentation, it was
added to clarify that if you use the macro to fill up values, it will
not override the values coming from the prepacked buffer, but doing an
OR.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29570>
The intent behind these asserts is to ensure the layer is within
bounds, so we rather check it is within the image layer count than
within the layerCount of the image subresource passed by the API.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29544>
If the cache is disabled then we need to destroy the pipelines
manually when they are no longer needed. Do that by adding them
as private objects to the command buffer.
Fixes: 4f26303dbb ('v3dv: add debug option to disable custom pipeline caches for meta operations')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29544>
Right now we have some HW-dependant constants that we are accessing
using the same mechanism that some hw-dependant functions, through a
macro (V3DV_X macro).
But this means that each time that we need to get those constant
values, we need to do a hw version check. Also, right now both the
macro and the defines with each HW value are duplicated on v3d and
v3dv. Also that macro is ugly and has a ugly name.
This commit moves those values to the already common v3d_device_info
structure.
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29535>
Introduced with VK_KHR_maintenance5, this is equivalent to
vkGetRenderAreaGranularity but for dynamic rendering where
we don't have render passes.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29468>
Macro values that define values for different HW generations should
use the V3DV_X helper instead of being defined under a V3D_VERSION #if
condition.
Without this change, the original V3D_CLE_READAHEAD and
V3D_CLE_BUFFER_MIN_SIZE definitions used were only working for 4.2 HW.
For the 7.1 HW (RPi5) the 4.2 definitions were applied.
The CLE MMU errors were hidden as they were reported at dmesg as
"MMU error from client PTB (1) at 0x1884200, pte invalid" instead of
client CLE. So fixes all v3dv dmesg warnings for PTB MMU errors on RPi5.
With this change we really don't need different functions per HW generation,
so we rename back file v3dvx_cl.c to v3dv_cl.c. As before, we can use
only the packets definitions for 4.2 HW as they use the same opcode as 7.1 HW.
It fixes also an indentation error introduced with 26c8a5cd72.
Fixes: bb77ac983e ("v3dv: Increase alignment to 16k on CL BO on RPi5")
Fixes: 26c8a5cd72 ("v3dv: fix CLE MMU errors avoiding using last bytes of CL BOs.")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29496>
So the version matches exactly the same as reported by the kernel in
`/sys/kernel/debug/dri/128/v3d_ident`, or the version used in the
simulator.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29186>
Since we now use the common vulkan runtime to handle pipeline state and
this sets a limit for this at MESA_VK_MAX_VERTEX_BINDING_STRIDE we should
do the same, or else we can run into an assert-fail in the runtime code.
Fixes:
dEQP-VK.pipeline.monolithic.bind_buffers_2.maintenance5.triangle_list.buffers5.stride_offset_rnd321.whole_size
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29454>
We were exposing them as zero, as based on just the name, we assumed
that it was about the descriptors using the
VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT bit.
But from spec, that limit takes into account descriptors created *with
or without*, so for example:
"maxPerStageDescriptorUpdateAfterBindUniformBuffers is similar to
maxPerStageDescriptorUniformBuffers but counts descriptors from
descriptor sets created with or without the
VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT bit
set."
As we don't support the feature, those limits are the same of the
existing without the DescriptorUpdateAfterBind.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29430>
We were multiplying it by 6, that is the number of possible shader
stages, but from spec it points that we need to multiply by the number
of supported shader stages.
From Vulkan 1.3 spec, chapter 33, "Limits", note 8 on Table 33
"Required Limits":
"The minimum maxDescriptorSet* limit is n times the corresponding
specification minimum maxPerStageDescriptor* limit, where n is the
number of shader stages supported by the VkPhysicalDevice. If all
shader stages are supported, n = 6 (vertex, tessellation control,
tessellation evaluation, geometry, fragment, compute)."
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29430>
This is added with VK_KHR_maintenance5 to allow 64-bit
for pipeline creation flags.
The flags are backwards compatible so we don't need to
change the flag enum values by the new ones.
This patch also addresses a small issue where compute pipelines
where not initializing the flags field in the pipeline object.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29449>
This is added with VK_KHR_maintenance5 to allow 64-bit
for buffer usage flags.
The flags are backwards compatible so we don't need to
change the flag enum values by the new ones.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29449>
We can use this to specify the maximum vertex index that can
be accessed, which the hardware will use to detect and prevent
out-of-bounds accesses to vertex buffers.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29425>
When programming the size, we should take into account the
offset from the start of the index buffer address.
cc: mesa-stable
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29425>
Before VK_KHR_maintenance5 point size is undefined unless the
shader explicitly writes it, but this extension changes this and
expects a default point size of 1.0 if none has been written.
We accomplish this by emitting a POINT_SIZE packet with the
default point size the first time we draw with a POINT primitive
in the job. If the shaders used in the draw call doesn't write
point size then the hardware will take the point size from the
state set by the packet. If the shader does write to point size
then the value written in the shader will be used instead.
Passes all tests we support in:
dEQP-VK.rasterization.primitive_size.default_size.points.*
when forcing maintenance5 enabled.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29413>
If the shader writes point size, then the compiler needs to ensure it
writes it in the appropriate vpm output slot and also clamp its value to
expected limits. This is why we have the per_vertex_point_size in the
shader key, so it doesn't really make sense to set this if the shader
doesn't write point size.
If the shader record flags that the shader writes point size then the
hardware will use the shader written value to override point size state
(set with the POINT_SIZE packet), so again, we really only want to set
this in the shader state record if the shader actually writes its value.
While we could also limit this to point primitives, since these are the
only primitives where point size has an effect, this is not really
required, and skipping this allows us to use the same shader with any
primitive type (otherwise we would have to compile 2 different shaders).
Finally, this change makes the vertex shader setup for point size match the
one we had been doing for geometry shaders, so it makes both stages behave
consistently regarding point size behavior.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29413>
As we are marking the last V3D_CLE_READAHEAD bytes as unusable we don't
need to reserve V3D_CL_MAX_INSTR_SIZE bytes for the CLE packet.
This reverts c2601f0690 ("v3dv: ensure at least V3D_CL_MAX_INSTR_SIZE
bytes in last CL instruction")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29023>
We increase the alignment to 16k for BOs allocated for the CL on RPi5 HW.
So we have the same ratio of usable space because of HW readahead as
than on RPi4, as readahead has been increased from 256 to 1024 bytes on
RPi5.
We have also concluded that when the kernel is running with 16k pages
that is the default on Raspberry Pi 5 HW, BO allocations are aligned to
16k so this increase has no cost and we would be using memory more
efficiently.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29023>
The last V3D_CLE_READAHEAD bytes of the CLE buffer are unusable because
using them would prefetch the next readahead bytes of the CL that would
be outside the allocated BO. To guarantee that we can chain a BO to the
current CL we always reserve space for the BRANCH or
RETURN_FROM_SUB_LIST packets.
Not taking this into account has been generating kernel dmesg errors like
"MMU error from client CLE".
As V3D_CLE_READAHEAD is different from RPi4 (256 bytes) to RPi5 (1024 bytes).
So we needed to rename v3dv_cl.c to v3dvX_cl.c to have different objects per
V3D_VERSION.
Extra assertions have been included to validate that we don't write
packets over the usable size of the CL silently.
v2: - Do not declare unusable the space needed for the BRANCH packet,
but take it into account for all space reservations.
v3: - Squash here ("v3dv: Secondary CL needs also to handle CLE readahead")
- Remove spureous parenthesis (Iago Toral)
- Refactor to avoid checking for needs_return_from_sub_list inside
cl_alloc_bo adding unusable_space as new parameter.
v4: - Improved logic for chaining BOs moving it to cl_alloc_bo using
a new enum v3dv_cl_chain_type to identify the different kinds
of BO chaining. Now we increase the size of the BO just before
submitting the BRACH/RETURN_FROM_SUB_LIST packages.
v5: - Assert on BO size updates that we are within the BO size.
(Iago Toral)
v6: - Remove changes at cmd_buffer_end_render_pass_secondary as we
assumed that cl->bo was already allocated when ending the
secondary CL, but it can be NULL. And this was already handle
by current code.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29023>
Currently, the information about the performance counters is duplicated
both in the kernel and in user space. Naturally, this leads to
inconsistency, as the user space might be updated and the kernel isn't.
Aiming to turn the kernel as the "single source of truth", use
DRM_IOCTL_V3D_GET_COUNTER, when available, to get the performance
counter information.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29154>
emit_subpass_color_clear_rects and emit_subpass_ds_clear_rects is
receiving a v3dv_render_pass parameter pass, but then using
cmd_buffer->state.pass to access the current pass. All calls to those
methods are already initializing that parameter to that value.
This commit just uses the parameter. An alternative would be to remove
one of the parameters of the function call. I find this option
slightly more readable.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29218>
The resulting pipeline/shaders are different when we are using
multiview (for example, a geometry shader is injected in order to
support multiview).
Doesn't fix any CTS test run individually, but fixes some
dEQP-VK.draw.dynamic_rendering.primary_cmd_buff.multi_draw.overlapping*
CTS tests when run in a batch (using deqp-vk --deqp-caselist-file),
like:
dEQP-VK.draw.dynamic_rendering.primary_cmd_buff.multi_draw.mosaic.indexed_mixed.16_draws.stride_zero.10_instances.vert_only.single_view.offset_6_no_draw_id
dEQP-VK.draw.dynamic_rendering.primary_cmd_buff.multi_draw.overlapping.normal.one_draw.stride_zero.1_instance.vert_only.multiview.no_offset_no_draw_id
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29218>
2712D0 has V3D 7.1.10 which included draw index and
base vertex in the shader state record packet, shuffling
the locations of most of its fields. Handle this at run
time by emitting the appropriate packet based on the
V3D version since our current versioning framework doesn't
support changes based on revision number alone.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29189>
Any drivers which use vk_spirv_to_nir() now no longer need to build a
caps table manually.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Iván Briano <ivan.briano@intel.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28905>
Note that we don't support (and clarify on code why) two of the
features of this extension:
* extendedDynamicState2PatchControlPoints: as we don't support
Tessellation Shaders
* extendedDynamicState2LogicOp: as supporting it would need to allow
compile shader variants after pipeline creation, that we try to
avoid as much as possible (and it is not supported right now)
Note that those two features are not mandatory for Vulkan 1.3. From
spec:
"Promotion to Vulkan 1.3
This extension has been partially promoted. The dynamic state
enumerants VK_DYNAMIC_STATE_DEPTH_BIAS_ENABLE_EXT,
VK_DYNAMIC_STATE_PRIMITIVE_RESTART_ENABLE_EXT, and
VK_DYNAMIC_STATE_RASTERIZER_DISCARD_ENABLE_EXT; and the
corresponding entry points in this extension are included in core
Vulkan 1.3, with the EXT suffix omitted. The enumerants and entry
points for dynamic logic operation and patch control points are not
promoted, nor is the feature structure. Extension interfaces that
were promoted remain available as aliases of the core functionality."
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28980>
Note that when it is dynamic, it goes to the codepath of having
enabled raster_enabled at the pipeline, even if at the end it will be
disabled. The fragment shader compilation, and the stage keys, depends
on rasterization being enabled or not. As mentioned, if the state is
dynamic, it assumes that the rasterization is enabled.
That would work, as then the rasterization could be discarded at the
CFG_BITS package, by the command buffer at draw time. We just have a
(discarded) shader slightly more complex that it would have been with
rasterization enabled.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28980>
Since VK_EXT_extended_dynamic_state2
We just move all related with depth bias to the command buffer. There
is not good reason to compute and save it at the pipeline.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28980>
