This adds extra stages, some of which involve geometry stages that are
relevant to the check we do to check for binning sync.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18290>
The common code in Mesa will rewrite the old entry points to these
if available.
Since we implement events and timestamps queries in the driver the
API changes don't quite affect us.
vkQueueSubmit2 is already implemented in the common synchronization
framework and the driver works in terms of a submit hook that is
independent of the actual entry point used by the application.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18290>
Added with KHR_synchronization2. The common code in Mesa will
rewrite vkCmdPipelineBarrier to vkCmdPipelineBarrier2.
With synchronization2 barriers now have a per-barrier stage
and access flags (previously these were shared by all the barriers
in a vkCmdPipelineBarrier commands), so we need to rewrite a bit
the logic to account for this.
Also, stage and access flag bits have been expanded and renamed.
Particularly, some new flags have been added that we need to account
for.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18290>
For some reason we were only checking the binning VS stage, but we
should also check the GS, like we do for other access types.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18290>
This is different from the internal create_image in that it doesn't
allocate memory for an image object, instead it expects the object
to be created and it initializes it from a VkImageCreateInfo struct.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18246>
The main issue was the inconsistent use of `unlikely()`, but the macro
also simplifies the code a little bit.
Signed-off-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18086>
Allows following tests to pass.
dEQP-VK.wsi.android.swapchain.create#image_swapchain_create_info
dEQP-VK.wsi.android.swapchain.simulate_oom#image_swapchain_create_info
Venus code was used as example.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18047>
Android CDD has additional requirements that must be met in order to
enable 1.1+:
- samplerYcbcrConversion
- VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT
- VK_EXTERNAL_FENCE_HANDLE_TYPE_SYNC_FD_BIT
- VK_ANDROID_external_memory_android_hardware_buffer >= v2
Requirements are checked by:
android.graphics.cts.VulkanFeaturesTest#testVulkan1_1Requirements CTS
Fixes: 2686c5419d ("v3dv: add Android support")
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18047>
vk_common_AcquireImageANDROID and vk_common_QueueSignalReleaseImageANDROID
expect sync_fd import/export to be enabled, otherwise they crashes
while trying to ImportSemaphoreFdKHR() / GetSemaphoreFdKHR().
Features was disabled on Linux to skip sync_fd CTS tests, which is using
late vkEvent signalling which causes deadlock / dEQP timeout on v3dv.
One of the options was implementing blocking v3dv-specific
AcquireImageANDROID / QueueSignalReleaseImageANDROID to avoid importing
/ exporting sync_fd, but since these features are also required by CDD
for Vulkan 1.1 and above, it was decided to enable the extensions for
Android in exchange of a few failed dEQP tests (which should not cause
any issues in non-dEQP scenarious).
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6977
Fixes: 316728a55b ("v3dv: Switch to the common submit framework")
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18047>
We improved this a long time ago and now it emits a clear rect inside
the current subpass job instead of emitting its own job with its own
RCL, so we no longer need to handle this as an exception to the rule.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17854>
For this we add a scoring system that evaluates various aspects of
the draw calls in a job.
If the cost of the geometry side of the pipeline is too high, then
we may pay too high a price in double-buffer mode because with smaller
tile size may will probably have more vertex shader invocations in the
render and binning stages.
On the other hand, if rendering cost is not high enough, we may not
have enough rendering work to hide the latency of tile stores in
double-buffer mode.
Also, because we need to make a decision after we know all the draw
calls in a job, but the double-buffer enable bit comes in the
TILE_BINNING_MODE_CFG that needs to be emitted first in the binning
command list before the draw calls are recorded, if we decide to
enable it we need to rewrite that packet and we need to size the
tile state properly to account for the extra tiles. For this
purpose we delay tile state setup for render pass jobs until we are
finishing a job.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17854>
We want to have control over the double-buffer setting here so we can control
explicitly from the driver when we want to enable this mode.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17854>
These are jobs for which we may want to enable double-buffering,
which affects tile state allocation. Since the idea is that we
want to decide about double buffering late, we also want to
postpone allocation of the tile state until we are about to
emit the RCL for the job.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17854>
If we enable double-buffer we are reducing the tile size, and thus,
we'll need more tiles and a larger tile state allocation, so we'll
need to call to this helper.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17854>
MSAA is not compatible with double-buffer mode. Also, jobs that emit
tile loads or that don't have any stores can't take advantage
of double-buffer mode.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17854>
As it is needed to have V3D_DEBUG defined. For the v3d case, I did it
restoring v3d_process_debug_variable, as it is at v3d_debug.c that
DEBUG_GET_ONCE_FLAGS_OPTION is called.
Fixes: 106b33405e ("vc4/v3d: stop adding NORAST when SHADERDB debug option is used")
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17812>
Right now if we use the option SHADERDB, NORAST is added
automatically. There's no comment justifying it, neither a lot of info
on the commits that added that. But I guess that the purpose is that
SHADERDB option is assumed to be used only to gather shader-db stats,
so setting setting NORAST would allow to get those dumps faster.
But adding debug options automatically can be confusing, as we could
get a behaviour that we were not expecting. At least I needed to check
why using SHADERDB was getting a black screen. And if we want to get
this behaviour, we can easily add manually the NORAST.
Finally, v3dv doesn't support NORAST right now (and we don't have
immediate plans to implement it), so it is somewhat inconsistent to
get different behaviour from the same debug option from the two
drivers.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17788>
For some reason the Vulkan spec required that these features must be
supported even though they only affect features that are optional
in Vulkan 1.2 and that we don't support, so enabling them doesn't
have any practical implications for us.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17786>
Semaphore waits in a command buffer only affect the first jobs we execute
in each hardware queue since jobs in the same queue are serialized against
each other. Binning syncs in particular, only affect CL jobs.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17594>
We only want to cleant BCL barrier flags if we consume a BCL barrier.
For example, if the client records a barrier for an index buffer
it should apply to the next draw call that uses an index buffer
which may not be the current draw call but one coming after it.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17594>
The trigger for this commit was when we found that we were not calling
nir_metadata_preserve when lowering the layout code. But then I found
that it would be better to just update the code to use
nir_shader_instructions_pass, so we can avoid to manually:
* Initialize the nir_builder
* Call nir_foreach functions (we pass the callback)
* Call nir_metadata_preserve functions (that as mentioned we were not calling)
We also get a nice cleanup of several functions by reducing the number
of parameters (we pass a state struct).
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17609>
