2019-12-16 09:09:40 +01:00
|
|
|
/*
|
2022-02-17 12:38:42 +01:00
|
|
|
* Copyright © 2019 Raspberry Pi Ltd
|
2019-12-16 09:09:40 +01:00
|
|
|
*
|
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
|
*
|
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
|
* Software.
|
|
|
|
|
*
|
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
|
* IN THE SOFTWARE.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "v3dv_private.h"
|
2019-12-17 11:39:36 +01:00
|
|
|
#include "drm-uapi/v3d_drm.h"
|
|
|
|
|
|
2020-01-02 13:31:59 +01:00
|
|
|
#include "broadcom/clif/clif_dump.h"
|
2022-03-29 17:52:32 -05:00
|
|
|
#include "util/libsync.h"
|
2022-04-04 10:22:45 -05:00
|
|
|
#include "util/os_time.h"
|
2022-03-29 17:52:32 -05:00
|
|
|
#include "vk_drm_syncobj.h"
|
2020-01-02 13:31:59 +01:00
|
|
|
|
2019-12-17 11:39:36 +01:00
|
|
|
#include <errno.h>
|
2020-01-14 09:48:19 +01:00
|
|
|
#include <time.h>
|
2019-12-17 11:39:36 +01:00
|
|
|
|
2020-01-02 13:31:59 +01:00
|
|
|
static void
|
2020-01-08 11:14:35 +01:00
|
|
|
v3dv_clif_dump(struct v3dv_device *device,
|
|
|
|
|
struct v3dv_job *job,
|
2020-01-02 13:31:59 +01:00
|
|
|
struct drm_v3d_submit_cl *submit)
|
|
|
|
|
{
|
2021-09-28 00:37:49 +02:00
|
|
|
if (!(unlikely(V3D_DEBUG & (V3D_DEBUG_CL |
|
|
|
|
|
V3D_DEBUG_CL_NO_BIN |
|
|
|
|
|
V3D_DEBUG_CLIF))))
|
2020-01-02 13:31:59 +01:00
|
|
|
return;
|
|
|
|
|
|
2020-01-08 11:14:35 +01:00
|
|
|
struct clif_dump *clif = clif_dump_init(&device->devinfo,
|
2020-01-02 13:31:59 +01:00
|
|
|
stderr,
|
2021-09-10 13:08:22 +02:00
|
|
|
V3D_DEBUG & (V3D_DEBUG_CL |
|
|
|
|
|
V3D_DEBUG_CL_NO_BIN),
|
|
|
|
|
V3D_DEBUG & V3D_DEBUG_CL_NO_BIN);
|
2020-01-02 13:31:59 +01:00
|
|
|
|
2020-01-08 11:14:35 +01:00
|
|
|
set_foreach(job->bos, entry) {
|
2020-01-02 13:31:59 +01:00
|
|
|
struct v3dv_bo *bo = (void *)entry->key;
|
|
|
|
|
char *name = ralloc_asprintf(NULL, "%s_0x%x",
|
2020-01-30 12:24:55 +01:00
|
|
|
bo->name, bo->offset);
|
2020-01-02 13:31:59 +01:00
|
|
|
|
2021-04-21 17:23:57 +02:00
|
|
|
bool ok = v3dv_bo_map(device, bo, bo->size);
|
|
|
|
|
if (!ok) {
|
|
|
|
|
fprintf(stderr, "failed to map BO for clif_dump.\n");
|
|
|
|
|
ralloc_free(name);
|
|
|
|
|
goto free_clif;
|
|
|
|
|
}
|
2020-01-02 13:31:59 +01:00
|
|
|
clif_dump_add_bo(clif, name, bo->offset, bo->size, bo->map);
|
|
|
|
|
|
|
|
|
|
ralloc_free(name);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
clif_dump(clif, submit);
|
|
|
|
|
|
2021-04-21 17:23:57 +02:00
|
|
|
free_clif:
|
2020-01-02 13:31:59 +01:00
|
|
|
clif_dump_destroy(clif);
|
|
|
|
|
}
|
|
|
|
|
|
2020-05-18 10:41:11 +02:00
|
|
|
static VkResult
|
2022-03-29 17:52:32 -05:00
|
|
|
queue_wait_idle(struct v3dv_queue *queue,
|
|
|
|
|
struct v3dv_submit_sync_info *sync_info)
|
|
|
|
|
{
|
|
|
|
|
if (queue->device->pdevice->caps.multisync) {
|
|
|
|
|
int ret = drmSyncobjWait(queue->device->pdevice->render_fd,
|
|
|
|
|
queue->last_job_syncs.syncs, 3,
|
|
|
|
|
INT64_MAX, DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL,
|
|
|
|
|
NULL);
|
|
|
|
|
if (ret) {
|
|
|
|
|
return vk_errorf(queue, VK_ERROR_DEVICE_LOST,
|
|
|
|
|
"syncobj wait failed: %m");
|
2020-05-18 10:41:11 +02:00
|
|
|
}
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
bool first = true;
|
|
|
|
|
for (int i = 0; i < 3; i++) {
|
|
|
|
|
if (!queue->last_job_syncs.first[i])
|
|
|
|
|
first = false;
|
|
|
|
|
}
|
2020-05-18 10:41:11 +02:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
/* If we're not the first job, that means we're waiting on some
|
|
|
|
|
* per-queue-type syncobj which transitively waited on the semaphores
|
|
|
|
|
* so we can skip the semaphore wait.
|
|
|
|
|
*/
|
|
|
|
|
if (first) {
|
|
|
|
|
VkResult result = vk_sync_wait_many(&queue->device->vk,
|
|
|
|
|
sync_info->wait_count,
|
|
|
|
|
sync_info->waits,
|
|
|
|
|
VK_SYNC_WAIT_COMPLETE,
|
|
|
|
|
UINT64_MAX);
|
|
|
|
|
if (result != VK_SUCCESS)
|
|
|
|
|
return result;
|
|
|
|
|
}
|
2020-05-18 10:41:11 +02:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
for (int i = 0; i < 3; i++)
|
|
|
|
|
queue->last_job_syncs.first[i] = false;
|
2021-12-14 13:40:34 -01:00
|
|
|
} else {
|
2022-03-29 17:52:32 -05:00
|
|
|
/* Without multisync, all the semaphores are baked into the one syncobj
|
|
|
|
|
* at the start of each submit so we only need to wait on the one.
|
|
|
|
|
*/
|
|
|
|
|
int ret = drmSyncobjWait(queue->device->pdevice->render_fd,
|
|
|
|
|
&queue->last_job_syncs.syncs[V3DV_QUEUE_ANY], 1,
|
|
|
|
|
INT64_MAX, DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL,
|
|
|
|
|
NULL);
|
|
|
|
|
if (ret) {
|
|
|
|
|
return vk_errorf(queue, VK_ERROR_DEVICE_LOST,
|
|
|
|
|
"syncobj wait failed: %m");
|
|
|
|
|
}
|
2021-12-14 13:40:34 -01:00
|
|
|
}
|
2020-05-18 10:41:11 +02:00
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
static VkResult
|
2022-03-29 17:52:32 -05:00
|
|
|
handle_reset_query_cpu_job(struct v3dv_queue *queue, struct v3dv_job *job,
|
|
|
|
|
struct v3dv_submit_sync_info *sync_info)
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
{
|
2020-12-18 12:51:08 +01:00
|
|
|
struct v3dv_reset_query_cpu_job_info *info = &job->cpu.query_reset;
|
|
|
|
|
assert(info->pool);
|
|
|
|
|
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
/* We are about to reset query counters so we need to make sure that
|
2020-10-29 11:55:23 +01:00
|
|
|
* The GPU is not using them. The exception is timestamp queries, since
|
|
|
|
|
* we handle those in the CPU.
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
*/
|
2021-04-14 13:34:00 +02:00
|
|
|
if (info->pool->query_type == VK_QUERY_TYPE_OCCLUSION)
|
2022-03-29 17:52:32 -05:00
|
|
|
v3dv_bo_wait(job->device, info->pool->bo, PIPE_TIMEOUT_INFINITE);
|
2021-04-14 13:34:00 +02:00
|
|
|
|
2021-10-12 16:58:33 +00:00
|
|
|
v3dv_reset_query_pools(job->device, info->pool, info->first, info->count);
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static VkResult
|
|
|
|
|
handle_end_query_cpu_job(struct v3dv_job *job)
|
|
|
|
|
{
|
2022-04-04 10:25:15 -05:00
|
|
|
mtx_lock(&job->device->query_mutex);
|
|
|
|
|
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
struct v3dv_end_query_cpu_job_info *info = &job->cpu.query_end;
|
2021-07-23 14:49:05 +02:00
|
|
|
for (uint32_t i = 0; i < info->count; i++) {
|
|
|
|
|
assert(info->query + i < info->pool->query_count);
|
|
|
|
|
struct v3dv_query *query = &info->pool->queries[info->query + i];
|
|
|
|
|
query->maybe_available = true;
|
|
|
|
|
}
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
|
2022-04-04 10:25:15 -05:00
|
|
|
cnd_broadcast(&job->device->query_ended);
|
|
|
|
|
mtx_unlock(&job->device->query_mutex);
|
|
|
|
|
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static VkResult
|
|
|
|
|
handle_copy_query_results_cpu_job(struct v3dv_job *job)
|
|
|
|
|
{
|
|
|
|
|
struct v3dv_copy_query_results_cpu_job_info *info =
|
|
|
|
|
&job->cpu.query_copy_results;
|
|
|
|
|
|
|
|
|
|
assert(info->dst && info->dst->mem && info->dst->mem->bo);
|
|
|
|
|
struct v3dv_bo *bo = info->dst->mem->bo;
|
2020-06-17 12:15:42 +02:00
|
|
|
|
|
|
|
|
/* Map the entire dst buffer for the CPU copy if needed */
|
|
|
|
|
assert(!bo->map || bo->map_size == bo->size);
|
|
|
|
|
if (!bo->map && !v3dv_bo_map(job->device, bo, bo->size))
|
2021-09-24 15:31:03 -05:00
|
|
|
return vk_error(job->device, VK_ERROR_OUT_OF_HOST_MEMORY);
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
|
2021-07-07 11:52:17 +02:00
|
|
|
uint8_t *offset = ((uint8_t *) bo->map) +
|
|
|
|
|
info->offset + info->dst->mem_offset;
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
v3dv_get_query_pool_results_cpu(job->device,
|
|
|
|
|
info->pool,
|
|
|
|
|
info->first,
|
|
|
|
|
info->count,
|
2021-07-07 11:52:17 +02:00
|
|
|
offset,
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
info->stride,
|
|
|
|
|
info->flags);
|
|
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
2020-05-18 10:41:11 +02:00
|
|
|
static VkResult
|
2022-03-29 17:52:32 -05:00
|
|
|
handle_set_event_cpu_job(struct v3dv_queue *queue, struct v3dv_job *job,
|
|
|
|
|
struct v3dv_submit_sync_info *sync_info)
|
2020-05-18 10:41:11 +02:00
|
|
|
{
|
|
|
|
|
/* From the Vulkan 1.0 spec:
|
|
|
|
|
*
|
|
|
|
|
* "When vkCmdSetEvent is submitted to a queue, it defines an execution
|
|
|
|
|
* dependency on commands that were submitted before it, and defines an
|
|
|
|
|
* event signal operation which sets the event to the signaled state.
|
|
|
|
|
* The first synchronization scope includes every command previously
|
|
|
|
|
* submitted to the same queue, including those in the same command
|
|
|
|
|
* buffer and batch".
|
|
|
|
|
*
|
|
|
|
|
* So we should wait for all prior work to be completed before signaling
|
|
|
|
|
* the event, this includes all active CPU wait threads spawned for any
|
|
|
|
|
* command buffer submitted *before* this.
|
|
|
|
|
*/
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
VkResult result = queue_wait_idle(queue, sync_info);
|
2020-05-18 10:41:11 +02:00
|
|
|
if (result != VK_SUCCESS)
|
|
|
|
|
return result;
|
|
|
|
|
|
|
|
|
|
struct v3dv_event_set_cpu_job_info *info = &job->cpu.event_set;
|
|
|
|
|
p_atomic_set(&info->event->state, info->state);
|
|
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
check_wait_events_complete(struct v3dv_job *job)
|
|
|
|
|
{
|
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_CPU_WAIT_EVENTS);
|
|
|
|
|
|
|
|
|
|
struct v3dv_event_wait_cpu_job_info *info = &job->cpu.event_wait;
|
|
|
|
|
for (uint32_t i = 0; i < info->event_count; i++) {
|
|
|
|
|
if (!p_atomic_read(&info->events[i]->state))
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
static VkResult
|
|
|
|
|
handle_wait_events_cpu_job(struct v3dv_job *job)
|
2020-05-18 10:41:11 +02:00
|
|
|
{
|
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_CPU_WAIT_EVENTS);
|
|
|
|
|
|
|
|
|
|
/* Wait for events to be signaled */
|
|
|
|
|
const useconds_t wait_interval_ms = 1;
|
|
|
|
|
while (!check_wait_events_complete(job))
|
|
|
|
|
usleep(wait_interval_ms * 1000);
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
return VK_SUCCESS;
|
2020-05-18 10:41:11 +02:00
|
|
|
}
|
|
|
|
|
|
2020-06-15 16:44:49 +02:00
|
|
|
static VkResult
|
2022-03-29 17:52:32 -05:00
|
|
|
handle_copy_buffer_to_image_cpu_job(struct v3dv_queue *queue,
|
|
|
|
|
struct v3dv_job *job,
|
|
|
|
|
struct v3dv_submit_sync_info *sync_info)
|
2020-06-15 16:44:49 +02:00
|
|
|
{
|
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_CPU_COPY_BUFFER_TO_IMAGE);
|
|
|
|
|
struct v3dv_copy_buffer_to_image_cpu_job_info *info =
|
|
|
|
|
&job->cpu.copy_buffer_to_image;
|
|
|
|
|
|
|
|
|
|
/* Wait for all GPU work to finish first, since we may be accessing
|
|
|
|
|
* the BOs involved in the operation.
|
|
|
|
|
*/
|
2022-03-29 17:52:32 -05:00
|
|
|
VkResult result = queue_wait_idle(queue, sync_info);
|
|
|
|
|
if (result != VK_SUCCESS)
|
|
|
|
|
return result;
|
2020-06-15 16:44:49 +02:00
|
|
|
|
|
|
|
|
/* Map BOs */
|
|
|
|
|
struct v3dv_bo *dst_bo = info->image->mem->bo;
|
2020-06-17 12:15:42 +02:00
|
|
|
assert(!dst_bo->map || dst_bo->map_size == dst_bo->size);
|
2020-06-15 16:44:49 +02:00
|
|
|
if (!dst_bo->map && !v3dv_bo_map(job->device, dst_bo, dst_bo->size))
|
2021-09-24 15:31:03 -05:00
|
|
|
return vk_error(job->device, VK_ERROR_OUT_OF_HOST_MEMORY);
|
2020-06-15 16:44:49 +02:00
|
|
|
void *dst_ptr = dst_bo->map;
|
|
|
|
|
|
|
|
|
|
struct v3dv_bo *src_bo = info->buffer->mem->bo;
|
2020-06-17 12:15:42 +02:00
|
|
|
assert(!src_bo->map || src_bo->map_size == src_bo->size);
|
2020-06-15 16:44:49 +02:00
|
|
|
if (!src_bo->map && !v3dv_bo_map(job->device, src_bo, src_bo->size))
|
2021-09-24 15:31:03 -05:00
|
|
|
return vk_error(job->device, VK_ERROR_OUT_OF_HOST_MEMORY);
|
2020-06-15 16:44:49 +02:00
|
|
|
void *src_ptr = src_bo->map;
|
|
|
|
|
|
|
|
|
|
const struct v3d_resource_slice *slice =
|
|
|
|
|
&info->image->slices[info->mip_level];
|
|
|
|
|
|
|
|
|
|
const struct pipe_box box = {
|
|
|
|
|
info->image_offset.x, info->image_offset.y, info->base_layer,
|
|
|
|
|
info->image_extent.width, info->image_extent.height, info->layer_count,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Copy each layer */
|
|
|
|
|
for (uint32_t i = 0; i < info->layer_count; i++) {
|
|
|
|
|
const uint32_t dst_offset =
|
|
|
|
|
v3dv_layer_offset(info->image, info->mip_level, info->base_layer + i);
|
|
|
|
|
const uint32_t src_offset =
|
|
|
|
|
info->buffer->mem_offset + info->buffer_offset +
|
|
|
|
|
info->buffer_layer_stride * i;
|
|
|
|
|
v3d_store_tiled_image(
|
|
|
|
|
dst_ptr + dst_offset, slice->stride,
|
|
|
|
|
src_ptr + src_offset, info->buffer_stride,
|
|
|
|
|
slice->tiling, info->image->cpp, slice->padded_height, &box);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-29 11:55:23 +01:00
|
|
|
static VkResult
|
2022-03-29 17:52:32 -05:00
|
|
|
handle_timestamp_query_cpu_job(struct v3dv_queue *queue, struct v3dv_job *job,
|
|
|
|
|
struct v3dv_submit_sync_info *sync_info)
|
2020-10-29 11:55:23 +01:00
|
|
|
{
|
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_CPU_TIMESTAMP_QUERY);
|
|
|
|
|
struct v3dv_timestamp_query_cpu_job_info *info = &job->cpu.query_timestamp;
|
|
|
|
|
|
|
|
|
|
/* Wait for completion of all work queued before the timestamp query */
|
2022-03-29 17:52:32 -05:00
|
|
|
VkResult result = queue_wait_idle(queue, sync_info);
|
|
|
|
|
if (result != VK_SUCCESS)
|
|
|
|
|
return result;
|
2020-10-29 11:55:23 +01:00
|
|
|
|
2022-04-04 10:25:15 -05:00
|
|
|
mtx_lock(&job->device->query_mutex);
|
|
|
|
|
|
2020-10-29 11:55:23 +01:00
|
|
|
/* Compute timestamp */
|
|
|
|
|
struct timespec t;
|
|
|
|
|
clock_gettime(CLOCK_MONOTONIC, &t);
|
2021-07-23 14:49:05 +02:00
|
|
|
|
|
|
|
|
for (uint32_t i = 0; i < info->count; i++) {
|
|
|
|
|
assert(info->query + i < info->pool->query_count);
|
|
|
|
|
struct v3dv_query *query = &info->pool->queries[info->query + i];
|
|
|
|
|
query->maybe_available = true;
|
|
|
|
|
if (i == 0)
|
|
|
|
|
query->value = t.tv_sec * 1000000000ull + t.tv_nsec;
|
|
|
|
|
}
|
2020-10-29 11:55:23 +01:00
|
|
|
|
2022-04-04 10:25:15 -05:00
|
|
|
cnd_broadcast(&job->device->query_ended);
|
|
|
|
|
mtx_unlock(&job->device->query_mutex);
|
|
|
|
|
|
2020-10-29 11:55:23 +01:00
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-19 11:56:20 +02:00
|
|
|
static VkResult
|
|
|
|
|
handle_csd_indirect_cpu_job(struct v3dv_queue *queue,
|
|
|
|
|
struct v3dv_job *job,
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_submit_sync_info *sync_info)
|
2020-06-19 11:56:20 +02:00
|
|
|
{
|
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_CPU_CSD_INDIRECT);
|
|
|
|
|
struct v3dv_csd_indirect_cpu_job_info *info = &job->cpu.csd_indirect;
|
|
|
|
|
assert(info->csd_job);
|
|
|
|
|
|
|
|
|
|
/* Make sure the GPU is no longer using the indirect buffer*/
|
|
|
|
|
assert(info->buffer && info->buffer->mem && info->buffer->mem->bo);
|
2021-01-19 08:24:04 +01:00
|
|
|
v3dv_bo_wait(queue->device, info->buffer->mem->bo, PIPE_TIMEOUT_INFINITE);
|
2020-06-19 11:56:20 +02:00
|
|
|
|
|
|
|
|
/* Map the indirect buffer and read the dispatch parameters */
|
|
|
|
|
assert(info->buffer && info->buffer->mem && info->buffer->mem->bo);
|
|
|
|
|
struct v3dv_bo *bo = info->buffer->mem->bo;
|
|
|
|
|
if (!bo->map && !v3dv_bo_map(job->device, bo, bo->size))
|
2021-09-24 15:31:03 -05:00
|
|
|
return vk_error(job->device, VK_ERROR_OUT_OF_HOST_MEMORY);
|
2020-06-19 11:56:20 +02:00
|
|
|
assert(bo->map);
|
|
|
|
|
|
|
|
|
|
const uint32_t offset = info->buffer->mem_offset + info->offset;
|
|
|
|
|
const uint32_t *group_counts = (uint32_t *) (bo->map + offset);
|
|
|
|
|
if (group_counts[0] == 0 || group_counts[1] == 0|| group_counts[2] == 0)
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
|
|
|
|
|
if (memcmp(group_counts, info->csd_job->csd.wg_count,
|
|
|
|
|
sizeof(info->csd_job->csd.wg_count)) != 0) {
|
|
|
|
|
v3dv_cmd_buffer_rewrite_indirect_csd_job(info, group_counts);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-17 11:39:36 +01:00
|
|
|
static VkResult
|
2022-03-29 17:52:32 -05:00
|
|
|
process_waits(struct v3dv_queue *queue,
|
|
|
|
|
uint32_t count, struct vk_sync_wait *waits)
|
2020-01-13 17:45:04 +01:00
|
|
|
{
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_device *device = queue->device;
|
|
|
|
|
VkResult result = VK_SUCCESS;
|
|
|
|
|
int err = 0;
|
|
|
|
|
|
2020-01-13 17:45:04 +01:00
|
|
|
if (count == 0)
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
/* If multisync is supported, we wait on semaphores in the first job
|
|
|
|
|
* submitted to each of the individual queues. We don't need to
|
|
|
|
|
* pre-populate the syncobjs.
|
2021-12-16 22:43:49 +00:00
|
|
|
*/
|
2022-03-29 17:52:32 -05:00
|
|
|
if (queue->device->pdevice->caps.multisync)
|
2021-12-16 22:43:49 +00:00
|
|
|
return VK_SUCCESS;
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
int fd = -1;
|
|
|
|
|
err = drmSyncobjExportSyncFile(device->pdevice->render_fd,
|
|
|
|
|
queue->last_job_syncs.syncs[V3DV_QUEUE_ANY],
|
|
|
|
|
&fd);
|
|
|
|
|
if (err) {
|
|
|
|
|
result = vk_errorf(queue, VK_ERROR_UNKNOWN,
|
|
|
|
|
"sync file export failed: %m");
|
|
|
|
|
goto fail;
|
|
|
|
|
}
|
2020-03-13 10:38:31 +01:00
|
|
|
|
2020-01-13 17:45:04 +01:00
|
|
|
for (uint32_t i = 0; i < count; i++) {
|
2022-03-29 17:52:32 -05:00
|
|
|
uint32_t syncobj = vk_sync_as_drm_syncobj(waits[i].sync)->syncobj;
|
|
|
|
|
int wait_fd = -1;
|
|
|
|
|
|
|
|
|
|
err = drmSyncobjExportSyncFile(device->pdevice->render_fd,
|
|
|
|
|
syncobj, &wait_fd);
|
|
|
|
|
if (err) {
|
|
|
|
|
result = vk_errorf(queue, VK_ERROR_UNKNOWN,
|
|
|
|
|
"sync file export failed: %m");
|
|
|
|
|
goto fail;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err = sync_accumulate("v3dv", &fd, wait_fd);
|
|
|
|
|
close(wait_fd);
|
|
|
|
|
if (err) {
|
|
|
|
|
result = vk_errorf(queue, VK_ERROR_UNKNOWN,
|
|
|
|
|
"sync file merge failed: %m");
|
|
|
|
|
goto fail;
|
2021-06-01 09:33:36 +02:00
|
|
|
}
|
2020-01-13 17:45:04 +01:00
|
|
|
}
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
err = drmSyncobjImportSyncFile(device->pdevice->render_fd,
|
|
|
|
|
queue->last_job_syncs.syncs[V3DV_QUEUE_ANY],
|
|
|
|
|
fd);
|
|
|
|
|
if (err) {
|
|
|
|
|
result = vk_errorf(queue, VK_ERROR_UNKNOWN,
|
|
|
|
|
"sync file import failed: %m");
|
|
|
|
|
}
|
2021-06-01 09:33:36 +02:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
fail:
|
|
|
|
|
close(fd);
|
2021-06-01 09:33:36 +02:00
|
|
|
return result;
|
2020-01-13 17:45:04 +01:00
|
|
|
}
|
|
|
|
|
|
2021-12-16 10:47:18 +00:00
|
|
|
static VkResult
|
2022-03-29 17:52:32 -05:00
|
|
|
process_signals(struct v3dv_queue *queue,
|
|
|
|
|
uint32_t count, struct vk_sync_signal *signals)
|
2020-01-14 09:48:19 +01:00
|
|
|
{
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_device *device = queue->device;
|
2020-01-14 09:48:19 +01:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
if (count == 0)
|
|
|
|
|
return VK_SUCCESS;
|
v3dv: move authenticated display fd acquisition to swapchain creation time
So far, we have only been supporting X11, so we assumed that we were running
inside X11 and would always try to get an authenticated fd from Xorg during
device initialization. While this works for desktop Raspbian, it is not
really correct and it is not what we want to do when we start considering
other WSIs.
Initially, one could think we can still do this by guarding the WSI code
under the proper instance extension check. This, however, doesn't work
reliably, as the Vulkan loader can call vkEnumerateDevices without enabling
surface extensions on the instance, which then can lead to us not
initializing any display_fd and failing with VK_ERROR_INITIALIZATION_FAILED,
which is not correct, so while we can try to acquire the display_fd here,
it might not always work, and we should definitely not fail initialization
of the physical device for that.
Instead, with this change we move acquisition of display_fd to swapchain
creation time where required extensions need to be enabled in the instance.
This was also suggested by Daniel Stone during review of a work-in-progress
implementation for the Wayland WSI.
There is a special case to consider though: applications like Zink that
don't use Vulkan's swapchains at all but still allocate images that they
intend to use for WSI. We need to handle these by checking that we have
indeed acquired a display_fd before doing any memory allocation for WSI,
and acquiring one at that time if that's not the case.
This change also removes the render_fd and display_fd fields from the
logical device (which we were copying from the physical device), because
now there is no guarantee that we have acquired a display_fd at the
time we create a logical device. Instead, we now put a reference to the
physical device on the logical device from which we can access these.
Finally, this also fixes a regression introduced with VK_KHR_display, where
if that extension is enabled but we are running inside a compositor, we would
acquire a display_fd that is not authenticated and try to use that instead
of acquiring an authenticated display_fd from the display server.
Fixes: b1188c9451 (v3dv: VK_KHR_display extension support)
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7546>
2020-11-11 09:45:33 +01:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
/* If multisync is supported, we are signalling semaphores in the last job
|
|
|
|
|
* of the last command buffer and, therefore, we do not need to process any
|
|
|
|
|
* semaphores here.
|
|
|
|
|
*/
|
|
|
|
|
if (device->pdevice->caps.multisync)
|
|
|
|
|
return VK_SUCCESS;
|
2021-12-16 10:47:18 +00:00
|
|
|
|
2020-01-14 09:48:19 +01:00
|
|
|
int fd;
|
2022-03-29 17:52:32 -05:00
|
|
|
drmSyncobjExportSyncFile(device->pdevice->render_fd,
|
|
|
|
|
queue->last_job_syncs.syncs[V3DV_QUEUE_ANY],
|
2021-12-14 13:40:34 -01:00
|
|
|
&fd);
|
2022-03-29 17:52:32 -05:00
|
|
|
if (fd == -1) {
|
|
|
|
|
return vk_errorf(queue, VK_ERROR_UNKNOWN,
|
|
|
|
|
"sync file export failed: %m");
|
|
|
|
|
}
|
2020-01-14 09:48:19 +01:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
VkResult result = VK_SUCCESS;
|
|
|
|
|
for (uint32_t i = 0; i < count; i++) {
|
|
|
|
|
uint32_t syncobj = vk_sync_as_drm_syncobj(signals[i].sync)->syncobj;
|
|
|
|
|
int err = drmSyncobjImportSyncFile(device->pdevice->render_fd,
|
|
|
|
|
syncobj, fd);
|
|
|
|
|
if (err) {
|
|
|
|
|
result = vk_errorf(queue, VK_ERROR_UNKNOWN,
|
|
|
|
|
"sync file import failed: %m");
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-01-14 09:48:19 +01:00
|
|
|
|
2021-06-01 09:33:36 +02:00
|
|
|
assert(fd >= 0);
|
|
|
|
|
close(fd);
|
2020-01-14 09:48:19 +01:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
return result;
|
2020-01-14 09:48:19 +01:00
|
|
|
}
|
|
|
|
|
|
2021-10-04 14:31:55 +01:00
|
|
|
static void
|
|
|
|
|
multisync_free(struct v3dv_device *device,
|
2022-03-22 16:20:10 -05:00
|
|
|
struct drm_v3d_multi_sync *ms)
|
2021-10-04 14:31:55 +01:00
|
|
|
{
|
2022-03-22 16:20:10 -05:00
|
|
|
vk_free(&device->vk.alloc, (void *)(uintptr_t)ms->out_syncs);
|
|
|
|
|
vk_free(&device->vk.alloc, (void *)(uintptr_t)ms->in_syncs);
|
2021-10-04 14:31:55 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct drm_v3d_sem *
|
2022-03-29 17:52:32 -05:00
|
|
|
set_in_syncs(struct v3dv_queue *queue,
|
2021-12-14 13:40:34 -01:00
|
|
|
struct v3dv_job *job,
|
2022-03-29 17:52:32 -05:00
|
|
|
enum v3dv_queue_type queue_sync,
|
2021-12-14 13:40:34 -01:00
|
|
|
uint32_t *count,
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_submit_sync_info *sync_info)
|
2021-10-04 14:31:55 +01:00
|
|
|
{
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_device *device = queue->device;
|
|
|
|
|
uint32_t n_syncs = 0;
|
2022-01-03 12:55:37 -01:00
|
|
|
|
|
|
|
|
/* If this is the first job submitted to a given GPU queue in this cmd buf
|
|
|
|
|
* batch, it has to wait on wait semaphores (if any) before running.
|
|
|
|
|
*/
|
2022-03-29 17:52:32 -05:00
|
|
|
if (queue->last_job_syncs.first[queue_sync])
|
|
|
|
|
n_syncs = sync_info->wait_count;
|
2022-01-03 12:55:37 -01:00
|
|
|
|
2022-04-07 10:17:26 -05:00
|
|
|
/* If the serialize flag is set, this job waits for completion of all GPU
|
|
|
|
|
* jobs submitted in any queue V3DV_QUEUE_(CL/TFU/CSD) before running.
|
2021-12-14 13:40:34 -01:00
|
|
|
*/
|
2022-03-29 17:52:32 -05:00
|
|
|
*count = n_syncs + (job->serialize ? 3 : 0);
|
2021-10-04 14:31:55 +01:00
|
|
|
|
|
|
|
|
if (!*count)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
struct drm_v3d_sem *syncs =
|
|
|
|
|
vk_zalloc(&device->vk.alloc, *count * sizeof(struct drm_v3d_sem),
|
|
|
|
|
8, VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
|
|
|
|
|
|
|
|
|
if (!syncs)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
for (int i = 0; i < n_syncs; i++) {
|
|
|
|
|
syncs[i].handle =
|
|
|
|
|
vk_sync_as_drm_syncobj(sync_info->waits[i].sync)->syncobj;
|
2022-04-07 10:17:26 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (job->serialize) {
|
|
|
|
|
for (int i = 0; i < 3; i++)
|
2022-03-29 17:52:32 -05:00
|
|
|
syncs[n_syncs + i].handle = queue->last_job_syncs.syncs[i];
|
2021-12-14 13:40:34 -01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return syncs;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct drm_v3d_sem *
|
2022-03-29 17:52:32 -05:00
|
|
|
set_out_syncs(struct v3dv_queue *queue,
|
2021-12-16 22:43:49 +00:00
|
|
|
struct v3dv_job *job,
|
2022-03-29 17:52:32 -05:00
|
|
|
enum v3dv_queue_type queue_sync,
|
2021-12-14 13:40:34 -01:00
|
|
|
uint32_t *count,
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_submit_sync_info *sync_info,
|
|
|
|
|
bool signal_syncs)
|
2021-12-14 13:40:34 -01:00
|
|
|
{
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_device *device = queue->device;
|
|
|
|
|
|
|
|
|
|
uint32_t n_vk_syncs = signal_syncs ? sync_info->signal_count : 0;
|
2021-12-14 13:40:34 -01:00
|
|
|
|
|
|
|
|
/* We always signal the syncobj from `device->last_job_syncs` related to
|
2021-12-16 10:47:18 +00:00
|
|
|
* this v3dv_queue_type to track the last job submitted to this queue.
|
2021-12-14 13:40:34 -01:00
|
|
|
*/
|
2022-03-29 17:52:32 -05:00
|
|
|
(*count) = n_vk_syncs + 1;
|
2021-12-14 13:40:34 -01:00
|
|
|
|
|
|
|
|
struct drm_v3d_sem *syncs =
|
|
|
|
|
vk_zalloc(&device->vk.alloc, *count * sizeof(struct drm_v3d_sem),
|
|
|
|
|
8, VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
|
|
|
|
|
|
|
|
|
if (!syncs)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
if (n_vk_syncs) {
|
|
|
|
|
for (unsigned i = 0; i < n_vk_syncs; i++) {
|
|
|
|
|
syncs[i].handle =
|
|
|
|
|
vk_sync_as_drm_syncobj(sync_info->signals[i].sync)->syncobj;
|
2021-10-04 14:31:55 +01:00
|
|
|
}
|
2021-12-14 13:40:34 -01:00
|
|
|
}
|
2021-10-04 14:31:55 +01:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
syncs[n_vk_syncs].handle = queue->last_job_syncs.syncs[queue_sync];
|
2021-10-04 14:31:55 +01:00
|
|
|
|
|
|
|
|
return syncs;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
set_ext(struct drm_v3d_extension *ext,
|
|
|
|
|
struct drm_v3d_extension *next,
|
|
|
|
|
uint32_t id,
|
|
|
|
|
uintptr_t flags)
|
|
|
|
|
{
|
|
|
|
|
ext->next = (uintptr_t)(void *)next;
|
|
|
|
|
ext->id = id;
|
|
|
|
|
ext->flags = flags;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* This function sets the extension for multiple in/out syncobjs. When it is
|
|
|
|
|
* successful, it sets the extension id to DRM_V3D_EXT_ID_MULTI_SYNC.
|
|
|
|
|
* Otherwise, the extension id is 0, which means an out-of-memory error.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
set_multisync(struct drm_v3d_multi_sync *ms,
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_submit_sync_info *sync_info,
|
2021-10-04 14:31:55 +01:00
|
|
|
struct drm_v3d_extension *next,
|
|
|
|
|
struct v3dv_device *device,
|
2021-12-14 13:40:34 -01:00
|
|
|
struct v3dv_job *job,
|
|
|
|
|
enum v3dv_queue_type queue_sync,
|
2022-03-29 17:52:32 -05:00
|
|
|
enum v3d_queue wait_stage,
|
|
|
|
|
bool signal_syncs)
|
2021-10-04 14:31:55 +01:00
|
|
|
{
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_queue *queue = &device->queue;
|
2021-10-04 14:31:55 +01:00
|
|
|
uint32_t out_sync_count = 0, in_sync_count = 0;
|
2022-03-22 16:20:10 -05:00
|
|
|
struct drm_v3d_sem *out_syncs = NULL, *in_syncs = NULL;
|
2021-10-04 14:31:55 +01:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
in_syncs = set_in_syncs(queue, job, queue_sync,
|
|
|
|
|
&in_sync_count, sync_info);
|
2021-12-14 13:40:34 -01:00
|
|
|
if (!in_syncs && in_sync_count)
|
|
|
|
|
goto fail;
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
out_syncs = set_out_syncs(queue, job, queue_sync,
|
|
|
|
|
&out_sync_count, sync_info, signal_syncs);
|
2021-10-04 14:31:55 +01:00
|
|
|
|
|
|
|
|
assert(out_sync_count > 0);
|
|
|
|
|
|
|
|
|
|
if (!out_syncs)
|
2021-12-14 13:40:34 -01:00
|
|
|
goto fail;
|
2021-10-04 14:31:55 +01:00
|
|
|
|
|
|
|
|
set_ext(&ms->base, next, DRM_V3D_EXT_ID_MULTI_SYNC, 0);
|
2021-12-14 13:40:34 -01:00
|
|
|
ms->wait_stage = wait_stage;
|
2021-10-04 14:31:55 +01:00
|
|
|
ms->out_sync_count = out_sync_count;
|
|
|
|
|
ms->out_syncs = (uintptr_t)(void *)out_syncs;
|
|
|
|
|
ms->in_sync_count = in_sync_count;
|
|
|
|
|
ms->in_syncs = (uintptr_t)(void *)in_syncs;
|
2021-12-14 13:40:34 -01:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
queue->last_job_syncs.first[queue_sync] = false;
|
2022-01-03 12:55:37 -01:00
|
|
|
|
2021-12-14 13:40:34 -01:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
fail:
|
|
|
|
|
if (in_syncs)
|
|
|
|
|
vk_free(&device->vk.alloc, in_syncs);
|
|
|
|
|
assert(!out_syncs);
|
|
|
|
|
|
|
|
|
|
return;
|
2021-10-04 14:31:55 +01:00
|
|
|
}
|
|
|
|
|
|
2020-01-13 17:45:04 +01:00
|
|
|
static VkResult
|
2020-04-20 13:24:09 +02:00
|
|
|
handle_cl_job(struct v3dv_queue *queue,
|
|
|
|
|
struct v3dv_job *job,
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_submit_sync_info *sync_info,
|
|
|
|
|
bool signal_syncs)
|
2019-12-17 11:39:36 +01:00
|
|
|
{
|
2020-03-13 12:01:38 +01:00
|
|
|
struct v3dv_device *device = queue->device;
|
|
|
|
|
|
2021-08-16 12:48:37 +02:00
|
|
|
struct drm_v3d_submit_cl submit = { 0 };
|
2019-12-17 11:39:36 +01:00
|
|
|
|
2020-07-08 09:56:44 +02:00
|
|
|
/* Sanity check: we should only flag a bcl sync on a job that needs to be
|
|
|
|
|
* serialized.
|
|
|
|
|
*/
|
|
|
|
|
assert(job->serialize || !job->needs_bcl_sync);
|
|
|
|
|
|
2020-06-08 10:13:22 +02:00
|
|
|
/* We expect to have just one RCL per job which should fit in just one BO.
|
|
|
|
|
* Our BCL, could chain multiple BOS together though.
|
|
|
|
|
*/
|
|
|
|
|
assert(list_length(&job->rcl.bo_list) == 1);
|
|
|
|
|
assert(list_length(&job->bcl.bo_list) >= 1);
|
|
|
|
|
struct v3dv_bo *bcl_fist_bo =
|
|
|
|
|
list_first_entry(&job->bcl.bo_list, struct v3dv_bo, list_link);
|
|
|
|
|
submit.bcl_start = bcl_fist_bo->offset;
|
2020-01-08 11:14:35 +01:00
|
|
|
submit.bcl_end = job->bcl.bo->offset + v3dv_cl_offset(&job->bcl);
|
|
|
|
|
submit.rcl_start = job->rcl.bo->offset;
|
|
|
|
|
submit.rcl_end = job->rcl.bo->offset + v3dv_cl_offset(&job->rcl);
|
2019-12-17 11:39:36 +01:00
|
|
|
|
2020-05-18 10:41:11 +02:00
|
|
|
submit.qma = job->tile_alloc->offset;
|
|
|
|
|
submit.qms = job->tile_alloc->size;
|
|
|
|
|
submit.qts = job->tile_state->offset;
|
|
|
|
|
|
|
|
|
|
submit.flags = 0;
|
2020-01-08 11:14:35 +01:00
|
|
|
if (job->tmu_dirty_rcl)
|
2019-12-30 13:01:44 +01:00
|
|
|
submit.flags |= DRM_V3D_SUBMIT_CL_FLUSH_CACHE;
|
2019-12-17 11:39:36 +01:00
|
|
|
|
2020-01-08 11:14:35 +01:00
|
|
|
submit.bo_handle_count = job->bo_count;
|
2019-12-17 11:39:36 +01:00
|
|
|
uint32_t *bo_handles =
|
2020-11-23 11:57:15 +01:00
|
|
|
(uint32_t *) malloc(sizeof(uint32_t) * submit.bo_handle_count);
|
2019-12-17 11:39:36 +01:00
|
|
|
uint32_t bo_idx = 0;
|
2020-01-08 11:14:35 +01:00
|
|
|
set_foreach(job->bos, entry) {
|
2019-12-17 11:39:36 +01:00
|
|
|
struct v3dv_bo *bo = (struct v3dv_bo *)entry->key;
|
|
|
|
|
bo_handles[bo_idx++] = bo->handle;
|
|
|
|
|
}
|
|
|
|
|
assert(bo_idx == submit.bo_handle_count);
|
|
|
|
|
submit.bo_handles = (uintptr_t)(void *)bo_handles;
|
|
|
|
|
|
2021-10-04 14:31:55 +01:00
|
|
|
/* We need a binning sync if we are waiting on a semaphore or if the job
|
|
|
|
|
* comes after a pipeline barrier that involves geometry stages
|
2020-07-09 08:47:59 +02:00
|
|
|
* (needs_bcl_sync).
|
|
|
|
|
*
|
|
|
|
|
* We need a render sync if the job doesn't need a binning sync but has
|
|
|
|
|
* still been flagged for serialization. It should be noted that RCL jobs
|
|
|
|
|
* don't start until the previous RCL job has finished so we don't really
|
|
|
|
|
* need to add a fence for those, however, we might need to wait on a CSD or
|
|
|
|
|
* TFU job, which are not automatically serialized with CL jobs.
|
2020-05-18 10:41:11 +02:00
|
|
|
*
|
2021-10-04 14:31:55 +01:00
|
|
|
* FIXME: see if we can do better and avoid bcl syncs for any jobs in the
|
|
|
|
|
* command buffer after the first job where we should be able to track bcl
|
|
|
|
|
* dependencies strictly through barriers.
|
2020-05-18 10:41:11 +02:00
|
|
|
*/
|
2021-10-04 14:31:55 +01:00
|
|
|
const bool needs_bcl_sync =
|
2022-03-29 17:52:32 -05:00
|
|
|
sync_info->wait_count > 0 || job->needs_bcl_sync;
|
2020-07-09 08:47:59 +02:00
|
|
|
const bool needs_rcl_sync = job->serialize && !needs_bcl_sync;
|
2020-07-08 09:56:44 +02:00
|
|
|
|
2021-10-04 14:31:55 +01:00
|
|
|
/* Replace single semaphore settings whenever our kernel-driver supports
|
|
|
|
|
* multiple semaphores extension.
|
|
|
|
|
*/
|
2022-03-22 16:20:10 -05:00
|
|
|
struct drm_v3d_multi_sync ms = { 0 };
|
2021-10-04 14:31:55 +01:00
|
|
|
if (device->pdevice->caps.multisync) {
|
2021-12-14 13:40:34 -01:00
|
|
|
enum v3d_queue wait_stage = needs_rcl_sync ? V3D_RENDER : V3D_BIN;
|
2022-03-29 17:52:32 -05:00
|
|
|
set_multisync(&ms, sync_info, NULL, device, job,
|
|
|
|
|
V3DV_QUEUE_CL, wait_stage, signal_syncs);
|
|
|
|
|
if (!ms.base.id)
|
2021-10-04 14:31:55 +01:00
|
|
|
return vk_error(device->instance, VK_ERROR_OUT_OF_HOST_MEMORY);
|
|
|
|
|
|
|
|
|
|
submit.flags |= DRM_V3D_SUBMIT_EXTENSION;
|
|
|
|
|
submit.extensions = (uintptr_t)(void *)&ms;
|
|
|
|
|
/* Disable legacy sync interface when multisync extension is used */
|
|
|
|
|
submit.in_sync_rcl = 0;
|
|
|
|
|
submit.in_sync_bcl = 0;
|
|
|
|
|
submit.out_sync = 0;
|
|
|
|
|
} else {
|
2022-03-29 17:52:32 -05:00
|
|
|
uint32_t last_job_sync = queue->last_job_syncs.syncs[V3DV_QUEUE_ANY];
|
2021-12-14 13:40:34 -01:00
|
|
|
submit.in_sync_bcl = needs_bcl_sync ? last_job_sync : 0;
|
|
|
|
|
submit.in_sync_rcl = needs_rcl_sync ? last_job_sync : 0;
|
|
|
|
|
submit.out_sync = last_job_sync;
|
2021-10-04 14:31:55 +01:00
|
|
|
}
|
|
|
|
|
|
2020-03-13 12:01:38 +01:00
|
|
|
v3dv_clif_dump(device, job, &submit);
|
v3dv: move authenticated display fd acquisition to swapchain creation time
So far, we have only been supporting X11, so we assumed that we were running
inside X11 and would always try to get an authenticated fd from Xorg during
device initialization. While this works for desktop Raspbian, it is not
really correct and it is not what we want to do when we start considering
other WSIs.
Initially, one could think we can still do this by guarding the WSI code
under the proper instance extension check. This, however, doesn't work
reliably, as the Vulkan loader can call vkEnumerateDevices without enabling
surface extensions on the instance, which then can lead to us not
initializing any display_fd and failing with VK_ERROR_INITIALIZATION_FAILED,
which is not correct, so while we can try to acquire the display_fd here,
it might not always work, and we should definitely not fail initialization
of the physical device for that.
Instead, with this change we move acquisition of display_fd to swapchain
creation time where required extensions need to be enabled in the instance.
This was also suggested by Daniel Stone during review of a work-in-progress
implementation for the Wayland WSI.
There is a special case to consider though: applications like Zink that
don't use Vulkan's swapchains at all but still allocate images that they
intend to use for WSI. We need to handle these by checking that we have
indeed acquired a display_fd before doing any memory allocation for WSI,
and acquiring one at that time if that's not the case.
This change also removes the render_fd and display_fd fields from the
logical device (which we were copying from the physical device), because
now there is no guarantee that we have acquired a display_fd at the
time we create a logical device. Instead, we now put a reference to the
physical device on the logical device from which we can access these.
Finally, this also fixes a regression introduced with VK_KHR_display, where
if that extension is enabled but we are running inside a compositor, we would
acquire a display_fd that is not authenticated and try to use that instead
of acquiring an authenticated display_fd from the display server.
Fixes: b1188c9451 (v3dv: VK_KHR_display extension support)
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7546>
2020-11-11 09:45:33 +01:00
|
|
|
int ret = v3dv_ioctl(device->pdevice->render_fd,
|
|
|
|
|
DRM_IOCTL_V3D_SUBMIT_CL, &submit);
|
2020-05-18 10:41:11 +02:00
|
|
|
|
2019-12-17 11:39:36 +01:00
|
|
|
static bool warned = false;
|
|
|
|
|
if (ret && !warned) {
|
|
|
|
|
fprintf(stderr, "Draw call returned %s. Expect corruption.\n",
|
|
|
|
|
strerror(errno));
|
|
|
|
|
warned = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
free(bo_handles);
|
2022-03-22 16:20:10 -05:00
|
|
|
multisync_free(device, &ms);
|
2019-12-17 11:39:36 +01:00
|
|
|
|
|
|
|
|
if (ret)
|
2022-04-04 09:50:26 -05:00
|
|
|
return vk_queue_set_lost(&queue->vk, "V3D_SUBMIT_CL failed: %m");
|
2019-12-17 11:39:36 +01:00
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
2019-12-16 09:09:40 +01:00
|
|
|
|
2020-04-20 13:24:09 +02:00
|
|
|
static VkResult
|
|
|
|
|
handle_tfu_job(struct v3dv_queue *queue,
|
|
|
|
|
struct v3dv_job *job,
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_submit_sync_info *sync_info,
|
|
|
|
|
bool signal_syncs)
|
2020-04-20 13:24:09 +02:00
|
|
|
{
|
2020-05-18 10:41:11 +02:00
|
|
|
struct v3dv_device *device = queue->device;
|
2020-04-20 13:24:09 +02:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
const bool needs_sync = sync_info->wait_count || job->serialize;
|
2021-10-04 14:36:12 +01:00
|
|
|
|
|
|
|
|
/* Replace single semaphore settings whenever our kernel-driver supports
|
|
|
|
|
* multiple semaphore extension.
|
|
|
|
|
*/
|
2022-03-22 16:20:10 -05:00
|
|
|
struct drm_v3d_multi_sync ms = { 0 };
|
2021-10-04 14:36:12 +01:00
|
|
|
if (device->pdevice->caps.multisync) {
|
2022-03-29 17:52:32 -05:00
|
|
|
set_multisync(&ms, sync_info, NULL, device, job,
|
|
|
|
|
V3DV_QUEUE_TFU, V3D_TFU, signal_syncs);
|
|
|
|
|
if (!ms.base.id)
|
2021-10-04 14:36:12 +01:00
|
|
|
return vk_error(device->instance, VK_ERROR_OUT_OF_HOST_MEMORY);
|
|
|
|
|
|
|
|
|
|
job->tfu.flags |= DRM_V3D_SUBMIT_EXTENSION;
|
|
|
|
|
job->tfu.extensions = (uintptr_t)(void *)&ms;
|
|
|
|
|
/* Disable legacy sync interface when multisync extension is used */
|
|
|
|
|
job->tfu.in_sync = 0;
|
|
|
|
|
job->tfu.out_sync = 0;
|
|
|
|
|
} else {
|
2022-03-29 17:52:32 -05:00
|
|
|
uint32_t last_job_sync = queue->last_job_syncs.syncs[V3DV_QUEUE_ANY];
|
2021-12-14 13:40:34 -01:00
|
|
|
job->tfu.in_sync = needs_sync ? last_job_sync : 0;
|
|
|
|
|
job->tfu.out_sync = last_job_sync;
|
2021-10-04 14:36:12 +01:00
|
|
|
}
|
v3dv: move authenticated display fd acquisition to swapchain creation time
So far, we have only been supporting X11, so we assumed that we were running
inside X11 and would always try to get an authenticated fd from Xorg during
device initialization. While this works for desktop Raspbian, it is not
really correct and it is not what we want to do when we start considering
other WSIs.
Initially, one could think we can still do this by guarding the WSI code
under the proper instance extension check. This, however, doesn't work
reliably, as the Vulkan loader can call vkEnumerateDevices without enabling
surface extensions on the instance, which then can lead to us not
initializing any display_fd and failing with VK_ERROR_INITIALIZATION_FAILED,
which is not correct, so while we can try to acquire the display_fd here,
it might not always work, and we should definitely not fail initialization
of the physical device for that.
Instead, with this change we move acquisition of display_fd to swapchain
creation time where required extensions need to be enabled in the instance.
This was also suggested by Daniel Stone during review of a work-in-progress
implementation for the Wayland WSI.
There is a special case to consider though: applications like Zink that
don't use Vulkan's swapchains at all but still allocate images that they
intend to use for WSI. We need to handle these by checking that we have
indeed acquired a display_fd before doing any memory allocation for WSI,
and acquiring one at that time if that's not the case.
This change also removes the render_fd and display_fd fields from the
logical device (which we were copying from the physical device), because
now there is no guarantee that we have acquired a display_fd at the
time we create a logical device. Instead, we now put a reference to the
physical device on the logical device from which we can access these.
Finally, this also fixes a regression introduced with VK_KHR_display, where
if that extension is enabled but we are running inside a compositor, we would
acquire a display_fd that is not authenticated and try to use that instead
of acquiring an authenticated display_fd from the display server.
Fixes: b1188c9451 (v3dv: VK_KHR_display extension support)
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7546>
2020-11-11 09:45:33 +01:00
|
|
|
int ret = v3dv_ioctl(device->pdevice->render_fd,
|
|
|
|
|
DRM_IOCTL_V3D_SUBMIT_TFU, &job->tfu);
|
2020-05-18 10:41:11 +02:00
|
|
|
|
2022-03-22 16:20:10 -05:00
|
|
|
multisync_free(device, &ms);
|
2021-10-04 14:36:12 +01:00
|
|
|
|
2022-04-04 09:50:26 -05:00
|
|
|
if (ret != 0)
|
|
|
|
|
return vk_queue_set_lost(&queue->vk, "V3D_SUBMIT_TFU failed: %m");
|
2020-04-20 13:24:09 +02:00
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-18 13:53:51 +02:00
|
|
|
static VkResult
|
|
|
|
|
handle_csd_job(struct v3dv_queue *queue,
|
|
|
|
|
struct v3dv_job *job,
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_submit_sync_info *sync_info,
|
|
|
|
|
bool signal_syncs)
|
2020-06-18 13:53:51 +02:00
|
|
|
{
|
|
|
|
|
struct v3dv_device *device = queue->device;
|
|
|
|
|
|
|
|
|
|
struct drm_v3d_submit_csd *submit = &job->csd.submit;
|
|
|
|
|
|
|
|
|
|
submit->bo_handle_count = job->bo_count;
|
|
|
|
|
uint32_t *bo_handles =
|
|
|
|
|
(uint32_t *) malloc(sizeof(uint32_t) * MAX2(4, submit->bo_handle_count * 2));
|
|
|
|
|
uint32_t bo_idx = 0;
|
|
|
|
|
set_foreach(job->bos, entry) {
|
|
|
|
|
struct v3dv_bo *bo = (struct v3dv_bo *)entry->key;
|
|
|
|
|
bo_handles[bo_idx++] = bo->handle;
|
|
|
|
|
}
|
|
|
|
|
assert(bo_idx == submit->bo_handle_count);
|
|
|
|
|
submit->bo_handles = (uintptr_t)(void *)bo_handles;
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
const bool needs_sync = sync_info->wait_count || job->serialize;
|
2020-07-09 08:47:59 +02:00
|
|
|
|
2021-10-04 15:53:51 +01:00
|
|
|
/* Replace single semaphore settings whenever our kernel-driver supports
|
|
|
|
|
* multiple semaphore extension.
|
|
|
|
|
*/
|
2022-03-22 16:20:10 -05:00
|
|
|
struct drm_v3d_multi_sync ms = { 0 };
|
2021-10-04 15:53:51 +01:00
|
|
|
if (device->pdevice->caps.multisync) {
|
2022-03-29 17:52:32 -05:00
|
|
|
set_multisync(&ms, sync_info, NULL, device, job,
|
|
|
|
|
V3DV_QUEUE_CSD, V3D_CSD, signal_syncs);
|
|
|
|
|
if (!ms.base.id)
|
2021-10-04 15:53:51 +01:00
|
|
|
return vk_error(device->instance, VK_ERROR_OUT_OF_HOST_MEMORY);
|
|
|
|
|
|
|
|
|
|
submit->flags |= DRM_V3D_SUBMIT_EXTENSION;
|
|
|
|
|
submit->extensions = (uintptr_t)(void *)&ms;
|
|
|
|
|
/* Disable legacy sync interface when multisync extension is used */
|
|
|
|
|
submit->in_sync = 0;
|
|
|
|
|
submit->out_sync = 0;
|
|
|
|
|
} else {
|
2022-03-29 17:52:32 -05:00
|
|
|
uint32_t last_job_sync = queue->last_job_syncs.syncs[V3DV_QUEUE_ANY];
|
2021-12-14 13:40:34 -01:00
|
|
|
submit->in_sync = needs_sync ? last_job_sync : 0;
|
|
|
|
|
submit->out_sync = last_job_sync;
|
2021-10-04 15:53:51 +01:00
|
|
|
}
|
v3dv: move authenticated display fd acquisition to swapchain creation time
So far, we have only been supporting X11, so we assumed that we were running
inside X11 and would always try to get an authenticated fd from Xorg during
device initialization. While this works for desktop Raspbian, it is not
really correct and it is not what we want to do when we start considering
other WSIs.
Initially, one could think we can still do this by guarding the WSI code
under the proper instance extension check. This, however, doesn't work
reliably, as the Vulkan loader can call vkEnumerateDevices without enabling
surface extensions on the instance, which then can lead to us not
initializing any display_fd and failing with VK_ERROR_INITIALIZATION_FAILED,
which is not correct, so while we can try to acquire the display_fd here,
it might not always work, and we should definitely not fail initialization
of the physical device for that.
Instead, with this change we move acquisition of display_fd to swapchain
creation time where required extensions need to be enabled in the instance.
This was also suggested by Daniel Stone during review of a work-in-progress
implementation for the Wayland WSI.
There is a special case to consider though: applications like Zink that
don't use Vulkan's swapchains at all but still allocate images that they
intend to use for WSI. We need to handle these by checking that we have
indeed acquired a display_fd before doing any memory allocation for WSI,
and acquiring one at that time if that's not the case.
This change also removes the render_fd and display_fd fields from the
logical device (which we were copying from the physical device), because
now there is no guarantee that we have acquired a display_fd at the
time we create a logical device. Instead, we now put a reference to the
physical device on the logical device from which we can access these.
Finally, this also fixes a regression introduced with VK_KHR_display, where
if that extension is enabled but we are running inside a compositor, we would
acquire a display_fd that is not authenticated and try to use that instead
of acquiring an authenticated display_fd from the display server.
Fixes: b1188c9451 (v3dv: VK_KHR_display extension support)
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7546>
2020-11-11 09:45:33 +01:00
|
|
|
int ret = v3dv_ioctl(device->pdevice->render_fd,
|
|
|
|
|
DRM_IOCTL_V3D_SUBMIT_CSD, submit);
|
2020-06-18 13:53:51 +02:00
|
|
|
|
|
|
|
|
static bool warned = false;
|
|
|
|
|
if (ret && !warned) {
|
|
|
|
|
fprintf(stderr, "Compute dispatch returned %s. Expect corruption.\n",
|
|
|
|
|
strerror(errno));
|
|
|
|
|
warned = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
free(bo_handles);
|
|
|
|
|
|
2022-03-22 16:20:10 -05:00
|
|
|
multisync_free(device, &ms);
|
2021-10-04 15:53:51 +01:00
|
|
|
|
2020-06-18 13:53:51 +02:00
|
|
|
if (ret)
|
2022-04-04 09:50:26 -05:00
|
|
|
return vk_queue_set_lost(&queue->vk, "V3D_SUBMIT_CSD failed: %m");
|
2020-06-18 13:53:51 +02:00
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-20 13:24:09 +02:00
|
|
|
static VkResult
|
2022-03-29 17:52:32 -05:00
|
|
|
queue_handle_job(struct v3dv_queue *queue,
|
2020-04-20 13:24:09 +02:00
|
|
|
struct v3dv_job *job,
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_submit_sync_info *sync_info,
|
|
|
|
|
bool signal_syncs)
|
2020-04-20 13:24:09 +02:00
|
|
|
{
|
|
|
|
|
switch (job->type) {
|
|
|
|
|
case V3DV_JOB_TYPE_GPU_CL:
|
2022-03-29 17:52:32 -05:00
|
|
|
return handle_cl_job(queue, job, sync_info, signal_syncs);
|
2020-04-20 13:24:09 +02:00
|
|
|
case V3DV_JOB_TYPE_GPU_TFU:
|
2022-03-29 17:52:32 -05:00
|
|
|
return handle_tfu_job(queue, job, sync_info, signal_syncs);
|
2020-06-18 13:53:51 +02:00
|
|
|
case V3DV_JOB_TYPE_GPU_CSD:
|
2022-03-29 17:52:32 -05:00
|
|
|
return handle_csd_job(queue, job, sync_info, signal_syncs);
|
2020-04-20 13:24:09 +02:00
|
|
|
case V3DV_JOB_TYPE_CPU_RESET_QUERIES:
|
2022-03-29 17:52:32 -05:00
|
|
|
return handle_reset_query_cpu_job(queue, job, sync_info);
|
2020-04-20 13:24:09 +02:00
|
|
|
case V3DV_JOB_TYPE_CPU_END_QUERY:
|
|
|
|
|
return handle_end_query_cpu_job(job);
|
|
|
|
|
case V3DV_JOB_TYPE_CPU_COPY_QUERY_RESULTS:
|
|
|
|
|
return handle_copy_query_results_cpu_job(job);
|
2020-05-18 10:41:11 +02:00
|
|
|
case V3DV_JOB_TYPE_CPU_SET_EVENT:
|
2022-03-29 17:52:32 -05:00
|
|
|
return handle_set_event_cpu_job(queue, job, sync_info);
|
2020-05-18 10:41:11 +02:00
|
|
|
case V3DV_JOB_TYPE_CPU_WAIT_EVENTS:
|
2022-03-29 17:52:32 -05:00
|
|
|
return handle_wait_events_cpu_job(job);
|
2020-06-15 16:44:49 +02:00
|
|
|
case V3DV_JOB_TYPE_CPU_COPY_BUFFER_TO_IMAGE:
|
2022-03-29 17:52:32 -05:00
|
|
|
return handle_copy_buffer_to_image_cpu_job(queue, job, sync_info);
|
2020-06-19 11:56:20 +02:00
|
|
|
case V3DV_JOB_TYPE_CPU_CSD_INDIRECT:
|
2022-03-29 17:52:32 -05:00
|
|
|
return handle_csd_indirect_cpu_job(queue, job, sync_info);
|
2020-10-29 11:55:23 +01:00
|
|
|
case V3DV_JOB_TYPE_CPU_TIMESTAMP_QUERY:
|
2022-03-29 17:52:32 -05:00
|
|
|
return handle_timestamp_query_cpu_job(queue, job, sync_info);
|
2020-04-20 13:24:09 +02:00
|
|
|
default:
|
|
|
|
|
unreachable("Unhandled job type");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-13 11:35:06 +01:00
|
|
|
static VkResult
|
2020-09-18 18:02:05 +02:00
|
|
|
queue_create_noop_job(struct v3dv_queue *queue)
|
2020-03-13 11:35:06 +01:00
|
|
|
{
|
2020-03-13 12:01:38 +01:00
|
|
|
struct v3dv_device *device = queue->device;
|
2020-11-12 16:30:41 +01:00
|
|
|
queue->noop_job = vk_zalloc(&device->vk.alloc, sizeof(struct v3dv_job), 8,
|
2020-09-18 18:02:05 +02:00
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
|
|
|
|
|
if (!queue->noop_job)
|
2021-09-24 15:31:03 -05:00
|
|
|
return vk_error(device, VK_ERROR_OUT_OF_HOST_MEMORY);
|
2020-09-18 18:02:05 +02:00
|
|
|
v3dv_job_init(queue->noop_job, V3DV_JOB_TYPE_GPU_CL, device, NULL, -1);
|
2020-03-13 11:35:06 +01:00
|
|
|
|
v3dv: start to move and wrap hw-version code with v3dv_queue
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>
2021-06-10 13:39:35 +02:00
|
|
|
v3dv_X(device, job_emit_noop)(queue->noop_job);
|
2020-03-13 11:35:06 +01:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
queue->noop_job->serialize = true;
|
2021-12-16 22:43:49 +00:00
|
|
|
|
2020-04-16 10:31:17 +02:00
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
VkResult
|
|
|
|
|
v3dv_queue_driver_submit(struct vk_queue *vk_queue,
|
|
|
|
|
struct vk_queue_submit *submit)
|
2020-05-18 10:41:11 +02:00
|
|
|
{
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_queue *queue = container_of(vk_queue, struct v3dv_queue, vk);
|
|
|
|
|
VkResult result;
|
2020-03-13 11:35:06 +01:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
struct v3dv_submit_sync_info sync_info = {
|
|
|
|
|
.wait_count = submit->wait_count,
|
|
|
|
|
.waits = submit->waits,
|
|
|
|
|
.signal_count = submit->signal_count,
|
|
|
|
|
.signals = submit->signals,
|
2021-11-08 14:50:52 -01:00
|
|
|
};
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
for (int i = 0; i < V3DV_QUEUE_COUNT; i++)
|
|
|
|
|
queue->last_job_syncs.first[i] = true;
|
2020-01-08 11:14:35 +01:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
result = process_waits(queue, sync_info.wait_count, sync_info.waits);
|
2020-03-13 11:35:06 +01:00
|
|
|
if (result != VK_SUCCESS)
|
|
|
|
|
return result;
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
for (uint32_t i = 0; i < submit->command_buffer_count; i++) {
|
|
|
|
|
struct v3dv_cmd_buffer *cmd_buffer =
|
|
|
|
|
container_of(submit->command_buffers[i], struct v3dv_cmd_buffer, vk);
|
|
|
|
|
list_for_each_entry_safe(struct v3dv_job, job,
|
|
|
|
|
&cmd_buffer->jobs, list_link) {
|
2020-01-13 12:31:12 +01:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
result = queue_handle_job(queue, job, &sync_info, false);
|
|
|
|
|
if (result != VK_SUCCESS)
|
|
|
|
|
return result;
|
2021-06-01 09:41:48 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
/* Finish by submitting a no-op job that synchronizes across all queues.
|
|
|
|
|
* This will ensure that the signal semaphores don't get triggered until
|
|
|
|
|
* all work on any queue completes.
|
2021-06-01 09:41:48 +02:00
|
|
|
*/
|
2022-03-29 17:52:32 -05:00
|
|
|
if (!queue->noop_job) {
|
|
|
|
|
result = queue_create_noop_job(queue);
|
|
|
|
|
if (result != VK_SUCCESS)
|
|
|
|
|
return result;
|
2020-01-14 09:48:19 +01:00
|
|
|
}
|
2022-03-29 17:52:32 -05:00
|
|
|
result = queue_handle_job(queue, queue->noop_job, &sync_info, true);
|
|
|
|
|
if (result != VK_SUCCESS)
|
|
|
|
|
return result;
|
2020-01-14 09:48:19 +01:00
|
|
|
|
2022-03-29 17:52:32 -05:00
|
|
|
process_signals(queue, sync_info.signal_count, sync_info.signals);
|
2020-01-14 09:48:19 +01:00
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
}
|
2020-06-04 09:03:42 +02:00
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
VKAPI_ATTR VkResult VKAPI_CALL
|
2020-06-04 09:03:42 +02:00
|
|
|
v3dv_QueueBindSparse(VkQueue _queue,
|
|
|
|
|
uint32_t bindInfoCount,
|
|
|
|
|
const VkBindSparseInfo *pBindInfo,
|
|
|
|
|
VkFence fence)
|
|
|
|
|
{
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_queue, queue, _queue);
|
2021-09-24 15:31:03 -05:00
|
|
|
return vk_error(queue, VK_ERROR_FEATURE_NOT_PRESENT);
|
2020-06-04 09:03:42 +02:00
|
|
|
}
|