They are u64. Fixes deadlock in
dEQP-VK.wsi.xcb.present_id_wait.wait.past_no_timeout.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: 9bffd81f1c ("vulkan: Add common implementations of vkQueueSubmit
and vkQueueWaitIdle")
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19951>
For drivers already using vk_common_ResetCommandBuffer(), it now only
calls the driver's reset hook if the command buffer is not in the
INITIAL state. Pulled this trick from the PowerVR driver.
v2 (Jason Ekstrand):
- Rename from "status" to "state" since that's what's in the spec
- Add vk_command_buffer_begin/end instead of drivers setting it all
manually
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16922>
This is a bit more accurate for what's going on and, while all Mesa
drivers today seem to be ok with extra bits, ensures we're passing a
valid Vulkan thing.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16145>
Accessing queue->submit.thread_run without holding lock vk_queue.submit.mutex.
Elsewhere, vk_queue.submit.thread_run is accessed with vk_queue.mutex
held 1 out of 2 times (1 of these accesses strongly imply that it is necessary).
Found by Coverity.
CID: 1503334
Signed-off-by: Illia Abernikhin <illia.abernikhin@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15736>
What we really care about is if we're DEFERRED so we need to do a flush
and if there can be any other threads we might race against. We don't
really care about the timeline mode itself.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15566>
Instead of basing everything on the timeline mode, base it on the submit
mode of the queue. This makes a lot more sense since it's what we
really care about anyway.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15566>
Now that we have a threading mode in the device, we can set that based
on the environment variable instead of delaying it to submit time. This
allows us to avoid the static variable trickery we use to avoid reading
environment variables over and over again. We also move the enabling of
the submit thread up a level or two and give it a bit more obvious
condition.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15566>
This encapsulates all three possible submit modes: immediate, deferred,
and threaded. It's more clear than the has_thread boolean combined with
device-level checks.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15566>
We've got enough information in common code to track this now so we may
as well throw in a helpful assert.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14917>
spec requires that the number of timeline waits/signals matches the
base number of waits/signals if there are any timeline semaphores
being processed by the submit, so asserting here is in line with what
validation will yield
failure to match these will also hang every driver I've tested, so asserting
here potentially saves some people their desktop session
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14741>
We handle it by asking the driver to create a vk_sync that wraps a
VkDeviceMemory object and gets passed as one of the signal ops.
Fixes: 9bffd81f1c ("vulkan: Add common implementations of vkQueueSubmit and vkQueueWaitIdle")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14237>
This wraps a timeline vk_sync type and turns it into a binary one. This
is useful for, for instance, driver layered on D3D12.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13427>
This adds a new vk_queue_submit object which contains a list of command
buffers as well as wait and signal operations along with a driver hook
which takes a vk_queue and a vk_queue_submit and does the actual submit.
The common code then handles spawning a submit thread if needed, waiting
for timeline points to materialize, dealing with timeline semaphore
emulation via vk_timeline, etc. All the driver sees are vk_queue.submit
calls with fully materialized vk_sync objects which it can wait on
unconditionally.
This implementation takes a page from RADV's book and only ever spawns
the submit thread if it sees a timeline wait on a time point that has
not yet materialized. If this never happens, it calls vk_queue.submit
directly from vkQueueSubmit() and the thread is never spawned.
One other nicety of the new framework is that there is no longer a
distinction, from the driver's PoV, between fences and semaphores. The
fence, if any, is included as just one more signal operation on the
final vk_queue_submit in the batch.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13427>
It's a bit on the over-complicated side but the objective is to make the
debug log messages show up in the same thread as the first
VK_ERROR_DEVICE_LOST so we don't massively confuse the app. It's
unknown if this is actually ever a problem but, with submit happening
off on its own thread, logging errors from threads the client doesn't
know about doesn't seem like a massively great plan.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13427>
