Limit number of concurrent query pools
authorRicardo Garcia <rgarcia@igalia.com>
Tue, 15 Nov 2022 15:07:16 +0000 (16:07 +0100)
committerRicardo Garcia <rgarcia@igalia.com>
Tue, 15 Nov 2022 15:07:16 +0000 (16:07 +0100)
commit9139323eb79a219439bc761ab387d7855b57a84b
tree60f7b002d976e8a6248c1b95cf7ce71e0048b59e
parent67f3bf68a9cb813b15b82be21f45b910352b7dd6
Limit number of concurrent query pools

The max concurrency tests use a heuristic to try to estimate a safe
number of objects of different types that the implementation would be
able to create, with an upper limit of 16384 objects.

However, in some implementations the creation of these objects have
external limitations that make the safe value hard to guess by only
looking at system and device memory usage. For example, the kernel
driver may impose further limits on the total number of certain objects.

This is reflected in the current tests with some lower hardcoded limits
for some types of objects, like instances, devices, synchronization
primitives and pipeline caches.

This commit halves the limit of concurrent query pools being tested to a
value that doesn't trigger any issue in the Mesa RPi drivers.

Affects:
dEQP-VK.api.object_management.max_concurrent.query_pool

VK-GL-CTS issue: 4106
Components: Vulkan

Change-Id: If88c6aa1ecd3d9c18892b38cb55907a82eee6cf8
external/vulkancts/modules/vulkan/api/vktApiObjectManagementTests.cpp