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 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>
7278 is the chip on the rpi3, while the rpi4 that made it to market has
the 2711 chip.
When this was introduced (82bf1979), the rpi4 was probably still in
flux, which is why the rpi3 chip was put there (and v3d doesn't care
about that, but v3dv does).
cc: mesa-stable
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29584>
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>
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>
This small patch fixes an issue where 'addr' is used uninitialized if
the assert gets removed due to compiling release code and thus
returning uninitialized 'addr'
v2: Modified based on initial review:
a) No need to initialize the 'addr' and 'ret' variables
b) Fix 'ret' variable to be proper type based on hw->get_mem return value
v3: Modified based on additional review:
a) Since both the simulator and mesa have their own version of
'unreachable()' and we cannot use ASSERT for the 'ret' value here,
just use a (void) ret after the assert
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29434>
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>
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>
We can emit spill setup before RA if we use scratch. In that case
we have the same situation as during spilling, with the caveat that
we have already emitted the instructions so we need to find them
(they should be the only instructions ones before the instructions
accessing payload registers) and flag them as such.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29343>
We read our payload registers first in the shader so we generally don't have
to care about temps being allocated to them and stomping their value before
we can read them. Hoewer, spilling setup instructions are an exception since
these will be inserted first when there is any spilling in the program.
To fix this, we flag RA nodes involved with these instructions so we can
then try to avoid assiging these registers to them.
Fixes CTS failures with V3D_DEBUG=opt_compile_time, particularly:
dEQP-VK.binding_model.buffer_device_address.set0.depth2.basessbo.convertcheckuv2.nostore.single.std140.comp_offset_nonzero
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29343>
Karol Herbst