2019-12-10 09:03:49 +01:00
|
|
|
|
/*
|
2022-02-17 12:38:42 +01:00
|
|
|
|
* Copyright © 2019 Raspberry Pi Ltd
|
2019-12-10 09:03:49 +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 08:58:20 +01:00
|
|
|
|
#include "util/u_pack_color.h"
|
2020-11-30 02:00:48 -08:00
|
|
|
|
#include "vk_util.h"
|
2019-12-13 10:48:12 +01:00
|
|
|
|
|
|
|
|
|
|
void
|
2020-01-08 11:14:35 +01:00
|
|
|
|
v3dv_job_add_bo(struct v3dv_job *job, struct v3dv_bo *bo)
|
2019-12-13 10:48:12 +01:00
|
|
|
|
{
|
|
|
|
|
|
if (!bo)
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
2021-04-14 09:08:36 +02:00
|
|
|
|
if (job->bo_handle_mask & bo->handle_bit) {
|
|
|
|
|
|
if (_mesa_set_search(job->bos, bo))
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
2019-12-13 10:48:12 +01:00
|
|
|
|
|
2020-01-08 11:14:35 +01:00
|
|
|
|
_mesa_set_add(job->bos, bo);
|
|
|
|
|
|
job->bo_count++;
|
2021-04-14 09:08:36 +02:00
|
|
|
|
job->bo_handle_mask |= bo->handle_bit;
|
2019-12-13 10:48:12 +01:00
|
|
|
|
}
|
2019-12-10 09:03:49 +01:00
|
|
|
|
|
2021-04-13 12:21:08 +02:00
|
|
|
|
void
|
|
|
|
|
|
v3dv_job_add_bo_unchecked(struct v3dv_job *job, struct v3dv_bo *bo)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(bo);
|
|
|
|
|
|
_mesa_set_add(job->bos, bo);
|
|
|
|
|
|
job->bo_count++;
|
2021-04-14 09:08:36 +02:00
|
|
|
|
job->bo_handle_mask |= bo->handle_bit;
|
2021-04-13 12:21:08 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-02-20 09:53:32 +01:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_init(struct v3dv_cmd_buffer *cmd_buffer,
|
2022-02-07 16:02:20 -06:00
|
|
|
|
struct v3dv_device *device)
|
2020-02-20 09:53:32 +01:00
|
|
|
|
{
|
2020-11-12 16:30:41 +01:00
|
|
|
|
/* Do not reset the base object! If we are calling this from a command
|
|
|
|
|
|
* buffer reset that would reset the loader's dispatch table for the
|
|
|
|
|
|
* command buffer, and any other relevant info from vk_object_base
|
2020-03-04 11:12:08 +01:00
|
|
|
|
*/
|
2021-04-06 15:13:14 +03:00
|
|
|
|
const uint32_t base_size = sizeof(struct vk_command_buffer);
|
2020-11-12 16:30:41 +01:00
|
|
|
|
uint8_t *cmd_buffer_driver_start = ((uint8_t *) cmd_buffer) + base_size;
|
|
|
|
|
|
memset(cmd_buffer_driver_start, 0, sizeof(*cmd_buffer) - base_size);
|
2020-02-20 09:53:32 +01:00
|
|
|
|
|
|
|
|
|
|
cmd_buffer->device = device;
|
|
|
|
|
|
|
2020-04-29 09:13:00 +02:00
|
|
|
|
list_inithead(&cmd_buffer->private_objs);
|
2020-05-26 12:05:43 +02:00
|
|
|
|
list_inithead(&cmd_buffer->jobs);
|
2020-05-18 10:41:11 +02:00
|
|
|
|
list_inithead(&cmd_buffer->list_link);
|
2020-02-20 09:53:32 +01:00
|
|
|
|
|
2020-03-31 12:59:44 +02:00
|
|
|
|
cmd_buffer->state.subpass_idx = -1;
|
|
|
|
|
|
cmd_buffer->state.meta.subpass_idx = -1;
|
|
|
|
|
|
|
2020-02-20 09:53:32 +01:00
|
|
|
|
cmd_buffer->status = V3DV_CMD_BUFFER_STATUS_INITIALIZED;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2022-02-07 16:02:20 -06:00
|
|
|
|
static void cmd_buffer_destroy(struct vk_command_buffer *cmd_buffer);
|
|
|
|
|
|
|
2019-12-10 09:33:13 +01:00
|
|
|
|
static VkResult
|
|
|
|
|
|
cmd_buffer_create(struct v3dv_device *device,
|
2022-02-07 16:02:20 -06:00
|
|
|
|
struct vk_command_pool *pool,
|
2019-12-10 09:33:13 +01:00
|
|
|
|
VkCommandBufferLevel level,
|
|
|
|
|
|
VkCommandBuffer *pCommandBuffer)
|
|
|
|
|
|
{
|
|
|
|
|
|
struct v3dv_cmd_buffer *cmd_buffer;
|
2022-02-07 16:02:20 -06:00
|
|
|
|
cmd_buffer = vk_zalloc(&pool->alloc,
|
2022-02-07 15:51:22 -06:00
|
|
|
|
sizeof(*cmd_buffer),
|
|
|
|
|
|
8,
|
|
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
|
2019-12-10 09:33:13 +01:00
|
|
|
|
if (cmd_buffer == NULL)
|
2021-09-24 15:31:03 -05:00
|
|
|
|
return vk_error(device, VK_ERROR_OUT_OF_HOST_MEMORY);
|
2019-12-10 09:33:13 +01:00
|
|
|
|
|
2021-04-06 15:13:14 +03:00
|
|
|
|
VkResult result;
|
2022-02-07 16:02:20 -06:00
|
|
|
|
result = vk_command_buffer_init(&cmd_buffer->vk, pool, level);
|
2021-04-06 15:13:14 +03:00
|
|
|
|
if (result != VK_SUCCESS) {
|
2022-02-07 16:02:20 -06:00
|
|
|
|
vk_free(&pool->alloc, cmd_buffer);
|
2021-04-06 15:13:14 +03:00
|
|
|
|
return result;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2022-02-07 16:02:20 -06:00
|
|
|
|
cmd_buffer->vk.destroy = cmd_buffer_destroy;
|
|
|
|
|
|
cmd_buffer_init(cmd_buffer, device);
|
2019-12-10 09:33:13 +01:00
|
|
|
|
|
|
|
|
|
|
*pCommandBuffer = v3dv_cmd_buffer_to_handle(cmd_buffer);
|
|
|
|
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-05-18 10:41:11 +02:00
|
|
|
|
static void
|
|
|
|
|
|
job_destroy_gpu_cl_resources(struct v3dv_job *job)
|
|
|
|
|
|
{
|
2020-06-02 12:26:50 +02:00
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_GPU_CL ||
|
|
|
|
|
|
job->type == V3DV_JOB_TYPE_GPU_CL_SECONDARY);
|
2020-05-18 10:41:11 +02:00
|
|
|
|
|
|
|
|
|
|
v3dv_cl_destroy(&job->bcl);
|
|
|
|
|
|
v3dv_cl_destroy(&job->rcl);
|
|
|
|
|
|
v3dv_cl_destroy(&job->indirect);
|
|
|
|
|
|
|
|
|
|
|
|
/* Since we don't ref BOs when we add them to the command buffer, don't
|
|
|
|
|
|
* unref them here either. Bo's will be freed when their corresponding API
|
|
|
|
|
|
* objects are destroyed.
|
|
|
|
|
|
*/
|
|
|
|
|
|
_mesa_set_destroy(job->bos, NULL);
|
|
|
|
|
|
|
|
|
|
|
|
v3dv_bo_free(job->device, job->tile_alloc);
|
|
|
|
|
|
v3dv_bo_free(job->device, job->tile_state);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-06-09 14:31:40 +02:00
|
|
|
|
static void
|
|
|
|
|
|
job_destroy_cloned_gpu_cl_resources(struct v3dv_job *job)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_GPU_CL);
|
|
|
|
|
|
|
|
|
|
|
|
list_for_each_entry_safe(struct v3dv_bo, bo, &job->bcl.bo_list, list_link) {
|
|
|
|
|
|
list_del(&bo->list_link);
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_free(&job->device->vk.alloc, bo);
|
2020-06-09 14:31:40 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
list_for_each_entry_safe(struct v3dv_bo, bo, &job->rcl.bo_list, list_link) {
|
|
|
|
|
|
list_del(&bo->list_link);
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_free(&job->device->vk.alloc, bo);
|
2020-06-09 14:31:40 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
list_for_each_entry_safe(struct v3dv_bo, bo, &job->indirect.bo_list, list_link) {
|
|
|
|
|
|
list_del(&bo->list_link);
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_free(&job->device->vk.alloc, bo);
|
2020-06-09 14:31:40 +02:00
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-06-18 13:53:51 +02:00
|
|
|
|
static void
|
|
|
|
|
|
job_destroy_gpu_csd_resources(struct v3dv_job *job)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_GPU_CSD);
|
|
|
|
|
|
assert(job->cmd_buffer);
|
|
|
|
|
|
|
|
|
|
|
|
v3dv_cl_destroy(&job->indirect);
|
|
|
|
|
|
|
|
|
|
|
|
_mesa_set_destroy(job->bos, NULL);
|
|
|
|
|
|
|
|
|
|
|
|
if (job->csd.shared_memory)
|
|
|
|
|
|
v3dv_bo_free(job->device, job->csd.shared_memory);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-05-18 10:41:11 +02:00
|
|
|
|
static void
|
|
|
|
|
|
job_destroy_cpu_wait_events_resources(struct v3dv_job *job)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_CPU_WAIT_EVENTS);
|
|
|
|
|
|
assert(job->cmd_buffer);
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_free(&job->cmd_buffer->device->vk.alloc, job->cpu.event_wait.events);
|
2020-05-18 10:41:11 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-03-13 11:35:06 +01:00
|
|
|
|
void
|
|
|
|
|
|
v3dv_job_destroy(struct v3dv_job *job)
|
2019-12-10 09:33:13 +01:00
|
|
|
|
{
|
2020-01-08 11:14:35 +01:00
|
|
|
|
assert(job);
|
|
|
|
|
|
|
|
|
|
|
|
list_del(&job->list_link);
|
2019-12-13 10:48:12 +01:00
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
/* Cloned jobs don't make deep copies of the original jobs, so they don't
|
2020-06-09 14:31:40 +02:00
|
|
|
|
* own any of their resources. However, they do allocate clones of BO
|
|
|
|
|
|
* structs, so make sure we free those.
|
2020-05-26 12:05:43 +02:00
|
|
|
|
*/
|
|
|
|
|
|
if (!job->is_clone) {
|
|
|
|
|
|
switch (job->type) {
|
|
|
|
|
|
case V3DV_JOB_TYPE_GPU_CL:
|
2020-06-02 12:26:50 +02:00
|
|
|
|
case V3DV_JOB_TYPE_GPU_CL_SECONDARY:
|
2020-05-26 12:05:43 +02:00
|
|
|
|
job_destroy_gpu_cl_resources(job);
|
|
|
|
|
|
break;
|
2020-06-18 13:53:51 +02:00
|
|
|
|
case V3DV_JOB_TYPE_GPU_CSD:
|
|
|
|
|
|
job_destroy_gpu_csd_resources(job);
|
|
|
|
|
|
break;
|
2020-05-26 12:05:43 +02:00
|
|
|
|
case V3DV_JOB_TYPE_CPU_WAIT_EVENTS:
|
|
|
|
|
|
job_destroy_cpu_wait_events_resources(job);
|
|
|
|
|
|
break;
|
|
|
|
|
|
default:
|
|
|
|
|
|
break;
|
|
|
|
|
|
}
|
2020-06-09 14:31:40 +02:00
|
|
|
|
} else {
|
|
|
|
|
|
/* Cloned jobs */
|
|
|
|
|
|
if (job->type == V3DV_JOB_TYPE_GPU_CL)
|
|
|
|
|
|
job_destroy_cloned_gpu_cl_resources(job);
|
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-03-12 11:53:13 +01:00
|
|
|
|
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_free(&job->device->vk.alloc, job);
|
2020-01-08 11:14:35 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-04-29 09:13:00 +02:00
|
|
|
|
void
|
|
|
|
|
|
v3dv_cmd_buffer_add_private_obj(struct v3dv_cmd_buffer *cmd_buffer,
|
2020-05-14 09:23:40 +02:00
|
|
|
|
uint64_t obj,
|
2020-04-29 09:13:00 +02:00
|
|
|
|
v3dv_cmd_buffer_private_obj_destroy_cb destroy_cb)
|
|
|
|
|
|
{
|
|
|
|
|
|
struct v3dv_cmd_buffer_private_obj *pobj =
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_alloc(&cmd_buffer->device->vk.alloc, sizeof(*pobj), 8,
|
2020-05-29 12:00:12 +02:00
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
2020-04-29 09:13:00 +02:00
|
|
|
|
if (!pobj) {
|
2020-05-15 10:46:13 +02:00
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
2020-04-29 09:13:00 +02:00
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
pobj->obj = obj;
|
|
|
|
|
|
pobj->destroy_cb = destroy_cb;
|
|
|
|
|
|
|
|
|
|
|
|
list_addtail(&pobj->list_link, &cmd_buffer->private_objs);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_destroy_private_obj(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct v3dv_cmd_buffer_private_obj *pobj)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(pobj && pobj->obj && pobj->destroy_cb);
|
|
|
|
|
|
pobj->destroy_cb(v3dv_device_to_handle(cmd_buffer->device),
|
|
|
|
|
|
pobj->obj,
|
2020-11-12 16:30:41 +01:00
|
|
|
|
&cmd_buffer->device->vk.alloc);
|
2020-04-29 09:13:00 +02:00
|
|
|
|
list_del(&pobj->list_link);
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_free(&cmd_buffer->device->vk.alloc, pobj);
|
2020-04-29 09:13:00 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-01-08 11:14:35 +01:00
|
|
|
|
static void
|
2020-02-20 09:53:32 +01:00
|
|
|
|
cmd_buffer_free_resources(struct v3dv_cmd_buffer *cmd_buffer)
|
2020-01-08 11:14:35 +01:00
|
|
|
|
{
|
|
|
|
|
|
list_for_each_entry_safe(struct v3dv_job, job,
|
2020-05-26 12:05:43 +02:00
|
|
|
|
&cmd_buffer->jobs, list_link) {
|
2020-03-13 11:35:06 +01:00
|
|
|
|
v3dv_job_destroy(job);
|
2020-01-08 11:14:35 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (cmd_buffer->state.job)
|
2020-03-13 11:35:06 +01:00
|
|
|
|
v3dv_job_destroy(cmd_buffer->state.job);
|
2019-12-17 08:41:35 +01:00
|
|
|
|
|
2020-06-02 13:13:43 +02:00
|
|
|
|
if (cmd_buffer->state.attachments)
|
2022-02-07 16:02:20 -06:00
|
|
|
|
vk_free(&cmd_buffer->vk.pool->alloc, cmd_buffer->state.attachments);
|
2020-01-09 12:50:43 +01:00
|
|
|
|
|
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
|
|
|
|
if (cmd_buffer->state.query.end.alloc_count > 0)
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_free(&cmd_buffer->device->vk.alloc, cmd_buffer->state.query.end.states);
|
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-03-16 12:34:02 +01:00
|
|
|
|
if (cmd_buffer->push_constants_resource.bo)
|
|
|
|
|
|
v3dv_bo_free(cmd_buffer->device, cmd_buffer->push_constants_resource.bo);
|
2020-04-29 09:13:00 +02:00
|
|
|
|
|
|
|
|
|
|
list_for_each_entry_safe(struct v3dv_cmd_buffer_private_obj, pobj,
|
|
|
|
|
|
&cmd_buffer->private_objs, list_link) {
|
|
|
|
|
|
cmd_buffer_destroy_private_obj(cmd_buffer, pobj);
|
|
|
|
|
|
}
|
2020-04-29 09:42:01 +02:00
|
|
|
|
|
2020-06-02 13:13:43 +02:00
|
|
|
|
if (cmd_buffer->state.meta.attachments) {
|
|
|
|
|
|
assert(cmd_buffer->state.meta.attachment_alloc_count > 0);
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_free(&cmd_buffer->device->vk.alloc, cmd_buffer->state.meta.attachments);
|
2020-06-02 13:13:43 +02:00
|
|
|
|
}
|
2020-02-20 09:53:32 +01:00
|
|
|
|
}
|
2020-09-11 23:26:07 +02:00
|
|
|
|
|
2020-02-20 09:53:32 +01:00
|
|
|
|
static void
|
2022-02-07 16:02:20 -06:00
|
|
|
|
cmd_buffer_destroy(struct vk_command_buffer *vk_cmd_buffer)
|
2020-02-20 09:53:32 +01:00
|
|
|
|
{
|
2022-02-07 16:02:20 -06:00
|
|
|
|
struct v3dv_cmd_buffer *cmd_buffer =
|
|
|
|
|
|
container_of(vk_cmd_buffer, struct v3dv_cmd_buffer, vk);
|
|
|
|
|
|
|
2020-02-20 09:53:32 +01:00
|
|
|
|
cmd_buffer_free_resources(cmd_buffer);
|
2021-04-06 15:13:14 +03:00
|
|
|
|
vk_command_buffer_finish(&cmd_buffer->vk);
|
2022-02-07 16:02:20 -06:00
|
|
|
|
vk_free(&cmd_buffer->vk.pool->alloc, cmd_buffer);
|
2019-12-10 09:33:13 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-01-10 11:31:51 +01:00
|
|
|
|
static bool
|
|
|
|
|
|
attachment_list_is_subset(struct v3dv_subpass_attachment *l1, uint32_t l1_count,
|
|
|
|
|
|
struct v3dv_subpass_attachment *l2, uint32_t l2_count)
|
|
|
|
|
|
{
|
|
|
|
|
|
for (uint32_t i = 0; i < l1_count; i++) {
|
|
|
|
|
|
uint32_t attachment_idx = l1[i].attachment;
|
|
|
|
|
|
if (attachment_idx == VK_ATTACHMENT_UNUSED)
|
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
|
|
uint32_t j;
|
|
|
|
|
|
for (j = 0; j < l2_count; j++) {
|
|
|
|
|
|
if (l2[j].attachment == attachment_idx)
|
|
|
|
|
|
break;
|
|
|
|
|
|
}
|
|
|
|
|
|
if (j == l2_count)
|
|
|
|
|
|
return false;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static bool
|
2020-04-14 11:35:46 +02:00
|
|
|
|
cmd_buffer_can_merge_subpass(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
uint32_t subpass_idx)
|
2020-01-10 11:31:51 +01:00
|
|
|
|
{
|
|
|
|
|
|
const struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
assert(state->pass);
|
|
|
|
|
|
|
|
|
|
|
|
const struct v3dv_physical_device *physical_device =
|
|
|
|
|
|
&cmd_buffer->device->instance->physicalDevice;
|
|
|
|
|
|
|
2021-12-14 15:42:14 +01:00
|
|
|
|
if (cmd_buffer->vk.level != VK_COMMAND_BUFFER_LEVEL_PRIMARY)
|
2020-05-26 12:05:43 +02:00
|
|
|
|
return false;
|
|
|
|
|
|
|
2020-03-18 10:00:31 +01:00
|
|
|
|
if (!cmd_buffer->state.job)
|
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
|
|
if (cmd_buffer->state.job->always_flush)
|
|
|
|
|
|
return false;
|
|
|
|
|
|
|
2020-01-10 11:31:51 +01:00
|
|
|
|
if (!physical_device->options.merge_jobs)
|
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
|
|
/* Each render pass starts a new job */
|
2020-04-14 11:35:46 +02:00
|
|
|
|
if (subpass_idx == 0)
|
2020-01-10 11:31:51 +01:00
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
|
|
/* Two subpasses can be merged in the same job if we can emit a single RCL
|
|
|
|
|
|
* for them (since the RCL includes the END_OF_RENDERING command that
|
|
|
|
|
|
* triggers the "render job finished" interrupt). We can do this so long
|
|
|
|
|
|
* as both subpasses render against the same attachments.
|
|
|
|
|
|
*/
|
2020-04-14 11:35:46 +02:00
|
|
|
|
assert(state->subpass_idx == subpass_idx - 1);
|
|
|
|
|
|
struct v3dv_subpass *prev_subpass = &state->pass->subpasses[state->subpass_idx];
|
|
|
|
|
|
struct v3dv_subpass *subpass = &state->pass->subpasses[subpass_idx];
|
2020-01-10 11:31:51 +01:00
|
|
|
|
|
2021-07-22 13:49:48 +02:00
|
|
|
|
/* Don't merge if the subpasses have different view masks, since in that
|
|
|
|
|
|
* case the framebuffer setup is different and we need to emit different
|
|
|
|
|
|
* RCLs.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (subpass->view_mask != prev_subpass->view_mask)
|
|
|
|
|
|
return false;
|
|
|
|
|
|
|
2020-01-10 11:31:51 +01:00
|
|
|
|
/* Because the list of subpass attachments can include VK_ATTACHMENT_UNUSED,
|
|
|
|
|
|
* we need to check that for each subpass all its used attachments are
|
|
|
|
|
|
* used by the other subpass.
|
|
|
|
|
|
*/
|
|
|
|
|
|
bool compatible =
|
|
|
|
|
|
attachment_list_is_subset(prev_subpass->color_attachments,
|
|
|
|
|
|
prev_subpass->color_count,
|
|
|
|
|
|
subpass->color_attachments,
|
|
|
|
|
|
subpass->color_count);
|
|
|
|
|
|
if (!compatible)
|
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
|
|
compatible =
|
|
|
|
|
|
attachment_list_is_subset(subpass->color_attachments,
|
|
|
|
|
|
subpass->color_count,
|
|
|
|
|
|
prev_subpass->color_attachments,
|
|
|
|
|
|
prev_subpass->color_count);
|
|
|
|
|
|
if (!compatible)
|
|
|
|
|
|
return false;
|
|
|
|
|
|
|
2020-01-28 13:03:41 +01:00
|
|
|
|
if (subpass->ds_attachment.attachment !=
|
|
|
|
|
|
prev_subpass->ds_attachment.attachment)
|
|
|
|
|
|
return false;
|
2020-01-10 11:31:51 +01:00
|
|
|
|
|
2020-07-31 14:58:42 +02:00
|
|
|
|
/* FIXME: Since some attachment formats can't be resolved using the TLB we
|
|
|
|
|
|
* need to emit separate resolve jobs for them and that would not be
|
|
|
|
|
|
* compatible with subpass merges. We could fix that by testing if any of
|
2022-01-27 11:57:08 +01:00
|
|
|
|
* the attachments to resolve doesn't support TLB resolves.
|
2020-07-31 14:58:42 +02:00
|
|
|
|
*/
|
2022-01-27 11:57:08 +01:00
|
|
|
|
if (prev_subpass->resolve_attachments || subpass->resolve_attachments ||
|
|
|
|
|
|
prev_subpass->resolve_depth || prev_subpass->resolve_stencil ||
|
|
|
|
|
|
subpass->resolve_depth || subpass->resolve_stencil) {
|
2020-07-31 14:58:42 +02:00
|
|
|
|
return false;
|
2022-01-27 11:57:08 +01:00
|
|
|
|
}
|
2020-07-28 08:53:19 +02:00
|
|
|
|
|
2020-01-10 11:31:51 +01:00
|
|
|
|
return true;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-03-03 11:57:59 +01:00
|
|
|
|
/**
|
|
|
|
|
|
* Computes and sets the job frame tiling information required to setup frame
|
|
|
|
|
|
* binning and rendering.
|
|
|
|
|
|
*/
|
|
|
|
|
|
static struct v3dv_frame_tiling *
|
|
|
|
|
|
job_compute_frame_tiling(struct v3dv_job *job,
|
|
|
|
|
|
uint32_t width,
|
|
|
|
|
|
uint32_t height,
|
|
|
|
|
|
uint32_t layers,
|
|
|
|
|
|
uint32_t render_target_count,
|
2020-07-24 10:33:16 +02:00
|
|
|
|
uint8_t max_internal_bpp,
|
|
|
|
|
|
bool msaa)
|
2020-03-03 11:57:59 +01:00
|
|
|
|
{
|
|
|
|
|
|
assert(job);
|
|
|
|
|
|
struct v3dv_frame_tiling *tiling = &job->frame_tiling;
|
|
|
|
|
|
|
|
|
|
|
|
tiling->width = width;
|
|
|
|
|
|
tiling->height = height;
|
|
|
|
|
|
tiling->layers = layers;
|
|
|
|
|
|
tiling->render_target_count = render_target_count;
|
2020-07-24 10:33:16 +02:00
|
|
|
|
tiling->msaa = msaa;
|
2020-03-03 11:57:59 +01:00
|
|
|
|
tiling->internal_bpp = max_internal_bpp;
|
|
|
|
|
|
|
2022-01-05 11:07:59 +01:00
|
|
|
|
/* We can use double-buffer when MSAA is disabled to reduce tile store
|
|
|
|
|
|
* overhead.
|
|
|
|
|
|
*
|
|
|
|
|
|
* FIXME: if we are emitting any tile loads the hardware will serialize
|
|
|
|
|
|
* loads and stores across tiles effectivley disabling double buffering,
|
|
|
|
|
|
* so we would want to check for that and not enable it in that case to
|
|
|
|
|
|
* avoid reducing the tile size.
|
|
|
|
|
|
*/
|
|
|
|
|
|
tiling->double_buffer =
|
|
|
|
|
|
unlikely(V3D_DEBUG & V3D_DEBUG_DOUBLE_BUFFER) && !msaa;
|
|
|
|
|
|
|
|
|
|
|
|
assert(!tiling->msaa || !tiling->double_buffer);
|
|
|
|
|
|
|
|
|
|
|
|
v3d_choose_tile_size(render_target_count, max_internal_bpp,
|
|
|
|
|
|
tiling->msaa, tiling->double_buffer,
|
|
|
|
|
|
&tiling->tile_width, &tiling->tile_height);
|
2020-03-03 11:57:59 +01:00
|
|
|
|
|
|
|
|
|
|
tiling->draw_tiles_x = DIV_ROUND_UP(width, tiling->tile_width);
|
|
|
|
|
|
tiling->draw_tiles_y = DIV_ROUND_UP(height, tiling->tile_height);
|
|
|
|
|
|
|
|
|
|
|
|
/* Size up our supertiles until we get under the limit */
|
|
|
|
|
|
const uint32_t max_supertiles = 256;
|
|
|
|
|
|
tiling->supertile_width = 1;
|
|
|
|
|
|
tiling->supertile_height = 1;
|
|
|
|
|
|
for (;;) {
|
|
|
|
|
|
tiling->frame_width_in_supertiles =
|
|
|
|
|
|
DIV_ROUND_UP(tiling->draw_tiles_x, tiling->supertile_width);
|
|
|
|
|
|
tiling->frame_height_in_supertiles =
|
|
|
|
|
|
DIV_ROUND_UP(tiling->draw_tiles_y, tiling->supertile_height);
|
|
|
|
|
|
const uint32_t num_supertiles = tiling->frame_width_in_supertiles *
|
|
|
|
|
|
tiling->frame_height_in_supertiles;
|
|
|
|
|
|
if (num_supertiles < max_supertiles)
|
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
|
|
if (tiling->supertile_width < tiling->supertile_height)
|
|
|
|
|
|
tiling->supertile_width++;
|
|
|
|
|
|
else
|
|
|
|
|
|
tiling->supertile_height++;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
return tiling;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-01-10 12:26:14 +01:00
|
|
|
|
void
|
2020-03-13 11:35:06 +01:00
|
|
|
|
v3dv_job_start_frame(struct v3dv_job *job,
|
|
|
|
|
|
uint32_t width,
|
|
|
|
|
|
uint32_t height,
|
|
|
|
|
|
uint32_t layers,
|
2021-07-16 08:23:11 +02:00
|
|
|
|
bool allocate_tile_state_for_all_layers,
|
2020-03-13 11:35:06 +01:00
|
|
|
|
uint32_t render_target_count,
|
2020-07-24 10:33:16 +02:00
|
|
|
|
uint8_t max_internal_bpp,
|
|
|
|
|
|
bool msaa)
|
2020-01-10 12:26:14 +01:00
|
|
|
|
{
|
|
|
|
|
|
assert(job);
|
|
|
|
|
|
|
2020-03-03 11:57:59 +01:00
|
|
|
|
/* Start by computing frame tiling spec for this job */
|
|
|
|
|
|
const struct v3dv_frame_tiling *tiling =
|
|
|
|
|
|
job_compute_frame_tiling(job,
|
|
|
|
|
|
width, height, layers,
|
2020-07-24 10:33:16 +02:00
|
|
|
|
render_target_count, max_internal_bpp, msaa);
|
2020-03-02 17:21:26 +01:00
|
|
|
|
|
2020-01-10 12:26:14 +01:00
|
|
|
|
v3dv_cl_ensure_space_with_branch(&job->bcl, 256);
|
2020-05-15 10:46:13 +02:00
|
|
|
|
v3dv_return_if_oom(NULL, job);
|
2020-01-10 12:26:14 +01:00
|
|
|
|
|
2021-07-16 08:23:11 +02:00
|
|
|
|
/* We only need to allocate tile state for all layers if the binner
|
|
|
|
|
|
* writes primitives to layers other than the first. This can only be
|
|
|
|
|
|
* done using layered rendering (writing gl_Layer from a geometry shader),
|
|
|
|
|
|
* so for other cases of multilayered framebuffers (typically with
|
|
|
|
|
|
* meta copy/clear operations) that won't use layered rendering, we only
|
|
|
|
|
|
* need one layer worth of of tile state for the binner.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (!allocate_tile_state_for_all_layers)
|
|
|
|
|
|
layers = 1;
|
|
|
|
|
|
|
2020-01-10 12:26:14 +01:00
|
|
|
|
/* The PTB will request the tile alloc initial size per tile at start
|
|
|
|
|
|
* of tile binning.
|
|
|
|
|
|
*/
|
2020-03-03 11:57:59 +01:00
|
|
|
|
uint32_t tile_alloc_size = 64 * tiling->layers *
|
2020-03-02 17:21:26 +01:00
|
|
|
|
tiling->draw_tiles_x *
|
|
|
|
|
|
tiling->draw_tiles_y;
|
2020-01-10 12:26:14 +01:00
|
|
|
|
|
|
|
|
|
|
/* The PTB allocates in aligned 4k chunks after the initial setup. */
|
|
|
|
|
|
tile_alloc_size = align(tile_alloc_size, 4096);
|
|
|
|
|
|
|
|
|
|
|
|
/* Include the first two chunk allocations that the PTB does so that
|
|
|
|
|
|
* we definitely clear the OOM condition before triggering one (the HW
|
|
|
|
|
|
* won't trigger OOM during the first allocations).
|
|
|
|
|
|
*/
|
|
|
|
|
|
tile_alloc_size += 8192;
|
|
|
|
|
|
|
|
|
|
|
|
/* For performance, allocate some extra initial memory after the PTB's
|
|
|
|
|
|
* minimal allocations, so that we hopefully don't have to block the
|
|
|
|
|
|
* GPU on the kernel handling an OOM signal.
|
|
|
|
|
|
*/
|
|
|
|
|
|
tile_alloc_size += 512 * 1024;
|
|
|
|
|
|
|
2020-03-13 11:35:06 +01:00
|
|
|
|
job->tile_alloc = v3dv_bo_alloc(job->device, tile_alloc_size,
|
v3dv/bo: adding a BO cache
Heavily based on the already existing for the v3d OpenGL driver, but
without references, and with some extra OOM checks (Vulkan CTS has
several OOM tests).
With this commit v3dv_bo_alloc and v3dv_bo_free became frontends to
the bo_cache. The former tries to get a BO from the cache if possible,
and the latter stores the BO on the cache if possible. The former also
adds a new parameter to point if the BO to allocate is private.
As v3d we are only caching private BOs, those created by the driver
for internal use (like CLs, tile_alloc, etc). They are the ones with
the highest change of being reused (for example, CL BOs are always
4KB, so they can always be reused). User-created BOs can have any
size, including some very large ones for buffers and images, which
makes them far less likely to be reused and would add a lot of memory
pressure if we decided to cache them.
In any case, in practice, we found that we could get a performance
improvement by caching also user-created BOs, but that would need more
care and an analysis to decide which ones makes sense. Would also
require to change how the cached BOs are stored by size. Right now
there are an array of list_head, that doesn't work well with big
BOs. If done, that would be handled on a separate commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-06-05 12:21:54 +02:00
|
|
|
|
"tile_alloc", true);
|
2020-05-15 10:46:13 +02:00
|
|
|
|
if (!job->tile_alloc) {
|
|
|
|
|
|
v3dv_flag_oom(NULL, job);
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-04-13 12:21:08 +02:00
|
|
|
|
v3dv_job_add_bo_unchecked(job, job->tile_alloc);
|
2020-01-10 12:26:14 +01:00
|
|
|
|
|
|
|
|
|
|
const uint32_t tsda_per_tile_size = 256;
|
2020-03-03 11:57:59 +01:00
|
|
|
|
const uint32_t tile_state_size = tiling->layers *
|
2020-03-02 17:21:26 +01:00
|
|
|
|
tiling->draw_tiles_x *
|
|
|
|
|
|
tiling->draw_tiles_y *
|
2020-01-10 12:26:14 +01:00
|
|
|
|
tsda_per_tile_size;
|
v3dv/bo: adding a BO cache
Heavily based on the already existing for the v3d OpenGL driver, but
without references, and with some extra OOM checks (Vulkan CTS has
several OOM tests).
With this commit v3dv_bo_alloc and v3dv_bo_free became frontends to
the bo_cache. The former tries to get a BO from the cache if possible,
and the latter stores the BO on the cache if possible. The former also
adds a new parameter to point if the BO to allocate is private.
As v3d we are only caching private BOs, those created by the driver
for internal use (like CLs, tile_alloc, etc). They are the ones with
the highest change of being reused (for example, CL BOs are always
4KB, so they can always be reused). User-created BOs can have any
size, including some very large ones for buffers and images, which
makes them far less likely to be reused and would add a lot of memory
pressure if we decided to cache them.
In any case, in practice, we found that we could get a performance
improvement by caching also user-created BOs, but that would need more
care and an analysis to decide which ones makes sense. Would also
require to change how the cached BOs are stored by size. Right now
there are an array of list_head, that doesn't work well with big
BOs. If done, that would be handled on a separate commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-06-05 12:21:54 +02:00
|
|
|
|
job->tile_state = v3dv_bo_alloc(job->device, tile_state_size, "TSDA", true);
|
2020-05-15 10:46:13 +02:00
|
|
|
|
if (!job->tile_state) {
|
|
|
|
|
|
v3dv_flag_oom(NULL, job);
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-04-13 12:21:08 +02:00
|
|
|
|
v3dv_job_add_bo_unchecked(job, job->tile_state);
|
2020-01-10 12:26:14 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(job->device, job_emit_binning_prolog)(job, tiling, layers);
|
2020-02-04 10:26:04 +01:00
|
|
|
|
|
2021-04-23 10:24:57 +02:00
|
|
|
|
job->ez_state = V3D_EZ_UNDECIDED;
|
|
|
|
|
|
job->first_ez_state = V3D_EZ_UNDECIDED;
|
2020-01-10 12:26:14 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_end_render_pass_frame(struct v3dv_cmd_buffer *cmd_buffer)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(cmd_buffer->state.job);
|
2020-03-25 12:09:12 +01:00
|
|
|
|
|
|
|
|
|
|
/* Typically, we have a single job for each subpass and we emit the job's RCL
|
|
|
|
|
|
* here when we are ending the frame for the subpass. However, some commands
|
|
|
|
|
|
* such as vkCmdClearAttachments need to run in their own separate job and
|
|
|
|
|
|
* they emit their own RCL even if they execute inside a subpass. In this
|
|
|
|
|
|
* scenario, we don't want to emit subpass RCL when we end the frame for
|
|
|
|
|
|
* those jobs, so we only emit the subpass RCL if the job has not recorded
|
|
|
|
|
|
* any RCL commands of its own.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (v3dv_cl_offset(&cmd_buffer->state.job->rcl) == 0)
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, cmd_buffer_emit_render_pass_rcl)(cmd_buffer);
|
2020-01-10 12:26:14 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, job_emit_binning_flush)(cmd_buffer->state.job);
|
2020-05-26 12:05:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-06-02 12:26:50 +02:00
|
|
|
|
struct v3dv_job *
|
|
|
|
|
|
v3dv_cmd_buffer_create_cpu_job(struct v3dv_device *device,
|
|
|
|
|
|
enum v3dv_job_type type,
|
|
|
|
|
|
struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
uint32_t subpass_idx)
|
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-11-12 16:30:41 +01:00
|
|
|
|
struct v3dv_job *job = vk_zalloc(&device->vk.alloc,
|
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
|
|
|
|
sizeof(struct v3dv_job), 8,
|
2020-05-29 12:00:12 +02:00
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
if (!job) {
|
|
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
|
|
|
|
|
return NULL;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
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_job_init(job, type, device, cmd_buffer, subpass_idx);
|
|
|
|
|
|
return job;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_add_cpu_jobs_for_pending_state(struct v3dv_cmd_buffer *cmd_buffer)
|
|
|
|
|
|
{
|
|
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
|
|
|
|
|
|
if (state->query.end.used_count > 0) {
|
|
|
|
|
|
const uint32_t query_count = state->query.end.used_count;
|
|
|
|
|
|
for (uint32_t i = 0; i < query_count; i++) {
|
|
|
|
|
|
assert(i < state->query.end.used_count);
|
|
|
|
|
|
struct v3dv_job *job =
|
2020-06-02 12:26:50 +02:00
|
|
|
|
v3dv_cmd_buffer_create_cpu_job(cmd_buffer->device,
|
|
|
|
|
|
V3DV_JOB_TYPE_CPU_END_QUERY,
|
|
|
|
|
|
cmd_buffer, -1);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
v3dv_return_if_oom(cmd_buffer, NULL);
|
|
|
|
|
|
|
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
|
|
|
|
job->cpu.query_end = state->query.end.states[i];
|
2020-05-26 12:05:43 +02:00
|
|
|
|
list_addtail(&job->list_link, &cmd_buffer->jobs);
|
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-01-08 11:14:35 +01:00
|
|
|
|
void
|
|
|
|
|
|
v3dv_cmd_buffer_finish_job(struct v3dv_cmd_buffer *cmd_buffer)
|
|
|
|
|
|
{
|
|
|
|
|
|
struct v3dv_job *job = cmd_buffer->state.job;
|
2020-04-02 11:09:05 +02:00
|
|
|
|
if (!job)
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
2022-05-30 08:04:04 +02:00
|
|
|
|
/* Always clear BCL state after a job has been finished if we don't have
|
|
|
|
|
|
* a pending graphics barrier that could consume it (BCL barriers only
|
|
|
|
|
|
* apply to graphics jobs). This can happen if the application recorded
|
|
|
|
|
|
* a barrier involving geometry stages but none of the draw calls in the
|
|
|
|
|
|
* job actually required a binning sync.
|
2022-05-03 09:05:19 +02:00
|
|
|
|
*/
|
2022-05-30 08:31:17 +02:00
|
|
|
|
if (!(cmd_buffer->state.barrier.dst_mask & V3DV_BARRIER_GRAPHICS_BIT)) {
|
|
|
|
|
|
cmd_buffer->state.barrier.bcl_buffer_access = 0;
|
|
|
|
|
|
cmd_buffer->state.barrier.bcl_image_access = 0;
|
2022-05-03 09:05:19 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-05-15 10:46:13 +02:00
|
|
|
|
if (cmd_buffer->state.oom) {
|
|
|
|
|
|
v3dv_job_destroy(job);
|
|
|
|
|
|
cmd_buffer->state.job = NULL;
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
/* If we have created a job for a command buffer then we should have
|
|
|
|
|
|
* recorded something into it: if the job was started in a render pass, it
|
|
|
|
|
|
* should at least have the start frame commands, otherwise, it should have
|
|
|
|
|
|
* a transfer command. The only exception are secondary command buffers
|
|
|
|
|
|
* inside a render pass.
|
|
|
|
|
|
*/
|
2021-12-14 15:42:14 +01:00
|
|
|
|
assert(cmd_buffer->vk.level == VK_COMMAND_BUFFER_LEVEL_SECONDARY ||
|
2020-05-26 12:05:43 +02:00
|
|
|
|
v3dv_cl_offset(&job->bcl) > 0);
|
2020-01-08 11:14:35 +01:00
|
|
|
|
|
2020-01-10 11:31:51 +01:00
|
|
|
|
/* When we merge multiple subpasses into the same job we must only emit one
|
|
|
|
|
|
* RCL, so we do that here, when we decided that we need to finish the job.
|
|
|
|
|
|
* Any rendering that happens outside a render pass is never merged, so
|
|
|
|
|
|
* the RCL should have been emitted by the time we got here.
|
|
|
|
|
|
*/
|
|
|
|
|
|
assert(v3dv_cl_offset(&job->rcl) != 0 || cmd_buffer->state.pass);
|
2020-06-02 12:26:50 +02:00
|
|
|
|
|
|
|
|
|
|
/* If we are finishing a job inside a render pass we have two scenarios:
|
|
|
|
|
|
*
|
|
|
|
|
|
* 1. It is a regular CL, in which case we will submit the job to the GPU,
|
|
|
|
|
|
* so we may need to generate an RCL and add a binning flush.
|
|
|
|
|
|
*
|
|
|
|
|
|
* 2. It is a partial CL recorded in a secondary command buffer, in which
|
|
|
|
|
|
* case we are not submitting it directly to the GPU but rather branch to
|
|
|
|
|
|
* it from a primary command buffer. In this case we just want to end
|
|
|
|
|
|
* the BCL with a RETURN_FROM_SUB_LIST and the RCL and binning flush
|
|
|
|
|
|
* will be the primary job that branches to this CL.
|
|
|
|
|
|
*/
|
2020-05-26 12:05:43 +02:00
|
|
|
|
if (cmd_buffer->state.pass) {
|
2020-06-02 12:26:50 +02:00
|
|
|
|
if (job->type == V3DV_JOB_TYPE_GPU_CL) {
|
2020-05-26 12:05:43 +02:00
|
|
|
|
cmd_buffer_end_render_pass_frame(cmd_buffer);
|
|
|
|
|
|
} else {
|
2020-06-02 12:26:50 +02:00
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_GPU_CL_SECONDARY);
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, cmd_buffer_end_render_pass_secondary)(cmd_buffer);
|
2020-05-26 12:05:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
}
|
2020-01-10 11:31:51 +01:00
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
list_addtail(&job->list_link, &cmd_buffer->jobs);
|
2020-01-08 11:14:35 +01:00
|
|
|
|
cmd_buffer->state.job = NULL;
|
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
|
|
|
|
|
|
|
|
|
|
/* If we have recorded any state with this last GPU job that requires to
|
2020-05-26 12:05:43 +02:00
|
|
|
|
* emit CPU jobs after the job is completed, add them now. The only
|
|
|
|
|
|
* exception is secondary command buffers inside a render pass, because in
|
|
|
|
|
|
* that case we want to defer this until we finish recording the primary
|
|
|
|
|
|
* job into which we execute the secondary.
|
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-12-14 15:42:14 +01:00
|
|
|
|
if (cmd_buffer->vk.level == VK_COMMAND_BUFFER_LEVEL_PRIMARY ||
|
2020-05-26 12:05:43 +02:00
|
|
|
|
!cmd_buffer->state.pass) {
|
|
|
|
|
|
cmd_buffer_add_cpu_jobs_for_pending_state(cmd_buffer);
|
|
|
|
|
|
}
|
2020-01-08 11:14:35 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2022-01-03 12:55:37 -01:00
|
|
|
|
bool
|
|
|
|
|
|
v3dv_job_type_is_gpu(struct v3dv_job *job)
|
2020-07-08 09:56:44 +02:00
|
|
|
|
{
|
|
|
|
|
|
switch (job->type) {
|
|
|
|
|
|
case V3DV_JOB_TYPE_GPU_CL:
|
|
|
|
|
|
case V3DV_JOB_TYPE_GPU_CL_SECONDARY:
|
|
|
|
|
|
case V3DV_JOB_TYPE_GPU_TFU:
|
|
|
|
|
|
case V3DV_JOB_TYPE_GPU_CSD:
|
|
|
|
|
|
return true;
|
|
|
|
|
|
default:
|
|
|
|
|
|
return false;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_serialize_job_if_needed(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct v3dv_job *job)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(cmd_buffer && job);
|
|
|
|
|
|
|
|
|
|
|
|
/* Serialization only affects GPU jobs, CPU jobs are always automatically
|
|
|
|
|
|
* serialized.
|
|
|
|
|
|
*/
|
2022-01-03 12:55:37 -01:00
|
|
|
|
if (!v3dv_job_type_is_gpu(job))
|
2020-07-08 09:56:44 +02:00
|
|
|
|
return;
|
|
|
|
|
|
|
2022-05-30 08:31:17 +02:00
|
|
|
|
uint8_t barrier_mask = cmd_buffer->state.barrier.dst_mask;
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
if (barrier_mask == 0)
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
|
|
uint8_t bit = 0;
|
2022-05-30 08:52:31 +02:00
|
|
|
|
uint8_t *src_mask;
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
if (job->type == V3DV_JOB_TYPE_GPU_CSD) {
|
|
|
|
|
|
assert(!job->is_transfer);
|
|
|
|
|
|
bit = V3DV_BARRIER_COMPUTE_BIT;
|
2022-05-30 08:52:31 +02:00
|
|
|
|
src_mask = &cmd_buffer->state.barrier.src_mask_compute;
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
} else if (job->is_transfer) {
|
|
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_GPU_CL ||
|
|
|
|
|
|
job->type == V3DV_JOB_TYPE_GPU_CL_SECONDARY ||
|
|
|
|
|
|
job->type == V3DV_JOB_TYPE_GPU_TFU);
|
|
|
|
|
|
bit = V3DV_BARRIER_TRANSFER_BIT;
|
2022-05-30 08:52:31 +02:00
|
|
|
|
src_mask = &cmd_buffer->state.barrier.src_mask_transfer;
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
} else {
|
|
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_GPU_CL ||
|
|
|
|
|
|
job->type == V3DV_JOB_TYPE_GPU_CL_SECONDARY);
|
|
|
|
|
|
bit = V3DV_BARRIER_GRAPHICS_BIT;
|
2022-05-30 08:52:31 +02:00
|
|
|
|
src_mask = &cmd_buffer->state.barrier.src_mask_graphics;
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (barrier_mask & bit) {
|
|
|
|
|
|
job->serialize = true;
|
2022-05-30 08:52:31 +02:00
|
|
|
|
*src_mask = 0;
|
2022-05-30 08:31:17 +02:00
|
|
|
|
cmd_buffer->state.barrier.dst_mask &= ~bit;
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
}
|
2020-07-08 09:56:44 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-03-13 11:35:06 +01:00
|
|
|
|
void
|
|
|
|
|
|
v3dv_job_init(struct v3dv_job *job,
|
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
|
|
|
|
enum v3dv_job_type type,
|
2020-03-13 11:35:06 +01:00
|
|
|
|
struct v3dv_device *device,
|
|
|
|
|
|
struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
int32_t subpass_idx)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(job);
|
|
|
|
|
|
|
2020-07-08 09:56:44 +02:00
|
|
|
|
/* Make sure we haven't made this new job current before calling here */
|
|
|
|
|
|
assert(!cmd_buffer || cmd_buffer->state.job != job);
|
|
|
|
|
|
|
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
|
|
|
|
job->type = type;
|
|
|
|
|
|
|
2020-03-13 11:35:06 +01:00
|
|
|
|
job->device = device;
|
|
|
|
|
|
job->cmd_buffer = cmd_buffer;
|
|
|
|
|
|
|
2020-05-15 10:46:13 +02:00
|
|
|
|
list_inithead(&job->list_link);
|
|
|
|
|
|
|
2020-06-02 12:26:50 +02:00
|
|
|
|
if (type == V3DV_JOB_TYPE_GPU_CL ||
|
2020-06-18 13:53:51 +02:00
|
|
|
|
type == V3DV_JOB_TYPE_GPU_CL_SECONDARY ||
|
|
|
|
|
|
type == V3DV_JOB_TYPE_GPU_CSD) {
|
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
|
|
|
|
job->bos =
|
|
|
|
|
|
_mesa_set_create(NULL, _mesa_hash_pointer, _mesa_key_pointer_equal);
|
|
|
|
|
|
job->bo_count = 0;
|
2020-03-13 11:35:06 +01:00
|
|
|
|
|
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_cl_init(job, &job->indirect);
|
2020-03-13 11:35:06 +01:00
|
|
|
|
|
2021-09-28 00:37:49 +02:00
|
|
|
|
if (unlikely(V3D_DEBUG & V3D_DEBUG_ALWAYS_FLUSH))
|
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
|
|
|
|
job->always_flush = true;
|
|
|
|
|
|
}
|
2020-04-16 08:48:22 +02:00
|
|
|
|
|
2020-06-18 13:53:51 +02:00
|
|
|
|
if (type == V3DV_JOB_TYPE_GPU_CL ||
|
|
|
|
|
|
type == V3DV_JOB_TYPE_GPU_CL_SECONDARY) {
|
|
|
|
|
|
v3dv_cl_init(job, &job->bcl);
|
|
|
|
|
|
v3dv_cl_init(job, &job->rcl);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-04-16 08:48:22 +02:00
|
|
|
|
if (cmd_buffer) {
|
|
|
|
|
|
/* Flag all state as dirty. Generally, we need to re-emit state for each
|
|
|
|
|
|
* new job.
|
|
|
|
|
|
*
|
|
|
|
|
|
* FIXME: there may be some exceptions, in which case we could skip some
|
|
|
|
|
|
* bits.
|
|
|
|
|
|
*/
|
|
|
|
|
|
cmd_buffer->state.dirty = ~0;
|
2021-04-16 10:14:23 +02:00
|
|
|
|
cmd_buffer->state.dirty_descriptor_stages = ~0;
|
2020-04-16 08:48:22 +02:00
|
|
|
|
|
2020-10-30 09:12:38 +01:00
|
|
|
|
/* Honor inheritance of occlussion queries in secondaries if requested */
|
2021-12-14 15:42:14 +01:00
|
|
|
|
if (cmd_buffer->vk.level == VK_COMMAND_BUFFER_LEVEL_SECONDARY &&
|
2020-10-30 09:12:38 +01:00
|
|
|
|
cmd_buffer->state.inheritance.occlusion_query_enable) {
|
|
|
|
|
|
cmd_buffer->state.dirty &= ~V3DV_CMD_DIRTY_OCCLUSION_QUERY;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-04-16 08:48:22 +02:00
|
|
|
|
/* Keep track of the first subpass that we are recording in this new job.
|
|
|
|
|
|
* We will use this when we emit the RCL to decide how to emit our loads
|
|
|
|
|
|
* and stores.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (cmd_buffer->state.pass)
|
|
|
|
|
|
job->first_subpass = subpass_idx;
|
2020-07-08 09:56:44 +02:00
|
|
|
|
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
job->is_transfer = cmd_buffer->state.is_transfer;
|
|
|
|
|
|
|
2020-07-08 09:56:44 +02:00
|
|
|
|
cmd_buffer_serialize_job_if_needed(cmd_buffer, job);
|
2020-04-16 08:48:22 +02:00
|
|
|
|
}
|
2020-03-13 11:35:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-01-08 11:14:35 +01:00
|
|
|
|
struct v3dv_job *
|
v3dv: implement vkCmdClearAttachments
For now this only implements a fast path using the tile buffer, so it
can only be used when clearing full images, but this is good enough
for VkRunner.
The implementation is a bit tricky because this command executes
inside a render pass, and yet, since we are using the tile buffer to
clear, this needs to go in its own job. This means that with this, we
need to be able to split a subpass into multiple jobs which creates
some issues.
For example, certain operations, such as the subpass load operation
(particularly if it is a clear) should only happen on the first job of
the subpass and subsequent jobs in the same subpass should always
load.
Similarly, we should not discard the last store on an attachment
unless we know it is the last job for the last subpass that uses the
attachment.
To handle these cases we add two new flags to the job, one to know if
the job is not the first in a subpass (is_subpass_continue) and
another one to know if a job is the last in a subpass
(is_subpass_finish).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-06 12:39:48 +01:00
|
|
|
|
v3dv_cmd_buffer_start_job(struct v3dv_cmd_buffer *cmd_buffer,
|
2020-06-02 12:26:50 +02:00
|
|
|
|
int32_t subpass_idx,
|
|
|
|
|
|
enum v3dv_job_type type)
|
2020-01-08 11:14:35 +01:00
|
|
|
|
{
|
2020-01-10 11:31:51 +01:00
|
|
|
|
/* Don't create a new job if we can merge the current subpass into
|
|
|
|
|
|
* the current job.
|
|
|
|
|
|
*/
|
v3dv: implement vkCmdClearAttachments
For now this only implements a fast path using the tile buffer, so it
can only be used when clearing full images, but this is good enough
for VkRunner.
The implementation is a bit tricky because this command executes
inside a render pass, and yet, since we are using the tile buffer to
clear, this needs to go in its own job. This means that with this, we
need to be able to split a subpass into multiple jobs which creates
some issues.
For example, certain operations, such as the subpass load operation
(particularly if it is a clear) should only happen on the first job of
the subpass and subsequent jobs in the same subpass should always
load.
Similarly, we should not discard the last store on an attachment
unless we know it is the last job for the last subpass that uses the
attachment.
To handle these cases we add two new flags to the job, one to know if
the job is not the first in a subpass (is_subpass_continue) and
another one to know if a job is the last in a subpass
(is_subpass_finish).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-06 12:39:48 +01:00
|
|
|
|
if (cmd_buffer->state.pass &&
|
2020-03-02 12:08:19 +01:00
|
|
|
|
subpass_idx != -1 &&
|
2020-04-14 11:35:46 +02:00
|
|
|
|
cmd_buffer_can_merge_subpass(cmd_buffer, subpass_idx)) {
|
v3dv: implement vkCmdClearAttachments
For now this only implements a fast path using the tile buffer, so it
can only be used when clearing full images, but this is good enough
for VkRunner.
The implementation is a bit tricky because this command executes
inside a render pass, and yet, since we are using the tile buffer to
clear, this needs to go in its own job. This means that with this, we
need to be able to split a subpass into multiple jobs which creates
some issues.
For example, certain operations, such as the subpass load operation
(particularly if it is a clear) should only happen on the first job of
the subpass and subsequent jobs in the same subpass should always
load.
Similarly, we should not discard the last store on an attachment
unless we know it is the last job for the last subpass that uses the
attachment.
To handle these cases we add two new flags to the job, one to know if
the job is not the first in a subpass (is_subpass_continue) and
another one to know if a job is the last in a subpass
(is_subpass_finish).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-06 12:39:48 +01:00
|
|
|
|
cmd_buffer->state.job->is_subpass_finish = false;
|
2020-01-10 11:31:51 +01:00
|
|
|
|
return cmd_buffer->state.job;
|
v3dv: implement vkCmdClearAttachments
For now this only implements a fast path using the tile buffer, so it
can only be used when clearing full images, but this is good enough
for VkRunner.
The implementation is a bit tricky because this command executes
inside a render pass, and yet, since we are using the tile buffer to
clear, this needs to go in its own job. This means that with this, we
need to be able to split a subpass into multiple jobs which creates
some issues.
For example, certain operations, such as the subpass load operation
(particularly if it is a clear) should only happen on the first job of
the subpass and subsequent jobs in the same subpass should always
load.
Similarly, we should not discard the last store on an attachment
unless we know it is the last job for the last subpass that uses the
attachment.
To handle these cases we add two new flags to the job, one to know if
the job is not the first in a subpass (is_subpass_continue) and
another one to know if a job is the last in a subpass
(is_subpass_finish).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-06 12:39:48 +01:00
|
|
|
|
}
|
2020-01-10 11:31:51 +01:00
|
|
|
|
|
2020-01-08 11:14:35 +01:00
|
|
|
|
/* Ensure we are not starting a new job without finishing a previous one */
|
2020-01-09 09:31:01 +01:00
|
|
|
|
if (cmd_buffer->state.job != NULL)
|
2020-01-08 11:14:35 +01:00
|
|
|
|
v3dv_cmd_buffer_finish_job(cmd_buffer);
|
|
|
|
|
|
|
|
|
|
|
|
assert(cmd_buffer->state.job == NULL);
|
2020-11-12 16:30:41 +01:00
|
|
|
|
struct v3dv_job *job = vk_zalloc(&cmd_buffer->device->vk.alloc,
|
2020-01-08 11:14:35 +01:00
|
|
|
|
sizeof(struct v3dv_job), 8,
|
2020-05-29 12:00:12 +02:00
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
2020-03-12 11:59:04 +01:00
|
|
|
|
|
|
|
|
|
|
if (!job) {
|
|
|
|
|
|
fprintf(stderr, "Error: failed to allocate CPU memory for job\n");
|
2020-05-15 10:46:13 +02:00
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
2020-03-12 11:59:04 +01:00
|
|
|
|
return NULL;
|
|
|
|
|
|
}
|
2020-01-08 11:14:35 +01:00
|
|
|
|
|
2020-06-02 12:26:50 +02:00
|
|
|
|
v3dv_job_init(job, type, cmd_buffer->device, cmd_buffer, subpass_idx);
|
2020-07-08 09:56:44 +02:00
|
|
|
|
cmd_buffer->state.job = job;
|
2020-01-10 11:31:51 +01:00
|
|
|
|
|
2020-01-08 11:14:35 +01:00
|
|
|
|
return job;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2019-12-11 10:14:10 +01:00
|
|
|
|
static VkResult
|
2020-02-20 09:53:32 +01:00
|
|
|
|
cmd_buffer_reset(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
VkCommandBufferResetFlags flags)
|
2019-12-11 10:14:10 +01:00
|
|
|
|
{
|
2021-04-06 15:13:14 +03:00
|
|
|
|
vk_command_buffer_reset(&cmd_buffer->vk);
|
2019-12-11 11:57:08 +01:00
|
|
|
|
if (cmd_buffer->status != V3DV_CMD_BUFFER_STATUS_INITIALIZED) {
|
2020-02-20 09:53:32 +01:00
|
|
|
|
struct v3dv_device *device = cmd_buffer->device;
|
2020-05-22 14:27:38 +02:00
|
|
|
|
|
2020-02-20 09:53:32 +01:00
|
|
|
|
/* FIXME: For now we always free all resources as if
|
|
|
|
|
|
* VK_COMMAND_BUFFER_RESET_RELEASE_RESOURCES_BIT was set.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (cmd_buffer->status != V3DV_CMD_BUFFER_STATUS_NEW)
|
|
|
|
|
|
cmd_buffer_free_resources(cmd_buffer);
|
2019-12-18 11:19:32 +01:00
|
|
|
|
|
2022-02-07 16:02:20 -06:00
|
|
|
|
cmd_buffer_init(cmd_buffer, device);
|
2019-12-11 11:57:08 +01:00
|
|
|
|
}
|
2020-02-20 09:53:32 +01:00
|
|
|
|
|
|
|
|
|
|
assert(cmd_buffer->status == V3DV_CMD_BUFFER_STATUS_INITIALIZED);
|
2019-12-11 10:14:10 +01:00
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR VkResult VKAPI_CALL
|
2019-12-10 09:33:13 +01:00
|
|
|
|
v3dv_AllocateCommandBuffers(VkDevice _device,
|
|
|
|
|
|
const VkCommandBufferAllocateInfo *pAllocateInfo,
|
|
|
|
|
|
VkCommandBuffer *pCommandBuffers)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_device, device, _device);
|
2022-02-07 16:02:20 -06:00
|
|
|
|
VK_FROM_HANDLE(vk_command_pool, pool, pAllocateInfo->commandPool);
|
2019-12-10 09:33:13 +01:00
|
|
|
|
|
|
|
|
|
|
VkResult result = VK_SUCCESS;
|
|
|
|
|
|
uint32_t i;
|
|
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < pAllocateInfo->commandBufferCount; i++) {
|
|
|
|
|
|
result = cmd_buffer_create(device, pool, pAllocateInfo->level,
|
|
|
|
|
|
&pCommandBuffers[i]);
|
|
|
|
|
|
if (result != VK_SUCCESS)
|
|
|
|
|
|
break;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (result != VK_SUCCESS) {
|
2022-02-07 16:02:20 -06:00
|
|
|
|
while (i--) {
|
|
|
|
|
|
VK_FROM_HANDLE(vk_command_buffer, cmd_buffer, pCommandBuffers[i]);
|
|
|
|
|
|
cmd_buffer_destroy(cmd_buffer);
|
|
|
|
|
|
}
|
2019-12-10 09:33:13 +01:00
|
|
|
|
for (i = 0; i < pAllocateInfo->commandBufferCount; i++)
|
|
|
|
|
|
pCommandBuffers[i] = VK_NULL_HANDLE;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-07-31 14:58:42 +02:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_subpass_handle_pending_resolves(struct v3dv_cmd_buffer *cmd_buffer)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(cmd_buffer->state.subpass_idx < cmd_buffer->state.pass->subpass_count);
|
|
|
|
|
|
const struct v3dv_render_pass *pass = cmd_buffer->state.pass;
|
|
|
|
|
|
const struct v3dv_subpass *subpass =
|
|
|
|
|
|
&pass->subpasses[cmd_buffer->state.subpass_idx];
|
|
|
|
|
|
|
|
|
|
|
|
if (!subpass->resolve_attachments)
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
|
|
/* At this point we have already ended the current subpass and now we are
|
|
|
|
|
|
* about to emit vkCmdResolveImage calls to get the resolves we can't handle
|
|
|
|
|
|
* handle in the subpass RCL.
|
|
|
|
|
|
*
|
|
|
|
|
|
* vkCmdResolveImage is not supposed to be called inside a render pass so
|
|
|
|
|
|
* before we call that we need to make sure our command buffer state reflects
|
|
|
|
|
|
* that we are no longer in a subpass by finishing the current job and
|
|
|
|
|
|
* resetting the framebuffer and render pass state temporarily and then
|
|
|
|
|
|
* restoring it after we are done with the resolves.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (cmd_buffer->state.job)
|
|
|
|
|
|
v3dv_cmd_buffer_finish_job(cmd_buffer);
|
|
|
|
|
|
struct v3dv_framebuffer *restore_fb = cmd_buffer->state.framebuffer;
|
|
|
|
|
|
struct v3dv_render_pass *restore_pass = cmd_buffer->state.pass;
|
|
|
|
|
|
uint32_t restore_subpass_idx = cmd_buffer->state.subpass_idx;
|
|
|
|
|
|
cmd_buffer->state.framebuffer = NULL;
|
|
|
|
|
|
cmd_buffer->state.pass = NULL;
|
|
|
|
|
|
cmd_buffer->state.subpass_idx = -1;
|
|
|
|
|
|
|
|
|
|
|
|
VkCommandBuffer cmd_buffer_handle = v3dv_cmd_buffer_to_handle(cmd_buffer);
|
|
|
|
|
|
for (uint32_t i = 0; i < subpass->color_count; i++) {
|
|
|
|
|
|
const uint32_t src_attachment_idx =
|
|
|
|
|
|
subpass->color_attachments[i].attachment;
|
|
|
|
|
|
if (src_attachment_idx == VK_ATTACHMENT_UNUSED)
|
|
|
|
|
|
continue;
|
|
|
|
|
|
|
2022-01-27 11:11:51 +01:00
|
|
|
|
/* Skip if this attachment doesn't have a resolve or if it was already
|
|
|
|
|
|
* implemented as a TLB resolve.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (!cmd_buffer->state.attachments[src_attachment_idx].has_resolve ||
|
|
|
|
|
|
cmd_buffer->state.attachments[src_attachment_idx].use_tlb_resolve) {
|
2020-07-31 14:58:42 +02:00
|
|
|
|
continue;
|
2022-01-27 11:11:51 +01:00
|
|
|
|
}
|
2020-07-31 14:58:42 +02:00
|
|
|
|
|
|
|
|
|
|
const uint32_t dst_attachment_idx =
|
|
|
|
|
|
subpass->resolve_attachments[i].attachment;
|
2022-01-27 11:11:51 +01:00
|
|
|
|
assert(dst_attachment_idx != VK_ATTACHMENT_UNUSED);
|
2020-07-31 14:58:42 +02:00
|
|
|
|
|
2022-01-24 13:38:08 +01:00
|
|
|
|
struct v3dv_image_view *src_iview =
|
|
|
|
|
|
cmd_buffer->state.attachments[src_attachment_idx].image_view;
|
|
|
|
|
|
struct v3dv_image_view *dst_iview =
|
|
|
|
|
|
cmd_buffer->state.attachments[dst_attachment_idx].image_view;
|
2020-07-31 14:58:42 +02:00
|
|
|
|
|
2021-06-17 10:18:14 +02:00
|
|
|
|
VkImageResolve2KHR region = {
|
|
|
|
|
|
.sType = VK_STRUCTURE_TYPE_IMAGE_RESOLVE_2_KHR,
|
2020-07-31 14:58:42 +02:00
|
|
|
|
.srcSubresource = {
|
|
|
|
|
|
VK_IMAGE_ASPECT_COLOR_BIT,
|
2021-07-26 13:23:30 +02:00
|
|
|
|
src_iview->vk.base_mip_level,
|
|
|
|
|
|
src_iview->vk.base_array_layer,
|
|
|
|
|
|
src_iview->vk.layer_count,
|
2020-07-31 14:58:42 +02:00
|
|
|
|
},
|
|
|
|
|
|
.srcOffset = { 0, 0, 0 },
|
|
|
|
|
|
.dstSubresource = {
|
|
|
|
|
|
VK_IMAGE_ASPECT_COLOR_BIT,
|
2021-07-26 13:23:30 +02:00
|
|
|
|
dst_iview->vk.base_mip_level,
|
|
|
|
|
|
dst_iview->vk.base_array_layer,
|
|
|
|
|
|
dst_iview->vk.layer_count,
|
2020-07-31 14:58:42 +02:00
|
|
|
|
},
|
|
|
|
|
|
.dstOffset = { 0, 0, 0 },
|
2021-07-26 13:23:30 +02:00
|
|
|
|
.extent = src_iview->vk.image->extent,
|
2020-07-31 14:58:42 +02:00
|
|
|
|
};
|
|
|
|
|
|
|
2021-07-26 13:23:30 +02:00
|
|
|
|
struct v3dv_image *src_image = (struct v3dv_image *) src_iview->vk.image;
|
|
|
|
|
|
struct v3dv_image *dst_image = (struct v3dv_image *) dst_iview->vk.image;
|
2021-06-17 10:18:14 +02:00
|
|
|
|
VkResolveImageInfo2KHR resolve_info = {
|
|
|
|
|
|
.sType = VK_STRUCTURE_TYPE_RESOLVE_IMAGE_INFO_2_KHR,
|
2021-07-26 13:23:30 +02:00
|
|
|
|
.srcImage = v3dv_image_to_handle(src_image),
|
2021-06-17 10:18:14 +02:00
|
|
|
|
.srcImageLayout = VK_IMAGE_LAYOUT_GENERAL,
|
2021-07-26 13:23:30 +02:00
|
|
|
|
.dstImage = v3dv_image_to_handle(dst_image),
|
2021-06-17 10:18:14 +02:00
|
|
|
|
.dstImageLayout = VK_IMAGE_LAYOUT_GENERAL,
|
|
|
|
|
|
.regionCount = 1,
|
|
|
|
|
|
.pRegions = ®ion,
|
|
|
|
|
|
};
|
|
|
|
|
|
v3dv_CmdResolveImage2KHR(cmd_buffer_handle, &resolve_info);
|
2020-07-31 14:58:42 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.framebuffer = restore_fb;
|
|
|
|
|
|
cmd_buffer->state.pass = restore_pass;
|
|
|
|
|
|
cmd_buffer->state.subpass_idx = restore_subpass_idx;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
static VkResult
|
|
|
|
|
|
cmd_buffer_begin_render_pass_secondary(
|
|
|
|
|
|
struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
const VkCommandBufferInheritanceInfo *inheritance_info)
|
|
|
|
|
|
{
|
2021-12-14 15:42:14 +01:00
|
|
|
|
assert(cmd_buffer->vk.level == VK_COMMAND_BUFFER_LEVEL_SECONDARY);
|
2020-05-26 12:05:43 +02:00
|
|
|
|
assert(cmd_buffer->usage_flags & VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT);
|
|
|
|
|
|
assert(inheritance_info);
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.pass =
|
|
|
|
|
|
v3dv_render_pass_from_handle(inheritance_info->renderPass);
|
|
|
|
|
|
assert(cmd_buffer->state.pass);
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.framebuffer =
|
|
|
|
|
|
v3dv_framebuffer_from_handle(inheritance_info->framebuffer);
|
|
|
|
|
|
|
2020-10-30 09:12:38 +01:00
|
|
|
|
assert(inheritance_info->subpass < cmd_buffer->state.pass->subpass_count);
|
|
|
|
|
|
cmd_buffer->state.subpass_idx = inheritance_info->subpass;
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.inheritance.occlusion_query_enable =
|
|
|
|
|
|
inheritance_info->occlusionQueryEnable;
|
|
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
/* Secondaries that execute inside a render pass won't start subpasses
|
|
|
|
|
|
* so we want to create a job for them here.
|
|
|
|
|
|
*/
|
|
|
|
|
|
struct v3dv_job *job =
|
2020-06-02 12:26:50 +02:00
|
|
|
|
v3dv_cmd_buffer_start_job(cmd_buffer, inheritance_info->subpass,
|
|
|
|
|
|
V3DV_JOB_TYPE_GPU_CL_SECONDARY);
|
2020-05-26 12:05:43 +02:00
|
|
|
|
if (!job) {
|
|
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
|
|
|
|
|
return VK_ERROR_OUT_OF_HOST_MEMORY;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Secondary command buffers don't know about the render area, but our
|
|
|
|
|
|
* scissor setup accounts for it, so let's make sure we make it large
|
|
|
|
|
|
* enough that it doesn't actually constrain any rendering. This should
|
|
|
|
|
|
* be fine, since the Vulkan spec states:
|
|
|
|
|
|
*
|
|
|
|
|
|
* "The application must ensure (using scissor if necessary) that all
|
|
|
|
|
|
* rendering is contained within the render area."
|
|
|
|
|
|
*
|
|
|
|
|
|
* FIXME: setup constants for the max framebuffer dimensions and use them
|
|
|
|
|
|
* here and when filling in VkPhysicalDeviceLimits.
|
|
|
|
|
|
*/
|
|
|
|
|
|
const struct v3dv_framebuffer *framebuffer = cmd_buffer->state.framebuffer;
|
|
|
|
|
|
cmd_buffer->state.render_area.offset.x = 0;
|
|
|
|
|
|
cmd_buffer->state.render_area.offset.y = 0;
|
|
|
|
|
|
cmd_buffer->state.render_area.extent.width =
|
|
|
|
|
|
framebuffer ? framebuffer->width : 4096;
|
|
|
|
|
|
cmd_buffer->state.render_area.extent.height =
|
|
|
|
|
|
framebuffer ? framebuffer->height : 4096;
|
|
|
|
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR VkResult VKAPI_CALL
|
2019-12-11 10:14:10 +01:00
|
|
|
|
v3dv_BeginCommandBuffer(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
const VkCommandBufferBeginInfo *pBeginInfo)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
|
|
|
|
|
/* If this is the first vkBeginCommandBuffer, we must initialize the
|
|
|
|
|
|
* command buffer's state. Otherwise, we must reset its state. In both
|
|
|
|
|
|
* cases we reset it.
|
|
|
|
|
|
*/
|
2020-02-20 09:53:32 +01:00
|
|
|
|
VkResult result = cmd_buffer_reset(cmd_buffer, 0);
|
2019-12-11 10:14:10 +01:00
|
|
|
|
if (result != VK_SUCCESS)
|
|
|
|
|
|
return result;
|
|
|
|
|
|
|
2019-12-11 11:57:08 +01:00
|
|
|
|
assert(cmd_buffer->status == V3DV_CMD_BUFFER_STATUS_INITIALIZED);
|
|
|
|
|
|
|
2019-12-11 10:14:10 +01:00
|
|
|
|
cmd_buffer->usage_flags = pBeginInfo->flags;
|
|
|
|
|
|
|
2021-12-14 15:42:14 +01:00
|
|
|
|
if (cmd_buffer->vk.level == VK_COMMAND_BUFFER_LEVEL_SECONDARY) {
|
2020-05-26 12:05:43 +02:00
|
|
|
|
if (pBeginInfo->flags & VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT) {
|
|
|
|
|
|
result =
|
|
|
|
|
|
cmd_buffer_begin_render_pass_secondary(cmd_buffer,
|
|
|
|
|
|
pBeginInfo->pInheritanceInfo);
|
|
|
|
|
|
if (result != VK_SUCCESS)
|
|
|
|
|
|
return result;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2019-12-11 11:57:08 +01:00
|
|
|
|
cmd_buffer->status = V3DV_CMD_BUFFER_STATUS_RECORDING;
|
2019-12-11 10:14:10 +01:00
|
|
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
|
}
|
2019-12-13 10:48:12 +01:00
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR VkResult VKAPI_CALL
|
2020-02-20 09:53:32 +01:00
|
|
|
|
v3dv_ResetCommandBuffer(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
VkCommandBufferResetFlags flags)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
return cmd_buffer_reset(cmd_buffer, flags);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-04-02 12:38:10 +02:00
|
|
|
|
static void
|
2020-05-26 12:05:43 +02:00
|
|
|
|
cmd_buffer_update_tile_alignment(struct v3dv_cmd_buffer *cmd_buffer)
|
2020-04-02 12:38:10 +02:00
|
|
|
|
{
|
|
|
|
|
|
/* Render areas and scissor/viewport are only relevant inside render passes,
|
|
|
|
|
|
* otherwise we are dealing with transfer operations where these elements
|
|
|
|
|
|
* don't apply.
|
|
|
|
|
|
*/
|
2020-05-26 12:05:43 +02:00
|
|
|
|
assert(cmd_buffer->state.pass);
|
|
|
|
|
|
const VkRect2D *rect = &cmd_buffer->state.render_area;
|
|
|
|
|
|
|
2020-06-02 12:26:50 +02:00
|
|
|
|
/* We should only call this at the beginning of a subpass so we should
|
|
|
|
|
|
* always have framebuffer information available.
|
2020-05-26 12:05:43 +02:00
|
|
|
|
*/
|
|
|
|
|
|
assert(cmd_buffer->state.framebuffer);
|
2020-04-02 12:38:10 +02:00
|
|
|
|
cmd_buffer->state.tile_aligned_render_area =
|
2021-06-14 11:35:06 +02:00
|
|
|
|
v3dv_subpass_area_is_tile_aligned(cmd_buffer->device, rect,
|
2020-10-08 13:24:13 +02:00
|
|
|
|
cmd_buffer->state.framebuffer,
|
|
|
|
|
|
cmd_buffer->state.pass,
|
|
|
|
|
|
cmd_buffer->state.subpass_idx);
|
2020-05-26 12:05:43 +02:00
|
|
|
|
|
|
|
|
|
|
if (!cmd_buffer->state.tile_aligned_render_area) {
|
|
|
|
|
|
perf_debug("Render area for subpass %d of render pass %p doesn't "
|
|
|
|
|
|
"match render pass granularity.\n",
|
|
|
|
|
|
cmd_buffer->state.subpass_idx, cmd_buffer->state.pass);
|
|
|
|
|
|
}
|
2020-04-02 12:38:10 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2022-01-27 11:11:51 +01:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_update_attachment_resolve_state(struct v3dv_cmd_buffer *cmd_buffer)
|
|
|
|
|
|
{
|
|
|
|
|
|
/* NOTE: This should be called after cmd_buffer_update_tile_alignment()
|
|
|
|
|
|
* since it relies on up-to-date information about subpass tile alignment.
|
|
|
|
|
|
*/
|
|
|
|
|
|
const struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
const struct v3dv_render_pass *pass = state->pass;
|
|
|
|
|
|
const struct v3dv_subpass *subpass = &pass->subpasses[state->subpass_idx];
|
|
|
|
|
|
|
|
|
|
|
|
for (uint32_t i = 0; i < subpass->color_count; i++) {
|
|
|
|
|
|
const uint32_t attachment_idx = subpass->color_attachments[i].attachment;
|
|
|
|
|
|
if (attachment_idx == VK_ATTACHMENT_UNUSED)
|
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
|
|
state->attachments[attachment_idx].has_resolve =
|
|
|
|
|
|
subpass->resolve_attachments &&
|
|
|
|
|
|
subpass->resolve_attachments[i].attachment != VK_ATTACHMENT_UNUSED;
|
|
|
|
|
|
|
|
|
|
|
|
state->attachments[attachment_idx].use_tlb_resolve =
|
|
|
|
|
|
state->attachments[attachment_idx].has_resolve &&
|
|
|
|
|
|
state->tile_aligned_render_area &&
|
|
|
|
|
|
pass->attachments[attachment_idx].try_tlb_resolve;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
uint32_t ds_attachment_idx = subpass->ds_attachment.attachment;
|
|
|
|
|
|
if (ds_attachment_idx != VK_ATTACHMENT_UNUSED) {
|
|
|
|
|
|
uint32_t ds_resolve_attachment_idx =
|
|
|
|
|
|
subpass->ds_resolve_attachment.attachment;
|
|
|
|
|
|
state->attachments[ds_attachment_idx].has_resolve =
|
|
|
|
|
|
ds_resolve_attachment_idx != VK_ATTACHMENT_UNUSED;
|
|
|
|
|
|
|
|
|
|
|
|
assert(!state->attachments[ds_attachment_idx].has_resolve ||
|
|
|
|
|
|
(subpass->resolve_depth || subpass->resolve_stencil));
|
|
|
|
|
|
|
|
|
|
|
|
state->attachments[ds_attachment_idx].use_tlb_resolve =
|
|
|
|
|
|
state->attachments[ds_attachment_idx].has_resolve &&
|
|
|
|
|
|
state->tile_aligned_render_area &&
|
|
|
|
|
|
pass->attachments[ds_attachment_idx].try_tlb_resolve;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-02-06 12:34:15 +01:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_state_set_attachment_clear_color(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
uint32_t attachment_idx,
|
|
|
|
|
|
const VkClearColorValue *color)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(attachment_idx < cmd_buffer->state.pass->attachment_count);
|
|
|
|
|
|
|
|
|
|
|
|
const struct v3dv_render_pass_attachment *attachment =
|
|
|
|
|
|
&cmd_buffer->state.pass->attachments[attachment_idx];
|
|
|
|
|
|
|
|
|
|
|
|
uint32_t internal_type, internal_bpp;
|
2021-06-14 11:35:06 +02:00
|
|
|
|
const struct v3dv_format *format =
|
|
|
|
|
|
v3dv_X(cmd_buffer->device, get_format)(attachment->desc.format);
|
|
|
|
|
|
|
|
|
|
|
|
v3dv_X(cmd_buffer->device, get_internal_type_bpp_for_output_format)
|
|
|
|
|
|
(format->rt_type, &internal_type, &internal_bpp);
|
2020-02-06 12:34:15 +01:00
|
|
|
|
|
|
|
|
|
|
uint32_t internal_size = 4 << internal_bpp;
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_cmd_buffer_attachment_state *attachment_state =
|
|
|
|
|
|
&cmd_buffer->state.attachments[attachment_idx];
|
|
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, get_hw_clear_color)
|
|
|
|
|
|
(color, internal_type, internal_size, &attachment_state->clear_value.color[0]);
|
2020-04-02 12:38:10 +02:00
|
|
|
|
|
|
|
|
|
|
attachment_state->vk_clear_value.color = *color;
|
2020-02-06 12:34:15 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-01-28 13:03:41 +01:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_state_set_attachment_clear_depth_stencil(
|
|
|
|
|
|
struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
uint32_t attachment_idx,
|
|
|
|
|
|
bool clear_depth, bool clear_stencil,
|
|
|
|
|
|
const VkClearDepthStencilValue *ds)
|
|
|
|
|
|
{
|
|
|
|
|
|
struct v3dv_cmd_buffer_attachment_state *attachment_state =
|
|
|
|
|
|
&cmd_buffer->state.attachments[attachment_idx];
|
|
|
|
|
|
|
|
|
|
|
|
if (clear_depth)
|
|
|
|
|
|
attachment_state->clear_value.z = ds->depth;
|
|
|
|
|
|
|
|
|
|
|
|
if (clear_stencil)
|
|
|
|
|
|
attachment_state->clear_value.s = ds->stencil;
|
2020-04-02 12:38:10 +02:00
|
|
|
|
|
|
|
|
|
|
attachment_state->vk_clear_value.depthStencil = *ds;
|
2020-01-28 13:03:41 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2019-12-18 11:44:35 +01:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_state_set_clear_values(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
uint32_t count, const VkClearValue *values)
|
|
|
|
|
|
{
|
|
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
2020-01-09 12:50:43 +01:00
|
|
|
|
const struct v3dv_render_pass *pass = state->pass;
|
|
|
|
|
|
|
2020-03-19 10:11:28 +01:00
|
|
|
|
/* There could be less clear values than attachments in the render pass, in
|
|
|
|
|
|
* which case we only want to process as many as we have, or there could be
|
|
|
|
|
|
* more, in which case we want to ignore those for which we don't have a
|
|
|
|
|
|
* corresponding attachment.
|
|
|
|
|
|
*/
|
|
|
|
|
|
count = MIN2(count, pass->attachment_count);
|
2020-01-09 14:19:44 +01:00
|
|
|
|
for (uint32_t i = 0; i < count; i++) {
|
2020-01-09 12:50:43 +01:00
|
|
|
|
const struct v3dv_render_pass_attachment *attachment =
|
|
|
|
|
|
&pass->attachments[i];
|
2019-12-18 11:44:35 +01:00
|
|
|
|
|
2020-01-09 12:50:43 +01:00
|
|
|
|
if (attachment->desc.loadOp != VK_ATTACHMENT_LOAD_OP_CLEAR)
|
|
|
|
|
|
continue;
|
|
|
|
|
|
|
2020-01-28 13:03:41 +01:00
|
|
|
|
VkImageAspectFlags aspects = vk_format_aspects(attachment->desc.format);
|
|
|
|
|
|
if (aspects & VK_IMAGE_ASPECT_COLOR_BIT) {
|
|
|
|
|
|
cmd_buffer_state_set_attachment_clear_color(cmd_buffer, i,
|
|
|
|
|
|
&values[i].color);
|
|
|
|
|
|
} else if (aspects & (VK_IMAGE_ASPECT_DEPTH_BIT |
|
|
|
|
|
|
VK_IMAGE_ASPECT_STENCIL_BIT)) {
|
|
|
|
|
|
cmd_buffer_state_set_attachment_clear_depth_stencil(
|
|
|
|
|
|
cmd_buffer, i,
|
|
|
|
|
|
aspects & VK_IMAGE_ASPECT_DEPTH_BIT,
|
|
|
|
|
|
aspects & VK_IMAGE_ASPECT_STENCIL_BIT,
|
|
|
|
|
|
&values[i].depthStencil);
|
|
|
|
|
|
}
|
2019-12-18 11:44:35 +01:00
|
|
|
|
}
|
2020-01-09 12:50:43 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2022-01-24 13:38:08 +01:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_state_set_attachments(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
const VkRenderPassBeginInfo *pRenderPassBegin)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_render_pass, pass, pRenderPassBegin->renderPass);
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_framebuffer, framebuffer, pRenderPassBegin->framebuffer);
|
|
|
|
|
|
|
|
|
|
|
|
const VkRenderPassAttachmentBeginInfoKHR *attach_begin =
|
|
|
|
|
|
vk_find_struct_const(pRenderPassBegin, RENDER_PASS_ATTACHMENT_BEGIN_INFO_KHR);
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
|
|
|
|
|
|
for (uint32_t i = 0; i < pass->attachment_count; i++) {
|
|
|
|
|
|
if (attach_begin && attach_begin->attachmentCount != 0) {
|
|
|
|
|
|
state->attachments[i].image_view =
|
|
|
|
|
|
v3dv_image_view_from_handle(attach_begin->pAttachments[i]);
|
|
|
|
|
|
} else if (framebuffer) {
|
|
|
|
|
|
state->attachments[i].image_view = framebuffer->attachments[i];
|
|
|
|
|
|
} else {
|
2021-12-14 15:42:14 +01:00
|
|
|
|
assert(cmd_buffer->vk.level == VK_COMMAND_BUFFER_LEVEL_SECONDARY);
|
2022-01-24 13:38:08 +01:00
|
|
|
|
state->attachments[i].image_view = NULL;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-01-09 14:19:44 +01:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_init_render_pass_attachment_state(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
const VkRenderPassBeginInfo *pRenderPassBegin)
|
|
|
|
|
|
{
|
|
|
|
|
|
cmd_buffer_state_set_clear_values(cmd_buffer,
|
|
|
|
|
|
pRenderPassBegin->clearValueCount,
|
|
|
|
|
|
pRenderPassBegin->pClearValues);
|
2022-01-24 13:38:08 +01:00
|
|
|
|
|
|
|
|
|
|
cmd_buffer_state_set_attachments(cmd_buffer, pRenderPassBegin);
|
2020-01-09 14:19:44 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-01-09 12:50:43 +01:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_ensure_render_pass_attachment_state(struct v3dv_cmd_buffer *cmd_buffer)
|
|
|
|
|
|
{
|
|
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
const struct v3dv_render_pass *pass = state->pass;
|
|
|
|
|
|
|
2020-06-02 13:13:43 +02:00
|
|
|
|
if (state->attachment_alloc_count < pass->attachment_count) {
|
|
|
|
|
|
if (state->attachments > 0) {
|
|
|
|
|
|
assert(state->attachment_alloc_count > 0);
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_free(&cmd_buffer->device->vk.alloc, state->attachments);
|
2020-06-02 13:13:43 +02:00
|
|
|
|
}
|
2019-12-18 11:44:35 +01:00
|
|
|
|
|
2020-01-09 12:50:43 +01:00
|
|
|
|
uint32_t size = sizeof(struct v3dv_cmd_buffer_attachment_state) *
|
|
|
|
|
|
pass->attachment_count;
|
2020-11-12 16:30:41 +01:00
|
|
|
|
state->attachments = vk_zalloc(&cmd_buffer->device->vk.alloc, size, 8,
|
2020-01-09 12:50:43 +01:00
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
if (!state->attachments) {
|
|
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
2020-06-02 13:13:43 +02:00
|
|
|
|
state->attachment_alloc_count = pass->attachment_count;
|
2020-01-09 12:50:43 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-06-02 13:13:43 +02:00
|
|
|
|
assert(state->attachment_alloc_count >= pass->attachment_count);
|
2019-12-18 11:44:35 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2021-10-28 08:29:33 +00:00
|
|
|
|
v3dv_CmdBeginRenderPass2(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
const VkRenderPassBeginInfo *pRenderPassBegin,
|
|
|
|
|
|
const VkSubpassBeginInfo *pSubpassBeginInfo)
|
2019-12-13 10:48:12 +01:00
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_render_pass, pass, pRenderPassBegin->renderPass);
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_framebuffer, framebuffer, pRenderPassBegin->framebuffer);
|
|
|
|
|
|
|
2019-12-18 11:44:35 +01:00
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
state->pass = pass;
|
|
|
|
|
|
state->framebuffer = framebuffer;
|
|
|
|
|
|
|
2020-01-09 12:50:43 +01:00
|
|
|
|
cmd_buffer_ensure_render_pass_attachment_state(cmd_buffer);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
v3dv_return_if_oom(cmd_buffer, NULL);
|
|
|
|
|
|
|
2020-01-09 14:19:44 +01:00
|
|
|
|
cmd_buffer_init_render_pass_attachment_state(cmd_buffer, pRenderPassBegin);
|
2019-12-13 10:48:12 +01:00
|
|
|
|
|
2019-12-18 11:44:35 +01:00
|
|
|
|
state->render_area = pRenderPassBegin->renderArea;
|
2019-12-28 11:42:53 +01:00
|
|
|
|
|
2020-04-01 10:18:52 +02:00
|
|
|
|
/* If our render area is smaller than the current clip window we will have
|
2020-04-02 12:38:10 +02:00
|
|
|
|
* to emit a new clip window to constraint it to the render area.
|
2020-04-01 10:18:52 +02:00
|
|
|
|
*/
|
|
|
|
|
|
uint32_t min_render_x = state->render_area.offset.x;
|
2021-06-03 10:44:49 +02:00
|
|
|
|
uint32_t min_render_y = state->render_area.offset.y;
|
2020-04-01 10:18:52 +02:00
|
|
|
|
uint32_t max_render_x = min_render_x + state->render_area.extent.width - 1;
|
|
|
|
|
|
uint32_t max_render_y = min_render_y + state->render_area.extent.height - 1;
|
|
|
|
|
|
uint32_t min_clip_x = state->clip_window.offset.x;
|
|
|
|
|
|
uint32_t min_clip_y = state->clip_window.offset.y;
|
|
|
|
|
|
uint32_t max_clip_x = min_clip_x + state->clip_window.extent.width - 1;
|
|
|
|
|
|
uint32_t max_clip_y = min_clip_y + state->clip_window.extent.height - 1;
|
|
|
|
|
|
if (min_render_x > min_clip_x || min_render_y > min_clip_y ||
|
|
|
|
|
|
max_render_x < max_clip_x || max_render_y < max_clip_y) {
|
|
|
|
|
|
state->dirty |= V3DV_CMD_DIRTY_SCISSOR;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2019-12-17 08:58:20 +01:00
|
|
|
|
/* Setup for first subpass */
|
2020-03-31 12:59:44 +02:00
|
|
|
|
v3dv_cmd_buffer_subpass_start(cmd_buffer, 0);
|
2020-01-08 12:16:39 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2021-10-28 08:29:33 +00:00
|
|
|
|
v3dv_CmdNextSubpass2(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
const VkSubpassBeginInfo *pSubpassBeginInfo,
|
|
|
|
|
|
const VkSubpassEndInfo *pSubpassEndInfo)
|
2020-01-08 12:16:39 +01:00
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
assert(state->subpass_idx < state->pass->subpass_count - 1);
|
|
|
|
|
|
|
|
|
|
|
|
/* Finish the previous subpass */
|
2020-03-31 12:59:44 +02:00
|
|
|
|
v3dv_cmd_buffer_subpass_finish(cmd_buffer);
|
2020-07-31 14:58:42 +02:00
|
|
|
|
cmd_buffer_subpass_handle_pending_resolves(cmd_buffer);
|
2020-01-08 12:00:49 +01:00
|
|
|
|
|
2020-01-08 12:16:39 +01:00
|
|
|
|
/* Start the next subpass */
|
2020-03-31 12:59:44 +02:00
|
|
|
|
v3dv_cmd_buffer_subpass_start(cmd_buffer, state->subpass_idx + 1);
|
2019-12-13 10:48:12 +01:00
|
|
|
|
}
|
2019-12-16 09:09:40 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_emit_subpass_clears(struct v3dv_cmd_buffer *cmd_buffer)
|
2019-12-17 09:01:32 +01:00
|
|
|
|
{
|
2021-12-14 15:42:14 +01:00
|
|
|
|
assert(cmd_buffer->vk.level == VK_COMMAND_BUFFER_LEVEL_PRIMARY);
|
2019-12-17 09:01:32 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
assert(cmd_buffer->state.pass);
|
|
|
|
|
|
assert(cmd_buffer->state.subpass_idx < cmd_buffer->state.pass->subpass_count);
|
|
|
|
|
|
const struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
const struct v3dv_render_pass *pass = state->pass;
|
|
|
|
|
|
const struct v3dv_subpass *subpass = &pass->subpasses[state->subpass_idx];
|
2019-12-17 09:01:32 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* We only need to emit subpass clears as draw calls when the render
|
|
|
|
|
|
* area is not aligned to tile boundaries or for GFXH-1461.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (cmd_buffer->state.tile_aligned_render_area &&
|
|
|
|
|
|
!subpass->do_depth_clear_with_draw &&
|
|
|
|
|
|
!subpass->do_depth_clear_with_draw) {
|
2019-12-17 09:01:32 +01:00
|
|
|
|
return;
|
2021-06-14 23:36:45 +02:00
|
|
|
|
}
|
2019-12-17 09:01:32 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
uint32_t att_count = 0;
|
|
|
|
|
|
VkClearAttachment atts[V3D_MAX_DRAW_BUFFERS + 1]; /* 4 color + D/S */
|
2019-12-17 09:01:32 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* We only need to emit subpass clears as draw calls for color attachments
|
|
|
|
|
|
* if the render area is not aligned to tile boundaries.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (!cmd_buffer->state.tile_aligned_render_area) {
|
|
|
|
|
|
for (uint32_t i = 0; i < subpass->color_count; i++) {
|
|
|
|
|
|
const uint32_t att_idx = subpass->color_attachments[i].attachment;
|
|
|
|
|
|
if (att_idx == VK_ATTACHMENT_UNUSED)
|
|
|
|
|
|
continue;
|
2019-12-17 09:01:32 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
struct v3dv_render_pass_attachment *att = &pass->attachments[att_idx];
|
|
|
|
|
|
if (att->desc.loadOp != VK_ATTACHMENT_LOAD_OP_CLEAR)
|
|
|
|
|
|
continue;
|
2021-06-14 20:19:40 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
if (state->subpass_idx != att->first_subpass)
|
|
|
|
|
|
continue;
|
2019-12-17 09:01:32 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
atts[att_count].aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
|
|
|
|
|
|
atts[att_count].colorAttachment = i;
|
|
|
|
|
|
atts[att_count].clearValue = state->attachments[att_idx].vk_clear_value;
|
|
|
|
|
|
att_count++;
|
2020-01-02 11:33:06 +01:00
|
|
|
|
}
|
2021-06-14 23:36:45 +02:00
|
|
|
|
}
|
2020-01-02 11:33:06 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* For D/S we may also need to emit a subpass clear for GFXH-1461 */
|
|
|
|
|
|
const uint32_t ds_att_idx = subpass->ds_attachment.attachment;
|
|
|
|
|
|
if (ds_att_idx != VK_ATTACHMENT_UNUSED) {
|
|
|
|
|
|
struct v3dv_render_pass_attachment *att = &pass->attachments[ds_att_idx];
|
|
|
|
|
|
if (state->subpass_idx == att->first_subpass) {
|
|
|
|
|
|
VkImageAspectFlags aspects = vk_format_aspects(att->desc.format);
|
|
|
|
|
|
if (att->desc.loadOp != VK_ATTACHMENT_LOAD_OP_CLEAR ||
|
|
|
|
|
|
(cmd_buffer->state.tile_aligned_render_area &&
|
|
|
|
|
|
!subpass->do_depth_clear_with_draw)) {
|
|
|
|
|
|
aspects &= ~VK_IMAGE_ASPECT_DEPTH_BIT;
|
|
|
|
|
|
}
|
|
|
|
|
|
if (att->desc.stencilLoadOp != VK_ATTACHMENT_LOAD_OP_CLEAR ||
|
|
|
|
|
|
(cmd_buffer->state.tile_aligned_render_area &&
|
|
|
|
|
|
!subpass->do_stencil_clear_with_draw)) {
|
|
|
|
|
|
aspects &= ~VK_IMAGE_ASPECT_STENCIL_BIT;
|
|
|
|
|
|
}
|
|
|
|
|
|
if (aspects) {
|
|
|
|
|
|
atts[att_count].aspectMask = aspects;
|
|
|
|
|
|
atts[att_count].colorAttachment = 0; /* Ignored */
|
|
|
|
|
|
atts[att_count].clearValue =
|
|
|
|
|
|
state->attachments[ds_att_idx].vk_clear_value;
|
|
|
|
|
|
att_count++;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
2020-01-02 11:33:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
if (att_count == 0)
|
|
|
|
|
|
return;
|
2021-01-20 09:36:06 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
if (!cmd_buffer->state.tile_aligned_render_area) {
|
|
|
|
|
|
perf_debug("Render area doesn't match render pass granularity, falling "
|
|
|
|
|
|
"back to vkCmdClearAttachments for "
|
|
|
|
|
|
"VK_ATTACHMENT_LOAD_OP_CLEAR.\n");
|
|
|
|
|
|
} else if (subpass->do_depth_clear_with_draw ||
|
|
|
|
|
|
subpass->do_stencil_clear_with_draw) {
|
|
|
|
|
|
perf_debug("Subpass clears DEPTH but loads STENCIL (or viceversa), "
|
|
|
|
|
|
"falling back to vkCmdClearAttachments for "
|
|
|
|
|
|
"VK_ATTACHMENT_LOAD_OP_CLEAR.\n");
|
|
|
|
|
|
}
|
2021-01-20 09:36:06 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* From the Vulkan 1.0 spec:
|
|
|
|
|
|
*
|
|
|
|
|
|
* "VK_ATTACHMENT_LOAD_OP_CLEAR specifies that the contents within the
|
|
|
|
|
|
* render area will be cleared to a uniform value, which is specified
|
|
|
|
|
|
* when a render pass instance is begun."
|
|
|
|
|
|
*
|
|
|
|
|
|
* So the clear is only constrained by the render area and not by pipeline
|
|
|
|
|
|
* state such as scissor or viewport, these are the semantics of
|
|
|
|
|
|
* vkCmdClearAttachments as well.
|
2021-01-20 09:36:06 +01:00
|
|
|
|
*/
|
2021-06-14 23:36:45 +02:00
|
|
|
|
VkCommandBuffer _cmd_buffer = v3dv_cmd_buffer_to_handle(cmd_buffer);
|
|
|
|
|
|
VkClearRect rect = {
|
|
|
|
|
|
.rect = state->render_area,
|
|
|
|
|
|
.baseArrayLayer = 0,
|
|
|
|
|
|
.layerCount = 1,
|
|
|
|
|
|
};
|
|
|
|
|
|
v3dv_CmdClearAttachments(_cmd_buffer, att_count, atts, 1, &rect);
|
2020-09-24 10:09:00 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
static struct v3dv_job *
|
|
|
|
|
|
cmd_buffer_subpass_create_job(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
uint32_t subpass_idx,
|
|
|
|
|
|
enum v3dv_job_type type)
|
2021-01-19 10:01:42 +01:00
|
|
|
|
{
|
2021-06-14 23:36:45 +02:00
|
|
|
|
assert(type == V3DV_JOB_TYPE_GPU_CL ||
|
|
|
|
|
|
type == V3DV_JOB_TYPE_GPU_CL_SECONDARY);
|
2021-01-19 10:01:42 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
assert(subpass_idx < state->pass->subpass_count);
|
2021-01-19 10:01:42 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* Starting a new job can trigger a finish of the current one, so don't
|
|
|
|
|
|
* change the command buffer state for the new job until we are done creating
|
|
|
|
|
|
* the new job.
|
2021-01-19 10:01:42 +01:00
|
|
|
|
*/
|
2021-06-14 23:36:45 +02:00
|
|
|
|
struct v3dv_job *job =
|
|
|
|
|
|
v3dv_cmd_buffer_start_job(cmd_buffer, subpass_idx, type);
|
|
|
|
|
|
if (!job)
|
|
|
|
|
|
return NULL;
|
2021-01-19 10:01:42 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
state->subpass_idx = subpass_idx;
|
2021-01-19 10:01:42 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* If we are starting a new job we need to setup binning. We only do this
|
|
|
|
|
|
* for V3DV_JOB_TYPE_GPU_CL jobs because V3DV_JOB_TYPE_GPU_CL_SECONDARY
|
|
|
|
|
|
* jobs are not submitted to the GPU directly, and are instead meant to be
|
|
|
|
|
|
* branched to from other V3DV_JOB_TYPE_GPU_CL jobs.
|
2021-01-19 10:01:42 +01:00
|
|
|
|
*/
|
2021-06-14 23:36:45 +02:00
|
|
|
|
if (type == V3DV_JOB_TYPE_GPU_CL &&
|
|
|
|
|
|
job->first_subpass == state->subpass_idx) {
|
|
|
|
|
|
const struct v3dv_subpass *subpass =
|
|
|
|
|
|
&state->pass->subpasses[state->subpass_idx];
|
|
|
|
|
|
|
|
|
|
|
|
const struct v3dv_framebuffer *framebuffer = state->framebuffer;
|
|
|
|
|
|
|
|
|
|
|
|
uint8_t internal_bpp;
|
|
|
|
|
|
bool msaa;
|
|
|
|
|
|
v3dv_X(job->device, framebuffer_compute_internal_bpp_msaa)
|
2022-01-24 13:38:08 +01:00
|
|
|
|
(framebuffer, state->attachments, subpass, &internal_bpp, &msaa);
|
2021-06-14 23:36:45 +02:00
|
|
|
|
|
2021-07-22 13:50:16 +02:00
|
|
|
|
/* From the Vulkan spec:
|
|
|
|
|
|
*
|
|
|
|
|
|
* "If the render pass uses multiview, then layers must be one and
|
|
|
|
|
|
* each attachment requires a number of layers that is greater than
|
|
|
|
|
|
* the maximum bit index set in the view mask in the subpasses in
|
|
|
|
|
|
* which it is used."
|
|
|
|
|
|
*
|
|
|
|
|
|
* So when multiview is enabled, we take the number of layers from the
|
|
|
|
|
|
* last bit set in the view mask.
|
|
|
|
|
|
*/
|
|
|
|
|
|
uint32_t layers = framebuffer->layers;
|
|
|
|
|
|
if (subpass->view_mask != 0) {
|
|
|
|
|
|
assert(framebuffer->layers == 1);
|
|
|
|
|
|
layers = util_last_bit(subpass->view_mask);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_job_start_frame(job,
|
|
|
|
|
|
framebuffer->width,
|
|
|
|
|
|
framebuffer->height,
|
2021-07-22 13:50:16 +02:00
|
|
|
|
layers,
|
2021-07-16 08:23:11 +02:00
|
|
|
|
true,
|
2021-06-14 23:36:45 +02:00
|
|
|
|
subpass->color_count,
|
|
|
|
|
|
internal_bpp,
|
|
|
|
|
|
msaa);
|
|
|
|
|
|
}
|
2021-01-19 10:01:42 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
return job;
|
2021-01-19 10:01:42 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
struct v3dv_job *
|
|
|
|
|
|
v3dv_cmd_buffer_subpass_start(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
uint32_t subpass_idx)
|
2021-01-20 09:46:53 +01:00
|
|
|
|
{
|
2021-06-14 23:36:45 +02:00
|
|
|
|
assert(cmd_buffer->state.pass);
|
|
|
|
|
|
assert(subpass_idx < cmd_buffer->state.pass->subpass_count);
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_job *job =
|
|
|
|
|
|
cmd_buffer_subpass_create_job(cmd_buffer, subpass_idx,
|
|
|
|
|
|
V3DV_JOB_TYPE_GPU_CL);
|
|
|
|
|
|
if (!job)
|
|
|
|
|
|
return NULL;
|
2021-01-20 09:46:53 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* Check if our render area is aligned to tile boundaries. We have to do
|
|
|
|
|
|
* this in each subpass because the subset of attachments used can change
|
|
|
|
|
|
* and with that the tile size selected by the hardware can change too.
|
2021-01-20 09:46:53 +01:00
|
|
|
|
*/
|
2021-06-14 23:36:45 +02:00
|
|
|
|
cmd_buffer_update_tile_alignment(cmd_buffer);
|
2021-01-20 09:46:53 +01:00
|
|
|
|
|
2022-01-27 11:11:51 +01:00
|
|
|
|
cmd_buffer_update_attachment_resolve_state(cmd_buffer);
|
|
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* If we can't use TLB clears then we need to emit draw clears for any
|
|
|
|
|
|
* LOAD_OP_CLEAR attachments in this subpass now. We might also need to emit
|
|
|
|
|
|
* Depth/Stencil clears if we hit GFXH-1461.
|
|
|
|
|
|
*
|
|
|
|
|
|
* Secondary command buffers don't start subpasses (and may not even have
|
|
|
|
|
|
* framebuffer state), so we only care about this in primaries. The only
|
|
|
|
|
|
* exception could be a secondary runnning inside a subpass that needs to
|
|
|
|
|
|
* record a meta operation (with its own render pass) that relies on
|
|
|
|
|
|
* attachment load clears, but we don't have any instances of that right
|
|
|
|
|
|
* now.
|
2021-01-20 09:46:53 +01:00
|
|
|
|
*/
|
2021-12-14 15:42:14 +01:00
|
|
|
|
if (cmd_buffer->vk.level == VK_COMMAND_BUFFER_LEVEL_PRIMARY)
|
2021-06-14 23:36:45 +02:00
|
|
|
|
cmd_buffer_emit_subpass_clears(cmd_buffer);
|
2021-01-20 09:46:53 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
return job;
|
2021-01-20 09:46:53 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
struct v3dv_job *
|
|
|
|
|
|
v3dv_cmd_buffer_subpass_resume(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
uint32_t subpass_idx)
|
2019-12-17 09:01:32 +01:00
|
|
|
|
{
|
2021-06-14 23:36:45 +02:00
|
|
|
|
assert(cmd_buffer->state.pass);
|
|
|
|
|
|
assert(subpass_idx < cmd_buffer->state.pass->subpass_count);
|
2020-01-02 11:33:06 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
struct v3dv_job *job;
|
2021-12-14 15:42:14 +01:00
|
|
|
|
if (cmd_buffer->vk.level == VK_COMMAND_BUFFER_LEVEL_PRIMARY) {
|
2021-06-14 23:36:45 +02:00
|
|
|
|
job = cmd_buffer_subpass_create_job(cmd_buffer, subpass_idx,
|
|
|
|
|
|
V3DV_JOB_TYPE_GPU_CL);
|
|
|
|
|
|
} else {
|
2021-12-14 15:42:14 +01:00
|
|
|
|
assert(cmd_buffer->vk.level == VK_COMMAND_BUFFER_LEVEL_SECONDARY);
|
2021-06-14 23:36:45 +02:00
|
|
|
|
job = cmd_buffer_subpass_create_job(cmd_buffer, subpass_idx,
|
|
|
|
|
|
V3DV_JOB_TYPE_GPU_CL_SECONDARY);
|
|
|
|
|
|
}
|
2020-01-02 11:33:06 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
if (!job)
|
|
|
|
|
|
return NULL;
|
2020-01-02 11:33:06 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
job->is_subpass_continue = true;
|
2020-04-03 14:19:40 +02:00
|
|
|
|
|
|
|
|
|
|
return job;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-03-31 12:59:44 +02:00
|
|
|
|
void
|
|
|
|
|
|
v3dv_cmd_buffer_subpass_finish(struct v3dv_cmd_buffer *cmd_buffer)
|
2020-01-03 11:27:01 +01:00
|
|
|
|
{
|
2020-04-02 11:09:05 +02:00
|
|
|
|
/* We can end up here without a job if the last command recorded into the
|
|
|
|
|
|
* subpass already finished the job (for example a pipeline barrier). In
|
|
|
|
|
|
* that case we miss to set the is_subpass_finish flag, but that is not
|
|
|
|
|
|
* required for proper behavior.
|
|
|
|
|
|
*/
|
2020-01-08 11:14:35 +01:00
|
|
|
|
struct v3dv_job *job = cmd_buffer->state.job;
|
2020-04-02 11:09:05 +02:00
|
|
|
|
if (job)
|
|
|
|
|
|
job->is_subpass_finish = true;
|
2020-01-03 11:27:01 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2021-10-28 08:29:33 +00:00
|
|
|
|
v3dv_CmdEndRenderPass2(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
const VkSubpassEndInfo *pSubpassEndInfo)
|
2019-12-16 09:09:40 +01:00
|
|
|
|
{
|
2019-12-17 09:01:32 +01:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
/* Finalize last subpass */
|
2019-12-17 09:01:32 +01:00
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
assert(state->subpass_idx == state->pass->subpass_count - 1);
|
2020-05-26 12:05:43 +02:00
|
|
|
|
v3dv_cmd_buffer_subpass_finish(cmd_buffer);
|
|
|
|
|
|
v3dv_cmd_buffer_finish_job(cmd_buffer);
|
2019-12-17 09:01:32 +01:00
|
|
|
|
|
2020-07-31 14:58:42 +02:00
|
|
|
|
cmd_buffer_subpass_handle_pending_resolves(cmd_buffer);
|
|
|
|
|
|
|
2019-12-17 09:01:32 +01:00
|
|
|
|
/* We are no longer inside a render pass */
|
|
|
|
|
|
state->framebuffer = NULL;
|
2020-04-21 14:00:32 +02:00
|
|
|
|
state->pass = NULL;
|
|
|
|
|
|
state->subpass_idx = -1;
|
2019-12-16 09:09:40 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR VkResult VKAPI_CALL
|
2019-12-16 09:09:40 +01:00
|
|
|
|
v3dv_EndCommandBuffer(VkCommandBuffer commandBuffer)
|
|
|
|
|
|
{
|
2019-12-17 09:48:54 +01:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
2020-03-12 11:59:04 +01:00
|
|
|
|
if (cmd_buffer->state.oom)
|
|
|
|
|
|
return VK_ERROR_OUT_OF_HOST_MEMORY;
|
|
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
/* Primaries should have ended any recording jobs by the time they hit
|
|
|
|
|
|
* vkEndRenderPass (if we are inside a render pass). Commands outside
|
|
|
|
|
|
* a render pass instance (for both primaries and secondaries) spawn
|
|
|
|
|
|
* complete jobs too. So the only case where we can get here without
|
|
|
|
|
|
* finishing a recording job is when we are recording a secondary
|
|
|
|
|
|
* inside a render pass.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (cmd_buffer->state.job) {
|
2021-12-14 15:42:14 +01:00
|
|
|
|
assert(cmd_buffer->vk.level == VK_COMMAND_BUFFER_LEVEL_SECONDARY &&
|
2020-05-26 12:05:43 +02:00
|
|
|
|
cmd_buffer->state.pass);
|
|
|
|
|
|
v3dv_cmd_buffer_finish_job(cmd_buffer);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2019-12-17 09:48:54 +01:00
|
|
|
|
cmd_buffer->status = V3DV_CMD_BUFFER_STATUS_EXECUTABLE;
|
|
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-06-09 14:31:40 +02:00
|
|
|
|
static void
|
|
|
|
|
|
clone_bo_list(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct list_head *dst,
|
|
|
|
|
|
struct list_head *src)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(cmd_buffer);
|
|
|
|
|
|
|
|
|
|
|
|
list_inithead(dst);
|
|
|
|
|
|
list_for_each_entry(struct v3dv_bo, bo, src, list_link) {
|
|
|
|
|
|
struct v3dv_bo *clone_bo =
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_alloc(&cmd_buffer->device->vk.alloc, sizeof(struct v3dv_bo), 8,
|
2020-06-09 14:31:40 +02:00
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
|
|
|
|
|
if (!clone_bo) {
|
|
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
*clone_bo = *bo;
|
|
|
|
|
|
list_addtail(&clone_bo->list_link, dst);
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-06-01 12:00:16 +02:00
|
|
|
|
/* Clones a job for inclusion in the given command buffer. Note that this
|
|
|
|
|
|
* doesn't make a deep copy so the cloned job it doesn't own any resources.
|
|
|
|
|
|
* Useful when we need to have a job in more than one list, which happens
|
|
|
|
|
|
* for jobs recorded in secondary command buffers when we want to execute
|
|
|
|
|
|
* them in primaries.
|
|
|
|
|
|
*/
|
2021-06-14 23:36:45 +02:00
|
|
|
|
struct v3dv_job *
|
|
|
|
|
|
v3dv_job_clone_in_cmd_buffer(struct v3dv_job *job,
|
|
|
|
|
|
struct v3dv_cmd_buffer *cmd_buffer)
|
2020-06-01 12:00:16 +02:00
|
|
|
|
{
|
2020-11-12 16:30:41 +01:00
|
|
|
|
struct v3dv_job *clone_job = vk_alloc(&job->device->vk.alloc,
|
2020-06-01 12:00:16 +02:00
|
|
|
|
sizeof(struct v3dv_job), 8,
|
|
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
2020-06-02 12:26:50 +02:00
|
|
|
|
if (!clone_job) {
|
|
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
2020-09-25 15:00:41 +02:00
|
|
|
|
return NULL;
|
2020-06-02 12:26:50 +02:00
|
|
|
|
}
|
2020-06-01 12:00:16 +02:00
|
|
|
|
|
2020-06-09 14:31:40 +02:00
|
|
|
|
/* Cloned jobs don't duplicate resources! */
|
2020-06-01 12:00:16 +02:00
|
|
|
|
*clone_job = *job;
|
|
|
|
|
|
clone_job->is_clone = true;
|
|
|
|
|
|
clone_job->cmd_buffer = cmd_buffer;
|
2020-06-02 12:26:50 +02:00
|
|
|
|
list_addtail(&clone_job->list_link, &cmd_buffer->jobs);
|
2020-06-09 14:31:40 +02:00
|
|
|
|
|
|
|
|
|
|
/* We need to regen the BO lists so that they point to the BO list in the
|
|
|
|
|
|
* cloned job. Otherwise functions like list_length() will loop forever.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (job->type == V3DV_JOB_TYPE_GPU_CL) {
|
|
|
|
|
|
clone_bo_list(cmd_buffer, &clone_job->bcl.bo_list, &job->bcl.bo_list);
|
|
|
|
|
|
clone_bo_list(cmd_buffer, &clone_job->rcl.bo_list, &job->rcl.bo_list);
|
|
|
|
|
|
clone_bo_list(cmd_buffer, &clone_job->indirect.bo_list,
|
|
|
|
|
|
&job->indirect.bo_list);
|
|
|
|
|
|
}
|
2020-09-25 15:00:41 +02:00
|
|
|
|
|
|
|
|
|
|
return clone_job;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_execute_outside_pass(struct v3dv_cmd_buffer *primary,
|
|
|
|
|
|
uint32_t cmd_buffer_count,
|
|
|
|
|
|
const VkCommandBuffer *cmd_buffers)
|
|
|
|
|
|
{
|
2022-05-30 08:31:17 +02:00
|
|
|
|
struct v3dv_barrier_state pending_barrier = { 0 };
|
2020-05-26 12:05:43 +02:00
|
|
|
|
for (uint32_t i = 0; i < cmd_buffer_count; i++) {
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, secondary, cmd_buffers[i]);
|
|
|
|
|
|
|
|
|
|
|
|
assert(!(secondary->usage_flags &
|
|
|
|
|
|
VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT));
|
|
|
|
|
|
|
|
|
|
|
|
/* Secondary command buffers that execute outside a render pass create
|
|
|
|
|
|
* complete jobs with an RCL and tile setup, so we simply want to merge
|
|
|
|
|
|
* their job list into the primary's. However, because they may be
|
|
|
|
|
|
* executed into multiple primaries at the same time and we only have a
|
|
|
|
|
|
* single list_link in each job, we can't just add then to the primary's
|
|
|
|
|
|
* job list and we instead have to clone them first.
|
|
|
|
|
|
*
|
|
|
|
|
|
* Alternatively, we could create a "execute secondary" CPU job that
|
|
|
|
|
|
* when executed in a queue, would submit all the jobs in the referenced
|
|
|
|
|
|
* secondary command buffer. However, this would raise some challenges
|
|
|
|
|
|
* to make it work with the implementation of wait threads in the queue
|
|
|
|
|
|
* which we use for event waits, for example.
|
|
|
|
|
|
*/
|
|
|
|
|
|
list_for_each_entry(struct v3dv_job, secondary_job,
|
|
|
|
|
|
&secondary->jobs, list_link) {
|
2020-06-02 12:26:50 +02:00
|
|
|
|
/* These can only happen inside a render pass */
|
|
|
|
|
|
assert(secondary_job->type != V3DV_JOB_TYPE_GPU_CL_SECONDARY);
|
2021-06-14 23:36:45 +02:00
|
|
|
|
struct v3dv_job *job = v3dv_job_clone_in_cmd_buffer(secondary_job, primary);
|
2020-09-25 15:00:41 +02:00
|
|
|
|
if (!job)
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
2022-05-30 08:31:17 +02:00
|
|
|
|
if (pending_barrier.dst_mask) {
|
2020-09-25 15:00:41 +02:00
|
|
|
|
job->serialize = true;
|
2022-05-30 08:31:17 +02:00
|
|
|
|
if (pending_barrier.bcl_buffer_access ||
|
|
|
|
|
|
pending_barrier.bcl_image_access) {
|
2020-09-25 15:00:41 +02:00
|
|
|
|
job->needs_bcl_sync = true;
|
2022-05-03 09:05:19 +02:00
|
|
|
|
}
|
2022-05-30 08:31:17 +02:00
|
|
|
|
memset(&pending_barrier, 0, sizeof(pending_barrier));
|
2020-09-25 15:00:41 +02:00
|
|
|
|
}
|
2020-05-26 12:05:43 +02:00
|
|
|
|
}
|
2020-09-25 15:00:41 +02:00
|
|
|
|
|
|
|
|
|
|
/* If this secondary had any pending barrier state we will need that
|
|
|
|
|
|
* barrier state consumed with whatever comes after it (first job in
|
|
|
|
|
|
* the next secondary or the primary, if this was the last secondary).
|
|
|
|
|
|
*/
|
2022-05-30 08:31:17 +02:00
|
|
|
|
assert(secondary->state.barrier.dst_mask ||
|
|
|
|
|
|
(!secondary->state.barrier.bcl_buffer_access &&
|
|
|
|
|
|
!secondary->state.barrier.bcl_image_access));
|
|
|
|
|
|
pending_barrier = secondary->state.barrier;
|
2020-09-25 15:00:41 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2022-05-30 08:31:17 +02:00
|
|
|
|
if (pending_barrier.dst_mask)
|
|
|
|
|
|
primary->state.barrier = pending_barrier;
|
2020-05-26 12:05:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-05-26 12:05:43 +02:00
|
|
|
|
v3dv_CmdExecuteCommands(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
uint32_t commandBufferCount,
|
|
|
|
|
|
const VkCommandBuffer *pCommandBuffers)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, primary, commandBuffer);
|
|
|
|
|
|
|
|
|
|
|
|
if (primary->state.pass != NULL) {
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(primary->device, cmd_buffer_execute_inside_pass)
|
|
|
|
|
|
(primary, commandBufferCount, pCommandBuffers);
|
2020-05-26 12:05:43 +02:00
|
|
|
|
} else {
|
|
|
|
|
|
cmd_buffer_execute_outside_pass(primary,
|
|
|
|
|
|
commandBufferCount, pCommandBuffers);
|
|
|
|
|
|
}
|
2019-12-16 09:09:40 +01:00
|
|
|
|
}
|
2019-12-18 15:38:21 +01:00
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
/* This goes though the list of possible dynamic states in the pipeline and,
|
|
|
|
|
|
* for those that are not configured as dynamic, copies relevant state into
|
|
|
|
|
|
* the command buffer.
|
|
|
|
|
|
*/
|
2019-12-28 12:20:45 +01:00
|
|
|
|
static void
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
cmd_buffer_bind_pipeline_static_state(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
const struct v3dv_dynamic_state *src)
|
2019-12-28 12:20:45 +01:00
|
|
|
|
{
|
|
|
|
|
|
struct v3dv_dynamic_state *dest = &cmd_buffer->state.dynamic;
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
uint32_t dynamic_mask = src->mask;
|
|
|
|
|
|
uint32_t dirty = 0;
|
2019-12-28 12:20:45 +01:00
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
if (!(dynamic_mask & V3DV_DYNAMIC_VIEWPORT)) {
|
2020-06-23 12:46:49 +02:00
|
|
|
|
dest->viewport.count = src->viewport.count;
|
2019-12-28 12:20:45 +01:00
|
|
|
|
if (memcmp(&dest->viewport.viewports, &src->viewport.viewports,
|
|
|
|
|
|
src->viewport.count * sizeof(VkViewport))) {
|
|
|
|
|
|
typed_memcpy(dest->viewport.viewports,
|
|
|
|
|
|
src->viewport.viewports,
|
|
|
|
|
|
src->viewport.count);
|
2020-02-03 12:55:25 +01:00
|
|
|
|
typed_memcpy(dest->viewport.scale, src->viewport.scale,
|
|
|
|
|
|
src->viewport.count);
|
|
|
|
|
|
typed_memcpy(dest->viewport.translate, src->viewport.translate,
|
|
|
|
|
|
src->viewport.count);
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
dirty |= V3DV_CMD_DIRTY_VIEWPORT;
|
2019-12-28 12:20:45 +01:00
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
if (!(dynamic_mask & V3DV_DYNAMIC_SCISSOR)) {
|
2020-06-23 12:46:49 +02:00
|
|
|
|
dest->scissor.count = src->scissor.count;
|
2019-12-28 12:20:45 +01:00
|
|
|
|
if (memcmp(&dest->scissor.scissors, &src->scissor.scissors,
|
|
|
|
|
|
src->scissor.count * sizeof(VkRect2D))) {
|
|
|
|
|
|
typed_memcpy(dest->scissor.scissors,
|
|
|
|
|
|
src->scissor.scissors, src->scissor.count);
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
dirty |= V3DV_CMD_DIRTY_SCISSOR;
|
2019-12-28 12:20:45 +01:00
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
if (!(dynamic_mask & V3DV_DYNAMIC_STENCIL_COMPARE_MASK)) {
|
2020-02-04 17:43:49 +01:00
|
|
|
|
if (memcmp(&dest->stencil_compare_mask, &src->stencil_compare_mask,
|
|
|
|
|
|
sizeof(src->stencil_compare_mask))) {
|
|
|
|
|
|
dest->stencil_compare_mask = src->stencil_compare_mask;
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
dirty |= V3DV_CMD_DIRTY_STENCIL_COMPARE_MASK;
|
2020-02-04 17:43:49 +01:00
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
if (!(dynamic_mask & V3DV_DYNAMIC_STENCIL_WRITE_MASK)) {
|
2020-02-04 17:43:49 +01:00
|
|
|
|
if (memcmp(&dest->stencil_write_mask, &src->stencil_write_mask,
|
|
|
|
|
|
sizeof(src->stencil_write_mask))) {
|
|
|
|
|
|
dest->stencil_write_mask = src->stencil_write_mask;
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
dirty |= V3DV_CMD_DIRTY_STENCIL_WRITE_MASK;
|
2020-02-04 17:43:49 +01:00
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
if (!(dynamic_mask & V3DV_DYNAMIC_STENCIL_REFERENCE)) {
|
2020-02-04 17:43:49 +01:00
|
|
|
|
if (memcmp(&dest->stencil_reference, &src->stencil_reference,
|
|
|
|
|
|
sizeof(src->stencil_reference))) {
|
|
|
|
|
|
dest->stencil_reference = src->stencil_reference;
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
dirty |= V3DV_CMD_DIRTY_STENCIL_REFERENCE;
|
2020-02-04 17:43:49 +01:00
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-03-18 11:50:47 +01:00
|
|
|
|
if (!(dynamic_mask & V3DV_DYNAMIC_BLEND_CONSTANTS)) {
|
2020-03-18 13:03:26 +01:00
|
|
|
|
if (memcmp(dest->blend_constants, src->blend_constants,
|
2020-03-18 11:50:47 +01:00
|
|
|
|
sizeof(src->blend_constants))) {
|
|
|
|
|
|
memcpy(dest->blend_constants, src->blend_constants,
|
|
|
|
|
|
sizeof(src->blend_constants));
|
|
|
|
|
|
dirty |= V3DV_CMD_DIRTY_BLEND_CONSTANTS;
|
2021-06-14 23:36:45 +02:00
|
|
|
|
}
|
2020-06-11 08:32:26 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
if (!(dynamic_mask & V3DV_DYNAMIC_DEPTH_BIAS)) {
|
|
|
|
|
|
if (memcmp(&dest->depth_bias, &src->depth_bias,
|
|
|
|
|
|
sizeof(src->depth_bias))) {
|
|
|
|
|
|
memcpy(&dest->depth_bias, &src->depth_bias, sizeof(src->depth_bias));
|
|
|
|
|
|
dirty |= V3DV_CMD_DIRTY_DEPTH_BIAS;
|
|
|
|
|
|
}
|
2020-02-04 10:26:04 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
if (!(dynamic_mask & V3DV_DYNAMIC_LINE_WIDTH)) {
|
|
|
|
|
|
if (dest->line_width != src->line_width) {
|
|
|
|
|
|
dest->line_width = src->line_width;
|
|
|
|
|
|
dirty |= V3DV_CMD_DIRTY_LINE_WIDTH;
|
|
|
|
|
|
}
|
2020-02-04 10:26:04 +01:00
|
|
|
|
}
|
2021-06-14 23:36:45 +02:00
|
|
|
|
|
2021-07-10 20:02:47 +00:00
|
|
|
|
if (!(dynamic_mask & V3DV_DYNAMIC_COLOR_WRITE_ENABLE)) {
|
|
|
|
|
|
if (dest->color_write_enable != src->color_write_enable) {
|
|
|
|
|
|
dest->color_write_enable = src->color_write_enable;
|
|
|
|
|
|
dirty |= V3DV_CMD_DIRTY_COLOR_WRITE_ENABLE;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
cmd_buffer->state.dynamic.mask = dynamic_mask;
|
|
|
|
|
|
cmd_buffer->state.dirty |= dirty;
|
2020-02-04 10:26:04 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
|
bind_graphics_pipeline(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct v3dv_pipeline *pipeline)
|
|
|
|
|
|
{
|
2020-06-18 11:06:00 +02:00
|
|
|
|
assert(pipeline && !(pipeline->active_stages & VK_SHADER_STAGE_COMPUTE_BIT));
|
2021-01-15 23:07:45 +01:00
|
|
|
|
if (cmd_buffer->state.gfx.pipeline == pipeline)
|
2020-02-04 10:26:04 +01:00
|
|
|
|
return;
|
|
|
|
|
|
|
2021-01-15 23:07:45 +01:00
|
|
|
|
cmd_buffer->state.gfx.pipeline = pipeline;
|
2020-02-04 10:26:04 +01:00
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
cmd_buffer_bind_pipeline_static_state(cmd_buffer, &pipeline->dynamic_state);
|
2020-02-04 10:26:04 +01:00
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_PIPELINE;
|
|
|
|
|
|
}
|
2019-12-18 15:38:21 +01:00
|
|
|
|
|
2020-06-18 11:06:00 +02:00
|
|
|
|
static void
|
|
|
|
|
|
bind_compute_pipeline(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct v3dv_pipeline *pipeline)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(pipeline && pipeline->active_stages == VK_SHADER_STAGE_COMPUTE_BIT);
|
|
|
|
|
|
|
2021-01-15 23:07:45 +01:00
|
|
|
|
if (cmd_buffer->state.compute.pipeline == pipeline)
|
2020-06-18 11:06:00 +02:00
|
|
|
|
return;
|
|
|
|
|
|
|
2021-01-15 23:07:45 +01:00
|
|
|
|
cmd_buffer->state.compute.pipeline = pipeline;
|
|
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_COMPUTE_PIPELINE;
|
2020-06-18 11:06:00 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2019-12-18 15:38:21 +01:00
|
|
|
|
v3dv_CmdBindPipeline(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
VkPipelineBindPoint pipelineBindPoint,
|
|
|
|
|
|
VkPipeline _pipeline)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_pipeline, pipeline, _pipeline);
|
|
|
|
|
|
|
|
|
|
|
|
switch (pipelineBindPoint) {
|
|
|
|
|
|
case VK_PIPELINE_BIND_POINT_COMPUTE:
|
2020-06-18 11:06:00 +02:00
|
|
|
|
bind_compute_pipeline(cmd_buffer, pipeline);
|
2019-12-18 15:38:21 +01:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
|
|
case VK_PIPELINE_BIND_POINT_GRAPHICS:
|
2020-02-04 10:26:04 +01:00
|
|
|
|
bind_graphics_pipeline(cmd_buffer, pipeline);
|
2019-12-18 15:38:21 +01:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
|
assert(!"invalid bind point");
|
|
|
|
|
|
break;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
2019-12-28 11:59:32 +01:00
|
|
|
|
|
2020-01-03 12:27:08 +01:00
|
|
|
|
/* FIXME: C&P from radv. tu has similar code. Perhaps common place? */
|
2020-02-03 12:55:25 +01:00
|
|
|
|
void
|
|
|
|
|
|
v3dv_viewport_compute_xform(const VkViewport *viewport,
|
|
|
|
|
|
float scale[3],
|
|
|
|
|
|
float translate[3])
|
2020-01-03 12:27:08 +01:00
|
|
|
|
{
|
|
|
|
|
|
float x = viewport->x;
|
|
|
|
|
|
float y = viewport->y;
|
|
|
|
|
|
float half_width = 0.5f * viewport->width;
|
|
|
|
|
|
float half_height = 0.5f * viewport->height;
|
|
|
|
|
|
double n = viewport->minDepth;
|
|
|
|
|
|
double f = viewport->maxDepth;
|
|
|
|
|
|
|
|
|
|
|
|
scale[0] = half_width;
|
|
|
|
|
|
translate[0] = half_width + x;
|
|
|
|
|
|
scale[1] = half_height;
|
|
|
|
|
|
translate[1] = half_height + y;
|
|
|
|
|
|
|
|
|
|
|
|
scale[2] = (f - n);
|
|
|
|
|
|
translate[2] = n;
|
2020-03-12 09:36:24 +01:00
|
|
|
|
|
|
|
|
|
|
/* It seems that if the scale is small enough the hardware won't clip
|
|
|
|
|
|
* correctly so we work around this my choosing the smallest scale that
|
|
|
|
|
|
* seems to work.
|
|
|
|
|
|
*
|
|
|
|
|
|
* This case is exercised by CTS:
|
|
|
|
|
|
* dEQP-VK.draw.inverted_depth_ranges.nodepthclamp_deltazero
|
|
|
|
|
|
*/
|
|
|
|
|
|
const float min_abs_scale = 0.000009f;
|
|
|
|
|
|
if (fabs(scale[2]) < min_abs_scale)
|
|
|
|
|
|
scale[2] = min_abs_scale * (scale[2] < 0 ? -1.0f : 1.0f);
|
2020-01-03 12:27:08 +01:00
|
|
|
|
}
|
2019-12-28 11:59:32 +01:00
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2019-12-28 11:59:32 +01:00
|
|
|
|
v3dv_CmdSetViewport(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
uint32_t firstViewport,
|
|
|
|
|
|
uint32_t viewportCount,
|
|
|
|
|
|
const VkViewport *pViewports)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
const uint32_t total_count = firstViewport + viewportCount;
|
|
|
|
|
|
|
|
|
|
|
|
assert(firstViewport < MAX_VIEWPORTS);
|
|
|
|
|
|
assert(total_count >= 1 && total_count <= MAX_VIEWPORTS);
|
|
|
|
|
|
|
2020-06-23 12:46:49 +02:00
|
|
|
|
if (state->dynamic.viewport.count < total_count)
|
|
|
|
|
|
state->dynamic.viewport.count = total_count;
|
|
|
|
|
|
|
2019-12-28 11:59:32 +01:00
|
|
|
|
if (!memcmp(state->dynamic.viewport.viewports + firstViewport,
|
|
|
|
|
|
pViewports, viewportCount * sizeof(*pViewports))) {
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
memcpy(state->dynamic.viewport.viewports + firstViewport, pViewports,
|
|
|
|
|
|
viewportCount * sizeof(*pViewports));
|
|
|
|
|
|
|
2020-06-10 12:12:21 +02:00
|
|
|
|
for (uint32_t i = firstViewport; i < total_count; i++) {
|
2020-02-03 12:55:25 +01:00
|
|
|
|
v3dv_viewport_compute_xform(&state->dynamic.viewport.viewports[i],
|
|
|
|
|
|
state->dynamic.viewport.scale[i],
|
|
|
|
|
|
state->dynamic.viewport.translate[i]);
|
2020-01-03 12:27:08 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_VIEWPORT;
|
2019-12-28 11:59:32 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_CmdSetScissor(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
uint32_t firstScissor,
|
|
|
|
|
|
uint32_t scissorCount,
|
|
|
|
|
|
const VkRect2D *pScissors)
|
2020-03-05 10:48:33 +01:00
|
|
|
|
{
|
2021-06-14 23:36:45 +02:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
2020-03-05 10:48:33 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
assert(firstScissor < MAX_SCISSORS);
|
|
|
|
|
|
assert(firstScissor + scissorCount >= 1 &&
|
|
|
|
|
|
firstScissor + scissorCount <= MAX_SCISSORS);
|
2020-03-05 10:48:33 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
if (state->dynamic.scissor.count < firstScissor + scissorCount)
|
|
|
|
|
|
state->dynamic.scissor.count = firstScissor + scissorCount;
|
|
|
|
|
|
|
|
|
|
|
|
if (!memcmp(state->dynamic.scissor.scissors + firstScissor,
|
|
|
|
|
|
pScissors, scissorCount * sizeof(*pScissors))) {
|
|
|
|
|
|
return;
|
2020-03-05 10:48:33 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
memcpy(state->dynamic.scissor.scissors + firstScissor, pScissors,
|
|
|
|
|
|
scissorCount * sizeof(*pScissors));
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_SCISSOR;
|
2020-03-05 10:48:33 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2019-12-30 13:01:44 +01:00
|
|
|
|
static void
|
2021-06-14 23:36:45 +02:00
|
|
|
|
emit_scissor(struct v3dv_cmd_buffer *cmd_buffer)
|
2020-03-18 15:53:24 +01:00
|
|
|
|
{
|
2021-06-14 23:36:45 +02:00
|
|
|
|
if (cmd_buffer->state.dynamic.viewport.count == 0)
|
|
|
|
|
|
return;
|
2020-03-24 12:18:10 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
struct v3dv_dynamic_state *dynamic = &cmd_buffer->state.dynamic;
|
2020-03-18 15:53:24 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* FIXME: right now we only support one viewport. viewporst[0] would work
|
|
|
|
|
|
* now, but would need to change if we allow multiple viewports.
|
|
|
|
|
|
*/
|
|
|
|
|
|
float *vptranslate = dynamic->viewport.translate[0];
|
|
|
|
|
|
float *vpscale = dynamic->viewport.scale[0];
|
2020-05-28 09:14:30 +02:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
float vp_minx = -fabsf(vpscale[0]) + vptranslate[0];
|
|
|
|
|
|
float vp_maxx = fabsf(vpscale[0]) + vptranslate[0];
|
|
|
|
|
|
float vp_miny = -fabsf(vpscale[1]) + vptranslate[1];
|
|
|
|
|
|
float vp_maxy = fabsf(vpscale[1]) + vptranslate[1];
|
2020-03-18 15:53:24 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* Quoting from v3dx_emit:
|
|
|
|
|
|
* "Clip to the scissor if it's enabled, but still clip to the
|
|
|
|
|
|
* drawable regardless since that controls where the binner
|
|
|
|
|
|
* tries to put things.
|
|
|
|
|
|
*
|
|
|
|
|
|
* Additionally, always clip the rendering to the viewport,
|
|
|
|
|
|
* since the hardware does guardband clipping, meaning
|
|
|
|
|
|
* primitives would rasterize outside of the view volume."
|
|
|
|
|
|
*/
|
|
|
|
|
|
uint32_t minx, miny, maxx, maxy;
|
2020-05-28 09:14:30 +02:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* From the Vulkan spec:
|
|
|
|
|
|
*
|
|
|
|
|
|
* "The application must ensure (using scissor if necessary) that all
|
|
|
|
|
|
* rendering is contained within the render area. The render area must be
|
|
|
|
|
|
* contained within the framebuffer dimensions."
|
|
|
|
|
|
*
|
|
|
|
|
|
* So it is the application's responsibility to ensure this. Still, we can
|
|
|
|
|
|
* help by automatically restricting the scissor rect to the render area.
|
|
|
|
|
|
*/
|
|
|
|
|
|
minx = MAX2(vp_minx, cmd_buffer->state.render_area.offset.x);
|
|
|
|
|
|
miny = MAX2(vp_miny, cmd_buffer->state.render_area.offset.y);
|
|
|
|
|
|
maxx = MIN2(vp_maxx, cmd_buffer->state.render_area.offset.x +
|
|
|
|
|
|
cmd_buffer->state.render_area.extent.width);
|
|
|
|
|
|
maxy = MIN2(vp_maxy, cmd_buffer->state.render_area.offset.y +
|
|
|
|
|
|
cmd_buffer->state.render_area.extent.height);
|
2020-03-18 15:53:24 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
minx = vp_minx;
|
|
|
|
|
|
miny = vp_miny;
|
|
|
|
|
|
maxx = vp_maxx;
|
|
|
|
|
|
maxy = vp_maxy;
|
2020-05-28 09:14:30 +02:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* Clip against user provided scissor if needed.
|
|
|
|
|
|
*
|
|
|
|
|
|
* FIXME: right now we only allow one scissor. Below would need to be
|
|
|
|
|
|
* updated if we support more
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (dynamic->scissor.count > 0) {
|
|
|
|
|
|
VkRect2D *scissor = &dynamic->scissor.scissors[0];
|
|
|
|
|
|
minx = MAX2(minx, scissor->offset.x);
|
|
|
|
|
|
miny = MAX2(miny, scissor->offset.y);
|
|
|
|
|
|
maxx = MIN2(maxx, scissor->offset.x + scissor->extent.width);
|
|
|
|
|
|
maxy = MIN2(maxy, scissor->offset.y + scissor->extent.height);
|
2020-03-18 15:53:24 +01:00
|
|
|
|
}
|
2020-04-21 14:05:15 +02:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
/* If the scissor is outside the viewport area we end up with
|
|
|
|
|
|
* min{x,y} > max{x,y}.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (minx > maxx)
|
|
|
|
|
|
maxx = minx;
|
|
|
|
|
|
if (miny > maxy)
|
|
|
|
|
|
maxy = miny;
|
2020-04-21 14:05:15 +02:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
cmd_buffer->state.clip_window.offset.x = minx;
|
|
|
|
|
|
cmd_buffer->state.clip_window.offset.y = miny;
|
|
|
|
|
|
cmd_buffer->state.clip_window.extent.width = maxx - minx;
|
|
|
|
|
|
cmd_buffer->state.clip_window.extent.height = maxy - miny;
|
2020-03-18 15:53:24 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, job_emit_clip_window)
|
|
|
|
|
|
(cmd_buffer->state.job, &cmd_buffer->state.clip_window);
|
2020-05-28 09:14:30 +02:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
cmd_buffer->state.dirty &= ~V3DV_CMD_DIRTY_SCISSOR;
|
2020-03-18 15:53:24 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
2021-01-15 23:07:45 +01:00
|
|
|
|
update_gfx_uniform_state(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
uint32_t dirty_uniform_state)
|
2019-12-30 13:01:44 +01:00
|
|
|
|
{
|
2021-01-05 09:02:13 +01:00
|
|
|
|
/* We need to update uniform streams if any piece of state that is passed
|
|
|
|
|
|
* to the shader as a uniform may have changed.
|
|
|
|
|
|
*
|
|
|
|
|
|
* If only descriptor sets are dirty then we can safely ignore updates
|
|
|
|
|
|
* for shader stages that don't access descriptors.
|
|
|
|
|
|
*/
|
|
|
|
|
|
|
2021-01-15 23:07:45 +01:00
|
|
|
|
struct v3dv_pipeline *pipeline = cmd_buffer->state.gfx.pipeline;
|
2019-12-30 13:01:44 +01:00
|
|
|
|
assert(pipeline);
|
|
|
|
|
|
|
2021-04-16 12:25:29 +02:00
|
|
|
|
const bool has_new_pipeline = dirty_uniform_state & V3DV_CMD_DIRTY_PIPELINE;
|
|
|
|
|
|
const bool has_new_viewport = dirty_uniform_state & V3DV_CMD_DIRTY_VIEWPORT;
|
|
|
|
|
|
const bool has_new_push_constants = dirty_uniform_state & V3DV_CMD_DIRTY_PUSH_CONSTANTS;
|
|
|
|
|
|
const bool has_new_descriptors = dirty_uniform_state & V3DV_CMD_DIRTY_DESCRIPTOR_SETS;
|
2021-07-23 09:41:14 +02:00
|
|
|
|
const bool has_new_view_index = dirty_uniform_state & V3DV_CMD_DIRTY_VIEW_INDEX;
|
2019-12-30 13:01:44 +01:00
|
|
|
|
|
2021-07-01 09:08:02 +02:00
|
|
|
|
/* VK_SHADER_STAGE_FRAGMENT_BIT */
|
2021-04-16 12:25:29 +02:00
|
|
|
|
const bool has_new_descriptors_fs =
|
|
|
|
|
|
has_new_descriptors &&
|
2021-04-16 10:14:23 +02:00
|
|
|
|
(cmd_buffer->state.dirty_descriptor_stages & VK_SHADER_STAGE_FRAGMENT_BIT);
|
2021-01-05 09:02:13 +01:00
|
|
|
|
|
2021-04-16 12:50:00 +02:00
|
|
|
|
const bool has_new_push_constants_fs =
|
|
|
|
|
|
has_new_push_constants &&
|
|
|
|
|
|
(cmd_buffer->state.dirty_push_constants_stages & VK_SHADER_STAGE_FRAGMENT_BIT);
|
2021-04-16 12:25:29 +02:00
|
|
|
|
|
|
|
|
|
|
const bool needs_fs_update = has_new_pipeline ||
|
2021-07-23 09:41:14 +02:00
|
|
|
|
has_new_view_index ||
|
2021-04-16 12:50:00 +02:00
|
|
|
|
has_new_push_constants_fs ||
|
2021-07-23 09:41:14 +02:00
|
|
|
|
has_new_descriptors_fs ||
|
|
|
|
|
|
has_new_view_index;
|
2021-04-16 12:25:29 +02:00
|
|
|
|
|
2021-01-05 09:02:13 +01:00
|
|
|
|
if (needs_fs_update) {
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
struct v3dv_shader_variant *fs_variant =
|
|
|
|
|
|
pipeline->shared_data->variants[BROADCOM_SHADER_FRAGMENT];
|
|
|
|
|
|
|
2021-01-05 09:02:13 +01:00
|
|
|
|
cmd_buffer->state.uniforms.fs =
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
v3dv_write_uniforms(cmd_buffer, pipeline, fs_variant);
|
2021-01-05 09:02:13 +01:00
|
|
|
|
}
|
2019-12-30 13:01:44 +01:00
|
|
|
|
|
2021-07-01 09:08:02 +02:00
|
|
|
|
/* VK_SHADER_STAGE_GEOMETRY_BIT */
|
|
|
|
|
|
if (pipeline->has_gs) {
|
|
|
|
|
|
const bool has_new_descriptors_gs =
|
|
|
|
|
|
has_new_descriptors &&
|
|
|
|
|
|
(cmd_buffer->state.dirty_descriptor_stages &
|
|
|
|
|
|
VK_SHADER_STAGE_GEOMETRY_BIT);
|
|
|
|
|
|
|
|
|
|
|
|
const bool has_new_push_constants_gs =
|
|
|
|
|
|
has_new_push_constants &&
|
|
|
|
|
|
(cmd_buffer->state.dirty_push_constants_stages &
|
|
|
|
|
|
VK_SHADER_STAGE_GEOMETRY_BIT);
|
|
|
|
|
|
|
|
|
|
|
|
const bool needs_gs_update = has_new_viewport ||
|
2021-07-23 09:41:14 +02:00
|
|
|
|
has_new_view_index ||
|
2021-07-01 09:08:02 +02:00
|
|
|
|
has_new_pipeline ||
|
|
|
|
|
|
has_new_push_constants_gs ||
|
|
|
|
|
|
has_new_descriptors_gs;
|
|
|
|
|
|
|
|
|
|
|
|
if (needs_gs_update) {
|
|
|
|
|
|
struct v3dv_shader_variant *gs_variant =
|
|
|
|
|
|
pipeline->shared_data->variants[BROADCOM_SHADER_GEOMETRY];
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_shader_variant *gs_bin_variant =
|
|
|
|
|
|
pipeline->shared_data->variants[BROADCOM_SHADER_GEOMETRY_BIN];
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.uniforms.gs =
|
|
|
|
|
|
v3dv_write_uniforms(cmd_buffer, pipeline, gs_variant);
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.uniforms.gs_bin =
|
|
|
|
|
|
v3dv_write_uniforms(cmd_buffer, pipeline, gs_bin_variant);
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* VK_SHADER_STAGE_VERTEX_BIT */
|
2021-04-16 12:50:00 +02:00
|
|
|
|
const bool has_new_descriptors_vs =
|
|
|
|
|
|
has_new_descriptors &&
|
|
|
|
|
|
(cmd_buffer->state.dirty_descriptor_stages & VK_SHADER_STAGE_VERTEX_BIT);
|
|
|
|
|
|
|
|
|
|
|
|
const bool has_new_push_constants_vs =
|
|
|
|
|
|
has_new_push_constants &&
|
|
|
|
|
|
(cmd_buffer->state.dirty_push_constants_stages & VK_SHADER_STAGE_VERTEX_BIT);
|
|
|
|
|
|
|
2021-04-16 12:25:29 +02:00
|
|
|
|
const bool needs_vs_update = has_new_viewport ||
|
2021-07-23 09:41:14 +02:00
|
|
|
|
has_new_view_index ||
|
2021-04-16 12:25:29 +02:00
|
|
|
|
has_new_pipeline ||
|
2021-04-16 12:50:00 +02:00
|
|
|
|
has_new_push_constants_vs ||
|
2021-04-16 12:25:29 +02:00
|
|
|
|
has_new_descriptors_vs;
|
2021-01-05 09:02:13 +01:00
|
|
|
|
|
|
|
|
|
|
if (needs_vs_update) {
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
struct v3dv_shader_variant *vs_variant =
|
|
|
|
|
|
pipeline->shared_data->variants[BROADCOM_SHADER_VERTEX];
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_shader_variant *vs_bin_variant =
|
|
|
|
|
|
pipeline->shared_data->variants[BROADCOM_SHADER_VERTEX_BIN];
|
|
|
|
|
|
|
2021-01-05 09:02:13 +01:00
|
|
|
|
cmd_buffer->state.uniforms.vs =
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
v3dv_write_uniforms(cmd_buffer, pipeline, vs_variant);
|
2021-01-05 09:02:13 +01:00
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.uniforms.vs_bin =
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
v3dv_write_uniforms(cmd_buffer, pipeline, vs_bin_variant);
|
2021-01-05 09:02:13 +01:00
|
|
|
|
}
|
2021-07-23 09:41:14 +02:00
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.dirty &= ~V3DV_CMD_DIRTY_VIEW_INDEX;
|
2020-11-19 09:45:16 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-04-21 14:01:35 +02:00
|
|
|
|
/* This stores command buffer state that we might be about to stomp for
|
|
|
|
|
|
* a meta operation.
|
2020-03-31 12:59:44 +02:00
|
|
|
|
*/
|
|
|
|
|
|
void
|
2020-04-22 08:27:58 +02:00
|
|
|
|
v3dv_cmd_buffer_meta_state_push(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
bool push_descriptor_state)
|
2020-03-31 12:59:44 +02:00
|
|
|
|
{
|
|
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
|
2020-04-21 14:01:35 +02:00
|
|
|
|
if (state->subpass_idx != -1) {
|
|
|
|
|
|
state->meta.subpass_idx = state->subpass_idx;
|
|
|
|
|
|
state->meta.framebuffer = v3dv_framebuffer_to_handle(state->framebuffer);
|
|
|
|
|
|
state->meta.pass = v3dv_render_pass_to_handle(state->pass);
|
|
|
|
|
|
|
|
|
|
|
|
const uint32_t attachment_state_item_size =
|
|
|
|
|
|
sizeof(struct v3dv_cmd_buffer_attachment_state);
|
|
|
|
|
|
const uint32_t attachment_state_total_size =
|
2020-06-02 13:13:43 +02:00
|
|
|
|
attachment_state_item_size * state->attachment_alloc_count;
|
|
|
|
|
|
if (state->meta.attachment_alloc_count < state->attachment_alloc_count) {
|
2020-04-21 14:01:35 +02:00
|
|
|
|
if (state->meta.attachment_alloc_count > 0)
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_free(&cmd_buffer->device->vk.alloc, state->meta.attachments);
|
2020-04-21 14:01:35 +02:00
|
|
|
|
|
2020-11-12 16:30:41 +01:00
|
|
|
|
state->meta.attachments = vk_zalloc(&cmd_buffer->device->vk.alloc,
|
2020-04-21 14:01:35 +02:00
|
|
|
|
attachment_state_total_size, 8,
|
|
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
if (!state->meta.attachments) {
|
|
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
2020-06-02 13:13:43 +02:00
|
|
|
|
state->meta.attachment_alloc_count = state->attachment_alloc_count;
|
2020-04-21 14:01:35 +02:00
|
|
|
|
}
|
2020-06-02 13:13:43 +02:00
|
|
|
|
state->meta.attachment_count = state->attachment_alloc_count;
|
2020-04-21 14:01:35 +02:00
|
|
|
|
memcpy(state->meta.attachments, state->attachments,
|
|
|
|
|
|
attachment_state_total_size);
|
|
|
|
|
|
|
|
|
|
|
|
state->meta.tile_aligned_render_area = state->tile_aligned_render_area;
|
|
|
|
|
|
memcpy(&state->meta.render_area, &state->render_area, sizeof(VkRect2D));
|
|
|
|
|
|
}
|
2020-04-03 09:41:45 +02:00
|
|
|
|
|
2021-01-15 23:07:45 +01:00
|
|
|
|
/* We expect that meta operations are graphics-only, so we only take into
|
|
|
|
|
|
* account the graphics pipeline, and the graphics state
|
|
|
|
|
|
*/
|
|
|
|
|
|
state->meta.gfx.pipeline = state->gfx.pipeline;
|
2020-07-23 12:45:41 +02:00
|
|
|
|
memcpy(&state->meta.dynamic, &state->dynamic, sizeof(state->dynamic));
|
2020-04-22 08:27:58 +02:00
|
|
|
|
|
2020-06-18 12:14:58 +02:00
|
|
|
|
struct v3dv_descriptor_state *gfx_descriptor_state =
|
2021-01-15 23:07:45 +01:00
|
|
|
|
&cmd_buffer->state.gfx.descriptor_state;
|
|
|
|
|
|
|
2020-06-25 09:30:04 +02:00
|
|
|
|
if (push_descriptor_state) {
|
|
|
|
|
|
if (gfx_descriptor_state->valid != 0) {
|
2021-01-15 23:07:45 +01:00
|
|
|
|
memcpy(&state->meta.gfx.descriptor_state, gfx_descriptor_state,
|
|
|
|
|
|
sizeof(state->gfx.descriptor_state));
|
2020-06-25 09:30:04 +02:00
|
|
|
|
}
|
|
|
|
|
|
state->meta.has_descriptor_state = true;
|
|
|
|
|
|
} else {
|
|
|
|
|
|
state->meta.has_descriptor_state = false;
|
2020-04-22 08:27:58 +02:00
|
|
|
|
}
|
2020-04-22 09:26:27 +02:00
|
|
|
|
|
|
|
|
|
|
/* FIXME: if we keep track of wether we have bound any push constant state
|
|
|
|
|
|
* at all we could restruct this only to cases where it is actually
|
|
|
|
|
|
* necessary.
|
|
|
|
|
|
*/
|
|
|
|
|
|
memcpy(state->meta.push_constants, cmd_buffer->push_constants_data,
|
|
|
|
|
|
sizeof(state->meta.push_constants));
|
2020-03-31 12:59:44 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-04-21 14:01:35 +02:00
|
|
|
|
/* This restores command buffer state after a meta operation
|
2020-03-31 12:59:44 +02:00
|
|
|
|
*/
|
|
|
|
|
|
void
|
2020-04-03 09:41:45 +02:00
|
|
|
|
v3dv_cmd_buffer_meta_state_pop(struct v3dv_cmd_buffer *cmd_buffer,
|
2020-07-16 12:34:30 +02:00
|
|
|
|
uint32_t dirty_dynamic_state,
|
|
|
|
|
|
bool needs_subpass_resume)
|
2020-03-31 12:59:44 +02:00
|
|
|
|
{
|
|
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
|
2020-04-21 14:01:35 +02:00
|
|
|
|
if (state->meta.subpass_idx != -1) {
|
|
|
|
|
|
state->pass = v3dv_render_pass_from_handle(state->meta.pass);
|
|
|
|
|
|
state->framebuffer = v3dv_framebuffer_from_handle(state->meta.framebuffer);
|
2020-03-31 12:59:44 +02:00
|
|
|
|
|
2020-06-02 13:13:43 +02:00
|
|
|
|
assert(state->meta.attachment_count <= state->attachment_alloc_count);
|
2020-04-21 14:01:35 +02:00
|
|
|
|
const uint32_t attachment_state_item_size =
|
|
|
|
|
|
sizeof(struct v3dv_cmd_buffer_attachment_state);
|
|
|
|
|
|
const uint32_t attachment_state_total_size =
|
|
|
|
|
|
attachment_state_item_size * state->meta.attachment_count;
|
|
|
|
|
|
memcpy(state->attachments, state->meta.attachments,
|
|
|
|
|
|
attachment_state_total_size);
|
2020-04-03 09:41:45 +02:00
|
|
|
|
|
2020-04-21 14:01:35 +02:00
|
|
|
|
state->tile_aligned_render_area = state->meta.tile_aligned_render_area;
|
|
|
|
|
|
memcpy(&state->render_area, &state->meta.render_area, sizeof(VkRect2D));
|
2020-04-03 09:41:45 +02:00
|
|
|
|
|
2020-07-16 12:34:30 +02:00
|
|
|
|
/* Is needs_subpass_resume is true it means that the emitted the meta
|
|
|
|
|
|
* operation in its own job (possibly with an RT config that is
|
|
|
|
|
|
* incompatible with the current subpass), so resuming subpass execution
|
|
|
|
|
|
* after it requires that we create a new job with the subpass RT setup.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (needs_subpass_resume)
|
|
|
|
|
|
v3dv_cmd_buffer_subpass_resume(cmd_buffer, state->meta.subpass_idx);
|
2020-03-31 12:59:44 +02:00
|
|
|
|
} else {
|
|
|
|
|
|
state->subpass_idx = -1;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-01-15 23:07:45 +01:00
|
|
|
|
if (state->meta.gfx.pipeline != NULL) {
|
|
|
|
|
|
struct v3dv_pipeline *pipeline = state->meta.gfx.pipeline;
|
2020-06-18 12:14:58 +02:00
|
|
|
|
VkPipelineBindPoint pipeline_binding =
|
|
|
|
|
|
v3dv_pipeline_get_binding_point(pipeline);
|
2020-04-21 14:01:35 +02:00
|
|
|
|
v3dv_CmdBindPipeline(v3dv_cmd_buffer_to_handle(cmd_buffer),
|
2020-06-18 12:14:58 +02:00
|
|
|
|
pipeline_binding,
|
2021-01-15 23:07:45 +01:00
|
|
|
|
v3dv_pipeline_to_handle(state->meta.gfx.pipeline));
|
2020-04-21 14:01:35 +02:00
|
|
|
|
} else {
|
2021-01-15 23:07:45 +01:00
|
|
|
|
state->gfx.pipeline = NULL;
|
2020-04-21 14:01:35 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-07-23 12:45:41 +02:00
|
|
|
|
if (dirty_dynamic_state) {
|
|
|
|
|
|
memcpy(&state->dynamic, &state->meta.dynamic, sizeof(state->dynamic));
|
|
|
|
|
|
state->dirty |= dirty_dynamic_state;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-06-25 09:30:04 +02:00
|
|
|
|
if (state->meta.has_descriptor_state) {
|
2021-01-15 23:07:45 +01:00
|
|
|
|
if (state->meta.gfx.descriptor_state.valid != 0) {
|
|
|
|
|
|
memcpy(&state->gfx.descriptor_state, &state->meta.gfx.descriptor_state,
|
|
|
|
|
|
sizeof(state->gfx.descriptor_state));
|
2020-06-25 09:30:04 +02:00
|
|
|
|
} else {
|
2021-01-15 23:07:45 +01:00
|
|
|
|
state->gfx.descriptor_state.valid = 0;
|
2020-06-25 09:30:04 +02:00
|
|
|
|
}
|
2020-04-22 08:27:58 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-04-22 09:26:27 +02:00
|
|
|
|
memcpy(cmd_buffer->push_constants_data, state->meta.push_constants,
|
|
|
|
|
|
sizeof(state->meta.push_constants));
|
|
|
|
|
|
|
2021-01-15 23:07:45 +01:00
|
|
|
|
state->meta.gfx.pipeline = NULL;
|
2020-03-31 12:59:44 +02:00
|
|
|
|
state->meta.framebuffer = VK_NULL_HANDLE;
|
|
|
|
|
|
state->meta.pass = VK_NULL_HANDLE;
|
|
|
|
|
|
state->meta.subpass_idx = -1;
|
2020-06-25 09:30:04 +02:00
|
|
|
|
state->meta.has_descriptor_state = false;
|
2020-03-31 12:59:44 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-03-18 10:00:31 +01:00
|
|
|
|
static struct v3dv_job *
|
|
|
|
|
|
cmd_buffer_pre_draw_split_job(struct v3dv_cmd_buffer *cmd_buffer)
|
|
|
|
|
|
{
|
|
|
|
|
|
struct v3dv_job *job = cmd_buffer->state.job;
|
v3dv: handle multisample rasterization with empty framebuffers
If the framebuffer has no attachments then multisample rasterization
is enabled based on the rasterizationSamples multisample state of
the pipelines. It should be noted that since we don't support
the variableMultisampleRate feature, all pipelines in the same
subpass must have matching number of samples.
V3D requires that we specifically setup our frames to enable
multisampling or not, and we do this when we create jobs inside
a subpass. Since we create the first job for a subpass as soon as
the subpas starts, this is problematic: if we don't have any
attachments, we don't won't enable MSAA at this point, but later
on we might bind an MSAA pipeline, since pipelines can be bound
at any point in the lifespan of a command buffer.
Here, we fix this by testing if the first draw call in a job uses
an MSAA pipeline but the job the was setup to not use MSAA, and in
that case we re-start the job with MSAA enabled.
We also take care of a corner case that seems to be tested by CTS
where a framebuffer with no attachments doesn't bind any pipelines
with MSAA enabled (so according to the Vulkan spec, multisample
rasterization must be disabled) but the fragment shader in use
reads gl_SampleID (which enables per-sample shading). This would
lead to enabling per-sample shading with single-sample rasterization,
which doesn't make sense and makes the simulator complain, so we just
disable per-sample shading in that case.
Fixes:
dEQP-VK.pipeline.multisample.mixed_count.*
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-08-04 13:11:10 +02:00
|
|
|
|
assert(job);
|
2020-03-18 10:00:31 +01:00
|
|
|
|
|
|
|
|
|
|
/* If the job has been flagged with 'always_flush' and it has already
|
|
|
|
|
|
* recorded any draw calls then we need to start a new job for it.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (job->always_flush && job->draw_count > 0) {
|
|
|
|
|
|
assert(cmd_buffer->state.pass);
|
|
|
|
|
|
/* First, flag the current job as not being the last in the
|
|
|
|
|
|
* current subpass
|
|
|
|
|
|
*/
|
|
|
|
|
|
job->is_subpass_finish = false;
|
|
|
|
|
|
|
|
|
|
|
|
/* Now start a new job in the same subpass and flag it as continuing
|
|
|
|
|
|
* the current subpass.
|
|
|
|
|
|
*/
|
2020-04-03 14:19:40 +02:00
|
|
|
|
job = v3dv_cmd_buffer_subpass_resume(cmd_buffer,
|
|
|
|
|
|
cmd_buffer->state.subpass_idx);
|
2020-03-18 10:00:31 +01:00
|
|
|
|
assert(job->draw_count == 0);
|
|
|
|
|
|
|
|
|
|
|
|
/* Inherit the 'always flush' behavior */
|
|
|
|
|
|
job->always_flush = true;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
assert(job->draw_count == 0 || !job->always_flush);
|
|
|
|
|
|
return job;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
v3dv: handle multisample rasterization with empty framebuffers
If the framebuffer has no attachments then multisample rasterization
is enabled based on the rasterizationSamples multisample state of
the pipelines. It should be noted that since we don't support
the variableMultisampleRate feature, all pipelines in the same
subpass must have matching number of samples.
V3D requires that we specifically setup our frames to enable
multisampling or not, and we do this when we create jobs inside
a subpass. Since we create the first job for a subpass as soon as
the subpas starts, this is problematic: if we don't have any
attachments, we don't won't enable MSAA at this point, but later
on we might bind an MSAA pipeline, since pipelines can be bound
at any point in the lifespan of a command buffer.
Here, we fix this by testing if the first draw call in a job uses
an MSAA pipeline but the job the was setup to not use MSAA, and in
that case we re-start the job with MSAA enabled.
We also take care of a corner case that seems to be tested by CTS
where a framebuffer with no attachments doesn't bind any pipelines
with MSAA enabled (so according to the Vulkan spec, multisample
rasterization must be disabled) but the fragment shader in use
reads gl_SampleID (which enables per-sample shading). This would
lead to enabling per-sample shading with single-sample rasterization,
which doesn't make sense and makes the simulator complain, so we just
disable per-sample shading in that case.
Fixes:
dEQP-VK.pipeline.multisample.mixed_count.*
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-08-04 13:11:10 +02:00
|
|
|
|
/**
|
|
|
|
|
|
* The Vulkan spec states:
|
|
|
|
|
|
*
|
|
|
|
|
|
* "It is legal for a subpass to use no color or depth/stencil
|
|
|
|
|
|
* attachments (...) This kind of subpass can use shader side effects such
|
|
|
|
|
|
* as image stores and atomics to produce an output. In this case, the
|
|
|
|
|
|
* subpass continues to use the width, height, and layers of the framebuffer
|
|
|
|
|
|
* to define the dimensions of the rendering area, and the
|
|
|
|
|
|
* rasterizationSamples from each pipeline’s
|
|
|
|
|
|
* VkPipelineMultisampleStateCreateInfo to define the number of samples used
|
|
|
|
|
|
* in rasterization."
|
|
|
|
|
|
*
|
|
|
|
|
|
* We need to enable MSAA in the TILE_BINNING_MODE_CFG packet, which we
|
|
|
|
|
|
* emit when we start a new frame at the begining of a subpass. At that point,
|
|
|
|
|
|
* if the framebuffer doesn't have any attachments we won't enable MSAA and
|
|
|
|
|
|
* the job won't be valid in the scenario described by the spec.
|
|
|
|
|
|
*
|
|
|
|
|
|
* This function is intended to be called before a draw call and will test if
|
|
|
|
|
|
* we are in that scenario, in which case, it will restart the current job
|
|
|
|
|
|
* with MSAA enabled.
|
|
|
|
|
|
*/
|
|
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_restart_job_for_msaa_if_needed(struct v3dv_cmd_buffer *cmd_buffer)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(cmd_buffer->state.job);
|
|
|
|
|
|
|
|
|
|
|
|
/* We don't support variableMultisampleRate so we know that all pipelines
|
|
|
|
|
|
* bound in the same subpass must have matching number of samples, so we
|
|
|
|
|
|
* can do this check only on the first draw call.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (cmd_buffer->state.job->draw_count > 0)
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
|
|
/* We only need to restart the frame if the pipeline requires MSAA but
|
|
|
|
|
|
* our frame tiling didn't enable it.
|
|
|
|
|
|
*/
|
2021-01-15 23:07:45 +01:00
|
|
|
|
if (!cmd_buffer->state.gfx.pipeline->msaa ||
|
v3dv: handle multisample rasterization with empty framebuffers
If the framebuffer has no attachments then multisample rasterization
is enabled based on the rasterizationSamples multisample state of
the pipelines. It should be noted that since we don't support
the variableMultisampleRate feature, all pipelines in the same
subpass must have matching number of samples.
V3D requires that we specifically setup our frames to enable
multisampling or not, and we do this when we create jobs inside
a subpass. Since we create the first job for a subpass as soon as
the subpas starts, this is problematic: if we don't have any
attachments, we don't won't enable MSAA at this point, but later
on we might bind an MSAA pipeline, since pipelines can be bound
at any point in the lifespan of a command buffer.
Here, we fix this by testing if the first draw call in a job uses
an MSAA pipeline but the job the was setup to not use MSAA, and in
that case we re-start the job with MSAA enabled.
We also take care of a corner case that seems to be tested by CTS
where a framebuffer with no attachments doesn't bind any pipelines
with MSAA enabled (so according to the Vulkan spec, multisample
rasterization must be disabled) but the fragment shader in use
reads gl_SampleID (which enables per-sample shading). This would
lead to enabling per-sample shading with single-sample rasterization,
which doesn't make sense and makes the simulator complain, so we just
disable per-sample shading in that case.
Fixes:
dEQP-VK.pipeline.multisample.mixed_count.*
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-08-04 13:11:10 +02:00
|
|
|
|
cmd_buffer->state.job->frame_tiling.msaa) {
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* FIXME: Secondary command buffers don't start frames. Instead, they are
|
|
|
|
|
|
* recorded into primary jobs that start them. For secondaries, we should
|
|
|
|
|
|
* still handle this scenario, but we should do that when we record them
|
|
|
|
|
|
* into primaries by testing if any of the secondaries has multisampled
|
|
|
|
|
|
* draw calls in them, and then using that info to decide if we need to
|
|
|
|
|
|
* restart the primary job into which they are being recorded.
|
|
|
|
|
|
*/
|
2021-12-14 15:42:14 +01:00
|
|
|
|
if (cmd_buffer->vk.level != VK_COMMAND_BUFFER_LEVEL_PRIMARY)
|
v3dv: handle multisample rasterization with empty framebuffers
If the framebuffer has no attachments then multisample rasterization
is enabled based on the rasterizationSamples multisample state of
the pipelines. It should be noted that since we don't support
the variableMultisampleRate feature, all pipelines in the same
subpass must have matching number of samples.
V3D requires that we specifically setup our frames to enable
multisampling or not, and we do this when we create jobs inside
a subpass. Since we create the first job for a subpass as soon as
the subpas starts, this is problematic: if we don't have any
attachments, we don't won't enable MSAA at this point, but later
on we might bind an MSAA pipeline, since pipelines can be bound
at any point in the lifespan of a command buffer.
Here, we fix this by testing if the first draw call in a job uses
an MSAA pipeline but the job the was setup to not use MSAA, and in
that case we re-start the job with MSAA enabled.
We also take care of a corner case that seems to be tested by CTS
where a framebuffer with no attachments doesn't bind any pipelines
with MSAA enabled (so according to the Vulkan spec, multisample
rasterization must be disabled) but the fragment shader in use
reads gl_SampleID (which enables per-sample shading). This would
lead to enabling per-sample shading with single-sample rasterization,
which doesn't make sense and makes the simulator complain, so we just
disable per-sample shading in that case.
Fixes:
dEQP-VK.pipeline.multisample.mixed_count.*
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-08-04 13:11:10 +02:00
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
|
|
/* Drop the current job and restart it with MSAA enabled */
|
|
|
|
|
|
struct v3dv_job *old_job = cmd_buffer->state.job;
|
|
|
|
|
|
cmd_buffer->state.job = NULL;
|
|
|
|
|
|
|
2020-11-12 16:30:41 +01:00
|
|
|
|
struct v3dv_job *job = vk_zalloc(&cmd_buffer->device->vk.alloc,
|
v3dv: handle multisample rasterization with empty framebuffers
If the framebuffer has no attachments then multisample rasterization
is enabled based on the rasterizationSamples multisample state of
the pipelines. It should be noted that since we don't support
the variableMultisampleRate feature, all pipelines in the same
subpass must have matching number of samples.
V3D requires that we specifically setup our frames to enable
multisampling or not, and we do this when we create jobs inside
a subpass. Since we create the first job for a subpass as soon as
the subpas starts, this is problematic: if we don't have any
attachments, we don't won't enable MSAA at this point, but later
on we might bind an MSAA pipeline, since pipelines can be bound
at any point in the lifespan of a command buffer.
Here, we fix this by testing if the first draw call in a job uses
an MSAA pipeline but the job the was setup to not use MSAA, and in
that case we re-start the job with MSAA enabled.
We also take care of a corner case that seems to be tested by CTS
where a framebuffer with no attachments doesn't bind any pipelines
with MSAA enabled (so according to the Vulkan spec, multisample
rasterization must be disabled) but the fragment shader in use
reads gl_SampleID (which enables per-sample shading). This would
lead to enabling per-sample shading with single-sample rasterization,
which doesn't make sense and makes the simulator complain, so we just
disable per-sample shading in that case.
Fixes:
dEQP-VK.pipeline.multisample.mixed_count.*
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-08-04 13:11:10 +02:00
|
|
|
|
sizeof(struct v3dv_job), 8,
|
|
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
|
|
|
|
|
if (!job) {
|
|
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
v3dv_job_init(job, V3DV_JOB_TYPE_GPU_CL, cmd_buffer->device, cmd_buffer,
|
|
|
|
|
|
cmd_buffer->state.subpass_idx);
|
|
|
|
|
|
cmd_buffer->state.job = job;
|
|
|
|
|
|
|
|
|
|
|
|
v3dv_job_start_frame(job,
|
|
|
|
|
|
old_job->frame_tiling.width,
|
|
|
|
|
|
old_job->frame_tiling.height,
|
|
|
|
|
|
old_job->frame_tiling.layers,
|
2021-07-16 08:23:11 +02:00
|
|
|
|
true,
|
v3dv: handle multisample rasterization with empty framebuffers
If the framebuffer has no attachments then multisample rasterization
is enabled based on the rasterizationSamples multisample state of
the pipelines. It should be noted that since we don't support
the variableMultisampleRate feature, all pipelines in the same
subpass must have matching number of samples.
V3D requires that we specifically setup our frames to enable
multisampling or not, and we do this when we create jobs inside
a subpass. Since we create the first job for a subpass as soon as
the subpas starts, this is problematic: if we don't have any
attachments, we don't won't enable MSAA at this point, but later
on we might bind an MSAA pipeline, since pipelines can be bound
at any point in the lifespan of a command buffer.
Here, we fix this by testing if the first draw call in a job uses
an MSAA pipeline but the job the was setup to not use MSAA, and in
that case we re-start the job with MSAA enabled.
We also take care of a corner case that seems to be tested by CTS
where a framebuffer with no attachments doesn't bind any pipelines
with MSAA enabled (so according to the Vulkan spec, multisample
rasterization must be disabled) but the fragment shader in use
reads gl_SampleID (which enables per-sample shading). This would
lead to enabling per-sample shading with single-sample rasterization,
which doesn't make sense and makes the simulator complain, so we just
disable per-sample shading in that case.
Fixes:
dEQP-VK.pipeline.multisample.mixed_count.*
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-08-04 13:11:10 +02:00
|
|
|
|
old_job->frame_tiling.render_target_count,
|
|
|
|
|
|
old_job->frame_tiling.internal_bpp,
|
|
|
|
|
|
true /* msaa */);
|
|
|
|
|
|
|
|
|
|
|
|
v3dv_job_destroy(old_job);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2022-05-03 09:05:19 +02:00
|
|
|
|
static bool
|
|
|
|
|
|
cmd_buffer_binning_sync_required(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct v3dv_pipeline *pipeline,
|
|
|
|
|
|
bool indexed, bool indirect)
|
|
|
|
|
|
{
|
|
|
|
|
|
const struct v3dv_descriptor_maps *vs_bin_maps =
|
|
|
|
|
|
pipeline->shared_data->maps[BROADCOM_SHADER_VERTEX_BIN];
|
|
|
|
|
|
|
|
|
|
|
|
const struct v3dv_descriptor_maps *gs_bin_maps =
|
|
|
|
|
|
pipeline->shared_data->maps[BROADCOM_SHADER_GEOMETRY_BIN];
|
|
|
|
|
|
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
VkAccessFlags buffer_access =
|
2022-05-30 08:31:17 +02:00
|
|
|
|
cmd_buffer->state.barrier.bcl_buffer_access;
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
if (buffer_access) {
|
2022-05-03 09:05:19 +02:00
|
|
|
|
/* Index buffer read */
|
|
|
|
|
|
if (indexed && (buffer_access & VK_ACCESS_INDEX_READ_BIT))
|
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
|
|
/* Indirect buffer read */
|
|
|
|
|
|
if (indirect && (buffer_access & VK_ACCESS_INDIRECT_COMMAND_READ_BIT))
|
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
|
|
/* Attribute read */
|
|
|
|
|
|
if (buffer_access & VK_ACCESS_VERTEX_ATTRIBUTE_READ_BIT) {
|
|
|
|
|
|
const struct v3d_vs_prog_data *prog_data =
|
|
|
|
|
|
pipeline->shared_data->variants[BROADCOM_SHADER_VERTEX_BIN]->prog_data.vs;
|
|
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i < ARRAY_SIZE(prog_data->vattr_sizes); i++) {
|
|
|
|
|
|
if (prog_data->vattr_sizes[i] > 0)
|
|
|
|
|
|
return true;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* UBO / SSBO read */
|
|
|
|
|
|
if (buffer_access & (VK_ACCESS_UNIFORM_READ_BIT |
|
|
|
|
|
|
VK_ACCESS_SHADER_READ_BIT |
|
|
|
|
|
|
VK_ACCESS_MEMORY_READ_BIT)) {
|
|
|
|
|
|
|
|
|
|
|
|
if (vs_bin_maps->ubo_map.num_desc > 0 ||
|
|
|
|
|
|
vs_bin_maps->ssbo_map.num_desc > 0) {
|
|
|
|
|
|
return true;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (gs_bin_maps && (gs_bin_maps->ubo_map.num_desc > 0 ||
|
|
|
|
|
|
gs_bin_maps->ssbo_map.num_desc > 0)) {
|
|
|
|
|
|
return true;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* SSBO write */
|
|
|
|
|
|
if (buffer_access & (VK_ACCESS_SHADER_WRITE_BIT |
|
|
|
|
|
|
VK_ACCESS_MEMORY_WRITE_BIT)) {
|
|
|
|
|
|
if (vs_bin_maps->ssbo_map.num_desc > 0)
|
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
|
|
if (gs_bin_maps && gs_bin_maps->ssbo_map.num_desc > 0)
|
|
|
|
|
|
return true;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
VkAccessFlags image_access =
|
2022-05-30 08:31:17 +02:00
|
|
|
|
cmd_buffer->state.barrier.bcl_image_access;
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
if (image_access) {
|
2022-05-03 09:05:19 +02:00
|
|
|
|
/* Image load / store */
|
|
|
|
|
|
if (image_access & (VK_ACCESS_SHADER_READ_BIT |
|
|
|
|
|
|
VK_ACCESS_SHADER_WRITE_BIT |
|
|
|
|
|
|
VK_ACCESS_MEMORY_READ_BIT |
|
|
|
|
|
|
VK_ACCESS_MEMORY_WRITE_BIT)) {
|
|
|
|
|
|
if (vs_bin_maps->texture_map.num_desc > 0 ||
|
|
|
|
|
|
vs_bin_maps->sampler_map.num_desc > 0) {
|
|
|
|
|
|
return true;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
|
consume_bcl_sync(struct v3dv_cmd_buffer *cmd_buffer, struct v3dv_job *job)
|
|
|
|
|
|
{
|
|
|
|
|
|
job->needs_bcl_sync = true;
|
2022-05-30 08:31:17 +02:00
|
|
|
|
cmd_buffer->state.barrier.bcl_buffer_access = 0;
|
|
|
|
|
|
cmd_buffer->state.barrier.bcl_image_access = 0;
|
2022-05-03 09:05:19 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
void
|
2022-05-03 09:05:19 +02:00
|
|
|
|
v3dv_cmd_buffer_emit_pre_draw(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
bool indexed, bool indirect)
|
2019-12-28 11:42:53 +01:00
|
|
|
|
{
|
2021-06-14 22:54:26 +01:00
|
|
|
|
assert(cmd_buffer->state.gfx.pipeline);
|
|
|
|
|
|
assert(!(cmd_buffer->state.gfx.pipeline->active_stages & VK_SHADER_STAGE_COMPUTE_BIT));
|
2020-06-18 11:06:00 +02:00
|
|
|
|
|
v3dv: handle multisample rasterization with empty framebuffers
If the framebuffer has no attachments then multisample rasterization
is enabled based on the rasterizationSamples multisample state of
the pipelines. It should be noted that since we don't support
the variableMultisampleRate feature, all pipelines in the same
subpass must have matching number of samples.
V3D requires that we specifically setup our frames to enable
multisampling or not, and we do this when we create jobs inside
a subpass. Since we create the first job for a subpass as soon as
the subpas starts, this is problematic: if we don't have any
attachments, we don't won't enable MSAA at this point, but later
on we might bind an MSAA pipeline, since pipelines can be bound
at any point in the lifespan of a command buffer.
Here, we fix this by testing if the first draw call in a job uses
an MSAA pipeline but the job the was setup to not use MSAA, and in
that case we re-start the job with MSAA enabled.
We also take care of a corner case that seems to be tested by CTS
where a framebuffer with no attachments doesn't bind any pipelines
with MSAA enabled (so according to the Vulkan spec, multisample
rasterization must be disabled) but the fragment shader in use
reads gl_SampleID (which enables per-sample shading). This would
lead to enabling per-sample shading with single-sample rasterization,
which doesn't make sense and makes the simulator complain, so we just
disable per-sample shading in that case.
Fixes:
dEQP-VK.pipeline.multisample.mixed_count.*
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-08-04 13:11:10 +02:00
|
|
|
|
/* If we emitted a pipeline barrier right before this draw we won't have
|
|
|
|
|
|
* an active job. In that case, create a new job continuing the current
|
|
|
|
|
|
* subpass.
|
|
|
|
|
|
*/
|
2021-03-30 11:00:01 +02:00
|
|
|
|
if (!cmd_buffer->state.job) {
|
|
|
|
|
|
v3dv_cmd_buffer_subpass_resume(cmd_buffer,
|
|
|
|
|
|
cmd_buffer->state.subpass_idx);
|
v3dv: handle multisample rasterization with empty framebuffers
If the framebuffer has no attachments then multisample rasterization
is enabled based on the rasterizationSamples multisample state of
the pipelines. It should be noted that since we don't support
the variableMultisampleRate feature, all pipelines in the same
subpass must have matching number of samples.
V3D requires that we specifically setup our frames to enable
multisampling or not, and we do this when we create jobs inside
a subpass. Since we create the first job for a subpass as soon as
the subpas starts, this is problematic: if we don't have any
attachments, we don't won't enable MSAA at this point, but later
on we might bind an MSAA pipeline, since pipelines can be bound
at any point in the lifespan of a command buffer.
Here, we fix this by testing if the first draw call in a job uses
an MSAA pipeline but the job the was setup to not use MSAA, and in
that case we re-start the job with MSAA enabled.
We also take care of a corner case that seems to be tested by CTS
where a framebuffer with no attachments doesn't bind any pipelines
with MSAA enabled (so according to the Vulkan spec, multisample
rasterization must be disabled) but the fragment shader in use
reads gl_SampleID (which enables per-sample shading). This would
lead to enabling per-sample shading with single-sample rasterization,
which doesn't make sense and makes the simulator complain, so we just
disable per-sample shading in that case.
Fixes:
dEQP-VK.pipeline.multisample.mixed_count.*
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-08-04 13:11:10 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Restart single sample job for MSAA pipeline if needed */
|
|
|
|
|
|
cmd_buffer_restart_job_for_msaa_if_needed(cmd_buffer);
|
|
|
|
|
|
|
2020-03-18 10:00:31 +01:00
|
|
|
|
/* If the job is configured to flush on every draw call we need to create
|
|
|
|
|
|
* a new job now.
|
|
|
|
|
|
*/
|
2021-03-30 11:00:01 +02:00
|
|
|
|
struct v3dv_job *job = cmd_buffer_pre_draw_split_job(cmd_buffer);
|
2020-03-18 10:00:31 +01:00
|
|
|
|
job->draw_count++;
|
|
|
|
|
|
|
2022-05-03 09:05:19 +02:00
|
|
|
|
/* If this job is serialized (has consumed a barrier) then check if we need
|
|
|
|
|
|
* to sync at the binning stage by testing if the binning shaders involved
|
|
|
|
|
|
* with the draw call require access to external resources.
|
|
|
|
|
|
*/
|
2022-05-30 08:31:17 +02:00
|
|
|
|
if (job->serialize && (cmd_buffer->state.barrier.bcl_buffer_access ||
|
|
|
|
|
|
cmd_buffer->state.barrier.bcl_image_access)) {
|
2022-05-03 09:05:19 +02:00
|
|
|
|
assert(!job->needs_bcl_sync);
|
|
|
|
|
|
struct v3dv_pipeline *pipeline = cmd_buffer->state.gfx.pipeline;
|
|
|
|
|
|
if (cmd_buffer_binning_sync_required(cmd_buffer, pipeline,
|
|
|
|
|
|
indexed, indirect)) {
|
|
|
|
|
|
consume_bcl_sync(cmd_buffer, job);
|
|
|
|
|
|
}
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
/* FIXME: clear bc flags whether consumed bcl barrier or not? */
|
2022-05-03 09:05:19 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-06-11 11:59:24 +02:00
|
|
|
|
/* GL shader state binds shaders, uniform and vertex attribute state. The
|
|
|
|
|
|
* compiler injects uniforms to handle some descriptor types (such as
|
|
|
|
|
|
* textures), so we need to regen that when descriptor state changes.
|
2020-07-17 12:28:46 +02:00
|
|
|
|
*
|
|
|
|
|
|
* We also need to emit new shader state if we have a dirty viewport since
|
|
|
|
|
|
* that will require that we new uniform state for QUNIFORM_VIEWPORT_*.
|
2020-06-11 11:59:24 +02:00
|
|
|
|
*/
|
v3dv: cleanup/remove support for pre-generated variants
In preparation to the changes that would allow to not need them.
It is worth to note that it is likely (we have some ideas in mind)
that we would need to bring back pre-generate variants on the
future. The approach is slightly different on v3dv_pipeline vs
v3dv_cmd_buffer:
* v3dv_pipeline: even after the clean-up, we had code for all the
functions they have, even if they were doing less things
(specifically, a second shader variant), so they still make sense
on their own, and serve as template for adding support of multiple
pre-generated shader variants in the future.
* v3dv_cmd_buffer: as we really don't need to fill up the key with
some after-pipeline data, we would end with some functions empty
(specifically cmd_buffer_populate_v3d_key). Even as a placeholder,
that would be odd. Additionally the current code has a lot of
boilerplate code (functions to fill up vs, cs and fs keys are
basically the same), and we already have in mind refactor them. So
it would be better to remove all of them, instead of keeping
around some code we would not be happy with. If in the future we
pregenerate more that one variant, hopefully the new code to chose
between them would be better.
v2: clarify the commit message, and fix typos on the comments (Iago)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7545>
2020-11-10 22:31:05 +01:00
|
|
|
|
uint32_t *dirty = &cmd_buffer->state.dirty;
|
2020-11-19 09:45:16 +01:00
|
|
|
|
|
2021-01-05 09:02:13 +01:00
|
|
|
|
const uint32_t dirty_uniform_state =
|
|
|
|
|
|
*dirty & (V3DV_CMD_DIRTY_PIPELINE |
|
|
|
|
|
|
V3DV_CMD_DIRTY_PUSH_CONSTANTS |
|
|
|
|
|
|
V3DV_CMD_DIRTY_DESCRIPTOR_SETS |
|
2021-07-23 09:41:14 +02:00
|
|
|
|
V3DV_CMD_DIRTY_VIEWPORT |
|
|
|
|
|
|
V3DV_CMD_DIRTY_VIEW_INDEX);
|
2021-01-05 09:02:13 +01:00
|
|
|
|
|
|
|
|
|
|
if (dirty_uniform_state)
|
2021-01-15 23:07:45 +01:00
|
|
|
|
update_gfx_uniform_state(cmd_buffer, dirty_uniform_state);
|
2020-11-19 09:45:16 +01:00
|
|
|
|
|
2021-06-14 23:36:45 +02:00
|
|
|
|
struct v3dv_device *device = cmd_buffer->device;
|
|
|
|
|
|
|
2021-01-05 09:02:13 +01:00
|
|
|
|
if (dirty_uniform_state || (*dirty & V3DV_CMD_DIRTY_VERTEX_BUFFER))
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(device, cmd_buffer_emit_gl_shader_state)(cmd_buffer);
|
2020-03-19 08:19:39 +01:00
|
|
|
|
|
|
|
|
|
|
if (*dirty & (V3DV_CMD_DIRTY_PIPELINE)) {
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(device, cmd_buffer_emit_configuration_bits)(cmd_buffer);
|
|
|
|
|
|
v3dv_X(device, cmd_buffer_emit_varyings_state)(cmd_buffer);
|
2019-12-30 13:01:44 +01:00
|
|
|
|
}
|
2019-12-28 11:42:53 +01:00
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
if (*dirty & (V3DV_CMD_DIRTY_VIEWPORT | V3DV_CMD_DIRTY_SCISSOR)) {
|
2019-12-28 11:42:53 +01:00
|
|
|
|
emit_scissor(cmd_buffer);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
if (*dirty & V3DV_CMD_DIRTY_VIEWPORT) {
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(device, cmd_buffer_emit_viewport)(cmd_buffer);
|
2019-12-27 16:13:31 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-04-09 10:47:51 +02:00
|
|
|
|
if (*dirty & V3DV_CMD_DIRTY_INDEX_BUFFER)
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(device, cmd_buffer_emit_index_buffer)(cmd_buffer);
|
2021-04-09 10:47:51 +02:00
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
const uint32_t dynamic_stencil_dirty_flags =
|
|
|
|
|
|
V3DV_CMD_DIRTY_STENCIL_COMPARE_MASK |
|
|
|
|
|
|
V3DV_CMD_DIRTY_STENCIL_WRITE_MASK |
|
|
|
|
|
|
V3DV_CMD_DIRTY_STENCIL_REFERENCE;
|
2020-03-18 16:52:17 +01:00
|
|
|
|
if (*dirty & (V3DV_CMD_DIRTY_PIPELINE | dynamic_stencil_dirty_flags))
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(device, cmd_buffer_emit_stencil)(cmd_buffer);
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
|
2020-05-13 10:35:30 +02:00
|
|
|
|
if (*dirty & (V3DV_CMD_DIRTY_PIPELINE | V3DV_CMD_DIRTY_DEPTH_BIAS))
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(device, cmd_buffer_emit_depth_bias)(cmd_buffer);
|
2020-05-13 10:35:30 +02:00
|
|
|
|
|
2020-03-18 13:03:26 +01:00
|
|
|
|
if (*dirty & (V3DV_CMD_DIRTY_PIPELINE | V3DV_CMD_DIRTY_BLEND_CONSTANTS))
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(device, cmd_buffer_emit_blend)(cmd_buffer);
|
2020-03-17 12:10:58 +01:00
|
|
|
|
|
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
|
|
|
|
if (*dirty & V3DV_CMD_DIRTY_OCCLUSION_QUERY)
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(device, cmd_buffer_emit_occlusion_query)(cmd_buffer);
|
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-05-13 12:21:55 +02:00
|
|
|
|
if (*dirty & V3DV_CMD_DIRTY_LINE_WIDTH)
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(device, cmd_buffer_emit_line_width)(cmd_buffer);
|
2020-05-13 12:21:55 +02:00
|
|
|
|
|
2020-07-24 10:42:43 +02:00
|
|
|
|
if (*dirty & V3DV_CMD_DIRTY_PIPELINE)
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_X(device, cmd_buffer_emit_sample_state)(cmd_buffer);
|
2020-07-24 10:42:43 +02:00
|
|
|
|
|
2021-07-10 20:02:47 +00:00
|
|
|
|
if (*dirty & (V3DV_CMD_DIRTY_PIPELINE | V3DV_CMD_DIRTY_COLOR_WRITE_ENABLE))
|
|
|
|
|
|
v3dv_X(device, cmd_buffer_emit_color_write_mask)(cmd_buffer);
|
|
|
|
|
|
|
2020-03-18 13:03:26 +01:00
|
|
|
|
cmd_buffer->state.dirty &= ~V3DV_CMD_DIRTY_PIPELINE;
|
2019-12-28 11:42:53 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-07-23 09:41:14 +02:00
|
|
|
|
static inline void
|
|
|
|
|
|
cmd_buffer_set_view_index(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
uint32_t view_index)
|
|
|
|
|
|
{
|
|
|
|
|
|
cmd_buffer->state.view_index = view_index;
|
|
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_VIEW_INDEX;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-02-07 10:10:39 +01:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_draw(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct v3dv_draw_info *info)
|
|
|
|
|
|
{
|
2021-07-23 09:41:14 +02:00
|
|
|
|
|
|
|
|
|
|
struct v3dv_render_pass *pass = cmd_buffer->state.pass;
|
|
|
|
|
|
if (likely(!pass->multiview_enabled)) {
|
2022-05-03 09:05:19 +02:00
|
|
|
|
v3dv_cmd_buffer_emit_pre_draw(cmd_buffer, false, false);
|
2021-07-23 09:41:14 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, cmd_buffer_emit_draw)(cmd_buffer, info);
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
uint32_t view_mask = pass->subpasses[cmd_buffer->state.subpass_idx].view_mask;
|
|
|
|
|
|
while (view_mask) {
|
|
|
|
|
|
cmd_buffer_set_view_index(cmd_buffer, u_bit_scan(&view_mask));
|
2022-05-03 09:05:19 +02:00
|
|
|
|
v3dv_cmd_buffer_emit_pre_draw(cmd_buffer, false, false);
|
2021-07-23 09:41:14 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, cmd_buffer_emit_draw)(cmd_buffer, info);
|
|
|
|
|
|
}
|
2020-02-07 10:10:39 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2019-12-28 11:42:53 +01:00
|
|
|
|
v3dv_CmdDraw(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
uint32_t vertexCount,
|
|
|
|
|
|
uint32_t instanceCount,
|
|
|
|
|
|
uint32_t firstVertex,
|
|
|
|
|
|
uint32_t firstInstance)
|
|
|
|
|
|
{
|
2021-03-25 01:45:39 +01:00
|
|
|
|
if (vertexCount == 0 || instanceCount == 0)
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
2019-12-28 11:42:53 +01:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
2020-01-02 12:34:43 +01:00
|
|
|
|
struct v3dv_draw_info info = {};
|
|
|
|
|
|
info.vertex_count = vertexCount;
|
|
|
|
|
|
info.instance_count = instanceCount;
|
|
|
|
|
|
info.first_instance = firstInstance;
|
|
|
|
|
|
info.first_vertex = firstVertex;
|
2019-12-28 11:42:53 +01:00
|
|
|
|
|
2020-01-02 12:34:43 +01:00
|
|
|
|
cmd_buffer_draw(cmd_buffer, &info);
|
2019-12-28 11:42:53 +01:00
|
|
|
|
}
|
2020-01-09 09:26:10 +01:00
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2021-06-08 00:19:55 +02:00
|
|
|
|
v3dv_CmdDrawIndexed(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
uint32_t indexCount,
|
|
|
|
|
|
uint32_t instanceCount,
|
|
|
|
|
|
uint32_t firstIndex,
|
|
|
|
|
|
int32_t vertexOffset,
|
|
|
|
|
|
uint32_t firstInstance)
|
2020-02-18 09:31:39 +01:00
|
|
|
|
{
|
2021-06-08 00:19:55 +02:00
|
|
|
|
if (indexCount == 0 || instanceCount == 0)
|
2021-03-25 01:45:39 +01:00
|
|
|
|
return;
|
|
|
|
|
|
|
2020-02-18 09:31:39 +01:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
2021-07-23 09:41:14 +02:00
|
|
|
|
struct v3dv_render_pass *pass = cmd_buffer->state.pass;
|
|
|
|
|
|
if (likely(!pass->multiview_enabled)) {
|
2022-05-03 09:05:19 +02:00
|
|
|
|
v3dv_cmd_buffer_emit_pre_draw(cmd_buffer, true, false);
|
2021-07-23 09:41:14 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, cmd_buffer_emit_draw_indexed)
|
|
|
|
|
|
(cmd_buffer, indexCount, instanceCount,
|
|
|
|
|
|
firstIndex, vertexOffset, firstInstance);
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
uint32_t view_mask = pass->subpasses[cmd_buffer->state.subpass_idx].view_mask;
|
|
|
|
|
|
while (view_mask) {
|
|
|
|
|
|
cmd_buffer_set_view_index(cmd_buffer, u_bit_scan(&view_mask));
|
2022-05-03 09:05:19 +02:00
|
|
|
|
v3dv_cmd_buffer_emit_pre_draw(cmd_buffer, true, false);
|
2021-07-23 09:41:14 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, cmd_buffer_emit_draw_indexed)
|
|
|
|
|
|
(cmd_buffer, indexCount, instanceCount,
|
|
|
|
|
|
firstIndex, vertexOffset, firstInstance);
|
|
|
|
|
|
}
|
2020-02-18 09:31:39 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2021-06-08 00:19:55 +02:00
|
|
|
|
v3dv_CmdDrawIndirect(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
VkBuffer _buffer,
|
|
|
|
|
|
VkDeviceSize offset,
|
|
|
|
|
|
uint32_t drawCount,
|
|
|
|
|
|
uint32_t stride)
|
2020-02-18 09:31:39 +01:00
|
|
|
|
{
|
2021-03-28 20:34:41 -07:00
|
|
|
|
/* drawCount is the number of draws to execute, and can be zero. */
|
2021-03-25 01:45:39 +01:00
|
|
|
|
if (drawCount == 0)
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
2020-02-18 09:31:39 +01:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_buffer, buffer, _buffer);
|
|
|
|
|
|
|
2021-07-23 09:41:14 +02:00
|
|
|
|
struct v3dv_render_pass *pass = cmd_buffer->state.pass;
|
|
|
|
|
|
if (likely(!pass->multiview_enabled)) {
|
2022-05-03 09:05:19 +02:00
|
|
|
|
v3dv_cmd_buffer_emit_pre_draw(cmd_buffer, false, true);
|
2021-07-23 09:41:14 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, cmd_buffer_emit_draw_indirect)
|
|
|
|
|
|
(cmd_buffer, buffer, offset, drawCount, stride);
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
uint32_t view_mask = pass->subpasses[cmd_buffer->state.subpass_idx].view_mask;
|
|
|
|
|
|
while (view_mask) {
|
|
|
|
|
|
cmd_buffer_set_view_index(cmd_buffer, u_bit_scan(&view_mask));
|
2022-05-03 09:05:19 +02:00
|
|
|
|
v3dv_cmd_buffer_emit_pre_draw(cmd_buffer, false, true);
|
2021-07-23 09:41:14 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, cmd_buffer_emit_draw_indirect)
|
|
|
|
|
|
(cmd_buffer, buffer, offset, drawCount, stride);
|
|
|
|
|
|
}
|
2021-06-08 00:19:55 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
|
|
|
|
|
v3dv_CmdDrawIndexedIndirect(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
VkBuffer _buffer,
|
|
|
|
|
|
VkDeviceSize offset,
|
|
|
|
|
|
uint32_t drawCount,
|
|
|
|
|
|
uint32_t stride)
|
|
|
|
|
|
{
|
|
|
|
|
|
/* drawCount is the number of draws to execute, and can be zero. */
|
|
|
|
|
|
if (drawCount == 0)
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_buffer, buffer, _buffer);
|
|
|
|
|
|
|
2021-07-23 09:41:14 +02:00
|
|
|
|
struct v3dv_render_pass *pass = cmd_buffer->state.pass;
|
|
|
|
|
|
if (likely(!pass->multiview_enabled)) {
|
2022-05-03 09:05:19 +02:00
|
|
|
|
v3dv_cmd_buffer_emit_pre_draw(cmd_buffer, true, true);
|
2021-07-23 09:41:14 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, cmd_buffer_emit_indexed_indirect)
|
|
|
|
|
|
(cmd_buffer, buffer, offset, drawCount, stride);
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
uint32_t view_mask = pass->subpasses[cmd_buffer->state.subpass_idx].view_mask;
|
|
|
|
|
|
while (view_mask) {
|
|
|
|
|
|
cmd_buffer_set_view_index(cmd_buffer, u_bit_scan(&view_mask));
|
2022-05-03 09:05:19 +02:00
|
|
|
|
v3dv_cmd_buffer_emit_pre_draw(cmd_buffer, true, true);
|
2021-07-23 09:41:14 +02:00
|
|
|
|
v3dv_X(cmd_buffer->device, cmd_buffer_emit_indexed_indirect)
|
|
|
|
|
|
(cmd_buffer, buffer, offset, drawCount, stride);
|
|
|
|
|
|
}
|
2020-02-18 09:31:39 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-01-09 09:26:10 +01:00
|
|
|
|
v3dv_CmdPipelineBarrier(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
VkPipelineStageFlags srcStageMask,
|
|
|
|
|
|
VkPipelineStageFlags dstStageMask,
|
|
|
|
|
|
VkDependencyFlags dependencyFlags,
|
|
|
|
|
|
uint32_t memoryBarrierCount,
|
|
|
|
|
|
const VkMemoryBarrier *pMemoryBarriers,
|
2020-07-08 09:56:44 +02:00
|
|
|
|
uint32_t bufferBarrierCount,
|
|
|
|
|
|
const VkBufferMemoryBarrier *pBufferBarriers,
|
|
|
|
|
|
uint32_t imageBarrierCount,
|
|
|
|
|
|
const VkImageMemoryBarrier *pImageBarriers)
|
2020-01-09 09:26:10 +01:00
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
2022-04-26 09:28:59 +02:00
|
|
|
|
/* We can safely skip barriers for image layout transitions from UNDEFINED
|
|
|
|
|
|
* layout.
|
|
|
|
|
|
*/
|
|
|
|
|
|
if (imageBarrierCount > 0) {
|
|
|
|
|
|
bool all_undefined = true;
|
|
|
|
|
|
for (int i = 0; all_undefined && i < imageBarrierCount; i++) {
|
|
|
|
|
|
if (pImageBarriers[i].oldLayout != VK_IMAGE_LAYOUT_UNDEFINED)
|
|
|
|
|
|
all_undefined = false;
|
|
|
|
|
|
}
|
|
|
|
|
|
if (all_undefined)
|
|
|
|
|
|
imageBarrierCount = 0;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2022-04-13 10:40:54 +02:00
|
|
|
|
if (memoryBarrierCount + bufferBarrierCount + imageBarrierCount == 0)
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
2020-07-16 09:25:18 +02:00
|
|
|
|
/* We only care about barriers between GPU jobs */
|
|
|
|
|
|
if (srcStageMask == VK_PIPELINE_STAGE_HOST_BIT ||
|
|
|
|
|
|
dstStageMask == VK_PIPELINE_STAGE_HOST_BIT) {
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-07-08 09:56:44 +02:00
|
|
|
|
/* If we have a recording job, finish it here */
|
2020-01-09 09:26:10 +01:00
|
|
|
|
struct v3dv_job *job = cmd_buffer->state.job;
|
2020-07-08 09:56:44 +02:00
|
|
|
|
if (job)
|
|
|
|
|
|
v3dv_cmd_buffer_finish_job(cmd_buffer);
|
2020-01-09 09:26:10 +01:00
|
|
|
|
|
2022-05-30 08:52:31 +02:00
|
|
|
|
/* Track the source of the barrier */
|
|
|
|
|
|
uint8_t src_mask = 0;
|
|
|
|
|
|
if (srcStageMask & (VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT |
|
|
|
|
|
|
VK_PIPELINE_STAGE_ALL_COMMANDS_BIT)) {
|
|
|
|
|
|
src_mask |= V3DV_BARRIER_COMPUTE_BIT;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (srcStageMask & (VK_PIPELINE_STAGE_TRANSFER_BIT |
|
|
|
|
|
|
VK_PIPELINE_STAGE_ALL_COMMANDS_BIT)) {
|
|
|
|
|
|
src_mask |= V3DV_BARRIER_TRANSFER_BIT;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (srcStageMask & (~(VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT |
|
|
|
|
|
|
VK_PIPELINE_STAGE_TRANSFER_BIT))) {
|
|
|
|
|
|
src_mask |= V3DV_BARRIER_GRAPHICS_BIT;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Track consumer of the barrier */
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
if (dstStageMask & (VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT |
|
2022-05-03 09:30:58 +02:00
|
|
|
|
VK_PIPELINE_STAGE_ALL_COMMANDS_BIT)) {
|
2022-05-30 08:31:17 +02:00
|
|
|
|
cmd_buffer->state.barrier.dst_mask |= V3DV_BARRIER_COMPUTE_BIT;
|
2022-05-30 08:52:31 +02:00
|
|
|
|
cmd_buffer->state.barrier.src_mask_compute |= src_mask;
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (dstStageMask & (VK_PIPELINE_STAGE_TRANSFER_BIT |
|
|
|
|
|
|
VK_PIPELINE_STAGE_ALL_COMMANDS_BIT)) {
|
2022-05-30 08:31:17 +02:00
|
|
|
|
cmd_buffer->state.barrier.dst_mask |= V3DV_BARRIER_TRANSFER_BIT;
|
2022-05-30 08:52:31 +02:00
|
|
|
|
cmd_buffer->state.barrier.src_mask_transfer |= src_mask;
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (dstStageMask & (~(VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT |
|
|
|
|
|
|
VK_PIPELINE_STAGE_TRANSFER_BIT))) {
|
2022-05-30 08:31:17 +02:00
|
|
|
|
cmd_buffer->state.barrier.dst_mask |= V3DV_BARRIER_GRAPHICS_BIT;
|
2022-05-30 08:52:31 +02:00
|
|
|
|
cmd_buffer->state.barrier.src_mask_graphics |= src_mask;
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
|
|
|
|
|
|
if (dstStageMask & (VK_PIPELINE_STAGE_VERTEX_INPUT_BIT |
|
|
|
|
|
|
VK_PIPELINE_STAGE_VERTEX_SHADER_BIT |
|
|
|
|
|
|
VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT |
|
|
|
|
|
|
VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT |
|
|
|
|
|
|
VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT |
|
|
|
|
|
|
VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT |
|
|
|
|
|
|
VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT |
|
|
|
|
|
|
VK_PIPELINE_STAGE_ALL_COMMANDS_BIT)) {
|
|
|
|
|
|
for (int i = 0; i < memoryBarrierCount; i++) {
|
2022-05-30 08:31:17 +02:00
|
|
|
|
cmd_buffer->state.barrier.bcl_buffer_access |=
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
pMemoryBarriers[i].dstAccessMask;
|
2022-05-30 08:31:17 +02:00
|
|
|
|
cmd_buffer->state.barrier.bcl_image_access |=
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
pMemoryBarriers[i].dstAccessMask;
|
|
|
|
|
|
}
|
|
|
|
|
|
for (int i = 0; i < bufferBarrierCount; i++) {
|
2022-05-30 08:31:17 +02:00
|
|
|
|
cmd_buffer->state.barrier.bcl_buffer_access |=
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
pBufferBarriers[i].dstAccessMask;
|
|
|
|
|
|
}
|
|
|
|
|
|
for (int i = 0; i < imageBarrierCount; i++) {
|
|
|
|
|
|
if (pImageBarriers[i].oldLayout != VK_IMAGE_LAYOUT_UNDEFINED) {
|
2022-05-30 08:31:17 +02:00
|
|
|
|
cmd_buffer->state.barrier.bcl_image_access |=
|
v3dv: consume barriers at the right stages
Until now, we have always consumed barriers with the next GPU job
recorded into the command buffer after the barrier even if the job
was not the target of the barrier itself. This works based on the
idea that when we consume a barrier in a job we serialize it against
all queues, so effectively we are ensuring that whatever came
before it has completed, so if the barrier was intended for an
even later job, it would have served its purpose anyway.
It should be noted that CL jobs are special because they are actually
split in two different queues: the binning queue and the render
queue, with a dependency between them to ensure render runs after
binning. With our current implementation, if we have 3 jobs (A, B,
C) and we have a barrier after job A which is intended to block job C
on A's completion, with our implementation we would instead block
B on A's completion. If C is a CL job, and the barrier was targetting
the binning stage then we can have the following scenarios:
1. If B) is a CL job, it will consume the barrier at its binning
stage, so we know that B's binning will not start until A has
completed. Then C's binning will not start until B's binning
has completed, and thus, will not start until A has completed,
as intended.
2. If B) is not a CL job, it will consume the barrier and will not
start until A has completed, however, C's binning job will be
submitted to the binning queue without any sync requirements
and since B did not put any jobs in the binning queue it will
start as soon as A's binning has completed, but not A's render,
which would be incorrect.
Further, since a981ac0539 we now skip consumming BCL barriers if
a job does not have draw calls that can be affected by them. In the
same scenarios as before, now case 1) would also be problematic,
since B may skip the binning sync in that case and start immediately,
and since C's binning would be allowe to start immediately after B's
binning, there is no guarantee that this doesn't happen in parallel
with A's render.
With this patch we fix this situation by tracking the intended
consumer of each barrier: graphics, compute or transfer, and we make
sure to consume them only with jobs that match those semantics.
This fixes flakyness in dEQP-VK.device_group.*
Fixes: a981ac0539 ('v3dv: skip binning sync if binning shaders don't access external resources')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16743>
2022-05-25 13:56:33 +02:00
|
|
|
|
pImageBarriers[i].dstAccessMask;
|
|
|
|
|
|
}
|
2022-05-03 09:05:19 +02:00
|
|
|
|
}
|
|
|
|
|
|
}
|
2020-07-08 09:56:44 +02:00
|
|
|
|
}
|
2020-01-09 09:26:10 +01:00
|
|
|
|
}
|
2020-07-31 01:11:39 +02:00
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-07-31 01:11:39 +02:00
|
|
|
|
v3dv_CmdBindVertexBuffers(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
uint32_t firstBinding,
|
|
|
|
|
|
uint32_t bindingCount,
|
|
|
|
|
|
const VkBuffer *pBuffers,
|
|
|
|
|
|
const VkDeviceSize *pOffsets)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
struct v3dv_vertex_binding *vb = cmd_buffer->state.vertex_bindings;
|
|
|
|
|
|
|
|
|
|
|
|
/* We have to defer setting up vertex buffer since we need the buffer
|
|
|
|
|
|
* stride from the pipeline.
|
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
assert(firstBinding + bindingCount <= MAX_VBS);
|
2020-06-11 11:59:24 +02:00
|
|
|
|
bool vb_state_changed = false;
|
2020-07-31 01:11:39 +02:00
|
|
|
|
for (uint32_t i = 0; i < bindingCount; i++) {
|
2020-06-11 11:59:24 +02:00
|
|
|
|
if (vb[firstBinding + i].buffer != v3dv_buffer_from_handle(pBuffers[i])) {
|
|
|
|
|
|
vb[firstBinding + i].buffer = v3dv_buffer_from_handle(pBuffers[i]);
|
|
|
|
|
|
vb_state_changed = true;
|
|
|
|
|
|
}
|
|
|
|
|
|
if (vb[firstBinding + i].offset != pOffsets[i]) {
|
|
|
|
|
|
vb[firstBinding + i].offset = pOffsets[i];
|
|
|
|
|
|
vb_state_changed = true;
|
|
|
|
|
|
}
|
2020-07-31 01:11:39 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-06-11 11:59:24 +02:00
|
|
|
|
if (vb_state_changed)
|
|
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_VERTEX_BUFFER;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static uint32_t
|
|
|
|
|
|
get_index_size(VkIndexType index_type)
|
|
|
|
|
|
{
|
|
|
|
|
|
switch (index_type) {
|
2021-06-17 12:12:46 +02:00
|
|
|
|
case VK_INDEX_TYPE_UINT8_EXT:
|
|
|
|
|
|
return 1;
|
|
|
|
|
|
break;
|
2020-06-11 11:59:24 +02:00
|
|
|
|
case VK_INDEX_TYPE_UINT16:
|
|
|
|
|
|
return 2;
|
|
|
|
|
|
break;
|
|
|
|
|
|
case VK_INDEX_TYPE_UINT32:
|
|
|
|
|
|
return 4;
|
|
|
|
|
|
break;
|
|
|
|
|
|
default:
|
|
|
|
|
|
unreachable("Unsupported index type");
|
|
|
|
|
|
}
|
2020-07-31 01:11:39 +02:00
|
|
|
|
}
|
2020-02-04 17:43:49 +01:00
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-02-07 10:10:39 +01:00
|
|
|
|
v3dv_CmdBindIndexBuffer(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
VkBuffer buffer,
|
|
|
|
|
|
VkDeviceSize offset,
|
|
|
|
|
|
VkIndexType indexType)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
2020-05-28 09:14:30 +02:00
|
|
|
|
|
2020-06-11 11:59:24 +02:00
|
|
|
|
const uint32_t index_size = get_index_size(indexType);
|
2021-04-09 10:47:51 +02:00
|
|
|
|
if (buffer == cmd_buffer->state.index_buffer.buffer &&
|
|
|
|
|
|
offset == cmd_buffer->state.index_buffer.offset &&
|
|
|
|
|
|
index_size == cmd_buffer->state.index_buffer.index_size) {
|
|
|
|
|
|
return;
|
2020-02-07 10:10:39 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-06-11 11:59:24 +02:00
|
|
|
|
cmd_buffer->state.index_buffer.buffer = buffer;
|
|
|
|
|
|
cmd_buffer->state.index_buffer.offset = offset;
|
|
|
|
|
|
cmd_buffer->state.index_buffer.index_size = index_size;
|
2021-04-09 10:47:51 +02:00
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_INDEX_BUFFER;
|
2020-02-07 10:10:39 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-02-04 17:43:49 +01:00
|
|
|
|
v3dv_CmdSetStencilCompareMask(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
VkStencilFaceFlags faceMask,
|
|
|
|
|
|
uint32_t compareMask)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
|
|
|
|
|
if (faceMask & VK_STENCIL_FACE_FRONT_BIT)
|
|
|
|
|
|
cmd_buffer->state.dynamic.stencil_compare_mask.front = compareMask & 0xff;
|
|
|
|
|
|
if (faceMask & VK_STENCIL_FACE_BACK_BIT)
|
|
|
|
|
|
cmd_buffer->state.dynamic.stencil_compare_mask.back = compareMask & 0xff;
|
|
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_STENCIL_COMPARE_MASK;
|
2020-02-04 17:43:49 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-02-04 17:43:49 +01:00
|
|
|
|
v3dv_CmdSetStencilWriteMask(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
VkStencilFaceFlags faceMask,
|
|
|
|
|
|
uint32_t writeMask)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
|
|
|
|
|
if (faceMask & VK_STENCIL_FACE_FRONT_BIT)
|
|
|
|
|
|
cmd_buffer->state.dynamic.stencil_write_mask.front = writeMask & 0xff;
|
|
|
|
|
|
if (faceMask & VK_STENCIL_FACE_BACK_BIT)
|
|
|
|
|
|
cmd_buffer->state.dynamic.stencil_write_mask.back = writeMask & 0xff;
|
|
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_STENCIL_WRITE_MASK;
|
2020-02-04 17:43:49 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-02-04 17:43:49 +01:00
|
|
|
|
v3dv_CmdSetStencilReference(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
VkStencilFaceFlags faceMask,
|
|
|
|
|
|
uint32_t reference)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
|
|
|
|
|
if (faceMask & VK_STENCIL_FACE_FRONT_BIT)
|
|
|
|
|
|
cmd_buffer->state.dynamic.stencil_reference.front = reference & 0xff;
|
|
|
|
|
|
if (faceMask & VK_STENCIL_FACE_BACK_BIT)
|
|
|
|
|
|
cmd_buffer->state.dynamic.stencil_reference.back = reference & 0xff;
|
|
|
|
|
|
|
v3dv: fix the mess with dynamic state handling
The general idea is that we always emit from our dynamic state, and when
a particular piece of state is not dynamic, we just set our dynamic state
from the pipeline state, however, the implementation was quite confusing:
the mask of dynamic states flagged states that were not dynamic and some
places woud mix dirty flags and dynamic state flags. We also were not
updating the dynamic state mask in the command buffer, etc.
This patch, hopefully, simplifies all this and makes it less confusing,
starting by making the dynamic state mask flag dynamic states, fixing
the places where we would confuse dirty state flags with dynamic state
flags, making sure that our command buffer state is setup correctly
and that we only emit state when it is actually dirty.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-02-05 10:53:20 +01:00
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_STENCIL_REFERENCE;
|
2020-02-04 17:43:49 +01:00
|
|
|
|
}
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 15:29:38 +01:00
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-05-13 10:35:30 +02:00
|
|
|
|
v3dv_CmdSetDepthBias(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
float depthBiasConstantFactor,
|
|
|
|
|
|
float depthBiasClamp,
|
|
|
|
|
|
float depthBiasSlopeFactor)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.dynamic.depth_bias.constant_factor = depthBiasConstantFactor;
|
2021-02-09 13:12:03 +01:00
|
|
|
|
cmd_buffer->state.dynamic.depth_bias.depth_bias_clamp = depthBiasClamp;
|
2020-05-13 10:35:30 +02:00
|
|
|
|
cmd_buffer->state.dynamic.depth_bias.slope_factor = depthBiasSlopeFactor;
|
|
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_DEPTH_BIAS;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-05-13 11:21:12 +02:00
|
|
|
|
v3dv_CmdSetDepthBounds(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
float minDepthBounds,
|
|
|
|
|
|
float maxDepthBounds)
|
|
|
|
|
|
{
|
|
|
|
|
|
/* We do not support depth bounds testing so we just ingore this. We are
|
|
|
|
|
|
* already asserting that pipelines don't enable the feature anyway.
|
|
|
|
|
|
*/
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2022-03-17 12:20:41 +01:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
|
|
|
|
|
v3dv_CmdSetLineStippleEXT(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
uint32_t lineStippleFactor,
|
|
|
|
|
|
uint16_t lineStipplePattern)
|
|
|
|
|
|
{
|
|
|
|
|
|
/* We do not support stippled line rasterization so we just ignore this. */
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-05-13 12:21:55 +02:00
|
|
|
|
v3dv_CmdSetLineWidth(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
float lineWidth)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.dynamic.line_width = lineWidth;
|
|
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_LINE_WIDTH;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 15:29:38 +01:00
|
|
|
|
v3dv_CmdBindDescriptorSets(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
VkPipelineBindPoint pipelineBindPoint,
|
|
|
|
|
|
VkPipelineLayout _layout,
|
|
|
|
|
|
uint32_t firstSet,
|
|
|
|
|
|
uint32_t descriptorSetCount,
|
|
|
|
|
|
const VkDescriptorSet *pDescriptorSets,
|
|
|
|
|
|
uint32_t dynamicOffsetCount,
|
|
|
|
|
|
const uint32_t *pDynamicOffsets)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
2020-02-24 11:32:57 +01:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_pipeline_layout, layout, _layout);
|
|
|
|
|
|
|
|
|
|
|
|
uint32_t dyn_index = 0;
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 15:29:38 +01:00
|
|
|
|
|
|
|
|
|
|
assert(firstSet + descriptorSetCount <= MAX_SETS);
|
|
|
|
|
|
|
2020-02-24 11:32:57 +01:00
|
|
|
|
struct v3dv_descriptor_state *descriptor_state =
|
2021-01-15 23:07:45 +01:00
|
|
|
|
pipelineBindPoint == VK_PIPELINE_BIND_POINT_COMPUTE ?
|
|
|
|
|
|
&cmd_buffer->state.compute.descriptor_state :
|
|
|
|
|
|
&cmd_buffer->state.gfx.descriptor_state;
|
2020-02-24 11:32:57 +01:00
|
|
|
|
|
2021-04-16 10:14:23 +02:00
|
|
|
|
VkShaderStageFlags dirty_stages = 0;
|
2020-06-11 11:59:24 +02:00
|
|
|
|
bool descriptor_state_changed = false;
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 15:29:38 +01:00
|
|
|
|
for (uint32_t i = 0; i < descriptorSetCount; i++) {
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_descriptor_set, set, pDescriptorSets[i]);
|
|
|
|
|
|
uint32_t index = firstSet + i;
|
|
|
|
|
|
|
2021-04-16 10:14:23 +02:00
|
|
|
|
descriptor_state->valid |= (1u << index);
|
2020-06-11 11:59:24 +02:00
|
|
|
|
if (descriptor_state->descriptor_sets[index] != set) {
|
|
|
|
|
|
descriptor_state->descriptor_sets[index] = set;
|
2021-04-16 10:14:23 +02:00
|
|
|
|
dirty_stages |= set->layout->shader_stages;
|
2020-06-11 11:59:24 +02:00
|
|
|
|
descriptor_state_changed = true;
|
|
|
|
|
|
}
|
2020-02-24 11:32:57 +01:00
|
|
|
|
|
|
|
|
|
|
for (uint32_t j = 0; j < set->layout->dynamic_offset_count; j++, dyn_index++) {
|
|
|
|
|
|
uint32_t idx = j + layout->set[i + firstSet].dynamic_offset_start;
|
|
|
|
|
|
|
2020-06-11 11:59:24 +02:00
|
|
|
|
if (descriptor_state->dynamic_offsets[idx] != pDynamicOffsets[dyn_index]) {
|
|
|
|
|
|
descriptor_state->dynamic_offsets[idx] = pDynamicOffsets[dyn_index];
|
2021-04-16 10:14:23 +02:00
|
|
|
|
dirty_stages |= set->layout->shader_stages;
|
2020-06-11 11:59:24 +02:00
|
|
|
|
descriptor_state_changed = true;
|
|
|
|
|
|
}
|
2020-02-24 11:32:57 +01:00
|
|
|
|
}
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 15:29:38 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-06-18 12:14:58 +02:00
|
|
|
|
if (descriptor_state_changed) {
|
2021-04-16 10:14:23 +02:00
|
|
|
|
if (pipelineBindPoint == VK_PIPELINE_BIND_POINT_GRAPHICS) {
|
2020-06-18 12:14:58 +02:00
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_DESCRIPTOR_SETS;
|
2021-04-16 10:14:23 +02:00
|
|
|
|
cmd_buffer->state.dirty_descriptor_stages |= dirty_stages & VK_SHADER_STAGE_ALL_GRAPHICS;
|
|
|
|
|
|
} else {
|
2020-06-18 12:14:58 +02:00
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_COMPUTE_DESCRIPTOR_SETS;
|
2021-04-16 10:14:23 +02:00
|
|
|
|
cmd_buffer->state.dirty_descriptor_stages |= VK_SHADER_STAGE_COMPUTE_BIT;
|
|
|
|
|
|
}
|
2020-06-18 12:14:58 +02:00
|
|
|
|
}
|
v3dv: initial descriptor set support
Focused on getting the basic UBO and SSBO cases implemented. So no
dynamic offset, push contanst, samplers, and so on.
This include a initial implementation for CreatedescriptorPool,
CreateDescriptorSetLayout, AllocateDescriptorSets,
UpdateDescriptorSets, CreatePipelineLayout, and CmdBindDescriptorSets.
Also introduces lowering vulkan intrinsics. For now just
vulkan_resource_index.
We also introduce a descriptor_map, in this case for the ubos and
ssbos, used to assign a index for each set/binding combination, that
would be used when filling back the details of the ubo or ssbo on
other places (like QUNIFORM_UBO_ADDR or QUNIFORM_SSBO_OFFSET).
Note that at this point we don't need a bo for the descriptor pool, so
descriptor sets are not getting a piece of it. That would likely
change as we start to support more descriptor set types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-01-20 15:29:38 +01:00
|
|
|
|
}
|
2020-09-11 23:26:07 +02:00
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-09-11 23:26:07 +02:00
|
|
|
|
v3dv_CmdPushConstants(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
VkPipelineLayout layout,
|
|
|
|
|
|
VkShaderStageFlags stageFlags,
|
|
|
|
|
|
uint32_t offset,
|
|
|
|
|
|
uint32_t size,
|
|
|
|
|
|
const void *pValues)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
2020-11-19 23:45:57 +01:00
|
|
|
|
if (!memcmp((uint8_t *) cmd_buffer->push_constants_data + offset, pValues, size))
|
2020-06-11 11:59:24 +02:00
|
|
|
|
return;
|
|
|
|
|
|
|
2020-11-19 23:45:57 +01:00
|
|
|
|
memcpy((uint8_t *) cmd_buffer->push_constants_data + offset, pValues, size);
|
2020-09-11 23:26:07 +02:00
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_PUSH_CONSTANTS;
|
2021-04-16 12:50:00 +02:00
|
|
|
|
cmd_buffer->state.dirty_push_constants_stages |= stageFlags;
|
2020-09-11 23:26:07 +02:00
|
|
|
|
}
|
2020-03-18 11:50:47 +01:00
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-03-18 11:50:47 +01:00
|
|
|
|
v3dv_CmdSetBlendConstants(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
const float blendConstants[4])
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
|
|
|
|
|
|
if (!memcmp(state->dynamic.blend_constants, blendConstants,
|
|
|
|
|
|
sizeof(state->dynamic.blend_constants))) {
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
memcpy(state->dynamic.blend_constants, blendConstants,
|
|
|
|
|
|
sizeof(state->dynamic.blend_constants));
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_BLEND_CONSTANTS;
|
|
|
|
|
|
}
|
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-10 20:02:47 +00:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
|
|
|
|
|
v3dv_CmdSetColorWriteEnableEXT(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
uint32_t attachmentCount,
|
|
|
|
|
|
const VkBool32 *pColorWriteEnables)
|
|
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
|
|
|
|
|
uint32_t color_write_enable = 0;
|
|
|
|
|
|
|
|
|
|
|
|
for (uint32_t i = 0; i < attachmentCount; i++)
|
|
|
|
|
|
color_write_enable |= pColorWriteEnables[i] ? (0xfu << (i * 4)) : 0;
|
|
|
|
|
|
|
|
|
|
|
|
if (state->dynamic.color_write_enable == color_write_enable)
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
|
|
state->dynamic.color_write_enable = color_write_enable;
|
|
|
|
|
|
|
|
|
|
|
|
state->dirty |= V3DV_CMD_DIRTY_COLOR_WRITE_ENABLE;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
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
|
|
|
|
void
|
|
|
|
|
|
v3dv_cmd_buffer_reset_queries(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
|
|
uint32_t first,
|
|
|
|
|
|
uint32_t count)
|
|
|
|
|
|
{
|
|
|
|
|
|
/* Resets can only happen outside a render pass instance so we should not
|
|
|
|
|
|
* be in the middle of job recording.
|
|
|
|
|
|
*/
|
|
|
|
|
|
assert(cmd_buffer->state.pass == NULL);
|
|
|
|
|
|
assert(cmd_buffer->state.job == NULL);
|
|
|
|
|
|
|
|
|
|
|
|
assert(first < pool->query_count);
|
|
|
|
|
|
assert(first + count <= pool->query_count);
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_job *job =
|
2020-06-02 12:26:50 +02:00
|
|
|
|
v3dv_cmd_buffer_create_cpu_job(cmd_buffer->device,
|
|
|
|
|
|
V3DV_JOB_TYPE_CPU_RESET_QUERIES,
|
|
|
|
|
|
cmd_buffer, -1);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
v3dv_return_if_oom(cmd_buffer, NULL);
|
|
|
|
|
|
|
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
|
|
|
|
job->cpu.query_reset.pool = pool;
|
|
|
|
|
|
job->cpu.query_reset.first = first;
|
|
|
|
|
|
job->cpu.query_reset.count = count;
|
|
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
list_addtail(&job->list_link, &cmd_buffer->jobs);
|
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-06-14 23:36:45 +02:00
|
|
|
|
void
|
|
|
|
|
|
v3dv_cmd_buffer_ensure_array_state(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
uint32_t slot_size,
|
|
|
|
|
|
uint32_t used_count,
|
|
|
|
|
|
uint32_t *alloc_count,
|
|
|
|
|
|
void **ptr)
|
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
|
|
|
|
{
|
|
|
|
|
|
if (used_count >= *alloc_count) {
|
|
|
|
|
|
const uint32_t prev_slot_count = *alloc_count;
|
|
|
|
|
|
void *old_buffer = *ptr;
|
|
|
|
|
|
|
|
|
|
|
|
const uint32_t new_slot_count = MAX2(*alloc_count * 2, 4);
|
|
|
|
|
|
const uint32_t bytes = new_slot_count * slot_size;
|
2020-11-12 16:30:41 +01:00
|
|
|
|
*ptr = vk_alloc(&cmd_buffer->device->vk.alloc, bytes, 8,
|
2020-05-29 12:00:12 +02:00
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
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
|
|
|
|
if (*ptr == NULL) {
|
|
|
|
|
|
fprintf(stderr, "Error: failed to allocate CPU buffer for query.\n");
|
2020-05-29 11:59:34 +02:00
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
|
|
|
|
|
return;
|
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
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
memcpy(*ptr, old_buffer, prev_slot_count * slot_size);
|
|
|
|
|
|
*alloc_count = new_slot_count;
|
|
|
|
|
|
}
|
|
|
|
|
|
assert(used_count < *alloc_count);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
|
v3dv_cmd_buffer_begin_query(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
|
|
uint32_t query,
|
|
|
|
|
|
VkQueryControlFlags flags)
|
|
|
|
|
|
{
|
|
|
|
|
|
/* FIXME: we only support one active query for now */
|
2021-04-14 13:34:00 +02:00
|
|
|
|
assert(cmd_buffer->state.query.active_query.bo == NULL);
|
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
|
|
|
|
assert(query < pool->query_count);
|
|
|
|
|
|
|
2021-04-14 13:34:00 +02:00
|
|
|
|
cmd_buffer->state.query.active_query.bo = pool->queries[query].bo;
|
|
|
|
|
|
cmd_buffer->state.query.active_query.offset = pool->queries[query].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
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_OCCLUSION_QUERY;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
|
v3dv_cmd_buffer_end_query(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
|
|
uint32_t query)
|
|
|
|
|
|
{
|
|
|
|
|
|
assert(query < pool->query_count);
|
2021-04-14 13:34:00 +02:00
|
|
|
|
assert(cmd_buffer->state.query.active_query.bo != NULL);
|
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
|
|
|
|
|
|
|
|
|
|
if (cmd_buffer->state.pass) {
|
|
|
|
|
|
/* Queue the EndQuery in the command buffer state, we will create a CPU
|
|
|
|
|
|
* job to flag all of these queries as possibly available right after the
|
|
|
|
|
|
* render pass job in which they have been recorded.
|
|
|
|
|
|
*/
|
|
|
|
|
|
struct v3dv_cmd_buffer_state *state = &cmd_buffer->state;
|
2021-06-14 23:36:45 +02:00
|
|
|
|
v3dv_cmd_buffer_ensure_array_state(cmd_buffer,
|
|
|
|
|
|
sizeof(struct v3dv_end_query_cpu_job_info),
|
|
|
|
|
|
state->query.end.used_count,
|
|
|
|
|
|
&state->query.end.alloc_count,
|
|
|
|
|
|
(void **) &state->query.end.states);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
v3dv_return_if_oom(cmd_buffer, NULL);
|
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 =
|
|
|
|
|
|
&state->query.end.states[state->query.end.used_count++];
|
|
|
|
|
|
|
|
|
|
|
|
info->pool = pool;
|
|
|
|
|
|
info->query = query;
|
2021-07-23 14:49:05 +02:00
|
|
|
|
|
|
|
|
|
|
/* From the Vulkan spec:
|
|
|
|
|
|
*
|
|
|
|
|
|
* "If queries are used while executing a render pass instance that has
|
|
|
|
|
|
* multiview enabled, the query uses N consecutive query indices in
|
|
|
|
|
|
* the query pool (starting at query) where N is the number of bits set
|
|
|
|
|
|
* in the view mask in the subpass the query is used in. How the
|
|
|
|
|
|
* numerical results of the query are distributed among the queries is
|
|
|
|
|
|
* implementation-dependent."
|
|
|
|
|
|
*
|
|
|
|
|
|
* In our case, only the first query is used but this means we still need
|
|
|
|
|
|
* to flag the other queries as available so we don't emit errors when
|
|
|
|
|
|
* the applications attempt to retrive values from them.
|
|
|
|
|
|
*/
|
|
|
|
|
|
struct v3dv_render_pass *pass = cmd_buffer->state.pass;
|
|
|
|
|
|
if (!pass->multiview_enabled) {
|
|
|
|
|
|
info->count = 1;
|
|
|
|
|
|
} else {
|
|
|
|
|
|
struct v3dv_subpass *subpass = &pass->subpasses[state->subpass_idx];
|
|
|
|
|
|
info->count = util_bitcount(subpass->view_mask);
|
|
|
|
|
|
}
|
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
|
|
|
|
} else {
|
|
|
|
|
|
/* Otherwise, schedule the CPU job immediately */
|
|
|
|
|
|
struct v3dv_job *job =
|
2020-06-02 12:26:50 +02:00
|
|
|
|
v3dv_cmd_buffer_create_cpu_job(cmd_buffer->device,
|
|
|
|
|
|
V3DV_JOB_TYPE_CPU_END_QUERY,
|
|
|
|
|
|
cmd_buffer, -1);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
v3dv_return_if_oom(cmd_buffer, NULL);
|
|
|
|
|
|
|
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
|
|
|
|
job->cpu.query_end.pool = pool;
|
|
|
|
|
|
job->cpu.query_end.query = query;
|
2021-07-23 14:49:05 +02:00
|
|
|
|
|
|
|
|
|
|
/* Multiview queries cannot cross subpass boundaries */
|
|
|
|
|
|
job->cpu.query_end.count = 1;
|
|
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
list_addtail(&job->list_link, &cmd_buffer->jobs);
|
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
|
|
|
|
cmd_buffer->state.query.active_query.bo = NULL;
|
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
|
|
|
|
cmd_buffer->state.dirty |= V3DV_CMD_DIRTY_OCCLUSION_QUERY;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
|
v3dv_cmd_buffer_copy_query_results(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
|
|
uint32_t first,
|
|
|
|
|
|
uint32_t count,
|
|
|
|
|
|
struct v3dv_buffer *dst,
|
|
|
|
|
|
uint32_t offset,
|
|
|
|
|
|
uint32_t stride,
|
|
|
|
|
|
VkQueryResultFlags flags)
|
|
|
|
|
|
{
|
|
|
|
|
|
/* Copies can only happen outside a render pass instance so we should not
|
|
|
|
|
|
* be in the middle of job recording.
|
|
|
|
|
|
*/
|
|
|
|
|
|
assert(cmd_buffer->state.pass == NULL);
|
|
|
|
|
|
assert(cmd_buffer->state.job == NULL);
|
|
|
|
|
|
|
|
|
|
|
|
assert(first < pool->query_count);
|
|
|
|
|
|
assert(first + count <= pool->query_count);
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_job *job =
|
2020-06-02 12:26:50 +02:00
|
|
|
|
v3dv_cmd_buffer_create_cpu_job(cmd_buffer->device,
|
|
|
|
|
|
V3DV_JOB_TYPE_CPU_COPY_QUERY_RESULTS,
|
|
|
|
|
|
cmd_buffer, -1);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
v3dv_return_if_oom(cmd_buffer, NULL);
|
|
|
|
|
|
|
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
|
|
|
|
job->cpu.query_copy_results.pool = pool;
|
|
|
|
|
|
job->cpu.query_copy_results.first = first;
|
|
|
|
|
|
job->cpu.query_copy_results.count = count;
|
|
|
|
|
|
job->cpu.query_copy_results.dst = dst;
|
|
|
|
|
|
job->cpu.query_copy_results.offset = offset;
|
|
|
|
|
|
job->cpu.query_copy_results.stride = stride;
|
|
|
|
|
|
job->cpu.query_copy_results.flags = flags;
|
|
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
list_addtail(&job->list_link, &cmd_buffer->jobs);
|
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-04-17 13:56:01 +02:00
|
|
|
|
|
2020-04-20 13:24:09 +02:00
|
|
|
|
void
|
|
|
|
|
|
v3dv_cmd_buffer_add_tfu_job(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct drm_v3d_submit_tfu *tfu)
|
|
|
|
|
|
{
|
|
|
|
|
|
struct v3dv_device *device = cmd_buffer->device;
|
2020-11-12 16:30:41 +01:00
|
|
|
|
struct v3dv_job *job = vk_zalloc(&device->vk.alloc,
|
2020-04-20 13:24:09 +02:00
|
|
|
|
sizeof(struct v3dv_job), 8,
|
2020-05-29 12:00:12 +02:00
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
if (!job) {
|
|
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-04-20 13:24:09 +02:00
|
|
|
|
v3dv_job_init(job, V3DV_JOB_TYPE_GPU_TFU, device, cmd_buffer, -1);
|
|
|
|
|
|
job->tfu = *tfu;
|
2020-05-26 12:05:43 +02:00
|
|
|
|
list_addtail(&job->list_link, &cmd_buffer->jobs);
|
2020-04-20 13:24:09 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-04-17 13:56:01 +02:00
|
|
|
|
v3dv_CmdSetEvent(VkCommandBuffer commandBuffer,
|
2020-05-18 10:41:11 +02:00
|
|
|
|
VkEvent _event,
|
2020-04-17 13:56:01 +02:00
|
|
|
|
VkPipelineStageFlags stageMask)
|
|
|
|
|
|
{
|
2020-05-18 10:41:11 +02:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_event, event, _event);
|
|
|
|
|
|
|
|
|
|
|
|
/* Event (re)sets can only happen outside a render pass instance so we
|
|
|
|
|
|
* should not be in the middle of job recording.
|
|
|
|
|
|
*/
|
|
|
|
|
|
assert(cmd_buffer->state.pass == NULL);
|
|
|
|
|
|
assert(cmd_buffer->state.job == NULL);
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_job *job =
|
2020-06-02 12:26:50 +02:00
|
|
|
|
v3dv_cmd_buffer_create_cpu_job(cmd_buffer->device,
|
|
|
|
|
|
V3DV_JOB_TYPE_CPU_SET_EVENT,
|
|
|
|
|
|
cmd_buffer, -1);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
v3dv_return_if_oom(cmd_buffer, NULL);
|
|
|
|
|
|
|
2020-05-18 10:41:11 +02:00
|
|
|
|
job->cpu.event_set.event = event;
|
|
|
|
|
|
job->cpu.event_set.state = 1;
|
|
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
list_addtail(&job->list_link, &cmd_buffer->jobs);
|
2020-04-17 13:56:01 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-04-17 13:56:01 +02:00
|
|
|
|
v3dv_CmdResetEvent(VkCommandBuffer commandBuffer,
|
2020-05-18 10:41:11 +02:00
|
|
|
|
VkEvent _event,
|
2020-04-17 13:56:01 +02:00
|
|
|
|
VkPipelineStageFlags stageMask)
|
|
|
|
|
|
{
|
2020-05-18 10:41:11 +02:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_event, event, _event);
|
|
|
|
|
|
|
|
|
|
|
|
/* Event (re)sets can only happen outside a render pass instance so we
|
|
|
|
|
|
* should not be in the middle of job recording.
|
|
|
|
|
|
*/
|
|
|
|
|
|
assert(cmd_buffer->state.pass == NULL);
|
|
|
|
|
|
assert(cmd_buffer->state.job == NULL);
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_job *job =
|
2020-06-02 12:26:50 +02:00
|
|
|
|
v3dv_cmd_buffer_create_cpu_job(cmd_buffer->device,
|
|
|
|
|
|
V3DV_JOB_TYPE_CPU_SET_EVENT,
|
|
|
|
|
|
cmd_buffer, -1);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
v3dv_return_if_oom(cmd_buffer, NULL);
|
|
|
|
|
|
|
2020-05-18 10:41:11 +02:00
|
|
|
|
job->cpu.event_set.event = event;
|
|
|
|
|
|
job->cpu.event_set.state = 0;
|
|
|
|
|
|
|
2020-05-26 12:05:43 +02:00
|
|
|
|
list_addtail(&job->list_link, &cmd_buffer->jobs);
|
2020-04-17 13:56:01 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-04-17 13:56:01 +02:00
|
|
|
|
v3dv_CmdWaitEvents(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
uint32_t eventCount,
|
|
|
|
|
|
const VkEvent *pEvents,
|
|
|
|
|
|
VkPipelineStageFlags srcStageMask,
|
|
|
|
|
|
VkPipelineStageFlags dstStageMask,
|
|
|
|
|
|
uint32_t memoryBarrierCount,
|
|
|
|
|
|
const VkMemoryBarrier *pMemoryBarriers,
|
|
|
|
|
|
uint32_t bufferMemoryBarrierCount,
|
|
|
|
|
|
const VkBufferMemoryBarrier *pBufferMemoryBarriers,
|
|
|
|
|
|
uint32_t imageMemoryBarrierCount,
|
|
|
|
|
|
const VkImageMemoryBarrier *pImageMemoryBarriers)
|
|
|
|
|
|
{
|
2020-05-18 10:41:11 +02:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
|
|
|
|
|
assert(eventCount > 0);
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_job *job =
|
2020-06-02 12:26:50 +02:00
|
|
|
|
v3dv_cmd_buffer_create_cpu_job(cmd_buffer->device,
|
|
|
|
|
|
V3DV_JOB_TYPE_CPU_WAIT_EVENTS,
|
|
|
|
|
|
cmd_buffer, -1);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
v3dv_return_if_oom(cmd_buffer, NULL);
|
2020-05-18 10:41:11 +02:00
|
|
|
|
|
|
|
|
|
|
const uint32_t event_list_size = sizeof(struct v3dv_event *) * eventCount;
|
|
|
|
|
|
|
|
|
|
|
|
job->cpu.event_wait.events =
|
2020-11-12 16:30:41 +01:00
|
|
|
|
vk_alloc(&cmd_buffer->device->vk.alloc, event_list_size, 8,
|
2020-05-29 12:00:12 +02:00
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
2020-05-29 11:59:34 +02:00
|
|
|
|
if (!job->cpu.event_wait.events) {
|
|
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
job->cpu.event_wait.event_count = eventCount;
|
|
|
|
|
|
|
2020-05-18 10:41:11 +02:00
|
|
|
|
for (uint32_t i = 0; i < eventCount; i++)
|
|
|
|
|
|
job->cpu.event_wait.events[i] = v3dv_event_from_handle(pEvents[i]);
|
|
|
|
|
|
|
2020-06-01 12:00:16 +02:00
|
|
|
|
/* vkCmdWaitEvents can be recorded inside a render pass, so we might have
|
|
|
|
|
|
* an active job.
|
|
|
|
|
|
*
|
|
|
|
|
|
* If we are inside a render pass, because we vkCmd(Re)SetEvent can't happen
|
|
|
|
|
|
* inside a render pass, it is safe to move the wait job so it happens right
|
|
|
|
|
|
* before the current job we are currently recording for the subpass, if any
|
|
|
|
|
|
* (it would actually be safe to move it all the way back to right before
|
2020-06-02 12:26:50 +02:00
|
|
|
|
* the start of the render pass).
|
2020-06-01 12:00:16 +02:00
|
|
|
|
*
|
|
|
|
|
|
* If we are outside a render pass then we should not have any on-going job
|
|
|
|
|
|
* and we are free to just add the wait job without restrictions.
|
|
|
|
|
|
*/
|
|
|
|
|
|
assert(cmd_buffer->state.pass || !cmd_buffer->state.job);
|
2020-06-02 12:26:50 +02:00
|
|
|
|
list_addtail(&job->list_link, &cmd_buffer->jobs);
|
2020-04-17 13:56:01 +02:00
|
|
|
|
}
|
2020-06-04 09:03:42 +02:00
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-06-04 09:03:42 +02:00
|
|
|
|
v3dv_CmdWriteTimestamp(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
VkPipelineStageFlagBits pipelineStage,
|
|
|
|
|
|
VkQueryPool queryPool,
|
|
|
|
|
|
uint32_t query)
|
|
|
|
|
|
{
|
2020-10-29 11:55:23 +01:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_query_pool, query_pool, queryPool);
|
|
|
|
|
|
|
|
|
|
|
|
/* If this is called inside a render pass we need to finish the current
|
|
|
|
|
|
* job here...
|
|
|
|
|
|
*/
|
2021-07-23 14:49:05 +02:00
|
|
|
|
struct v3dv_render_pass *pass = cmd_buffer->state.pass;
|
|
|
|
|
|
if (pass)
|
2020-10-29 11:55:23 +01:00
|
|
|
|
v3dv_cmd_buffer_finish_job(cmd_buffer);
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_job *job =
|
|
|
|
|
|
v3dv_cmd_buffer_create_cpu_job(cmd_buffer->device,
|
|
|
|
|
|
V3DV_JOB_TYPE_CPU_TIMESTAMP_QUERY,
|
|
|
|
|
|
cmd_buffer, -1);
|
|
|
|
|
|
v3dv_return_if_oom(cmd_buffer, NULL);
|
|
|
|
|
|
|
|
|
|
|
|
job->cpu.query_timestamp.pool = query_pool;
|
|
|
|
|
|
job->cpu.query_timestamp.query = query;
|
|
|
|
|
|
|
2021-07-23 14:49:05 +02:00
|
|
|
|
if (!pass || !pass->multiview_enabled) {
|
|
|
|
|
|
job->cpu.query_timestamp.count = 1;
|
|
|
|
|
|
} else {
|
|
|
|
|
|
struct v3dv_subpass *subpass =
|
|
|
|
|
|
&pass->subpasses[cmd_buffer->state.subpass_idx];
|
|
|
|
|
|
job->cpu.query_timestamp.count = util_bitcount(subpass->view_mask);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2020-10-29 11:55:23 +01:00
|
|
|
|
list_addtail(&job->list_link, &cmd_buffer->jobs);
|
|
|
|
|
|
cmd_buffer->state.job = NULL;
|
|
|
|
|
|
|
|
|
|
|
|
/* ...and resume the subpass after the timestamp */
|
|
|
|
|
|
if (cmd_buffer->state.pass)
|
|
|
|
|
|
v3dv_cmd_buffer_subpass_resume(cmd_buffer, cmd_buffer->state.subpass_idx);
|
2020-06-04 09:03:42 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2020-06-18 13:53:51 +02:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_emit_pre_dispatch(struct v3dv_cmd_buffer *cmd_buffer)
|
|
|
|
|
|
{
|
2021-01-15 23:07:45 +01:00
|
|
|
|
assert(cmd_buffer->state.compute.pipeline);
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
assert(cmd_buffer->state.compute.pipeline->active_stages ==
|
|
|
|
|
|
VK_SHADER_STAGE_COMPUTE_BIT);
|
2020-06-18 13:53:51 +02:00
|
|
|
|
|
2021-04-16 10:14:23 +02:00
|
|
|
|
cmd_buffer->state.dirty &= ~(V3DV_CMD_DIRTY_COMPUTE_PIPELINE |
|
|
|
|
|
|
V3DV_CMD_DIRTY_COMPUTE_DESCRIPTOR_SETS);
|
|
|
|
|
|
cmd_buffer->state.dirty_descriptor_stages &= ~VK_SHADER_STAGE_COMPUTE_BIT;
|
2021-04-16 12:50:00 +02:00
|
|
|
|
cmd_buffer->state.dirty_push_constants_stages &= ~VK_SHADER_STAGE_COMPUTE_BIT;
|
2020-06-18 13:53:51 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
#define V3D_CSD_CFG012_WG_COUNT_SHIFT 16
|
|
|
|
|
|
#define V3D_CSD_CFG012_WG_OFFSET_SHIFT 0
|
|
|
|
|
|
/* Allow this dispatch to start while the last one is still running. */
|
|
|
|
|
|
#define V3D_CSD_CFG3_OVERLAP_WITH_PREV (1 << 26)
|
|
|
|
|
|
/* Maximum supergroup ID. 6 bits. */
|
|
|
|
|
|
#define V3D_CSD_CFG3_MAX_SG_ID_SHIFT 20
|
|
|
|
|
|
/* Batches per supergroup minus 1. 8 bits. */
|
|
|
|
|
|
#define V3D_CSD_CFG3_BATCHES_PER_SG_M1_SHIFT 12
|
|
|
|
|
|
/* Workgroups per supergroup, 0 means 16 */
|
|
|
|
|
|
#define V3D_CSD_CFG3_WGS_PER_SG_SHIFT 8
|
|
|
|
|
|
#define V3D_CSD_CFG3_WG_SIZE_SHIFT 0
|
|
|
|
|
|
|
|
|
|
|
|
#define V3D_CSD_CFG5_PROPAGATE_NANS (1 << 2)
|
|
|
|
|
|
#define V3D_CSD_CFG5_SINGLE_SEG (1 << 1)
|
|
|
|
|
|
#define V3D_CSD_CFG5_THREADING (1 << 0)
|
|
|
|
|
|
|
2020-06-19 11:56:20 +02:00
|
|
|
|
void
|
|
|
|
|
|
v3dv_cmd_buffer_rewrite_indirect_csd_job(
|
|
|
|
|
|
struct v3dv_csd_indirect_cpu_job_info *info,
|
|
|
|
|
|
const uint32_t *wg_counts)
|
2020-06-18 13:53:51 +02:00
|
|
|
|
{
|
2020-06-19 11:56:20 +02:00
|
|
|
|
assert(info->csd_job);
|
|
|
|
|
|
struct v3dv_job *job = info->csd_job;
|
2020-06-18 13:53:51 +02:00
|
|
|
|
|
2020-06-19 11:56:20 +02:00
|
|
|
|
assert(job->type == V3DV_JOB_TYPE_GPU_CSD);
|
|
|
|
|
|
assert(wg_counts[0] > 0 && wg_counts[1] > 0 && wg_counts[2] > 0);
|
2020-06-18 13:53:51 +02:00
|
|
|
|
|
|
|
|
|
|
struct drm_v3d_submit_csd *submit = &job->csd.submit;
|
|
|
|
|
|
|
2020-06-19 11:56:20 +02:00
|
|
|
|
job->csd.wg_count[0] = wg_counts[0];
|
|
|
|
|
|
job->csd.wg_count[1] = wg_counts[1];
|
|
|
|
|
|
job->csd.wg_count[2] = wg_counts[2];
|
|
|
|
|
|
|
|
|
|
|
|
submit->cfg[0] = wg_counts[0] << V3D_CSD_CFG012_WG_COUNT_SHIFT;
|
|
|
|
|
|
submit->cfg[1] = wg_counts[1] << V3D_CSD_CFG012_WG_COUNT_SHIFT;
|
|
|
|
|
|
submit->cfg[2] = wg_counts[2] << V3D_CSD_CFG012_WG_COUNT_SHIFT;
|
|
|
|
|
|
|
|
|
|
|
|
submit->cfg[4] = DIV_ROUND_UP(info->wg_size, 16) *
|
|
|
|
|
|
(wg_counts[0] * wg_counts[1] * wg_counts[2]) - 1;
|
|
|
|
|
|
assert(submit->cfg[4] != ~0);
|
|
|
|
|
|
|
|
|
|
|
|
if (info->needs_wg_uniform_rewrite) {
|
|
|
|
|
|
/* Make sure the GPU is not currently accessing the indirect CL for this
|
|
|
|
|
|
* job, since we are about to overwrite some of the uniform data.
|
|
|
|
|
|
*/
|
2021-01-19 08:24:04 +01:00
|
|
|
|
v3dv_bo_wait(job->device, job->indirect.bo, PIPE_TIMEOUT_INFINITE);
|
2020-06-19 11:56:20 +02:00
|
|
|
|
|
|
|
|
|
|
for (uint32_t i = 0; i < 3; i++) {
|
|
|
|
|
|
if (info->wg_uniform_offsets[i]) {
|
|
|
|
|
|
/* Sanity check that our uniform pointers are within the allocated
|
|
|
|
|
|
* BO space for our indirect CL.
|
|
|
|
|
|
*/
|
|
|
|
|
|
assert(info->wg_uniform_offsets[i] >= (uint32_t *) job->indirect.base);
|
|
|
|
|
|
assert(info->wg_uniform_offsets[i] < (uint32_t *) job->indirect.next);
|
|
|
|
|
|
*(info->wg_uniform_offsets[i]) = wg_counts[i];
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static struct v3dv_job *
|
|
|
|
|
|
cmd_buffer_create_csd_job(struct v3dv_cmd_buffer *cmd_buffer,
|
2021-05-27 09:06:00 +02:00
|
|
|
|
uint32_t base_offset_x,
|
|
|
|
|
|
uint32_t base_offset_y,
|
|
|
|
|
|
uint32_t base_offset_z,
|
2020-06-19 11:56:20 +02:00
|
|
|
|
uint32_t group_count_x,
|
|
|
|
|
|
uint32_t group_count_y,
|
|
|
|
|
|
uint32_t group_count_z,
|
|
|
|
|
|
uint32_t **wg_uniform_offsets_out,
|
|
|
|
|
|
uint32_t *wg_size_out)
|
|
|
|
|
|
{
|
2021-01-15 23:07:45 +01:00
|
|
|
|
struct v3dv_pipeline *pipeline = cmd_buffer->state.compute.pipeline;
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
assert(pipeline && pipeline->shared_data->variants[BROADCOM_SHADER_COMPUTE]);
|
|
|
|
|
|
struct v3dv_shader_variant *cs_variant =
|
|
|
|
|
|
pipeline->shared_data->variants[BROADCOM_SHADER_COMPUTE];
|
2020-06-19 11:56:20 +02:00
|
|
|
|
|
2020-11-12 16:30:41 +01:00
|
|
|
|
struct v3dv_job *job = vk_zalloc(&cmd_buffer->device->vk.alloc,
|
2020-06-19 11:56:20 +02:00
|
|
|
|
sizeof(struct v3dv_job), 8,
|
|
|
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
|
|
|
|
|
|
if (!job) {
|
|
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
|
|
|
|
|
return NULL;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
v3dv_job_init(job, V3DV_JOB_TYPE_GPU_CSD, cmd_buffer->device, cmd_buffer, -1);
|
|
|
|
|
|
cmd_buffer->state.job = job;
|
|
|
|
|
|
|
|
|
|
|
|
struct drm_v3d_submit_csd *submit = &job->csd.submit;
|
|
|
|
|
|
|
|
|
|
|
|
job->csd.wg_count[0] = group_count_x;
|
|
|
|
|
|
job->csd.wg_count[1] = group_count_y;
|
|
|
|
|
|
job->csd.wg_count[2] = group_count_z;
|
2020-06-18 13:53:51 +02:00
|
|
|
|
|
2021-05-27 09:06:00 +02:00
|
|
|
|
job->csd.wg_base[0] = base_offset_x;
|
|
|
|
|
|
job->csd.wg_base[1] = base_offset_y;
|
|
|
|
|
|
job->csd.wg_base[2] = base_offset_z;
|
|
|
|
|
|
|
2020-06-18 13:53:51 +02:00
|
|
|
|
submit->cfg[0] |= group_count_x << V3D_CSD_CFG012_WG_COUNT_SHIFT;
|
|
|
|
|
|
submit->cfg[1] |= group_count_y << V3D_CSD_CFG012_WG_COUNT_SHIFT;
|
|
|
|
|
|
submit->cfg[2] |= group_count_z << V3D_CSD_CFG012_WG_COUNT_SHIFT;
|
|
|
|
|
|
|
2021-02-27 00:35:54 +01:00
|
|
|
|
const struct v3d_compute_prog_data *cpd =
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
cs_variant->prog_data.cs;
|
2020-06-18 13:53:51 +02:00
|
|
|
|
|
2021-04-28 11:09:04 +02:00
|
|
|
|
const uint32_t num_wgs = group_count_x * group_count_y * group_count_z;
|
2021-02-27 00:35:54 +01:00
|
|
|
|
const uint32_t wg_size = cpd->local_size[0] *
|
|
|
|
|
|
cpd->local_size[1] *
|
|
|
|
|
|
cpd->local_size[2];
|
2021-04-28 11:09:04 +02:00
|
|
|
|
|
2021-04-28 14:48:13 +02:00
|
|
|
|
uint32_t wgs_per_sg =
|
2021-04-29 09:23:28 +02:00
|
|
|
|
v3d_csd_choose_workgroups_per_supergroup(
|
|
|
|
|
|
&cmd_buffer->device->devinfo,
|
2021-06-22 12:34:02 +02:00
|
|
|
|
cs_variant->prog_data.cs->has_subgroups,
|
2021-04-29 09:23:28 +02:00
|
|
|
|
cs_variant->prog_data.cs->base.has_control_barrier,
|
|
|
|
|
|
cs_variant->prog_data.cs->base.threads,
|
|
|
|
|
|
num_wgs, wg_size);
|
|
|
|
|
|
|
2021-04-28 11:09:04 +02:00
|
|
|
|
uint32_t batches_per_sg = DIV_ROUND_UP(wgs_per_sg * wg_size, 16);
|
|
|
|
|
|
uint32_t whole_sgs = num_wgs / wgs_per_sg;
|
|
|
|
|
|
uint32_t rem_wgs = num_wgs - whole_sgs * wgs_per_sg;
|
|
|
|
|
|
uint32_t num_batches = batches_per_sg * whole_sgs +
|
|
|
|
|
|
DIV_ROUND_UP(rem_wgs * wg_size, 16);
|
|
|
|
|
|
|
|
|
|
|
|
submit->cfg[3] |= (wgs_per_sg & 0xf) << V3D_CSD_CFG3_WGS_PER_SG_SHIFT;
|
|
|
|
|
|
submit->cfg[3] |= (batches_per_sg - 1) << V3D_CSD_CFG3_BATCHES_PER_SG_M1_SHIFT;
|
2020-06-18 13:53:51 +02:00
|
|
|
|
submit->cfg[3] |= (wg_size & 0xff) << V3D_CSD_CFG3_WG_SIZE_SHIFT;
|
2020-06-19 11:56:20 +02:00
|
|
|
|
if (wg_size_out)
|
|
|
|
|
|
*wg_size_out = wg_size;
|
2020-06-18 13:53:51 +02:00
|
|
|
|
|
2021-04-28 11:09:04 +02:00
|
|
|
|
submit->cfg[4] = num_batches - 1;
|
2020-06-18 13:53:51 +02:00
|
|
|
|
assert(submit->cfg[4] != ~0);
|
|
|
|
|
|
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
assert(pipeline->shared_data->assembly_bo);
|
|
|
|
|
|
struct v3dv_bo *cs_assembly_bo = pipeline->shared_data->assembly_bo;
|
|
|
|
|
|
|
|
|
|
|
|
submit->cfg[5] = cs_assembly_bo->offset + cs_variant->assembly_offset;
|
2020-06-18 13:53:51 +02:00
|
|
|
|
submit->cfg[5] |= V3D_CSD_CFG5_PROPAGATE_NANS;
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
if (cs_variant->prog_data.base->single_seg)
|
2020-06-18 13:53:51 +02:00
|
|
|
|
submit->cfg[5] |= V3D_CSD_CFG5_SINGLE_SEG;
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
if (cs_variant->prog_data.base->threads == 4)
|
2020-06-18 13:53:51 +02:00
|
|
|
|
submit->cfg[5] |= V3D_CSD_CFG5_THREADING;
|
|
|
|
|
|
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
if (cs_variant->prog_data.cs->shared_size > 0) {
|
2020-06-18 13:53:51 +02:00
|
|
|
|
job->csd.shared_memory =
|
|
|
|
|
|
v3dv_bo_alloc(cmd_buffer->device,
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
cs_variant->prog_data.cs->shared_size * wgs_per_sg,
|
2020-06-18 13:53:51 +02:00
|
|
|
|
"shared_vars", true);
|
2020-06-19 11:56:20 +02:00
|
|
|
|
if (!job->csd.shared_memory) {
|
|
|
|
|
|
v3dv_flag_oom(cmd_buffer, NULL);
|
|
|
|
|
|
return job;
|
|
|
|
|
|
}
|
2020-06-18 13:53:51 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-04-13 12:21:08 +02:00
|
|
|
|
v3dv_job_add_bo_unchecked(job, cs_assembly_bo);
|
2020-06-18 13:53:51 +02:00
|
|
|
|
struct v3dv_cl_reloc uniforms =
|
v3dv/pipeline: try to get the shader variant directly from the cache
Until now we were always doing a two-step cache lookup, as we were
using the NIR shaders to fill up the key to lookup for the compiled
shaders. But since we were already generating the sha1 key with the
original SPIR-V shader (or its internal NIR representation) any info
we were collecting from from NIR is already implicit in the original
shader, so we can avoid using the NIR in most cases.
Because the v3d_key that is used to compile a shader is populated with
data coming directly from the NIR shader or produced during NIR
lowerings, we can't use it directly as part of the pipeline cache
entry. We could split them, but that would be confusing, so we add a
new struct, v3dv_pipeline_key used specifically to search for the
compiled shaders on the pipeline cache. v3d_key would be still used to
compile the shaders.
As we are using the same sha1 key for all compiled shaders in a
pipeline, we can also group all of them in the same cache entry, so we
don't need a lookup for each stage. This also allows to cache pipeline
data shared by all the stages (like the descriptor maps).
While we are here, we also create a single BO to store the assembly
for all the pipeline stages.
Finally, we remove the link to the variant on the pipeline stage
struct, to avoid the confusion of having two links to the same
data. This mostly means that we stop to use the pipeline stage
structures after the pipeline is created, so we can freed them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9403>
2021-02-27 01:05:54 +01:00
|
|
|
|
v3dv_write_uniforms_wg_offsets(cmd_buffer, pipeline,
|
|
|
|
|
|
cs_variant,
|
2020-06-19 11:56:20 +02:00
|
|
|
|
wg_uniform_offsets_out);
|
2020-06-18 13:53:51 +02:00
|
|
|
|
submit->cfg[6] = uniforms.bo->offset + uniforms.offset;
|
|
|
|
|
|
|
|
|
|
|
|
v3dv_job_add_bo(job, uniforms.bo);
|
|
|
|
|
|
|
2020-06-19 11:56:20 +02:00
|
|
|
|
return job;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_dispatch(struct v3dv_cmd_buffer *cmd_buffer,
|
2021-05-27 09:06:00 +02:00
|
|
|
|
uint32_t base_offset_x,
|
|
|
|
|
|
uint32_t base_offset_y,
|
|
|
|
|
|
uint32_t base_offset_z,
|
2020-06-19 11:56:20 +02:00
|
|
|
|
uint32_t group_count_x,
|
|
|
|
|
|
uint32_t group_count_y,
|
|
|
|
|
|
uint32_t group_count_z)
|
|
|
|
|
|
{
|
|
|
|
|
|
if (group_count_x == 0 || group_count_y == 0 || group_count_z == 0)
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
|
|
struct v3dv_job *job =
|
|
|
|
|
|
cmd_buffer_create_csd_job(cmd_buffer,
|
2021-05-27 09:06:00 +02:00
|
|
|
|
base_offset_x,
|
|
|
|
|
|
base_offset_y,
|
|
|
|
|
|
base_offset_z,
|
2020-06-19 11:56:20 +02:00
|
|
|
|
group_count_x,
|
|
|
|
|
|
group_count_y,
|
|
|
|
|
|
group_count_z,
|
|
|
|
|
|
NULL, NULL);
|
|
|
|
|
|
|
2020-06-18 13:53:51 +02:00
|
|
|
|
list_addtail(&job->list_link, &cmd_buffer->jobs);
|
|
|
|
|
|
cmd_buffer->state.job = NULL;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-06-04 09:03:42 +02:00
|
|
|
|
v3dv_CmdDispatch(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
uint32_t groupCountX,
|
|
|
|
|
|
uint32_t groupCountY,
|
|
|
|
|
|
uint32_t groupCountZ)
|
|
|
|
|
|
{
|
2020-06-18 13:53:51 +02:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer_emit_pre_dispatch(cmd_buffer);
|
2021-05-27 09:06:00 +02:00
|
|
|
|
cmd_buffer_dispatch(cmd_buffer, 0, 0, 0,
|
|
|
|
|
|
groupCountX, groupCountY, groupCountZ);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
|
|
|
|
|
v3dv_CmdDispatchBase(VkCommandBuffer commandBuffer,
|
|
|
|
|
|
uint32_t baseGroupX,
|
|
|
|
|
|
uint32_t baseGroupY,
|
|
|
|
|
|
uint32_t baseGroupZ,
|
|
|
|
|
|
uint32_t groupCountX,
|
|
|
|
|
|
uint32_t groupCountY,
|
|
|
|
|
|
uint32_t groupCountZ)
|
2021-05-27 09:06:00 +02:00
|
|
|
|
{
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer_emit_pre_dispatch(cmd_buffer);
|
|
|
|
|
|
cmd_buffer_dispatch(cmd_buffer,
|
|
|
|
|
|
baseGroupX, baseGroupY, baseGroupZ,
|
|
|
|
|
|
groupCountX, groupCountY, groupCountZ);
|
2020-06-04 09:03:42 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-27 09:06:00 +02:00
|
|
|
|
|
2020-06-19 11:56:20 +02:00
|
|
|
|
static void
|
|
|
|
|
|
cmd_buffer_dispatch_indirect(struct v3dv_cmd_buffer *cmd_buffer,
|
|
|
|
|
|
struct v3dv_buffer *buffer,
|
|
|
|
|
|
uint32_t offset)
|
|
|
|
|
|
{
|
|
|
|
|
|
/* We can't do indirect dispatches, so instead we record a CPU job that,
|
|
|
|
|
|
* when executed in the queue, will map the indirect buffer, read the
|
|
|
|
|
|
* dispatch parameters, and submit a regular dispatch.
|
|
|
|
|
|
*/
|
|
|
|
|
|
struct v3dv_job *job =
|
|
|
|
|
|
v3dv_cmd_buffer_create_cpu_job(cmd_buffer->device,
|
|
|
|
|
|
V3DV_JOB_TYPE_CPU_CSD_INDIRECT,
|
|
|
|
|
|
cmd_buffer, -1);
|
|
|
|
|
|
v3dv_return_if_oom(cmd_buffer, NULL);
|
|
|
|
|
|
|
|
|
|
|
|
/* We need to create a CSD job now, even if we still don't know the actual
|
|
|
|
|
|
* dispatch parameters, because the job setup needs to be done using the
|
|
|
|
|
|
* current command buffer state (i.e. pipeline, descriptor sets, push
|
|
|
|
|
|
* constants, etc.). So we create the job with default dispatch parameters
|
|
|
|
|
|
* and we will rewrite the parts we need at submit time if the indirect
|
|
|
|
|
|
* parameters don't match the ones we used to setup the job.
|
|
|
|
|
|
*/
|
|
|
|
|
|
struct v3dv_job *csd_job =
|
|
|
|
|
|
cmd_buffer_create_csd_job(cmd_buffer,
|
2021-05-27 09:06:00 +02:00
|
|
|
|
0, 0, 0,
|
2020-06-19 11:56:20 +02:00
|
|
|
|
1, 1, 1,
|
|
|
|
|
|
&job->cpu.csd_indirect.wg_uniform_offsets[0],
|
|
|
|
|
|
&job->cpu.csd_indirect.wg_size);
|
|
|
|
|
|
v3dv_return_if_oom(cmd_buffer, NULL);
|
|
|
|
|
|
assert(csd_job);
|
|
|
|
|
|
|
|
|
|
|
|
job->cpu.csd_indirect.buffer = buffer;
|
|
|
|
|
|
job->cpu.csd_indirect.offset = offset;
|
|
|
|
|
|
job->cpu.csd_indirect.csd_job = csd_job;
|
|
|
|
|
|
|
|
|
|
|
|
/* If the compute shader reads the workgroup sizes we will also need to
|
|
|
|
|
|
* rewrite the corresponding uniforms.
|
|
|
|
|
|
*/
|
|
|
|
|
|
job->cpu.csd_indirect.needs_wg_uniform_rewrite =
|
|
|
|
|
|
job->cpu.csd_indirect.wg_uniform_offsets[0] ||
|
|
|
|
|
|
job->cpu.csd_indirect.wg_uniform_offsets[1] ||
|
|
|
|
|
|
job->cpu.csd_indirect.wg_uniform_offsets[2];
|
|
|
|
|
|
|
|
|
|
|
|
list_addtail(&job->list_link, &cmd_buffer->jobs);
|
2022-04-01 16:10:12 -05:00
|
|
|
|
list_addtail(&csd_job->list_link, &cmd_buffer->jobs);
|
2020-06-19 11:56:20 +02:00
|
|
|
|
cmd_buffer->state.job = NULL;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2020-06-04 09:03:42 +02:00
|
|
|
|
v3dv_CmdDispatchIndirect(VkCommandBuffer commandBuffer,
|
2020-06-19 11:56:20 +02:00
|
|
|
|
VkBuffer _buffer,
|
2020-06-04 09:03:42 +02:00
|
|
|
|
VkDeviceSize offset)
|
|
|
|
|
|
{
|
2020-06-19 11:56:20 +02:00
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_buffer, buffer, _buffer);
|
|
|
|
|
|
|
|
|
|
|
|
assert(offset <= UINT32_MAX);
|
|
|
|
|
|
|
|
|
|
|
|
cmd_buffer_emit_pre_dispatch(cmd_buffer);
|
|
|
|
|
|
cmd_buffer_dispatch_indirect(cmd_buffer, buffer, offset);
|
2020-06-04 09:03:42 +02:00
|
|
|
|
}
|
2021-05-27 09:16:18 +02:00
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
2021-05-27 09:16:18 +02:00
|
|
|
|
v3dv_CmdSetDeviceMask(VkCommandBuffer commandBuffer, uint32_t deviceMask)
|
|
|
|
|
|
{
|
|
|
|
|
|
/* Nothing to do here since we only support a single device */
|
2021-06-05 00:02:45 -07:00
|
|
|
|
assert(deviceMask == 0x1);
|
2021-05-27 09:16:18 +02:00
|
|
|
|
}
|