This was required to handle the case of secondary command buffers that
did not have framebuffer information available from the primary, since
we used to have an implementation that required this information to
be available for the fallback path of vkCmdClearAttachments. Now that
we can handle our our attachment clears in the current subpass by
emitting draw calls, we no longer need the framebuffer information to
be available and we can remove this.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11783>
Now that we have geometry shaders, we can leverage this to implement
clears of layered framebuffers by adding a geometry shader in our
clear pipelines that redirects the clear rect to the appropriate
layer in the framebuffer, instead of falling back to emitting separate
clear jobs for each layer, which is a lot slower.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11783>
There is a bit of a corner case here for secondary buffers that
don't inherit framebuffer information, since those won't have
access to the number of layers in the framebuffer by the time
we get here. Since we only emit this to sanitize the value of
gl_Layer produced from geometry shaders, I think it is probably
fine to lie about it and just use the maximum number of layers
we support. The only issue with that is that broken shaders that
emit out of bounds layer indices (which the spect states may lead
to unfined shading results) may cause undefined results.
In the future we could do better and patch the uniform streams
later when the secondary is executed inside a primary, since we
will have the required framebuffer information at that point,
but for now this seems like a reasonable compromise.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11783>
Specifically A8B8G8R8_UINT_PACK32, A8B8G8R8_SINT_PACK32, and
A2B10G10R10_UINT_PACK32. They are based on the internal types RGBA8UI,
RGBA8I, and RGB10_A2UI, that are not filterable.
That gets several failing CTS like this:
dEQP-VK.api.copy_and_blit.core.blit_image.all_formats.color.3d.a8b8g8r8_uint_pack32.a8b8g8r8_uint_pack32.optimal_optimal_linear_stripes_x
To properly skip instead of fail. So we also update the ci
expectation.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11794>
When using subgroups there are additional restrictions to consider,
so for now we keep it simple and disable supergroup packing in that
scenario.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11620>
We follow the same approach that v3d. We compile the files that
depends on the version several times, passing a different version each
time. We link all those per-version libs on the main library.
Note that right now we only support version == 42, so the array of
supported versions is one-sized.
Also note that although we were doing a previous work to split
hw-version dependant code from general code, this is the first commit
that only inject the current V3D_VERSION on the former.
We have two cases where we hardcode the V3D_VERSION (as a full
wrapping would be an overkill) that we need to include here to avoid
warnings/errors if we do that before or after.
Having some exceptions also happens on v3d. As we are here we add some
comment on v3d clarifying that.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11310>
cl_packet_length depends on the specific hw generation packets, so it
is can't be included directly by main header.
The straight forward solution would be to allocate them dynamically,
based on the current generation. That ended to be complex and
messy. Also, even if that change between hw versions, it will not
change significantly.
So we just add some definition with the size of the packets we
prepack. We just need to be careful that this needs to be the maximum
value considering all the versions supported.
Note that on Opengl v3d does something similar, using hardcoded
values, but without a define, neither a runtime check.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11310>
As part of this, we get rid of the v3dv_xxx_descriptor structs to
v3dv_descriptor. The main reason is that in order to support several
versions, we would need to define them several times. Also, they were
somewhat an overkill even before, as their main advantage was getting
the offset for each data on the combined case. That functionality is
replaced with some new helpers.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11310>
This includes code from:
* v3dv_cmd_buffer
* v3dv_meta_copy
* v3dv_meta_clear
v2: move some of the functions to source files that makes more sense
now (Iago).
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11310>
The idea would be to move all the code that uses cl_emit,
cl_emit_with_prepack, v3dx_pack, and any enum/structure definition
defined on the v3d pack headers.
All those methods would be defined on v3dvx_private (that would be the
equivalent to v3dx_context.h on v3d).
This commit includes the definition of v3dX for the current version
supported (42), a function calling wrapper, and the move for v3dv_queue
methods as a reference.
About the function calling wrapper, I took the idea from anv. We don't
have on v3d, but we added it because we foresee that we will need that
functionality more often. So without that macro, in order to call the
correct version of the method from the general code we would need to
do like we do on v3d, and doing something like this:
if (devinfo->ver >= 42)
return v3d42_pack_sampler_state(sampler, pCreateInfo);
else
return v3d33_pack_sampler_state(sampler, pCreateInfo);
So with the macro we can just do this:
v3dv_X(device, pack_sampler_state)(sampler, pCreateInfo).
Note that as mentioned, that is to be used on the general code, so a
runtime decision. If we are already on version-dependant code (so at
v3dx_queue for example) we just use v3dX, as at that point is a build
time decision.
Also, fwiw, I don't like too much the name of that macro, but I was
not able to think on a better one.
v2: merge job_emit_noop_bin and job_emit_noop_render (Iago)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11310>
For consistency, as we use use the v3dvx convention to point that it
depends on the hw version. Also on OpenGL the equivalent macro is
v3dx_pack.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11310>
This is entirely implemented in the SPIR-V frontend.
Relevant CTS tests:
dEQP-VK.spirv_assembly.instruction.compute.non_semantic_info.*
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11440>
