GitLab

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <!6766>

Part-of: <!6766>

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <!6766>

This is the same as nir_get_buffer_size but geared towards UBOs instead
of SSBOs. The new intrinsic is useful in Vulkan backends that need to
add bound checks on buffer accesses to honor the robust buffer access
feature.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <!6766>

Part-of: <!6766>

Subpass color clear pipelines are those used to emit partial attachment
clears as draw calls inside the render pass currently bound by the
application in the command buffer, leading to a huge performance improvement
compared to the case where we emit them in their own render pass.

Unfortunately, because the pipeline references the render pass
object in which it is used and the render pass object is owned by the
application (and can be destroyed at any point), we can't cache these
pipelines (unless we implement a refcounting mechanism or other
similar strategy).

Performance impact looks negligible based on experiments with vkQuake3,
probably because the underlying pipeline cache is preventing the
redundant shader recompiles.

Part-of: <!6766>

Specifically, we should select the slice to blit from on the source
image to be in the middle of the depth step.

This issue was only raised recently after the CTS improved the 3D
blitting tests.

Fixes:
dEQP-VK.api.copy_and_blit.core.blit_image.all_formats.*.3d.*

Part-of: <!6766>

Originally, copies between buffers and images required a buffer offset
that was a multiple of 4 bytes, however, the spec was later fixed to
relax this rule and only require offsets that had texel alignment.

Our implementation of image to buffer copies using the blit path needs
to bind the destination buffer as a linear image and be able to bind
the requested buffer memory at the required offset, so for that to work
we need to chnage the alignment requirements for linear images to match
the relaxed texel alignment requirement.

Fixes new tests in Vulkan CTS 1.2.4:
dEQP-VK.api.copy_and_blit.core.image_to_buffer.buffer_offset_relaxed
dEQP-VK.api.copy_and_blit.dedicated_allocation.image_to_buffer.buffer_offset_relaxed

Part-of: <!6766>

The lowering will get all the interpolateAt() functions from GLSL lowered to
the corresponding intrinsics we have just implemented in the compiler backend,
which was the last piece we needed to enable the feature.

This gets us to pass all the relevant tests in:
dEQP-VK.pipeline.multisample_interpolation.*

Part-of: <!6766>

The option use_interpolated_input_intrinsics will lower these as well
as regular input loads. This is inconvenient for V3D, where we can
produce optimal code for regular input loads based on the input
variable layout qualifiers, so this change adds an option to only
lower instances of interpolateAt().
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <!6766>

as we have just set proper values for point granularity etc, we can
enable largePoints. With this change tests like this:
dEQP-VK.rasterization.primitive_size.points.point_size_*

goes from Skip to Pass.

Part-of: <!6766>

As we are here, we also tweak some line-related limits, as some use
the same value that for point, and in order to use the enum we added
recently at common/v3d_limits.h

Fixes the following test:
   dEQP-VK.glsl.builtin_var.simple.pointcoord

Part-of: <!6766>

They will be the same for the OpenGL and Vulkan driver, so let's put
it on the commit limits header.

Part-of: <!6766>

PTB assumes that instance id to be 0 at start of tile, but hw would
not do that, we need to set it.

This fixes some Vulkan CTS tests that start to fails after some other
tests used an instance id.

So for example, before this commit for the following tests, executed
in that order, we got the following behaviour:

dEQP-VK.pipeline.vertex_input.multiple_attributes.binding_one_to_many.attributes.float.mat2.mat3 => Pass
dEQP-VK.draw.indexed_draw.draw_instanced_indexed_triangle_strip => Pass
dEQP-VK.pipeline.vertex_input.multiple_attributes.binding_one_to_many.attributes.float.mat2.mat3 => Fails

Part-of: <!6766>

So far we were pre-generating two variants, an all 16 bit return_size
and an all 32-bit return_size, as at pipeline creation time we don't
know the texture format that it would be used finally used.

But it is possible to override or at least refine the 32bit case, as
we know in advance that all shadow textures can (and in fact should)
use return_size 16bit.

Part-of: <!6766>

To be used to decide the texture return size. We add it on the
descriptor map because it is the easier place to do so. As we are
lowering the texture accesses we can check instr->is_shadow at that
point. It is true that it is somewhat odd, as so far the descriptor
map was general-descriptor info, but is_shadow is only for
textures. But it doesn't make sense to make an effort now, as it is
possible that we would get more descriptor-specific info on the map on
the future. We can revisit that later.

Part-of: <!6766>

Part-of: <!6766>

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: <!6766>

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: <!6766>

Reviewed-by: Iago Toral <itoral@igalia.com>
Part-of: <!6766>

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: <!6766>

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: <!6766>

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: <!6766>

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

Part-of: <!6766>

Part-of: <!6766>

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: <!6766>

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: <!6766>

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: <!6766>

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: <!6766>

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: <!6766>

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: <!6766>

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

Part-of: <!6766>

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: <!6766>

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: <!6766>

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

Part-of: <!6766>

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: <!6766>

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

Part-of: <!6766>

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

Part-of: <!6766>

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <!6766>

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

Part-of: <!6766>