v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
/*
|
2022-02-17 12:38:42 +01:00
|
|
|
* Copyright © 2020 Raspberry Pi Ltd
|
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
|
|
|
*
|
|
|
|
|
* 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"
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
VKAPI_ATTR VkResult VKAPI_CALL
|
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_CreateQueryPool(VkDevice _device,
|
|
|
|
|
const VkQueryPoolCreateInfo *pCreateInfo,
|
|
|
|
|
const VkAllocationCallbacks *pAllocator,
|
|
|
|
|
VkQueryPool *pQueryPool)
|
|
|
|
|
{
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_device, device, _device);
|
|
|
|
|
|
2020-10-29 11:55:23 +01:00
|
|
|
assert(pCreateInfo->queryType == VK_QUERY_TYPE_OCCLUSION ||
|
|
|
|
|
pCreateInfo->queryType == VK_QUERY_TYPE_TIMESTAMP);
|
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(pCreateInfo->queryCount > 0);
|
|
|
|
|
|
|
|
|
|
struct v3dv_query_pool *pool =
|
2020-11-12 16:30:41 +01:00
|
|
|
vk_object_zalloc(&device->vk, pAllocator, sizeof(*pool),
|
|
|
|
|
VK_OBJECT_TYPE_QUERY_POOL);
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
if (pool == NULL)
|
2021-09-24 15:31:03 -05:00
|
|
|
return vk_error(device, VK_ERROR_OUT_OF_HOST_MEMORY);
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
|
2020-10-29 11:55:23 +01:00
|
|
|
pool->query_type = pCreateInfo->queryType;
|
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
|
|
|
pool->query_count = pCreateInfo->queryCount;
|
|
|
|
|
|
|
|
|
|
VkResult result;
|
|
|
|
|
|
|
|
|
|
const uint32_t pool_bytes = sizeof(struct v3dv_query) * pool->query_count;
|
2020-11-12 16:30:41 +01:00
|
|
|
pool->queries = vk_alloc2(&device->vk.alloc, pAllocator, pool_bytes, 8,
|
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
|
|
|
VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
|
|
|
|
|
if (pool->queries == NULL) {
|
2021-09-24 15:31:03 -05:00
|
|
|
result = vk_error(device, VK_ERROR_OUT_OF_HOST_MEMORY);
|
2021-04-14 13:34:00 +02:00
|
|
|
goto fail;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (pool->query_type == VK_QUERY_TYPE_OCCLUSION) {
|
|
|
|
|
/* The hardware allows us to setup groups of 16 queries in consecutive
|
|
|
|
|
* 4-byte addresses, requiring only that each group of 16 queries is
|
|
|
|
|
* aligned to a 1024 byte boundary.
|
|
|
|
|
*/
|
|
|
|
|
const uint32_t query_groups = DIV_ROUND_UP(pool->query_count, 16);
|
|
|
|
|
const uint32_t bo_size = query_groups * 1024;
|
|
|
|
|
pool->bo = v3dv_bo_alloc(device, bo_size, "query", true);
|
|
|
|
|
if (!pool->bo) {
|
2021-09-24 15:31:03 -05:00
|
|
|
result = vk_error(device, VK_ERROR_OUT_OF_DEVICE_MEMORY);
|
2021-04-14 13:34:00 +02:00
|
|
|
goto fail;
|
|
|
|
|
}
|
|
|
|
|
if (!v3dv_bo_map(device, pool->bo, bo_size)) {
|
2021-09-24 15:31:03 -05:00
|
|
|
result = vk_error(device, VK_ERROR_OUT_OF_DEVICE_MEMORY);
|
2021-04-14 13:34:00 +02:00
|
|
|
goto fail;
|
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
uint32_t i;
|
|
|
|
|
for (i = 0; i < pool->query_count; i++) {
|
|
|
|
|
pool->queries[i].maybe_available = false;
|
2020-10-29 11:55:23 +01:00
|
|
|
switch (pool->query_type) {
|
2021-04-14 13:34:00 +02:00
|
|
|
case VK_QUERY_TYPE_OCCLUSION: {
|
|
|
|
|
const uint32_t query_group = i / 16;
|
|
|
|
|
const uint32_t query_offset = query_group * 1024 + (i % 16) * 4;
|
|
|
|
|
pool->queries[i].bo = pool->bo;
|
|
|
|
|
pool->queries[i].offset = query_offset;
|
2020-10-29 11:55:23 +01:00
|
|
|
break;
|
2021-04-14 13:34:00 +02:00
|
|
|
}
|
2020-10-29 11:55:23 +01:00
|
|
|
case VK_QUERY_TYPE_TIMESTAMP:
|
|
|
|
|
pool->queries[i].value = 0;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
unreachable("Unsupported query type");
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
*pQueryPool = v3dv_query_pool_to_handle(pool);
|
|
|
|
|
|
|
|
|
|
return VK_SUCCESS;
|
|
|
|
|
|
2021-04-14 13:34:00 +02:00
|
|
|
fail:
|
|
|
|
|
if (pool->bo)
|
|
|
|
|
v3dv_bo_free(device, pool->bo);
|
|
|
|
|
if (pool->queries)
|
|
|
|
|
vk_free2(&device->vk.alloc, pAllocator, pool->queries);
|
2020-11-12 16:30:41 +01:00
|
|
|
vk_object_free(&device->vk, pAllocator, pool);
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
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_DestroyQueryPool(VkDevice _device,
|
|
|
|
|
VkQueryPool queryPool,
|
|
|
|
|
const VkAllocationCallbacks *pAllocator)
|
|
|
|
|
{
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_device, device, _device);
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_query_pool, pool, queryPool);
|
|
|
|
|
|
|
|
|
|
if (!pool)
|
|
|
|
|
return;
|
|
|
|
|
|
2021-04-14 13:34:00 +02:00
|
|
|
if (pool->bo)
|
|
|
|
|
v3dv_bo_free(device, pool->bo);
|
|
|
|
|
|
|
|
|
|
if (pool->queries)
|
|
|
|
|
vk_free2(&device->vk.alloc, pAllocator, pool->queries);
|
2020-10-29 11:55:23 +01:00
|
|
|
|
2020-11-12 16:30:41 +01:00
|
|
|
vk_object_free(&device->vk, pAllocator, pool);
|
v3dv: implement occlusion queries
The design for queries in Vulkan requires that some commands execute
in the GPU as part of a command buffer. Unfortunately, V3D doesn't
really have supprt for this, which means that we need to execute them
in the CPU but we still need to make it look as if they happened
inside the comamnd buffer from the point of view of the user, which
adds certain hassle.
The above means that in some cases we need to do CPU waits for certain
parts of the command buffer to execute so we can then run the CPU
code. For exmaple, we need to wait before executing a query resets
just in case the GPU is using them, and we have to do a CPU wait wait
for previous GPU jobs to complete before copying query results if the
user has asked us to do that. In the future, we may want to have
submission thread instead so we don't block the main thread in these
scenarios.
Because we now need to execute some tasks in the CPU as part of a
command buffer, this introduces the concept of job types, there is one
type for all GPU jobs, and then we have one type for each kind of job
that needs to execute in the CPU. CPU jobs are executed by the queue
in order just like GPU jobs, only that they are exclusively CPU tasks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
2020-04-16 10:30:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2020-10-29 11:55:23 +01:00
|
|
|
write_query_result(void *dst, uint32_t idx, bool do_64bit, uint64_t value)
|
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 (do_64bit) {
|
|
|
|
|
uint64_t *dst64 = (uint64_t *) dst;
|
|
|
|
|
dst64[idx] = value;
|
|
|
|
|
} else {
|
|
|
|
|
uint32_t *dst32 = (uint32_t *) dst;
|
2020-10-29 11:55:23 +01:00
|
|
|
dst32[idx] = (uint32_t) value;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-23 13:45:54 +02:00
|
|
|
static VkResult
|
2020-10-29 11:55:23 +01:00
|
|
|
get_occlusion_query_result(struct v3dv_device *device,
|
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
|
uint32_t query,
|
|
|
|
|
bool do_wait,
|
2021-07-23 13:45:54 +02:00
|
|
|
bool *available,
|
|
|
|
|
uint64_t *value)
|
2020-10-29 11:55:23 +01:00
|
|
|
{
|
|
|
|
|
assert(pool && pool->query_type == VK_QUERY_TYPE_OCCLUSION);
|
|
|
|
|
|
|
|
|
|
struct v3dv_query *q = &pool->queries[query];
|
|
|
|
|
assert(q->bo && q->bo->map);
|
|
|
|
|
|
|
|
|
|
if (do_wait) {
|
|
|
|
|
/* From the Vulkan 1.0 spec:
|
|
|
|
|
*
|
|
|
|
|
* "If VK_QUERY_RESULT_WAIT_BIT is set, (...) If the query does not
|
|
|
|
|
* become available in a finite amount of time (e.g. due to not
|
|
|
|
|
* issuing a query since the last reset), a VK_ERROR_DEVICE_LOST
|
|
|
|
|
* error may occur."
|
|
|
|
|
*/
|
|
|
|
|
if (!q->maybe_available)
|
2021-09-24 15:31:03 -05:00
|
|
|
return vk_error(device, VK_ERROR_DEVICE_LOST);
|
2020-10-29 11:55:23 +01:00
|
|
|
|
|
|
|
|
if (!v3dv_bo_wait(device, q->bo, 0xffffffffffffffffull))
|
2021-09-24 15:31:03 -05:00
|
|
|
return vk_error(device, VK_ERROR_DEVICE_LOST);
|
2020-10-29 11:55:23 +01:00
|
|
|
|
|
|
|
|
*available = true;
|
|
|
|
|
} else {
|
|
|
|
|
*available = q->maybe_available && v3dv_bo_wait(device, q->bo, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-14 13:34:00 +02:00
|
|
|
const uint8_t *query_addr = ((uint8_t *) q->bo->map) + q->offset;
|
2021-07-23 13:45:54 +02:00
|
|
|
*value = (uint64_t) *((uint32_t *)query_addr);
|
|
|
|
|
return VK_SUCCESS;
|
2020-10-29 11:55:23 +01:00
|
|
|
}
|
|
|
|
|
|
2021-07-23 13:45:54 +02:00
|
|
|
static VkResult
|
2020-10-29 11:55:23 +01:00
|
|
|
get_timestamp_query_result(struct v3dv_device *device,
|
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
|
uint32_t query,
|
|
|
|
|
bool do_wait,
|
2021-07-23 13:45:54 +02:00
|
|
|
bool *available,
|
|
|
|
|
uint64_t *value)
|
2020-10-29 11:55:23 +01:00
|
|
|
{
|
|
|
|
|
assert(pool && pool->query_type == VK_QUERY_TYPE_TIMESTAMP);
|
|
|
|
|
|
|
|
|
|
struct v3dv_query *q = &pool->queries[query];
|
|
|
|
|
|
|
|
|
|
if (do_wait) {
|
|
|
|
|
/* From the Vulkan 1.0 spec:
|
|
|
|
|
*
|
|
|
|
|
* "If VK_QUERY_RESULT_WAIT_BIT is set, (...) If the query does not
|
|
|
|
|
* become available in a finite amount of time (e.g. due to not
|
|
|
|
|
* issuing a query since the last reset), a VK_ERROR_DEVICE_LOST
|
|
|
|
|
* error may occur."
|
|
|
|
|
*/
|
|
|
|
|
if (!q->maybe_available)
|
2021-09-24 15:31:03 -05:00
|
|
|
return vk_error(device, VK_ERROR_DEVICE_LOST);
|
2020-10-29 11:55:23 +01:00
|
|
|
|
|
|
|
|
*available = true;
|
|
|
|
|
} else {
|
|
|
|
|
*available = q->maybe_available;
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-23 13:45:54 +02:00
|
|
|
*value = q->value;
|
|
|
|
|
return VK_SUCCESS;
|
2020-10-29 11:55:23 +01:00
|
|
|
}
|
|
|
|
|
|
2021-07-23 13:45:54 +02:00
|
|
|
static VkResult
|
2020-10-29 11:55:23 +01:00
|
|
|
get_query_result(struct v3dv_device *device,
|
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
|
uint32_t query,
|
|
|
|
|
bool do_wait,
|
2021-07-23 13:45:54 +02:00
|
|
|
bool *available,
|
|
|
|
|
uint64_t *value)
|
2020-10-29 11:55:23 +01:00
|
|
|
{
|
|
|
|
|
switch (pool->query_type) {
|
|
|
|
|
case VK_QUERY_TYPE_OCCLUSION:
|
2021-07-23 13:45:54 +02:00
|
|
|
return get_occlusion_query_result(device, pool, query, do_wait,
|
|
|
|
|
available, value);
|
2020-10-29 11:55:23 +01:00
|
|
|
case VK_QUERY_TYPE_TIMESTAMP:
|
2021-07-23 13:45:54 +02:00
|
|
|
return get_timestamp_query_result(device, pool, query, do_wait,
|
|
|
|
|
available, value);
|
2020-10-29 11:55:23 +01:00
|
|
|
default:
|
|
|
|
|
unreachable("Unsupported query type");
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
VkResult
|
|
|
|
|
v3dv_get_query_pool_results_cpu(struct v3dv_device *device,
|
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
|
uint32_t first,
|
|
|
|
|
uint32_t count,
|
|
|
|
|
void *data,
|
|
|
|
|
VkDeviceSize stride,
|
|
|
|
|
VkQueryResultFlags flags)
|
|
|
|
|
{
|
|
|
|
|
assert(first < pool->query_count);
|
|
|
|
|
assert(first + count <= pool->query_count);
|
|
|
|
|
assert(data);
|
|
|
|
|
|
|
|
|
|
const bool do_64bit = flags & VK_QUERY_RESULT_64_BIT;
|
|
|
|
|
const bool do_wait = flags & VK_QUERY_RESULT_WAIT_BIT;
|
|
|
|
|
const bool do_partial = flags & VK_QUERY_RESULT_PARTIAL_BIT;
|
|
|
|
|
|
|
|
|
|
VkResult result = VK_SUCCESS;
|
|
|
|
|
for (uint32_t i = first; i < first + count; i++) {
|
2021-01-18 18:16:12 -06:00
|
|
|
bool available = false;
|
2021-07-23 13:45:54 +02:00
|
|
|
uint64_t value = 0;
|
|
|
|
|
VkResult query_result =
|
|
|
|
|
get_query_result(device, pool, i, do_wait, &available, &value);
|
|
|
|
|
if (query_result == VK_ERROR_DEVICE_LOST)
|
|
|
|
|
result = VK_ERROR_DEVICE_LOST;
|
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
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* From the Vulkan 1.0 spec:
|
|
|
|
|
*
|
|
|
|
|
* "If VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are
|
|
|
|
|
* both not set then no result values are written to pData for queries
|
|
|
|
|
* that are in the unavailable state at the time of the call, and
|
|
|
|
|
* vkGetQueryPoolResults returns VK_NOT_READY. However, availability
|
|
|
|
|
* state is still written to pData for those queries if
|
|
|
|
|
* VK_QUERY_RESULT_WITH_AVAILABILITY_BIT is set."
|
|
|
|
|
*/
|
|
|
|
|
uint32_t slot = 0;
|
|
|
|
|
|
|
|
|
|
const bool write_result = available || do_partial;
|
|
|
|
|
if (write_result)
|
2020-10-29 11:55:23 +01:00
|
|
|
write_query_result(data, slot, do_64bit, value);
|
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
|
|
|
slot++;
|
|
|
|
|
|
|
|
|
|
if (flags & VK_QUERY_RESULT_WITH_AVAILABILITY_BIT)
|
|
|
|
|
write_query_result(data, slot++, do_64bit, available ? 1u : 0u);
|
|
|
|
|
|
2021-07-23 13:45:54 +02:00
|
|
|
if (!write_result && result != VK_ERROR_DEVICE_LOST)
|
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
|
|
|
result = VK_NOT_READY;
|
|
|
|
|
|
|
|
|
|
data += stride;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
VKAPI_ATTR VkResult VKAPI_CALL
|
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_GetQueryPoolResults(VkDevice _device,
|
|
|
|
|
VkQueryPool queryPool,
|
|
|
|
|
uint32_t firstQuery,
|
|
|
|
|
uint32_t queryCount,
|
|
|
|
|
size_t dataSize,
|
|
|
|
|
void *pData,
|
|
|
|
|
VkDeviceSize stride,
|
|
|
|
|
VkQueryResultFlags flags)
|
|
|
|
|
{
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_device, device, _device);
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_query_pool, pool, queryPool);
|
|
|
|
|
|
|
|
|
|
return v3dv_get_query_pool_results_cpu(device, pool, firstQuery, queryCount,
|
|
|
|
|
pData, stride, flags);
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
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_CmdResetQueryPool(VkCommandBuffer commandBuffer,
|
|
|
|
|
VkQueryPool queryPool,
|
|
|
|
|
uint32_t firstQuery,
|
|
|
|
|
uint32_t queryCount)
|
|
|
|
|
{
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_query_pool, pool, queryPool);
|
|
|
|
|
|
|
|
|
|
v3dv_cmd_buffer_reset_queries(cmd_buffer, pool, firstQuery, queryCount);
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
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_CmdCopyQueryPoolResults(VkCommandBuffer commandBuffer,
|
|
|
|
|
VkQueryPool queryPool,
|
|
|
|
|
uint32_t firstQuery,
|
|
|
|
|
uint32_t queryCount,
|
|
|
|
|
VkBuffer dstBuffer,
|
|
|
|
|
VkDeviceSize dstOffset,
|
|
|
|
|
VkDeviceSize stride,
|
|
|
|
|
VkQueryResultFlags flags)
|
|
|
|
|
{
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_query_pool, pool, queryPool);
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_buffer, dst, dstBuffer);
|
|
|
|
|
|
|
|
|
|
v3dv_cmd_buffer_copy_query_results(cmd_buffer, pool,
|
|
|
|
|
firstQuery, queryCount,
|
|
|
|
|
dst, dstOffset, stride, flags);
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
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_CmdBeginQuery(VkCommandBuffer commandBuffer,
|
|
|
|
|
VkQueryPool queryPool,
|
|
|
|
|
uint32_t query,
|
|
|
|
|
VkQueryControlFlags flags)
|
|
|
|
|
{
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_query_pool, pool, queryPool);
|
|
|
|
|
|
|
|
|
|
v3dv_cmd_buffer_begin_query(cmd_buffer, pool, query, flags);
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-28 14:53:25 +02:00
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
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_CmdEndQuery(VkCommandBuffer commandBuffer,
|
|
|
|
|
VkQueryPool queryPool,
|
|
|
|
|
uint32_t query)
|
|
|
|
|
{
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_cmd_buffer, cmd_buffer, commandBuffer);
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_query_pool, pool, queryPool);
|
|
|
|
|
|
|
|
|
|
v3dv_cmd_buffer_end_query(cmd_buffer, pool, query);
|
|
|
|
|
}
|
2021-10-12 16:58:33 +00:00
|
|
|
|
|
|
|
|
void
|
|
|
|
|
v3dv_reset_query_pools(struct v3dv_device *device,
|
|
|
|
|
struct v3dv_query_pool *pool,
|
|
|
|
|
uint32_t first,
|
|
|
|
|
uint32_t count)
|
|
|
|
|
{
|
|
|
|
|
for (uint32_t i = first; i < first + count; i++) {
|
|
|
|
|
assert(i < pool->query_count);
|
|
|
|
|
struct v3dv_query *q = &pool->queries[i];
|
|
|
|
|
q->maybe_available = false;
|
|
|
|
|
switch (pool->query_type) {
|
|
|
|
|
case VK_QUERY_TYPE_OCCLUSION: {
|
|
|
|
|
const uint8_t *q_addr = ((uint8_t *) q->bo->map) + q->offset;
|
|
|
|
|
uint32_t *counter = (uint32_t *) q_addr;
|
|
|
|
|
*counter = 0;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case VK_QUERY_TYPE_TIMESTAMP:
|
|
|
|
|
q->value = 0;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
unreachable("Unsupported query type");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
VKAPI_ATTR void VKAPI_CALL
|
|
|
|
|
v3dv_ResetQueryPool(VkDevice _device,
|
|
|
|
|
VkQueryPool queryPool,
|
|
|
|
|
uint32_t firstQuery,
|
|
|
|
|
uint32_t queryCount)
|
|
|
|
|
{
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_device, device, _device);
|
|
|
|
|
V3DV_FROM_HANDLE(v3dv_query_pool, pool, queryPool);
|
|
|
|
|
|
|
|
|
|
v3dv_reset_query_pools(device, pool, firstQuery, queryCount);
|
|
|
|
|
}
|